皇上,还记得我吗?我就是1999年那个Linux伊甸园啊-----24小时滚动更新开源资讯,全年无休!

Rust 创始人谈 Rust 2019 和未来:社区应限制成长速度

本文翻译自 Graydon 的个人博客:Rust 2019 and beyond: limits to (some) growth.

提案需要通过流程进行控制,以避免发展过快导致不良后果。Rust 创始人 Graydon Hoare 针对语言资源共享以及处理社区个体压力两部分提出建议。

本文作者 Graydon Hoare 是 Rust 语言创始人。众所周知,Rust 最初是 Mozilla 公司员工 Graydon Hoare 的私人项目。2009 年 Mozilla 开始赞助 Rust,并有若干 Mozilla 员工参与 Rust 语言的设计和研发。2013 年 8 月,Graydon Hoare 卸任 Rust 技术负责人职位。

需要说明的是,Graydon Hoare 表示文章仅代表其本人的观点和立场,与其他任何人无关,甚至不再是以 Rust 积极参与者的身份在表达,而且这些建议在很大程度上适用于许多项目。Rust 只是一个案例,不过目前恰好适合进行一次年终总结。

Graydon Hoare 对 Rust 项目的发展轨迹也非常满意,之所以写下这篇文章是为了保持它的健康,以及让它在轨道上如期行驶。更重要的是,希望 Rust 能避免他以“局外人”身份进行开发时观察到的这些问题。

Rust 创始人 Graydon Hoare 对 Rust 的发展,表达了两个具体需要注意与改善建议的部分,一是必须要共享技术文件与成品 (Artifacts),特别是语言定义本身,再来则是要把注意力放回到社区成员 —— 个体身上,关注参与工作的社区个人的压力,Graydon Hoare 提到,这些必须要及早控制,以有计划的方式进行。

Graydon Hoare 认为,任何事物因缺乏控制机制而发展过快,最终都会导致不好的后果,并列举了几个 Rust 项目对变化率与增长率进行限制的控制案例。他提到,这对于项目的成功有很大的帮助,像 Bors Queue 通常是用来对程序范围内的正确性进行修改,而 Crater Runs 则是用来修正整个生态系统的正确性,而基于时间的版本发布 (Time-based releases) 也是流程控制之一,用来决定是否需要放弃遵守时间表,或者是削减功能。

另外,Rust 还增加了一些制度化不太明显,但仍十分重要的社区结构,以管理参与项目的人员成长,例如 RFC 流程,包括关于形式、内容、时间、参与者组合以及讨论重大变化时讨论的规则等,另外,治理模型也是其中的一种控制方式,用于划分责任区域、必要时的权限授予、参与者的角色和期望等。

Graydon Hoare 认为,目前 Rust 仍有两大领域缺乏功能性的管理,第一是语言的发展本身,这需要有更多的规范;第二是人,亦即社区成员。Graydon Hoare 提到,当社区成员过于疲惫,可能会做出糟糕的决定,而且社区也可能因成员拥有的资源不均而导致发展偏斜,具有特权、精力充沛、收入丰厚或是其他优越条件的人,才能跟上社区的发展。人们也常为赢得争论,使得言论自由变得狭隘,成员也会因为倦怠、表现不佳而离开项目,社区甚至会因为恶意指责、语言仇恨或挫折而分裂。

为此,Graydon Hoare 提出了几项建议,他认为 Rust 项目现在应该暂停、反思、集思广益并执行一些控制措施。他认为最重要的是,社区要学会拥抱负面的语言,试着接纳消极、负面的意见,像是“Rust 永远不会有某功能”这样的话语,唯有沉住气冷静地思考,才能获得长远的视野。

除此之外,社区还需要设立一些限制机制,针对诸如编译器编译代码行数、Bootstrap 的总时间数、每日 AWS 执行个体的花费成本、类别系统中推理规则数量等,找出有意义的指标,制定机制以限制发展速度。再则就是基于个人时间预算的活动限制 —— 计算出在不疲惫的情况下,每个团队有多少可用的时间,或是每个版本的发布需要耗费多少人力和时数,并移除超过这个时间范围可以做的工作。

项目维护团队应在特定的讨论上加以速率限制或是提供冷静期,因为有时从外部看来,社区的整体讨论过于激烈,而限制讨论是简单的可以“降温”的方式,能让讨论焦点重新回到主题上,而不会被个人行为影响。另外,还应设置一个额外的项目团队,主要负责审核其他团队的预算以达“负载均衡”,Graydon Hoare 认为这对于团队是有帮助的,让第三方而不是团队中的大多数成员来判断事情的进展,因为大多成员会因为抱着预设的立场而对大多数的事情都说好。

转自 https://www.oschina.net/news/103234/rust-2019-and-beyond

分享到:更多 ()