-
Notifications
You must be signed in to change notification settings - Fork 17.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
proposal: identify large changes & add more process #33670
Comments
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. |
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). |
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
Or, one closer to me personally:
|
Or build a slightly fancier version of what Russ made for the |
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. |
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:
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.
The text was updated successfully, but these errors were encountered: