likes
comments
collection
share

给 Go 提问题?充分了解 Go 提案流程

作者站长头像
站长
· 阅读数 27

大家好,我是煎鱼。

前段时间分享了《被 Go 团队打脸了,已接受的提案也能一句话推翻!!!》引发了大家对 Go 的大范围讨论。但后面发现一个问题,似乎行业内从未给大家讲解过 Go 变更语言规范和提案流程。

今天这篇文章将给大家分享,也可以借此学习社区的运作模式。

前言

在官方资料《Proposing Changes to Go》中,给出了一系列的提案指导意见、流程规划以及目标。

Go 语言项目,开发过程以设计为驱动

有以下的要求: 在实施重要的语言、库或工具更改(包括 Go 主仓库和所有 golang.org/x 仓库中的 API 更改,以及 go 命令的命令行更改)之前,必须首先进行讨论,有时还需要正式文档化。

提案流程是怎么样的

提案(proposal)过程指的是对提案进行审查并决定是否接受或拒绝提案的过程。

整个提案的流程是使用 GitHub 中的 Label(标签)来做流程规范的,在此也可以称其为分类的栏目。

创建提案描述

第一步,提案作者需要创建一个简要的问题描述提案。一般对应提 issues 时的对应分类:

给 Go 提问题?充分了解 Go 提案流程

而对应的不同的分类,会给出不同的 issues 模板:

给 Go 提问题?充分了解 Go 提案流程

基本上要满足社区所要求的模板才会有核心团队的人交流,否则一开口就会让你去补充内容。

此时是不需要设计文档的。

进行提案分类

第二步,需要对提案进行问题讨论和标签分类、跟踪。一般会将提案分为以下三种结果之一:

  • 接受提案(Accept proposal)
  • 拒绝提案(Decline proposal)
  • 索要设计文档(Ask for a design doc)

如果提案被接受或拒绝,则这一项完成。否则,预计需要基于更详细的设计进行进一步的问题讨论。

提供设计文档

第三步,提案作者编写和提供设计文档,以详细说明提议的设计并解决初始讨论中提出的问题。也就是提出提案者需要给出设计解决自己提出的问题。

最终讨论

完成第三步后,社区会结合设计文档和问题进行讨论,需要提案作者进行及时的修订。再进行多轮讨论。

最终确定提案的走向,两种结果之一:

  • 接受提案
  • 拒绝提案

在提案被接受或拒绝后,下一步的实施工作将按照常规的贡献代码的方式进行。

提案有哪些状态

Proposal Review(提案审查)

Go 核心团队大约每周召开一次 proposal review meetings(提案审查会议),审查和讨论待决定的提案。

这个会议会就已达成共识的提案,将流程推进到下一步(通过标记提案已被接受或拒绝,或要求提供设计文档)。

每周会议结束后,会议记录会发布到 golang.org/s/proposal-…,任何对哪些提案正在审议的小伙伴都可以关注这个 issues。

给 Go 提问题?充分了解 Go 提案流程

Incoming(传入)

新提案会被添加到 "Incoming" 这一栏。

每周的提案审查会议会优先审查 "活动"、"可能接受 "和 "可能拒绝" 栏中的所有问题。

如果还有剩余时间,则会选择将 "Incoming" 中的提案移至 "活跃" 栏。

给 Go 提问题?充分了解 Go 提案流程

Incoming 栏中的提案被相关成员识别、讨论后,很快就会转挪动到 Proposal 栏下。但由于官方文档未有提及,因此主要做此补充说明。

给 Go 提问题?充分了解 Go 提案流程

Active(活跃)

在每周的提案会议上,都会对 "活跃" 栏中的问题进行审查,以观察讨论中是否出现了共识。

提案审查小组还可以发表评论、提出建议、提出澄清性问题,并尝试重述提案,以确保每个人都同意讨论的具体内容。

给 Go 提问题?充分了解 Go 提案流程

Likely Accept(可能接受)

如果议题讨论似乎已达成接受提案的共识,提案审查小组会将该议题移至 "可能接受" 栏,并张贴评论,指出这一变化。

给 Go 提问题?充分了解 Go 提案流程

再继续等待一段时间,一般可能是数周。观察后续的新的讨论情况和内容。再继续推进下一步流程。

Likely Decline(可能拒绝)

如果提案讨论似乎已达成拒绝提案的共识,提案审查组就会将该问题移至 "可能拒绝 "栏。

如果提案审查小组认为不可能达成一致意见,因此默认不接受该提案是合适的,则也可将该提案移至 "可能否决 "栏。

等待时间和动作与 “可能接受” 会是一样的。

Accepted(已接受)

提案转到 "可能接受" 栏一周后,如果共识没有改变,提案审查小组就会将提案转到 "已接受" 一栏。

如果在这一周内进行了大量讨论,提案审查小组可能会将提案在 "可能接受" 栏中再保留一周,甚至将提案移回 "活跃" 栏。

一旦提案被标记为 "已接受",就会贴上 "提案-已接受" 标签,它就会从 "提案" 里程碑移到 "工作" 里程碑中,问题也会被重新使用,以跟踪提案的实施工作。

给 Go 提问题?充分了解 Go 提案流程

Declined(已拒绝)

在提案转为 "可能已被否决" 一周后,如果共识没有改变,提案审查小组会将提案转到 "已被否决" 一栏。

如果在这一周内进行了重要讨论,提案审查小组可能会将提案在 "可能拒绝 "栏中再保留一周,甚至将提案移回 "激活" 栏。一旦提案被标记为 "拒绝",该提案即被关闭。

给 Go 提问题?充分了解 Go 提案流程

否决还会分为四种情况,处理流程类似,分别归类为:

  • 因重复而被拒绝(Declined as Duplicate)
  • 因不可行而被拒绝(Declined as Infeasible)
  • 因撤回而被拒绝(Declined as Retracted)
  • 因已过时而被拒绝(Declined as Obsolete)

Hold(搁置)

如果讨论提案需要修改设计或补充信息,而这些信息在几周或更长时间内都无法获得,提案审查小组就会将提案移到 "搁置" 栏,并注明等待的内容。

给 Go 提问题?充分了解 Go 提案流程

一旦准备就绪,任何可以编辑问题跟踪器的人都可以将提案移回 "激活 "栏,以便在下一次提案审核会议上进行审议。

给 Go 提问题?充分了解 Go 提案流程

总结

Go 提案的整体流程规范是比较明确的,但其并不是每个标签(栏)都一定会用到。从实际的情况来看,会根据 issues 讨论的激烈和复杂度还决定是否使用 “可能接受/可能拒绝” 等场景。

我们在官方提案文档上也会有提到提案的讨论一定是能得到适当、公平、及时、有记录的评估,能得到明确的答复。且要求在 “proposal review meetings” 上审查和记录。

给 Go 提问题?充分了解 Go 提案流程

同时会发现,这套流程打标签挪栏目的动作,是非常依赖人的行为。大部分的行为都相当的主观。

结合上次的已接受、已合并提案被 rsc 突然一句话撤销来看,规范也仅仅是规范。话事人的行径一旦有所缺失(例如:离职、生病等),这套流程就很有可能会跑不通了。

文章持续更新,可以微信搜【脑子进煎鱼了】阅读,本文 GitHub github.com/eddycjy/blo… 已收录,学习 Go 语言可以看 Go 学习地图和路线,欢迎 Star 催更。

Go 图书系列

推荐阅读

转载自:https://juejin.cn/post/7295276751595847732
评论
请登录