proposal: all: structured framework for Go language proposal discussions

[mikeschinkel]

Proposal Details

This proposal is the result of this dialog: #71460 (reply in thread)

---

Abstract

This proposal presents a framework for managing community feedback on Go language proposals, particularly those involving contentious topics like syntax changes. The framework provides structured channels for both direct feedback and suggested modifications, acknowledging both the Go team's need for focused feedback and the community's natural desire to suggest improvements. While specific implementation suggestions are provided, the Go team maintains full authority to modify any aspect of this framework based on their experience and needs.

Background and Motivation

The Go team faces a recurring challenge when presenting proposals for language changes: despite explicit requests to focus discussion on specific aspects of a proposal, community members frequently suggest modifications and alternatives, leading to overwhelming threads that become difficult to manage effectively.

This pattern emerges from several fundamental factors:

First, programmers develop an intimate relationship with their programming language through daily use. The syntax and semantics become deeply personal, leading to strong emotional investments in how the language evolves. This investment manifests in two primary ways: developers who have experienced friction with certain language aspects often envision specific improvements to address their pain points, and developers who have developed effective patterns within current constraints may resist changes that could make their approaches less attractive to their teams.

Second, the current approach of requesting that community members avoid suggesting modifications while providing feedback has proven consistently ineffective. This mirrors situations in other domains where attempting to restrict natural human impulses to suggest improvements often leads to community frustration and reduced engagement quality.

Proposed Solution

Rather than fighting against the natural inclination to suggest improvements, this framework creates structured channels for both direct feedback and modification suggestions. The following implementation approach could be modified based on the Go team's needs and experience.

Core Framework

1. Proposal Classification

For proposals that might generate significant discussion, particularly around syntax or other contentious topics, the Go team could designate them as following this framework. A clear section at the top of such proposals would explain the framework's rules and expectations. Third-party proposals could also use this framework, as some community-initiated proposals can generate similar levels of discussion.

2. Direct Feedback Channels

Proposals should clearly specify acceptable types of direct feedback, such as:

• Specific feedback requested by the proposal
• General support or concerns about the proposal
• Use-case analysis (benefits and potential issues)
• Implementation considerations
• Other relevant observations that don't suggest modifications

3. Change Proposal System

When community members wish to suggest modifications, they would be expected to create a new issue with one of two designations:

• "AMENDS #<issue_no>": For suggesting modifications to the original proposal
• "REPLACES #<issue_no>": For presenting an alternative approach

Change proposals should:

• Present a complete, cogent description of the proposed changes
• Address all concerns covered by the original proposal, especially for alternative approaches
• Follow a consistent format that includes:
  • Clear statement of the proposed changes
  • Rationale for the changes
  • Impact analysis
  • Implementation considerations
  • Migration strategy (if applicable)

4. Discussion Management

The original proposal should maintain separate threads for amendments and alternatives:

1. Two pinned comments created immediately after the proposal:

   • One collecting links to amendment proposals
   • One collecting links to alternative proposals

2. All discussion of modifications should occur in the respective change proposal issues, not the main thread.

3. Community members could assist in maintaining thread focus by directing modification discussions to the appropriate channels.

5. Collaboration Framework

Those proposing changes should support collaborative improvement through a clear structure:

1. Proposal Maintenance:

   • Maintain the current state of their proposal at the top of their issue
   • Provide complete revision history with timestamps preserved
   • Maintain active collaborators listed at the top of each proposal's state, when applicable
   • Update issue to reflect consensus reached during discussions, as consensus occurs

2. Collaboration Process:

   • Multiple community members pursuing similar changes should be encouraged to collaborate on a single proposal
   • The original proposer should maintain the change proposal
   • Updates should reflect collaborative work while preserving attribution
   • Prior collaborators should remain listed with their contributions even if they later disagree with the proposal's direction

6. Go Team Commitments

The framework suggests the following lightweight approach for the Go team:

• Maintain simple status tracking through pinned comments on the original proposal listing change proposals as accepted, rejected, or pending (this could be automated using the Github Issues API if desired)
• Consider all change proposals that were properly submitted during the timeframe designated by the Go team
• Provide a clear decision on each change proposal before accepting their own proposal, which could be as simple as posting a comment as to the Go team's disposition on the change proposal and then updating status of that change proposal in the pinned comment

Implementation Approach

The framework could be implemented with minimal overhead through:

1. Template Creation:

   • Standard text explaining the framework for proposal headers
   • Template for change proposals
   • Standard text for the amendment and alternative thread starters

2. Status Tracking:

   • Simple pinned comment tracking with links to change proposals
   • Optional automation using the Github Issues API
   • Basic labeling system for proposal states

3. Community Support:

   • Community-driven moderation helping to enforce the framework
   • Occasional review of process effectiveness through normal proposal interactions
   • Natural adjustments based on observed patterns and feedback

Expected Benefits

This framework should provide:

1. Improved Signal-to-Noise Ratio through structured channels for different types of feedback

2. Enhanced Community Engagement by providing clear paths for constructive contribution

3. Efficient Process Management by leveraging community self-organization while maintaining Go team oversight

Success Metrics

Success could be measured through:

1. Reduction in off-topic comments on main proposals
2. Increased quality of alternative proposals
3. Higher proportion of constructive discussion
4. Reduced moderation needs
5. Positive community feedback

Requested Action

The Go team is respectfully asked to:

1. Review this proposal with relevant team members and give it full consideration
2. Explicitly communicate that the Go team has given this proposal its consideration, and any specifics the Go team would care to share
3. If rejected, simply communicate that decision without requiring detailed explanation

Next Steps

Upon acceptance, implementation could proceed — with assistance from this proposal's author, if requested — through:

1. Creation of necessary templates and documentation
2. Testing the framework on the next proposal where contention is expected
3. Natural collection of feedback through standard Github interactions and informal team observations
4. Gradual expansion to more proposals as appropriate

The Go team may of course modify the approach proposed based on their needs and resources.

[seankhliao]

this is way more work for everyone to track and moderate over multiple threads, people can't even keep their comments in discussions on topic, I don't see how this will be any better.

[mikeschinkel]

@seankhliao — Thank you for commenting.

I don't see how this will be any better.

Currently people are not provided guidance by the Go team for any other action they can take, so they comment.

The reason I believe it could be any better is:

1. The frameworks guides users to moves excessive comments on changes to a different issue,
2. And it gives users an alternative action besides just commenting.

As my proposal points out "the current approach ... has proven consistently ineffective." So not trying something different will certainly not result in anything improving.

[seankhliao]

If people can't take simple instructions like "read the proposal first", how do you expect them to read through this wall of text, and the proposal?
The majority of comments and discussion sprawl comes from drive by comments, and people who just really want to make their point, whether or not it's the appropriate venue.
It'll just be ignored like how people scroll through terms&conditions.
Without a method of enforcement, this is just boilerplate that makes proposals difficult to read.

note that it's possible to keep discussions on track with aggressive moderation, but it takes a heavy toll on maintainers.

[mikeschinkel]

"If people can't take simple instructions like "read the proposal first", how do you expect them to read through this wall of text, and the proposal?"

They would not need to. This is all the proposal would need to say:

Any reader who wishes to suggest modifications needs to submit a new issue, either

• "AMENDS #<issue_no>": For suggesting modifications to the original proposal, or
• "REPLACES #<issue_no>": For presenting an alternative approach

Please refer to here for how to link your proposal back to this one.

Then both the Go team and those of us who know the ground rules can nudge people in the right direction any time someone start suggesting additions or alternatives.

The majority of comments and discussion sprawl comes from drive by comments, and people who just really want to make their point, whether or not it's the appropriate venue.

Per this framework, those comments could be immediately told they need to follow the framework that instructs them how to make comments, and their comments that did not follow the framework could soon be hidden after they have been given enough time to see that feedback.

Further, the clear directive that they need to "take their comment elsewhere" as it will soon be hidden would likely keep others from piling on to the drive-by comment with their own follow up comments. If I am not mistaken the sole drive-by comment is not itself what causes excessive noise but the fact that each drive-by comment often attract tens of other comments.

"It'll just be ignored like how people scroll through terms&conditions."

At first, maybe.

"Without a method of enforcement, this is just boilerplate that makes proposals difficult to read."

But if it became an expected norm within the community, the community would almost certainly enforce it for you.

Peer pressure for violating an objective community norm when there is a clear alternative is usually a very powerful method of self-enforcement.

"note that it's possible to keep discussions on track with aggressive moderation, but it takes a heavy toll on maintainers."

The problem with aggressive moderation is when moderation is subjective. When it is objective the community supports the moderator, but it takes a toll when moderation is subjective because reasonable people can and will disagree.

BTW, I do hope you can see that I really am trying to offer positive input to help improve the experience the Go team has when having to deal with all of those of us who just ignore things.

That said, if I have not made my case to you for why this would be different then no need to reply. You considered the proposal and that was what I asked.

I do hope others who are involved in making proposals on behalf of the Go team will also give it consideration.

P.S. One final rhetorical question though; would it hurt to try it on the next discussion and see if helps or not? If it actually does help, wouldn't that be a good thing? What is the worst that could happen?

[seankhliao]

Per this framework, those comments could be immediately told they need to follow the framework that instructs them how to make comments, and their comments that did not follow the framework could soon be hidden after they have been given enough time to see that feedback.

This is a terrible amount of toil to inflict upon maintainers, I don't see how this could be sustainable.

[mikeschinkel]

There in no reason it would not need to be inflicted upon the maintainers as proposed by the framework. All community member could be empowered by the Go team in advance to tell them.

As I said, peer pressure for violating objective community norms can be a very powerful method of self-enforcement.