Can Weighted Voting and Multi‑Track Review Rescue Go’s Nearly 1,000‑Proposal Backlog?

Backlog of Go proposals grows 23% per year, median waiting age exceeds two years, and there is no formal priority mechanism.

New lifecycle

Proposal life is split into four stages: Incoming → Ready → Active → Decided . Each stage adds structured rules and automation while keeping the open, expert‑driven decision principle.

Core mechanisms

1. Formalized triage group

A 3‑5‑person triage team performs an initial health check. Each member casts one of three hidden votes:

Close – requires a two‑thirds majority (minimum two votes) and a reason.

Enter review – provides track, initial priority, and controversy level; passes with a one‑third majority (minimum two votes), deliberately favoring admission.

Request more information – author must respond within 30 days or the proposal auto‑closes.

Triage decisions are reversible; closed proposals can be appealed and returned to the triage queue.

2. Weighted community voting

Community emoji votes affect only priority (when a proposal is examined) and not the final acceptance decision, which remains with the expert review committee.

Initial priority from triage maps to base scores (high = 50, medium = 25, low = 10). Community likes are weighted by contributor status: an approver’s vote counts 5 points, a regular user’s vote counts 1 point. Median emoji count is 1, 90th percentile is 16; there is no down‑vote mechanism.

3. Multi‑track parallel review

Review is split into domain‑specific tracks, mirroring existing language‑change and command work‑groups but formalized and expanded. Planned tracks:

Language changes

Go command

Static language toolchain, compiler, core language facilities, algorithm libraries

Security & cryptography, production‑environment interfaces, reliability testing, dynamic diagnostics

This aims to increase throughput and allow more community contributors to participate.

4. Controversy grading and queue‑theoretic scheduling

Each proposal receives a controversy level with associated characteristics and decision‑time reference:

Trivial – clear definition, no compatibility impact; decision time: days.

Minor – local changes, naming/signature tweaks; decision time: weeks.

Substantial – new capabilities or mental models; decision time: months.

Contentious – heavy technical trade‑offs, ecosystem impact; decision time: quarters to years.

Weekly review meetings allocate fixed time‑boxes based on controversy (Trivial 15 min, Minor 20 min, Substantial/Contentious 25 min) to prevent large proposals from blocking small ones. Scheduling draws on the SITA (Size Interval Task Assignment) algorithm, routing tasks of different sizes to separate queues to handle the heavy‑tail distribution of proposal effort.

Final review guard

If a track’s committee leans toward rejection, the proposal is marked “Likely Decline” and publicly displayed for at least five days; without new substantive arguments it becomes “Declined”. If the committee leans toward acceptance, the proposal is marked “Likely Accept” and sent to a dedicated Final Review group, which checks platform‑wide design consistency without re‑evaluating technical merit.

Community concerns

Risk that niche proposals never receive enough voting weight; triage can assign a high initial priority to bypass pure popularity.

Potential for the triage step to become a second bottleneck; periodic audits of write‑in reasons and triage‑to‑ready latency are planned.

Possibility of an “accepted but unimplemented” front‑log; a time window for the “Accepted” state and an “icebox” status for overdue items are proposed.

Open questions about integrating GitHub Discussions, adding a dedicated security track, and improving meeting‑record transparency.

Conclusion

The proposal represents the most extensive overhaul of Go’s proposal process to date, replacing ad‑hoc priority decisions with weighted voting, multi‑track review, and queue‑theoretic scheduling. Its effectiveness will be judged by performance over the next one to two years. Original discussion: https://github.com/golang/go/discussions/80580.