今天這篇文章將給大家分享，也可以借此學習社區的運作模式。

前言

在官方資料《Proposing Changes to Go》中，給出了一系列的提案指導意見、流程規劃以及目標。

Go 語言項目，開發過程以設計為驅動。

有以下的要求：在實施重要的語言、庫或工具更改（包括 Go 主倉庫和所有 golang.org/x 倉庫中的 API 更改，以及 go 命令的命令行更改）之前，必須首先進行討論，有時還需要正式文檔化。

提案流程是怎么樣的

提案（proposal）過程指的是對提案進行審查并決定是否接受或拒絕提案的過程。

整個提案的流程是使用 GitHub 中的 Label（標簽）來做流程規范的，在此也可以稱其為分類的欄目。

創建提案描述

第一步，提案作者需要創建一個簡要的問題描述提案。一般對應提 issues 時的對應分類：

圖片

而對應的不同的分類，會給出不同的 issues 模板：

圖片

基本上要滿足社區所要求的模板才會有核心團隊的人交流，否則一開口就會讓你去補充內容。

此時是不需要設計文檔的。

進行提案分類

第二步，需要對提案進行問題討論和標簽分類、跟蹤。一般會將提案分為以下三種結果之一：

• 接受提案（Accept proposal）
• 拒絕提案（Decline proposal）
• 索要設計文檔（Ask for a design doc）

如果提案被接受或拒絕，則這一項完成。否則，預計需要基于更詳細的設計進行進一步的問題討論。

提供設計文檔

第三步，提案作者編寫和提供設計文檔，以詳細說明提議的設計并解決初始討論中提出的問題。也就是提出提案者需要給出設計解決自己提出的問題。

最終討論

完成第三步后，社區會結合設計文檔和問題進行討論，需要提案作者進行及時的修訂。再進行多輪討論。

最終確定提案的走向，兩種結果之一：

• 接受提案
• 拒絕提案

在提案被接受或拒絕后，下一步的實施工作將按照常規的貢獻代碼的方式進行。

提案有哪些狀態

Proposal Review（提案審查）

Go 核心團隊大約每周召開一次 proposal review meetings（提案審查會議），審查和討論待決定的提案。

這個會議會就已達成共識的提案，將流程推進到下一步（通過標記提案已被接受或拒絕，或要求提供設計文檔）。

每周會議結束后，會議記錄會發布到 golang.org/s/proposal-minutes[1]，任何對哪些提案正在審議的小伙伴都可以關注這個 issues。

圖片

Incoming（傳入）

新提案會被添加到 "Incoming" 這一欄。

每周的提案審查會議會優先審查 "活動"、"可能接受 "和 "可能拒絕" 欄中的所有問題。

如果還有剩余時間，則會選擇將 "Incoming" 中的提案移至 "活躍" 欄。

圖片

Incoming 欄中的提案被相關成員識別、討論后，很快就會轉挪動到 Proposal 欄下。但由于官方文檔未有提及，因此主要做此補充說明。

圖片

Active（活躍）

在每周的提案會議上，都會對 "活躍" 欄中的問題進行審查，以觀察討論中是否出現了共識。

提案審查小組還可以發表評論、提出建議、提出澄清性問題，并嘗試重述提案，以確保每個人都同意討論的具體內容。

圖片

Likely Accept（可能接受）

如果議題討論似乎已達成接受提案的共識，提案審查小組會將該議題移至 "可能接受" 欄，并張貼評論，指出這一變化。

圖片

再繼續等待一段時間，一般可能是數周。觀察后續的新的討論情況和內容。再繼續推進下一步流程。

Likely Decline（可能拒絕）

如果提案討論似乎已達成拒絕提案的共識，提案審查組就會將該問題移至 "可能拒絕 "欄。

如果提案審查小組認為不可能達成一致意見，因此默認不接受該提案是合適的，則也可將該提案移至 "可能否決 "欄。

等待時間和動作與 “可能接受” 會是一樣的。

Accepted（已接受）

提案轉到 "可能接受" 欄一周后，如果共識沒有改變，提案審查小組就會將提案轉到 "已接受" 一欄。

如果在這一周內進行了大量討論，提案審查小組可能會將提案在 "可能接受" 欄中再保留一周，甚至將提案移回 "活躍" 欄。

一旦提案被標記為 "已接受"，就會貼上 "提案-已接受" 標簽，它就會從 "提案" 里程碑移到 "工作" 里程碑中，問題也會被重新使用，以跟蹤提案的實施工作。

圖片

Declined（已拒絕）

在提案轉為 "可能已被否決" 一周后，如果共識沒有改變，提案審查小組會將提案轉到 "已被否決" 一欄。

如果在這一周內進行了重要討論，提案審查小組可能會將提案在 "可能拒絕 "欄中再保留一周，甚至將提案移回 "激活" 欄。一旦提案被標記為 "拒絕"，該提案即被關閉。

圖片

否決還會分為四種情況，處理流程類似，分別歸類為：

• 因重復而被拒絕（Declined as Duplicate）
• 因不可行而被拒絕（Declined as Infeasible）
• 因撤回而被拒絕（Declined as Retracted）
• 因已過時而被拒絕（Declined as Obsolete）

Hold（擱置）

如果討論提案需要修改設計或補充信息，而這些信息在幾周或更長時間內都無法獲得，提案審查小組就會將提案移到 "擱置" 欄，并注明等待的內容。

圖片

一旦準備就緒，任何可以編輯問題跟蹤器的人都可以將提案移回 "激活 "欄，以便在下一次提案審核會議上進行審議。

圖片

總結

Go 提案的整體流程規范是比較明確的，但其并不是每個標簽（欄）都一定會用到。從實際的情況來看，會根據 issues 討論的激烈和復雜度還決定是否使用 “可能接受/可能拒絕” 等場景。

我們在官方提案文檔上也會有提到提案的討論一定是能得到適當、公平、及時、有記錄的評估，能得到明確的答復。且要求在 “proposal review meetings” 上審查和記錄。

圖片

同時會發現，這套流程打標簽挪欄目的動作，非常依賴人的行為。大部分的行為都相當的主觀。

結合上次的已接受、已合并提案被 rsc 突然一句話撤銷來看，規范也僅僅是規范。話事人的行徑一旦有所缺失（例如：離職、生病等），這套流程就很有可能會跑不通了。