今天这篇文章将给大家分享，也可以借此学习社区的运作模式。
在官方资料《Proposing Changes to Go》中，给出了一系列的提案指导意见、流程规划以及目标。
Go 语言项目，开发过程以设计为驱动。
有以下的要求：在实施重要的语言、库或工具更改（包括 Go 主仓库和所有 golang.org/x 仓库中的 API 更改，以及 go 命令的命令行更改）之前，必须首先进行讨论，有时还需要正式文档化。
提案（proposal）过程指的是对提案进行审查并决定是否接受或拒绝提案的过程。
整个提案的流程是使用 GitHub 中的 Label（标签）来做流程规范的，在此也可以称其为分类的栏目。
第一步，提案作者需要创建一个简要的问题描述提案。一般对应提 issues 时的对应分类：
图片
而对应的不同的分类，会给出不同的 issues 模板：
图片
基本上要满足社区所要求的模板才会有核心团队的人交流，否则一开口就会让你去补充内容。
此时是不需要设计文档的。
第二步，需要对提案进行问题讨论和标签分类、跟踪。一般会将提案分为以下三种结果之一：
如果提案被接受或拒绝，则这一项完成。否则，预计需要基于更详细的设计进行进一步的问题讨论。
第三步，提案作者编写和提供设计文档，以详细说明提议的设计并解决初始讨论中提出的问题。也就是提出提案者需要给出设计解决自己提出的问题。
完成第三步后，社区会结合设计文档和问题进行讨论，需要提案作者进行及时的修订。再进行多轮讨论。
最终确定提案的走向，两种结果之一：
在提案被接受或拒绝后，下一步的实施工作将按照常规的贡献代码的方式进行。
Go 核心团队大约每周召开一次 proposal review meetings（提案审查会议），审查和讨论待决定的提案。
这个会议会就已达成共识的提案，将流程推进到下一步（通过标记提案已被接受或拒绝，或要求提供设计文档）。
每周会议结束后，会议记录会发布到 golang.org/s/proposal-minutes[1]，任何对哪些提案正在审议的小伙伴都可以关注这个 issues。
图片
新提案会被添加到 "Incoming" 这一栏。
每周的提案审查会议会优先审查 "活动"、"可能接受 "和 "可能拒绝" 栏中的所有问题。
如果还有剩余时间，则会选择将 "Incoming" 中的提案移至 "活跃" 栏。
图片
Incoming 栏中的提案被相关成员识别、讨论后，很快就会转挪动到 Proposal 栏下。但由于官方文档未有提及，因此主要做此补充说明。
图片
在每周的提案会议上，都会对 "活跃" 栏中的问题进行审查，以观察讨论中是否出现了共识。
提案审查小组还可以发表评论、提出建议、提出澄清性问题，并尝试重述提案，以确保每个人都同意讨论的具体内容。
图片
如果议题讨论似乎已达成接受提案的共识，提案审查小组会将该议题移至 "可能接受" 栏，并张贴评论，指出这一变化。
图片
再继续等待一段时间，一般可能是数周。观察后续的新的讨论情况和内容。再继续推进下一步流程。
如果提案讨论似乎已达成拒绝提案的共识，提案审查组就会将该问题移至 "可能拒绝 "栏。
如果提案审查小组认为不可能达成一致意见，因此默认不接受该提案是合适的，则也可将该提案移至 "可能否决 "栏。
等待时间和动作与 “可能接受” 会是一样的。
提案转到 "可能接受" 栏一周后，如果共识没有改变，提案审查小组就会将提案转到 "已接受" 一栏。
如果在这一周内进行了大量讨论，提案审查小组可能会将提案在 "可能接受" 栏中再保留一周，甚至将提案移回 "活跃" 栏。
一旦提案被标记为 "已接受"，就会贴上 "提案-已接受" 标签，它就会从 "提案" 里程碑移到 "工作" 里程碑中，问题也会被重新使用，以跟踪提案的实施工作。
图片
在提案转为 "可能已被否决" 一周后，如果共识没有改变，提案审查小组会将提案转到 "已被否决" 一栏。
如果在这一周内进行了重要讨论，提案审查小组可能会将提案在 "可能拒绝 "栏中再保留一周，甚至将提案移回 "激活" 栏。一旦提案被标记为 "拒绝"，该提案即被关闭。
图片
否决还会分为四种情况，处理流程类似，分别归类为：
如果讨论提案需要修改设计或补充信息，而这些信息在几周或更长时间内都无法获得，提案审查小组就会将提案移到 "搁置" 栏，并注明等待的内容。
图片
一旦准备就绪，任何可以编辑问题跟踪器的人都可以将提案移回 "激活 "栏，以便在下一次提案审核会议上进行审议。
图片
Go 提案的整体流程规范是比较明确的，但其并不是每个标签（栏）都一定会用到。从实际的情况来看，会根据 issues 讨论的激烈和复杂度还决定是否使用 “可能接受/可能拒绝” 等场景。
我们在官方提案文档上也会有提到提案的讨论一定是能得到适当、公平、及时、有记录的评估，能得到明确的答复。且要求在 “proposal review meetings” 上审查和记录。
图片
同时会发现，这套流程打标签挪栏目的动作，非常依赖人的行为。大部分的行为都相当的主观。
结合上次的已接受、已合并提案被 rsc 突然一句话撤销来看，规范也仅仅是规范。话事人的行径一旦有所缺失（例如：离职、生病等），这套流程就很有可能会跑不通了。
本文链接：http://www.28at.com/showinfo-26-15719-0.html给 Go 提问题？充分了解 Go 提案流程
声明：本网页内容旨在传播知识，若有侵权等问题请及时与本网联系，我们将在第一时间删除处理。邮件：2376512515@qq.com
上一篇： 语雀停机事件后，你也在找替代方案吗？
下一篇： 作为前端开发者，你没有必要学 Rust
Copyright © 2016-2023 天津谷骐科技有限公司 版权所有 sitemap.xml
违法及侵权请联系：2376512515@qq.com 津ICP备18001702号
津公网安备 12010102000574号
