Skip to content

proposal: all: structured framework for Go language proposal discussions #71741

Open
@mikeschinkel

Description

@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.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    Status

    Incoming

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions