a more robust proposal process

[aclements]

Short link: https://go.dev/s/proposal-proposal-2026

Since I took over leading Go's proposal process in late 2024, I've been thinking deeply about its strengths and faults. I believe deeply in its goals of transparency and community involvement, but that while its foundations are solid, its process failures mean it doesn't always live up to its goals. I don't think these process failures are something that can be addressed piecemeal, so this is my attempt at a holistic update to the proposal process. The basic outline isn't so different: anyone can file a proposal, discussion all happens in the open, and decisions are made after careful consideration by a small group of experts. This proposal is largely about technical updates throughout the process to better achieve its goals.

Abstract

The proposal process is Go’s engine of change. It’s a critical way the community shapes and informs the evolution of Go. But it also has some clear flaws: a backlog that is growing 23% year-over-year with a median age of over two years, and a manual prioritization process that is neither transparent nor community-informed. To resolve these bottlenecks, this proposal refines the process by:

• Establishing a formal triage process to engage proposals quickly and make fast, early decisions,
• Using weighted community emoji voting to transparently prioritize proposals for review,
• Splitting proposal review into domain-specific tracks to scale throughput and create the capacity to bring in community .

Background

The Go proposal process is a vital mechanism for ensuring the Go project’s development remains transparent and community-driven, and for maintaining the Go platform’s incredibly high standards of compatibility and simplicity. The proposal process was first formalized in 2015 and evolved between 2015 and 2019 for better transparency and to handle large and contentious changes. This period also marked a shift from rigid stability bordering on ossification to pragmatic evolution.

The proposal process is a careful balance of many factors. It is designed to make irreversible decisions that are subject to the Go compatibility promise, while also maintaining Go’s uniformity of design. Over the past several years, we’ve introduced technical mechanisms to lower the risk of making such decisions, such as language versions, forward compatibility, and GOEXPERIMENT, but the proposal process is necessarily heavyweight because “yes is forever.” The process is also designed to protect the attention of the small proposal review group and prevent receive livelock by strictly balancing our intake of proposals with our output of decisions. At the same time, anyone can file a proposal, and this openness is at the heart of the proposal process.

The public proposal process has critically shaped the Go project, but these factors, combined with time and growth, have led to several problems. These problems are felt by the community and many of them can be seen in the data, such as in figure 1. The backlog of unreviewed proposals is growing by 23% year over year, and the median age of a proposal in the backlog now exceeds two years. Today, there’s no process for prioritizing this massive backlog, so which proposals enter review and when is frustratingly opaque and fails to broadly account for community input. Meanwhile, this backlog would be growing far faster were it not for the heroics of a few self-nominated contributors triaging incoming proposals. This triage work is thankless and often leads to conflict (nobody likes having their proposal closed!). At the same time, accepted proposals also often languish, leading to confusion and wasted work. Finally, since the proposal review committee itself is small while covering diverse expertise, often only one or two people have the expertise to evaluate any given proposal and there are inevitable gaps.

Figure 1. The proposal process by the numbers. “New” shows the number of new proposals filed in each year. “Backlog” shows the total number of proposals that have been filed but not reviewed as of Jan 1 each year. “Early reject” shows how many proposals were closed without review in each year, including by ad hoc triage. “Review” shows how many proposals passed through the proposal review committee within each year. The last four rows show the outcomes of the review process.

Overview of the proposed process

Figure 2. An overview of the flow of a proposal through the proposed process. The four columns represent the phases a proposal passes through. Blue boxes represent people processes and green pills represent decisions, often with supporting data.

We propose a refined process to align the mechanics of proposals with our principles. This process divides a proposal's lifecycle into four distinct phases (figure 2):

• Incoming: The entry point for a newly filed proposal. Here, an asynchronous, lightweight triage decides if a proposal meets the bar for review or should be closed with a standard rationale.
• Ready: Where proposals wait in a public queue and the community can indicate interest using emoji voting. The triaged priority is combined with weighted emoji votes to determine how quickly a proposal enters active review.
• Active: Domain-specific review tracks meet weekly to review active proposals. Sessions are timeboxed by proposal controversy to isolate “easy” proposals from “hard” ones. As these groups decide on proposals, they pull in Ready proposals based on priority, track, and controversy.
• Decided: Like now, proposals have a one week final comment period after a review track recommends “accept” or “decline.” A final review group also checks all proposals recommended for “accept” for uniformity of design.

The specific mechanics and rules for each phase are detailed in the following sections.

Detailed mechanics

Proposal triage

The newly formed proposal triage group will consist of 3–5 individuals. Their role is twofold: reviewing new proposals to determine whether they meet the bar for proposal review and providing initial prioritization. By formalizing this process and establishing a small, designated group, we aim to distribute the workload more equitably, provide a consistent framework for triage, and ensure decisions reflect a wider range of perspectives while also officially recognizing the efforts of triage members. Unlike proposal review—a stringent process for making high-confidence, irreversible decisions—proposal triage is designed for making reversible decisions through asynchronous and lightweight voting rather than consensus.

For each proposal, each member of the proposal triage can select one of three actions:

1. Vote to close, with a rationale. Closure requires a ⅔ supermajority with a minimum of two “close” votes (v_c ≥ ⅔ n ∧ v_c ≥ 2).
2. Vote ready for proposal review, with a track, initial priority, and a controversy level. Promoting a proposal to proposal review requires a vote of at least ⅓ of the group, again with a minimum of two “ready” votes (v_r > ⅓ n ∧ v_r ≥ 2). (For a group of 3 to 5 members, this always means two “ready” votes are sufficient.) The process is intentionally biased toward this outcome.
3. Request revision or clarification. This indicates the triage member thinks there isn’t enough information to decide whether to close or promote a proposal, or that the proposal simply needs more work before review. The member should post their question or critique to the issue, and automation will hide the proposal from the member’s triage dashboard until there’s further discussion. At that point, they can review if their question has been answered and vote, post again, or simply mark it as still unresolved. After 30 days, if it remains unresolved and is still in the Incoming state, this automatically flips to a “close” vote.

To reduce anchoring bias, members cannot see how others vote on a proposal until they themselves have voted, but they can change their vote after. (Some common causes for changing one’s vote may be if a member first votes to open, and then sees someone else found a duplicate; or if their decision overlooked an important aspect that another reviewer surfaced.) Since voting is asynchronous, a proposal will be considered triaged once there are enough votes to pass the threshold; it does not require everyone to vote. If a proposal does pass the voting threshold, after 24 hours without any changes to votes, automation will post the outcome to the proposal issue. This delay is to allow for second thoughts, to give time for other votes to come in (though additional votes couldn’t undo the outcome), and to build in some debouncing.

Triage group members are always welcome to perform routine issue gardening as well. For example, if an issue is filed as a proposal, but is actually a feature request, any member of triage (or anyone gardening) can simply move it out of the proposal process, mark it with the FeatureRequest label, and suggest filing concrete proposals as sub-issues. Likewise, if an issue filed as a proposal is actually just a bug or doesn’t affect any surface subject to the Go compatibility promise, anyone gardening can move it out of the proposal process.

Open question: How do we catch up with the current backlog? It would be valuable to work through the backlog, at minimum to assign the metadata that informs the rest of the process. But we don’t want to dump 800 proposals on a volunteer triage group. Most will be trivial to triage, but some will not.

Closure rationales

A vote to close must include a rationale, either one of the following standard rationales, or a write-in rationale:

• Backwards-incompatible change
• Insufficient information for proposal review
• Duplicate of rejected proposal #N without new rationale (closed as duplicate)
• Duplicate of open proposal #N (closed as duplicate)

We can refine and expand these rationales over time. If a proposal is closed, automation will post the rationales and handles of those who voted to close. Proposal triage isn’t intended to be anonymous, so posting handles avoids unintentionally obscuring identities through automation.

Appeals

Closure can be appealed if there is additional information or context to consider. The exact mechanism for this is TBD; most likely it will be by posting a comment to the proposal bot on GitHub. An appealed closure will go back into proposal triage. We may put a limit on the number of times a proposal can be appealed.

Ready for proposal review

For a proposal to be ready for proposal review, it must be backwards-compatible, and must not reintroduce a settled idea without significant new rationale.

It must also satisfy some structural requirements:

• It must describe the problem being solved, propose a concrete solution (not just a request for a solution), and provide rationale for the solution.
• For proposals where adherence to the Go Compatibility Promise isn’t obvious, it must include a discussion of compatibility.
• If a proposal would create a new way to do something that is already possible, it must justify why it is a significant improvement and discuss whether a go fix upgrade is possible.
• More complex proposals should include a discussion of alternate approaches and why they were rejected in favor of the given solution, as well as advantages, and disadvantages of the specified approach.

The degree of structure in a proposal should be commensurate with its complexity; trivial proposals need only a few sentences of justification, while complex proposals should follow the proposal template. We will update the rather minimal GitHub proposal issue template to better guide people into meeting these requirements.

A proposal does not need to be perfect or have clear community consensus to be considered Ready.

A vote that a proposal is ready for proposal review will also include three pieces of metadata that inform the rest of the process: a track, an initial priority, and a controversy level. If the triage group votes that a proposal is ready for review, it enters the Ready state.

The track, priority, and controversy level will be recorded by the proposal automation in GitHub issue fields (a fairly new GitHub feature), which are searchable and always visible in the right hand bar of an issue.

Track. We’ll discuss the possible review tracks in the section on multi-track proposal review. We combine the tracks from the triage votes by taking their mode, with simple random selection if there’s more than one mode. If there’s disagreement on the track, then probably any of the selected tracks is reasonable, and proposal review itself can move a proposal to a different track if it turns out to be better suited to another track.

Priority. A vote for ready also establishes an initial priority. There are five priority levels:

1. Urgent - Must be reviewed immediately. A proposal to revisit a change that is about to become irreversible, or a proposal to revisit a reversible change that has just become public. To be used sparingly. An urgent proposal directly enters the Active state, meaning it will be reviewed immediately.
2. Next major - A proposal specifically targeting the next major release. Generally a proposal that’s required in order to unblock other work in the Go project, or part of a multi-release change, or a proposal that’s already available as a GOEXPERIMENT and ready for general release. A next major proposal does not directly enter the Active state, but it skips the queue, so it will be reviewed as soon as there’s capacity to do so. Like urgent, this should be used sparingly.
3. High - A proposal that would impact a large fraction of Go’s users, or a proposal that would have a large impact on specific segments of users.
4. Medium
5. Low - A proposal with minimal or very narrow impact.

We combine the priorities from the triage votes by taking the highest priority. The top two levels–urgent and next major–are strict and bypass community prioritization to go straight to the proposal committee. The other three levels–high, medium, and low–are probabilistic and feed into community prioritization, which we’ll discuss in the next section.

Controversy. The final component of a vote for ready is controversy. Controversy captures size, complexity, and impact, and estimates how much discussion a proposal will require before reaching a decision. There are four controversy levels:

1. Trivial - A simple addition with a clear definition, a clear use case, and obviously no backwards-compatibility issues. Likely to be approved or rejected in a single review session. Decision time: days.
2. Minor - A localized change that may require some review of naming, signature, or semantic details, but has no broader ecosystem side-effects and clearly fits in with existing API and/or design. Decision time: weeks.
3. Substantial - A change that introduces a new capability or mental model and requires active design synthesis, but has alignment on the overall direction. Decision time: months.
4. Contentious - Proposals where the technical trade-offs are heavy, the ecosystem impact is massive, and reaching a true Go-like consensus requires exhaustive deliberation. Decision time: quarters to years.

We combine the controversy levels from the triage votes by simply averaging their numerical values (with ties rounded up). We’ll describe the use of controversy levels in detail below, but in short they are used to box proposal review time and ensure the “easier” proposals don’t get drowned out by discussion on the difficult ones.

Community-informed prioritization

Currently the proposal process has almost no way for the community to weigh in on what’s important. I propose we officially use GitHub emoji votes to drive prioritization of when proposals enter review. To be clear, emoji votes would purely influence when a proposal gets reviewed, not how it is decided.

The “base weight” of a proposal will be determined by its triaged priority. The exact weights are TBD, but for initial tuning let’s say high is worth 50 points, medium 25 points, and low 10 points. From there, we add a community weight based on the number of “thumbs-up” votes on the top post, weighted by contributor level. Again, exact weights are TBD, but for initial I propose a vote from an approver is 5 points and otherwise a vote is 1 point. Weighting votes elevates the input of those more familiar with the Go project, and serves to prevent Sybil attacks and gaming the system.

The weighting scheme is sure to be refined over time. Currently, the median number of thumbs-up votes a proposal receives is just 1, and the 90th percentile is just 16, though the tail is quite long (details in figure 3). This aligns with the initial weights proposed above, but changing the incentives will also change community behavior. We may adjust the weights, or introduce logarithmic scaling if virality turns out to be a problem. Furthermore, we are working on a more detailed contributor ladder that should give a more robust basis for contributor weighting if and when it gets adopted. Finally, giving more weight to approvers is an easy place to start, but we want to expand this system to reward and incentivize many forms of active participation in the project, not just code contributions.

Figure 3. A sorted value plot, showing the number of “thumbs-up” votes received by every proposal ever filed. 1.4% of proposals have more than 100 votes and are not shown here. Four proposals ever (0.07%) have had over 1,000 up-votes.

Aside: Votes in the current backlog

While we don’t formally use emoji votes for anything today, that doesn’t mean the community hasn’t been providing input this way. A few existing proposals are clearly at the top and are sure to be picked up soon after we adopt vote-based prioritization. That’s okay. However, several of those proposals are actually feature requests that don’t meet the criteria for a Ready proposal, though there are concrete proposals buried within them. Part of this transition will be cleaning up that distinction and pulling concrete proposals out of these umbrella issues as sub-issues that can be reviewed as proposals.

There’s intentionally no downvoting mechanism, such as counting “thumbs-down” emoji, because we don’t want to actively encourage downvoting or enable negative brigading that could suppress controversial but valuable discussions.

When a proposal review committee is ready to take on another proposal—that is, to move it from Ready to Active—we select randomly by weight from the Ready proposals. If there are any Ready proposals given next major priority by the triage group, then this selection is limited to those. Because urgent proposals bypass this lottery entirely, and next major proposals move to the front of the queue, critical and release-blocking work is always fast-tracked. For general proposals, this probabilistic approach means high-priority proposals are very likely to be selected for review, while also ensuring low-priority proposals have some chance of getting reviewed, rather than being permanently starved at the bottom of a strict queue.

Scaling proposal review through multi-track review

The proposal review committee is clearly a bottleneck in the current system. Increasing its throughput would require either spending less time discussing each individual proposal, having everyone spend more time on proposal review, or adding more people. While some proposals could certainly stand less discussion, we don’t want to sacrifice the quality of outcomes, and we’re all too busy to spend more time on proposal review. However, adding more people to the single proposal review committee would almost certainly run headlong into Brooks’s Law, increasing communication and consensus overhead and reducing throughput. Hence, I propose we split proposal review into multiple tracks by subject area. In a way, we already have multiple tracks with the Go language change committee and the Go command working group, and these work well for those domains. This would formalize and expand on that. Initially, we propose the following tracks, though these will evolve as the project’s needs change:

• Language changes
• Go command
• Static language tooling (go/*, x/tools, etc), compiler, core language facilities (reflect, sync, hash, maps, slices, unique, weak, etc), algorithms (math, sort, containers/*)
• Security & cryptography (crypto/*), production surface (net/*, encoding/*, log, etc), reliability (testing, race detector, etc), dynamic diagnostics (runtime/metics, pprof, etc)

The triage process will select a finer-grained track (such as “static language tooling”) so we can rebalance the proposal review committees as necessary, while still keeping the number of meetings reasonable.

Some proposals are likely to move through multiple committees. For example, language change proposals often touch on the compiler, runtime, and/or language tooling, so they may start in the language change track, but then also pass through another track before acceptance.

In addition to better scaling the proposal review process, the other goal of multi-track review is to create the capacity to invite more of the Go contributor community into the proposal process. We believe creating tracks will enable this without simply bogging down the process.

The proposal review process

Each proposal review track can have its own specifics, but by default the group for each track will meet for one hour, once per week, to discuss, review, and respond to Active proposals.

Urgent proposals enter the Active state directly from triage, and get reviewed first in a session. However, we assume that, most of the time, there won’t be any urgent proposals.

Urgent proposals aside, to prevent head-of-line blocking, we divide our weekly meetings into distinct timeboxes based on controversy: 15 minutes for trivial proposals, 20 minutes for minor proposals, and 25 minutes for substantial and contentious proposals. This is exactly like having an express lane at the supermarket: low-controversy proposals get dedicated time so they don't get stuck waiting behind a single contentious proposal (like a massive language change) that requires weeks of debate. In fact, the proposal review committee has been using a controversy metric for active proposals for the past year and it seems to help move smaller proposals along faster once they enter discussion.

Within each timebox, we discuss Active proposals in a random order. If we get through all of the Active proposals in a controversy level before the end of the timebox, then we bring in a new Ready proposal for the same track and controversy level, using the probabilistic priority scheme described above. This approach intentionally limits the number of Active proposals at any given time to roughly how many can be discussed in one session and to keep from overwhelming reviewers with too much context. Of course, discussion times vary, so committees are unlikely to get to every Active proposal in every session. That’s okay, and the random order within each timebox is meant to reduce bias here. We may explore other ways to mitigate oversized Active sets in the future.

Proposal review committees are allowed to use their discretion to bypass priority-based selection, but this is meant as an escape hatch. They are generally expected to follow the system. If such overrides happen often, then we need to revisit the system.

The discussion of each proposal aims to either make a decision, pose a question to be further discussed on the issue, or determine an action item. After each proposal is discussed, the committee should post a summary of the discussion to the proposal issue, along with their question(s) or action item(s). If the follow-up is expected to take a long time (for example, it requires some non-trivial redesign of a proposed API), the committee can put a proposal on “hold” to indicate that they’re waiting on some bigger follow-up action and will check in periodically to see if that’s been done.

Aside: The queueing theory behind this process

This controversy-partitioning scheme borrows the basic insight from Size Interval Task Assignment (SITA) in queueing theory. In SITA, incoming jobs are assigned a work estimate, which is used to partition jobs across servers so one server handles all of the “quick” jobs, another handles all of the “long” jobs, etc. Proposal review timeboxes serve the purpose of multiple servers. SITA is well-suited to heavy-tailed work distributions, which is certainly true of the proposal process, as shown in figure 4. One way the proposal process clearly diverges from SITA is that reviewing a proposal is not a run-to-completion job—it frequently blocks on someone else’s turn—so we keep multiple “jobs” going at once. At the same time, we don’t want too many active proposals at once lest we encounter the human equivalent of cache thrashing. Hence, we combine SITA-style partitioning with an adaptive admission control scheme.

*Figure 4\. The time that proposals spend in review is heavy-tailed, as shown by this cumulative distribution of days spent in review for proposals decided in the past three years.*

The role of proposal review itself remains the same. This is currently described as: “The principal goal of the review meeting is to make sure that proposals are receiving attention from the right people, by cc'ing relevant developers, raising important questions, pinging lapsed discussions, and generally trying to guide discussion toward agreement about the outcome. The discussion itself is expected to happen on the issue tracker, so that anyone can take part. The proposal review meetings also identify issues where consensus has been reached and the process can be advanced to the next step.”

If a proposal review committee recommends declining a proposal, it will be publicly marked as “likely decline” for at least five days (often seven) for final comments. The next session will check for substantive arguments on the proposal issue and, barring such arguments, will mark it as “declined.”

If a proposal review committee recommends accepting a proposal, they:

1. Update the proposal issue with a self-contained write-up of the final proposal (or a link to a clear write-up already on the proposal issue) and optionally an overview of rationale and alternatives considered,
2. mark the proposal “likely accept”, and
3. send the proposal to a “final review” group.

The final review group’s role is solely to check for design uniformity across the entire Go platform. They are not there to reevaluate the technical merits of a proposal, and are expected to trust the track committee’s domain expertise. Once a proposal has been in “likely accept” for at least five days without substantive arguments, and is approved by the final review group, it moves to “accept.”

Once we have more experience, we’ll reevaluate the final review step. Initially, this is a hedge against switching to multi-track review, to make sure we don’t lose our current single point of broad visibility. It also mirrors the process for the current language change and go command groups, which in practice either decline proposals or recommend that the main committee accept them. The final review group will meet weekly at first, but may switch to an asynchronous process or we may find it’s simply unnecessary.

Trivial proposals follow a more lightweight process and bypass final review. However, if they aren’t moved to “likely accept” or “likely decline” in one session, then they get moved to the minor controversy timebox for later sessions.

Implementation

We foresee three components to implementing this updated process: documentation, transition tooling, and automation.

For documentation, we will update https://github.com/golang/proposal#readme (which has drifted quite a bit from the process we follow even today), establish a proper GitHub issue template for filing general proposals, and refresh the issue template for language change proposals.

For transition tooling, we will build one-off tooling to transition our proposal state into GitHub issue fields. This will replace our current proposal state-related issue labels and the proposal project. Issue fields are far more structured and remain searchable. We plan to do this before building new automation because the existing automation is relatively simple, so it should be easier to change the existing automation and then build the new automation from a clean slate.

Much of this updated process will be made possible by more sophisticated automation.

Currently, the proposal process is managed through a Google Sheet plus a combination of tools that sync information to and from GitHub. While this sheet is the source of truth, essentially all information in it gets exported to the proposal minutes issue, the proposal project, and automated posts and label updates to individual proposal issues. The whole process is quite clunky and error-prone and clearly won’t scale to multiple tracks or a more complex queueing approach. We’ve been through many versions of this process, tracked variously through spreadsheets, docs, and GitHub projects. General-purpose tooling never really fits what we need.

Hence, we intend to build a dedicated system for the proposal process. There will be a triage interface for the triage group, a review interface for the proposal review committees, and likely a public dashboard with an overview of proposals and their states. Like now, all decisions and “permanent state” will be captured in GitHub. We will continue to automatically post updates to a proposal minutes issue, but will probably merge the different tracks into a single issue. The proposal system itself will only store “transient” state, such as triage votes before the decision threshold has been reached, or draft proposal review state during a review session.

Conclusion

The proposal process is essential to Go's success, but it needs to scale with the community. By formalizing triage, bringing community-driven prioritization to the backlog, and enabling parallel review tracks, we can create a sustainable, scalable process that is more transparent and community-informed. These refinements preserve the core values of the Go proposal process while ensuring we can continue to evolve the Go ecosystem effectively. I look forward to feedback on this approach and to iterating on these mechanics together.

Acknowledgements

Thank you to the many, many people who have weighed in on this proposal, from my initial spit-balling to the crafting of this text. Special thanks go to Robert Griesemer, Mateusz Poliwczak, Damien Neil, Alan Donovan, Ian Lance Taylor, Michael Pratt, and Sean Liao.

[aclements]

FAQ

Q1: If the triage group votes to close my proposal, is that the end?

No. The design of the triage process is biased toward low latency over certainty, the opposite of proposal review. As such, we expect it to make mistakes. If you have additional context or information to address triage’s closure rationale, you can appeal the decision. Appealed closures go straight back into the triage group for reconsideration.

Q2: Does community emoji voting mean that Go proposals are now decided by a popularity contest?

No. Community voting affects priority, but not decision-making. The final decision still rests on expert technical consensus of the proposal review committee, informed by community discussion.

Q3: Why are we weighting "approver" votes more heavily?

Weighting votes is a necessary security measure to prevent Sybil attacks and coordinated brigading (for example, if a proposal is shared on social media and gets a flood of votes). Elevating the input of those who are already deeply familiar with the Go project ensures the prioritization signal is robust. We also plan to expand this to recognized non-code contributor roles.

Q4: Why use a "lottery" (probabilistic selection) to pull proposals from the queue?

A strict priority queue inevitably leads to starvation in an overloaded system: low-priority proposals would sit at the bottom of the backlog, never to be reviewed at all. We don’t want low priority to be a pocket veto. To prevent critical work from being delayed by bad luck, urgent and next major proposals bypass this lottery.

Q5: What prevents the "Final Review Group" from becoming a second bottleneck or vetoing track decisions?

The final review group is expected to trust each track’s domain expertise and strictly ensure design uniformity across the Go platform. It acts as a hedge during the transition to a multi-track system to ensure we don’t lose our single point of broad visibility. To prevent it from becoming a second bottleneck, it runs in parallel with the “likely accept” phase.

[deefdragon]

I'm very happy to see this. I've wanted a number of changes to the proposal process for some time. I have a lot of notes that I need to work through and format into coherent discussion on this.

While I'm doing that, would it be worth adding examples of past/current proposals to the different track, controversy, and priority levels? Just so that everyone is discussing those on the same page?

[aclements]

I think doing an "example triage" of a sample of proposals is a good idea (though I won't have time to do that myself for a few weeks).

Looking forward to your comments. Just a logistical note: I suggest posting them as a few separate, thematically grouped comments so we can make the most of the structure of GitHub's Discussions.

[earthboundkid]

This is very good. For large or controversial proposals, it can happen that the same points are repeated because no one can read the whole thing. Github Discussions are slightly better because they can be broken into different sub-topics. Is there any interest in having a formal process for moving some proposals from Issues into Discussions?

[aclements]

Definitely worth thinking about, though my sense is that it's fairly orthogonal to this proposal. I think our existing recommendations stand: proposals that are likely to generate a lot of discussion should start as a Discussion, and if discussion is starting to loop, add a FAQ to the top post. I'm not sure how practical it is to convert an issue that has already passed the threshold of repetition into a GitHub Discussion. Personally, if a proposal has gotten too big for me to digest, I'll point an LLM at it before I post anything to check that I'm not repeating anything. It sure would be neat to have something more standardized for that.

[seankhliao]

Github hides just as much or more in discussions as well. And personally they're harder to search since you have to expand the hidden top levels, then expand up & down in each subthread.

IMO it's a stack overflow clone, unsuited for large discussions.

[neild]

For proposals which generate a lot of conversation, I think the right approach is to create a new child issue for each topic being discussed.

Child issues have some nice attributes over GitHub discussions:

• It's easier to see comments-since-some-point-in-time in an issue than in a discussion.
• We can pin a comment to the top of the issue with a decision, or a summary of the comments so far, or whatever seems useful.
• We can close the issue if the topic is resolved, such as if someone proposes an amendment to a proposal which is then accepted or rejected.
• It's easier to make the switch from "issue that we don't expect to have a lot of discussion" to "unexpectedly contentious, needs more structure"--lock comments on the original issue, pin a comment requesting that further discussion happen in new child issues.
• Noisy topics don't drown out quieter ones.

[jakebailey]

If voting is key in elevating a proposal above others, how do you balance for "niche" / less-flashy proposals?

I know there are a few proposals I'm interested in (say, for Windows stuff), that don't have a lot of votes. They're never going to get as many votes as popular language changes, but do matter to people who have those sort of behind-the-scene needs.

[aclements]

In addition to what Ian said, the triage priority carries a lot of weight. So if something is clearly important but perhaps not flashy, the intent is that it gets a high triage priority and that bumps it up, even if it doesn't draw widespread attention.

[aclements]

I am a bit concerned about proposals where the "real" proposal winds up buried in the thread. For feature requests, my plan is to push people toward filing concrete proposals as sub-issues of the feature request. It may make sense that when a discussion lands on a different approach than was originally proposed, that should also be filed as a new proposal issue, perhaps also as a sub-issue. That can obviously be tricky in an organic discussion, but the whole system will probably work more smoothly if we can have the discipline of "one proposal, one issue".

[aclements]

(I split the last two messages in this thread into new top-level threads because they were diverging a bit from the initial topic.)

[aclements]

Etiquette for updating proposals and the difficulty of finding the latest version of a proposal

Split out from the above thread:

@seankhliao
As for converging on a different design,I think triage / proposal review can make more use of the new pin comment feature.

@jakebailey
I think that makes sense, though in my experience, that won't stop people from commenting in two places; I know so far it's been standard to reedit the original post with the final idea, but that has only happened really after acceptance to prevent confusion...

I didn't cover this in this proposal, but I would generally like us to stop editing proposal posts in place to update them. It's way too confusing when trying to reconstruct or catch up on the history of a proposal discussion. It's fine to copy-paste the proposal details into a new message; we're not going to run out of space. :) That works pretty well if we pin the comment with latest version of the proposal details, though I really wish GitHub would show the pin at the top of the issue, not at the bottom of the first post.

Prior to GitHub's pinning feature, I considered adding a Gopherbot feature so anyone could mark a post as an update to the proposal details and Gopherbot would edit in an info block at the top of the top post. With the pinning feature, I'm not sure what's worth it.

That's mostly about incremental updates to proposal details, though, and not completely different designs.

[prattmic]

On the other hand, if you edit the top comment, it is possible to look at the comment edit diff to see how it changed since you last looked at it.

That said, GitHub's comment diff view is very rudimentary, so it's not a huge endorsement. Google Docs has a pretty good diff view which I use all the time to catch up on changes to design docs. (I am not suggesting we use Google Docs for proposal discussions)

[prattmic]

Many projects, such as Rust, use pull requests to a proposal repository for their proposal discussions.

We could do the same: proposals are CLs to x/proposal and the discussion is on Gerrit.

That would solve many of the pain points here:

• Finding the latest version is trivial (it's the latest patch set). As is finding the accepted proposal (whatever gets merged).
• Diffs between changes are well supported.
• Good support for multiple threads of discussion.

But such a change equally comes with several downsides:

• The CL has exactly one owner, someone else can't take over the proposal [1].
• Slightly higher bar for community members to participate (must be familiar with Gerrit).
• Active proposals are less discoverable since they aren't on GitHub. Our Gerrit review dashboard is generally a mess, though a custom dashboard for proposals could likely help.

All this said, I think this entire sub-thread is largely out of scope of Austin's high-level proposal.

[1] I think we actually could safely allow the Gerrit permission for non-owners to push to x/proposal CLs. That would solve the case of the original author disappearing, but not many people suggesting alternatives in an active discussion.

[aclements]

Information required in a proposal

Split out from above thread:

@seankhliao
Partly I think the proposal process requires too little information from the author, especially around what motivates a proposal, this can make it hard for others to judge how important the proposal is.

In the proposal proposal, I list these "structural requirements":

• It must describe the problem being solved, propose a concrete solution (not just a request for a solution), and provide rationale for the solution.
• For proposals where adherence to the Go Compatibility Promise isn’t obvious, it must include a discussion of compatibility.
• If a proposal would create a new way to do something that is already possible, it must justify why it is a significant improvement and discuss whether a go fix upgrade is possible.
• More complex proposals should include a discussion of alternate approaches and why they were rejected in favor of the given solution, as well as advantages, and disadvantages of the specified approach.

My intent is to put those into the proposal issue template.

Do you think this is enough to triage a proposal, or do you think we need more? I sort of beat around "motivation" without explicitly mentioning it.

[seankhliao]

I think describe the problem being solved mostly covers motivation, though sometimes it's too local. That might be something to clarify in triage?

one more is expected impact size, does it affect a niche use case, will it introduce a new preferred method.
we've used code searches before to judge how common a particular pattern is.

[seankhliao]

also maybe who is going to do the work of implementing it, and for complex changes, how.

trawling through our backlog, I've certainly seen (accepted) proposals where I just don't see how it can be efficiently implemented.

and I don't really want proposals to be a wishing well...

[deefdragon]

Role drift and "Second proposal Committee"

As has been shown with the existing process, roles and expectations shift over time. One of the worries I have is that the triage process will slowly become a second proposal process hurdle to clear instead of a quick and easy sorting. I think the write-in specifically is my biggest worry here. Id like to suggest that, if a write-in rationale is used for closing the proposal, the vote threashold (either count or %) needs to be higher? On a somewhat regular basis, all of the write-in reasons can be examined, and new base rationale can be suggested if one keeps getting used on the regular in write-ins.

I'm also worried a bit about certain good ideas that started out as IE backwards incompatible, and, with engagement from others became backwards compatible. I'm curious how that might work in this new process. Would the triage team be encouraged to let this kind of issue through?

[deefdragon]

Backlog handling

For handling the backlog, a suggestion might be to do a 1 to 1, where each new proposal that is triaged, (potentially only if it empties the triage queue), lets 1 old proposal into the queue to be triaged (or, slowly over time just let new ones in). This should, over time, eat into the backlog without flooding the triage team. The backlog will have to be addressed eventually. I don't think there's a way to NOT.

[deefdragon]

Go team "Big" proposals

There have been a number of "Big Proposals" brought by the more internal go team members that have a tendency to be brought into the proposal process right away. This has some reasonable sides (the go team is well versed and has high skill and experience, so their proposals are normally quite well founded) but it also has some negatives (a perspective of go just being a "google" language, a feeling of unfairness on addressing proposals). I'm unsure the best way to address this, tho I think discussions (comments below) may help a bit?

[deefdragon]

Role of discussions in the proposal process

By my recollection, most of the more prominent recent cases of a go team proposal being pulled in right away, the proposal came out of a discussion. I think that we should solidify the place of discussions in this process while we are going through the work of rebuilding how proposals work, and given that discussions have (IMO) worked out rather well (tho their usage has room for improvement).

Id like to suggest that, in cases where a discussion of a potential feature is used, it is possible for the results of that discussion to be prioritized as atleast high, if not given its own prioritization above high (I don't think most discussions would end up as next major, but I may be misunderstanding how next major would work?). regardless, where discussions land should probably be explicitly called out, and likely separate from the other tiers.

I think some of the best discussions have been those that sought community input on what was desired before making the proposal itself. I felt that a large number of the discussions in the past were basically proposals in disguise. Id like to suggest limiting discussions to input gathering on features instead of being "beta proposals" (or at least explicitly splitting into 2 types of discussions, and labeling them as necessary). IE "What features do you desire in a structured logging library" as opposed to "I came up with a basic structured logging API. Do you have any suggestions" (no shade at jba. Was just a big discussion/proposal so it came to mind). I think taking this feedback and converting it into a solid proposal which is THEN discussed and refined further is most ideal, and should be encouraged where possible.

[deefdragon]

External Github tooling for proposal voting

Will there be some method outside of github for finding and voting on proposals? The github search interface can be... complicated and confusing at the best of times. If we are using emoji voting, having a way to find interesting proposals and vote on them is going to be vital. I'm unsure if it would be worth the workload to make a separate interface to display the proposals that would allow voting with the github API (don't know if emoji on issues even has an endpoint) however.

I think the need of a discovery surface is going to largely be determined on how the voting goes, and if the floor of emoji votes can be raised so the median is more than 1.

[deefdragon]

Additional tracks

A track that I would like to see added to the list of tracks would be that of a "meta" track for things not related to the language itself, but that still need community discussion and feedback. This discussion would, for example, fall under the meta track. So would the oscar and gabyhelp discussions. I'm split on if go new would as well, or if it would be under static language tooling.

I would also suggest that Security & cryptography be its own track as well. The knowledge needed is highly specialized while not really meshing with the other items in the track its currently in, its extremely important that its done correctly, and there are a LOT of crypto issues that get into the proposal process on the regular.

[deefdragon]

Clarity in Review committee updates & Holds

One of the issues I have with the current process is that it is difficult to see what was discussed by the review committee, what had actual discussion happen, what didn't have discussion, and what was just not reached during the meeting. My biggest example of this is (I believe) #61902 which was stuck as "discussion ongoing" for several months with little progress before being finally put on hold. I think any tooling that is used to keep the community up to date needs to split out "discussion happened by the community" and "the committee discussed this proposal" into two separate notes in the updates.

Regarding on hold, Id like it if there was some timer going on for a proposal on hold to make sure that they get revisited at least every few months to make sure that they are either still good on hold, able to be brought back into discussion, or no longer relevant. I had to be the one to request 902 be looked at again after a year on hold, and it still took another 6~ months to get a comment from Austin.

[deefdragon]

Committee selections and meeting transparency

I'd like to see some transparency on how the members of the different groups are selected, and better clarity about what is discussed in the meetings that are happening. The latter issue has become better over time, but I'd really like to see something closer to the notes for the jsonv2 working group (example), or if possible, for the meetings to be recorded/streamed.

I don't distrust the committee. I just think that having fuller notes might make discussion about the worries that the committee has be better addressed.

[deefdragon]

Covering issues in the given tracks

One of my worries I have with regards to the time-boxing is that a high-discussion issue may take an hour or more just to keep up with the new comments. With the time boxing & random ordering, This should not be too much of an issue to prevent other issues from ever being discussed, but I'm worried about the track committee keeping up with those big-ticket issues if there is only 25 minutes.

I'm also worried that the random ordering could also work out in the negative where a "the massive issue of the quarter" gets first pick several weeks in a row over the other issues that were already in there, preventing anything else from getting looked at in that track&contention.

Would a bag system (see: Tetris piece bag) to make sure everything gets through at least 1 time every so often be worth it here? I'm not sure if the complexity is necessitated, but if we are already building tooling to pick the next issue at random it may be worth it?

[deefdragon]

What success looks like.

Id like to know what success with these changes looks like. Ideally, with those defined, Id also like if there was a specific time (A year from now?) where the changes get reviewed to determine what lessons have been learned and if more changes need to be made. I suspect a year wont be enough to get the full feel of everything, but having that specific time to say "lets take a look back" would be good for making adjustments as needed.

(Also, Sorry for the spam. I tried my best to compress my notes as much as possible, and I'm still leaving a few things out for now.)

[seankhliao]

The number of accepted / implemented proposals has mostly remained constant. I think this could point to two things:

we've accepted too many unimplentable proposals, and/or the code authoring/review pipeline is at it's limit as well.

scaling proposal review should increase the number of accepted proposals, but having a backlog of not yet implemented things makes it harder to evaluate new ones if you have to consider the possible interactions with things that don't yet exist.

maybe accepted should have a time limit too (2 years?) before it gets either closed or re triaged