Skip to content
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

Open
rsc opened this issue Aug 15, 2019 · 5 comments

Comments

@rsc
Copy link
Contributor

commented Aug 15, 2019

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.

@rsc rsc added the Proposal label Aug 15, 2019

@rsc rsc added this to the Proposal milestone Aug 15, 2019

@mvdan

This comment has been minimized.

Copy link
Member

commented Aug 15, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 16, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 16, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 17, 2019

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

This comment has been minimized.

Copy link
Member

commented Aug 27, 2019

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.