<ins id="iFMVB"></ins>

  1. <label id="iFMVB"><option id="iFMVB"><caption id="iFMVB"></caption></option></label><strike id="iFMVB"></strike><acronym id="iFMVB"><li id="iFMVB"><dd id="iFMVB"><table id="iFMVB"><link id="iFMVB"><acronym id="iFMVB"><option id="iFMVB"><meter id="iFMVB"></meter></option><source id="iFMVB"></source></acronym></link></table></dd></li></acronym><sub id="iFMVB"><rt id="iFMVB"><keygen id="iFMVB"></keygen></rt></sub>
  2. <form id="iFMVB"><meter id="iFMVB"><map id="iFMVB"></map></meter></form>
  3. <span id="iFMVB"></span>
  4. <strong id="iFMVB"></strong>

  5. <dfn id="iFMVB"><nav id="iFMVB"></nav></dfn>

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

        2020年12月06日 08:40 次阅读 稿源:开源中国 条评论

        本文作者 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 认为这对于团队是有帮助的,让第三方而不是团队中的大多数成员来判断事情的进展,因为大多成员会因为抱着预设的立场而对大多数的事情都说好。

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

        相关文章:

        Rust 2018即将到来:设法从Rust 2015过渡

        Rust 2018 年度调查报告发布

        Rust 全新官网已上线测试 这样的风格你喜欢吗?

        腾讯云

        活动入口:

        腾讯云 - 热销云产品年付3折起

        对文章打分

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

        2 (13%)
        已有 条意见

        300-250.jpg

          最新资讯

          加载中...

          今日最热

          加载中...

          新品速递

          • 微软官方商城新春特惠专区上线 Surface最高降千元2020-12-06

            Xbox新品上市,Surface多达千元折扣。

          • 企业级性能云服务器限时2折起2020-12-06

            更高性能的云服务器 限时红包最高¥1888

          • 腾讯云AMD云服务器拼团活动2020-12-06

            最高可获赠40个月时长

          热门评论

            招聘


            Advertisment ad adsense googles cpro.baidu.com
            created by ceallan