大家好，我是煎鱼。
前段时间分享了《被 Go 团队打脸了，已接受的提案也能一句话推翻！！！》引发了大家对 Go 的大范围讨论。但后面发现一个问题，似乎行业内从未给大家讲解过 Go 变更语言规范和提案流程。
今天这篇文章将给大家分享，也可以借此学习社区的运作模式。
前言
在官方资料《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，任何对哪些提案正在审议的小伙伴都可以关注这个 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 突然一句话撤销来看，规范也仅仅是规范。话事人的行径一旦有所缺失（例如：离职、生病等），这套流程就很有可能会跑不通了。
文章持续更新，可以微信搜【脑子进煎鱼了】阅读，本文 GitHub github.com/eddycjy/blog 已收录，学习 Go 语言可以看 Go 学习地图和路线，欢迎 Star 催更。
**粗体** _斜体_ [链接](http://example.com) `代码` - 列表 > 引用。你还可以使用@来通知其他用户。