proposal: identify large changes & add more process

[rsc]

The proposal process was designed in 2015, when the language was effectively frozen and we were not making large changes. Even now, the vast majority of proposed changes are small. But some are large.

The lightweight process we have works well for small changes, and we wouldn't want to add unnecessary process to those. But if we can reliably identify large changes then we can think about adding extra process for those.

One way to identify large changes is with a simple checklist of how much impact it would have. For example:

• Is the change user-visible at all?
• Does it require any changes to any documentation?
• Are its effects confined to a single package?
• Does it require changes to the language spec?
• Does it require users to change existing scripts or workflows?
• Does it require updating introductory materials?
• And so on.

Once a change has been identified as large, we could add more process, although we need to decide exactly what that is too. One idea is to keep iterating on design drafts before making an official proposal. Another is to require an experimental prototype be available. And so on. We can collect those ideas here too.

[mvdan]

I'd like to echo an idea that was widely discussed at GopherCon - these large changes tend to attract lots of attention, so the issue threads become unbearably long to the point that they can't be loaded all at once easily.

[bcmills]

To expand on @mvdan's point: I think it would be helpful to split the discussion threads for large changes into a main “process and draft updates” issue (with discussion locked) and separate per-topic issues referencing that issue (with discussion unlocked).

[bcmills]

For designs with multiple interlocking features, it might also be helpful to split the proposal into separate issues for the overall problem and overall approach and specific sub-proposals that can be adopted or rejected independently.

Some examples:

Main issue: “Interpreting errors is hard. Let's add more structure to the errors package.”
Sub-proposals:

• errors.{Unwrap,Is,As}
• Implement errors.Is for syscall types.
• %w and an error-formatting interface.
• Capturing stack info in fmt and errors.

Or, one closer to me personally:
Main issue: “Overflow is error-prone. Let's make it explicit.”
Sub-proposals:

• Add checked-integer packages.
• Add , ok forms for arithmetic expressions.
• Remove unchecked arithmetic from int.

[josharian]

Or build a slightly fancier version of what Russ made for the try proposal, namely a better presentation layer. Two possible features: (1) Instead of being purely readonly, allow sentiments/votes to be added directly (writing back through to the underlying GitHub issue). (2) Instead of Russ categorizing comments, use hash tags in the comments to organize. When manual categorization is needed, gardeners can edit the comments to add/remove/edit tags.

[bcmills]

Another pattern I've noticed for a few large changes (particularly #6977 and #30228) is that the update comments from associated CLs can easily swamp out the discussion thread on GitHub.

It might help to split out a separate tracking issue for associated changes, so the mention-noise can go there instead of to the proposal issue itself.