github: make language change proposal triage less confusing to the outside

[zephyrtronium]

Currently, language change proposals created through the corresponding template are given titles starting with "proposal: Go 2:" and assigned LanguageChange and v2 labels. As an outsider to the process, there are a number of reasons this is confusing.

• "Go 2" in other contexts usually refers to changes that cannot be made in a backward compatible manner, requiring a (major) version 2 of Go. However, the Go team has already announced the decision that a version 2 of Go will never exist. And notably, now that math/rand/v2: revised API for math/rand #61716 has opened up the opportunity for v2 standard library packages, it seems like the only truly backward incompatible changes are language changes.
• The LanguageChange and v2 labels have enormous overlap. There are currently eight open issues which are LanguageChange and not v2 (all of which are titled "proposal: spec:" instead of "proposal: Go 2:") and forty-one open issues which are v2 and not LanguageChange (all of which are over three years old), versus eighty-eight which are both. I learned while writing this issue that the v2 label has a description that it includes "incompatible library changes," and indeed most of the non-language-change v2 issues are of that sort, but math/rand/v2: revised API for math/rand #61716 never carried it.
• As mentioned, a different way to create a language change proposal is to say "proposal: spec:". Many of the issues titled this way are also labeled LanguageChange and v2; some are not, which in practice has made it hard for me to find particular proposals when answering questions. (There are also many issues titled like "proposal: Go 2: spec:".)
• proposal: review meeting minutes #33502 and spec: language change review meeting minutes #33892 both sometimes mention issues titled as either "Go 2" or "spec." Some "spec" language changes, e.g. spec: add range over int, range over func #61405 and spec: add clear(x) builtin, to clear map, zero content of slice #56351, never appeared in the latter.

While I recognize that the situation reflects processes of the respective proposal review teams, it is not intuitive and sometimes actively interferes with outside usage. In particular, the question of why backward compatible language change proposals are titled "Go 2" comes up often. (Most recently this occurred in #65652 (comment), but I recall several other instances on the issue tracker, and I've explained it frequently in other channels as well.) It's also worth noting that the document explaining the proposal process doesn't explain what "Go 2" means.

There are a few measures which I suggest to reduce the confusion around language change proposal triage and make searching more consistent:

• Title all language change proposals as "proposal: spec:" and drop the "Go 2" moniker. Then the most common question disappears entirely.
• Label all "proposal: spec:" issues as LanguageChange. Then it's easy to narrow a search to all language change proposals. (Strictly speaking, this isn't necessary if the previous item is implemented, since one could search for "proposal: spec:" in:title, but that phrasing makes it hard to search issue and comment text as well.)
• Apply the v2 label to backward-incompatible changes only. Ostensibly, these should either be for standard library packages – which will actually be v2 – or rejected as infeasible almost immediately. This would likely require manual intervention during triage.

[seankhliao]

cc @golang/proposal-review

[ianlancetaylor]

I agree that the current situation is confusing.

We need a clear way to distinguish major and unusual language change proposals from smaller changes like improvements to generic type inference. We send major changes through a separate proposal process designated by the v2 tag. Notably this includes all changes related to error handling, which is by far the most common kind of language change proposal.

While I agree that something should probably change, I think that we need to keep that distinction.

[ianlancetaylor]

For background, as people who follow these things closely are aware, there are two proposal committees. One is the "ordinary" committee that handles most proposals, tracked in #33502. The other is the "Go 2" committee that handles (most) language changes and incompatible library changes, tracked in #33892. Typically a proposal that seems worthwhile to the second committee is forwarded to the first committee for final review and acceptance. Rejections by the second committee are final.

I don't think there is anything wrong with those processes, but I agree that the labels are confusing.

After discussion, I think a workable approach is to introduce a new Proposal-Major label that we will use for major language changes. Issues with that label will be handled by the Go 2 committee. In general we expect that every issue marked Proposal-Major will have either a LanguageChange label (indicating a language change) or a v2 label (indicating a backward incompatible library change that requires a /v2 version of the package).

If the Go 2 committee passes the proposal to the ordinary committee, the Proposal-Major label will be removed (the LanguageChange or v2 label will remain).

Does anybody see any difficulties with this suggested change? Thanks.

[seankhliao]

Do we then drop the Go 2: convention in the title and switch to spec: for the language changes?

[ianlancetaylor]

Yes.

[ALTree]

introduce a new Proposal-Major label that we will use for major language changes. Issues with that label will be handled by the Go 2 committee. In general we expect that every issue marked Proposal-Major will have either a LanguageChange label (indicating a language change) or a v2 label (indicating a backward incompatible library change that requires a /v2 version of the package).

I would also suggest either removing or renaming the Go2Cleanup label. It looks like most issues with it are just v2 library changes.

[ianlancetaylor]

After further discussion, it seems that most of the proposals handled by the "Go 2" committee are language change proposals. This seems likely to be more true as we now have support for v2 packages in the standard library (with math/rand/v2). Incompatible library changes can now be handled in the "ordinary" proposal committee, as v2 proposals.

Therefore, we can consider the "Go 2" review meeting to be the "language review" meeting. Going forward, language changes will go first to the "language review" meeting and then, if accepted there, go to the ordinary proposal review meeting for final approval.

We already have a LanguageChange label which we will continue to use for issues that are language changes. We can add a new label LanguageChangeReview to indicate that the issue is under the purview of the "language change" meeting. We should add that label to new language change issues. We can remove it if and when a proposal moves to the ordinary committee.

Any thoughts on that approach? Thanks.

[gopherbot]

Change https://go.dev/cl/603401 mentions this issue: HandlingIssues: add notes about proposal process

[ianlancetaylor]

This is now done. Thanks.