我们在 2018 年底发布了 Rust 的第二个“版本”。该版本的一部分是对 Rust 网站的改版。这项工作按时完成，但在发布时引发了一些争议，而且该项目本身对参与者来说是困难且令人精疲力尽的。本次回顾旨在记录该项目汲取的教训，并为那些感兴趣但未直接参与的人提供项目背景。

本次回顾旨在做到 不责备 和面向未来。重新审理已经发生的事情没有任何好处，我们在这里感兴趣的是规划、项目管理和社区方面，而不是批评设计或实施。

经验教训

在下次承担类似项目时，我们吸取了哪些经验教训？

• 以人为本：人比进度表更重要；保持人们的健康、快乐和高效是管理项目最重要的方面。
• 公开沟通：我们应该尽可能早地就项目进行公开沟通，即使项目的性质意味着我们不能公开所有开发过程。
• 尽早获取反馈，并设定关于哪种反馈有用的期望。Rust 社区中一直存在问题，即（大多数情况下）来自社区的善意反馈变得令人难以承受，以至于变成骚扰；我们还没有解决这个问题。
• 准备好管理反馈，特别是要有足够的人员来回应。
• 认识到项目的复杂性，并确保适当的项目管理。
• 项目应有明确的所有权。
• 大型项目不应安排在同一时间完成。
• 迭代式工作，而不是进行“大爆炸”式发布。
• 考虑持续维护：有多少工作要做？谁来做？不考虑这一点意味着初始版本面临更大的压力。

事后看来，这些观点似乎很明显。然而，每个决定都是一种权衡，尽管有最好的意图，也很容易在这些权衡中错误地权衡因素。事后看来，以上这些因素应该给予更多的重视。

在接下来的章节中，我将详细阐述总结中的一些教训，然后通过描述项目来提供一些背景信息。

沟通

主要关注设计的项目与大多数其他软件项目具有不同的动态。例如，存在“委员会设计”的风险。当试图进行开放式开发时，这种风险会放大，因为“委员会”实际上是全世界。然而，事后看来，我们过度了，在网站项目上不够开放。

我们可以更好地沟通项目的动机和限制。在 Beta 版本发布时，社区并没有与项目团队分享对网站要求的概念化。未来，我们可能会创建一个预 RFC 来讨论和沟通需求，而无需启动设计工作。一旦做出高层设计，就应积极向社区推广。

除了征求反馈（见下文）外，我们还应该沟通项目进展，并分享贡献机会。回顾 GitHub 上的存储库时，不清楚发生了多少迭代，或者讨论了哪些问题。但是，如果从一开始就关注存储库，这些事情就很清楚。

一般来说，沟通应该是一场对话。不幸的是，由于其他正在进行的项目，我们没有足够的人员和足够的时间来进行对话。我们认为这里一个重要的教训是不应同时安排大型项目。

项目管理

我们低估了项目的规模，包括需要完成的工作量和需要协调的人员数量。结果，几个优秀的人员因该项目而筋疲力尽。软件估算中的错误很常见；我们应该优先考虑人 - 任何项目都不值得为此失去优秀的人员。没有发生这种情况的一个原因是，没有人觉得有权退一步并重新评估该项目。总的来说，项目的所有权不明确，这导致了糟糕的领导。此外，确实存在的所有权没有很好地传达给更广泛的社区。

整个项目不仅突出了我们（在同类项目方面的）相对缺乏经验，还突出了我们的流程债务。我们没有（并且在很大程度上仍然没有）创建流程和结构来支持项目和人员在出现问题时。这使得小问题像滚雪球一样变成大问题。对于网站项目，由于没有足够的人员参与而加剧了这种情况 - 他们变得工作过度和压力过大，这意味着他们没有足够的精力来实施良好的项目管理，即使我们知道应该怎么做。

反馈

如前所述，我们认为如果在整个项目中收集社区反馈，而不是压缩到最后两周，反馈将更容易管理。除此之外，我们需要为反馈期配备更好的人员。处理反馈是一次极其紧张和困难的经历。未来，我们应确保有更多的人员，并尽可能地构建反馈，以确保其有用而不是压倒性的。

少数社区成员的反馈超出了可接受的范围。再加上互联网上讨论的“一拥而上”效应，这变成了对网站开发人员的骚扰。这种行为是不可接受的，我们希望社区能做得更好。一些影响是无意的，这也是影响有争议的 RFC 讨论的问题。目前尚不清楚如何解决这个问题，但这是我们应该调查的事情。

背景

网站改版是 2018 版的一部分。该版本是一项了不起的成就，但工作量巨大。新网站是从年初开始计划的，在版本规划的早期阶段。我们认为新网站及时为该版本做好准备非常重要，以获得最大的影响，并且因为之前的网站不符合我们的目标（更多内容见下文）。由于时间安排，与可能的情况相比，有更少的人员可以参与网站工作，领导和监督的时间和精力减少，并且参与人员有许多相互竞争的项目。

之前的网站是逐步添加的，但从未对内容或设计进行过重大工作（初始版本除外）。本质上，网站重写是一个全新的项目，而我们在该领域没有组织经验（有些人有网络开发经验，但没有机会让这些经验成为机构知识）。

最初的网站非常适合其目的和受众：向感兴趣的黑客展示一个小型研究项目。然而，随着项目和网站的增长，该网站变得越来越不合适。

核心团队一致认为旧网站需要更换。尽管社区中的许多人对它有美好的回忆（毕竟，这是大多数人第一次接触 Rust），但旧网站在几个方面存在客观的不足：信息难以查找，许多内容已过时，页面拥挤且组织不佳，难以更新和本地化（导致信息丢失和过时），并且缺少社区和生态系统的许多部分（例如，任何关于在嵌入式系统中使用 Rust 的提及）。

在设计方面，之前的网站简单整洁，但存在一些问题 - 难以强调文本，各部分之间的对比度很小（使其难以阅读），并且缺乏 Rust 生态系统和社区的活力。它是为构建它的受众而设计的，而我们对 Rust 的雄心壮志以及网站的受众，此后都变得更大。

2018 版的目标之一是吸引更广泛的受众。该网站是实现该目标的关键工具。然而，很明显，设计和大部分内容都需要进行彻底的修改。

这听起来像一个相对标准的网站项目，可以制作一个相对较小的网站。然而，事后看来，这些限制是困难的 - 有很多信息需要变得易于访问，而不会使网站不堪重负；我们需要为具有不同背景的新手服务，以及希望查找信息的现有 Rust 用户；之前的“小型”网站已经变得很大，并且有很多内容需要更新或替换。

工作开始得很慢，进展也很慢，部分原因是人员配置问题。2018 年中期，从各团队寻求内容。我们大大低估了制作和收集内容的复杂性。内容制作缓慢且审查缓慢；存在许多未识别的依赖关系。我们需要大量的迭代。本质上，该网站成为了一个有 50 人左右的项目，但管理方式就像一个有一两个人的项目。我们是在大多数内容准备就绪之前构建网站，这是一个众所周知的 Web 开发反模式。

尽管如此，并且主要由于英雄般的努力，网站还是按时完成了。所有计划的内容都存在且经过润色。我们有一个引人注目的、充满活力的新设计，以及一个使网站更容易保持最新和翻译的实现。基本信息很容易找到，并且该网站可以被更广泛的受众访问，特别是那些对 Rust 一无所知的开发人员、工程管理人员以及更广泛的潜在贡献者。

不幸的是，这只是及时完成。除了意味着最后阶段的工作紧张而仓促之外，还意味着我们没有足够的时间进行测试和反馈：只有两周时间来收集和解决关于 Beta 版本的反馈。由于这一点和早先缺乏沟通，涌入了大量的评论，其中一些评论带有明显的负面情绪，还有一些是钓鱼或骚扰。团队没有资源或时间做出很好的回应。

当然，作为一个软件项目，存在一些错误（其中大部分已迅速解决）和一些缺失的功能（特别是本地化，这使得该网站对于许多不以英语为母语的访问者来说体验更差）。

发布后，内容和设计得到了润色，错误得到了解决，并且我们试图创建一个团队来维护该网站。不幸的是，社区的一些不良行为仍在继续。参与该版本特别是该网站的一些人筋疲力尽，离开了 Rust 或大幅减少了工作。

结论

总而言之，我们认为该网站是一个成功的（但并不完善的）产品，但交付方式欠佳。很多出现的问题都是相当常见的项目管理问题。我们认为最重要的一点教训是，Rust 组织应该改进其项目和产品管理。（需要明确的是，我们认为这是一个组织问题，而不是对任何个人在该领域技能的评论）。我们通常的开发风格是迭代和增量的；当处理更大、增量更少的项目时，我们需要投入更多的资源、管理和协调，以确保成功。该项目人员不足，除了显而易见的问题之外，这意味着即使我们知道正确的事情要做，我们也没有人员、时间或精力去做。

最后，感谢所有构建该网站以及帮助进行本次回顾的人。