我们在 2018 年底发布了 Rust 的第二个“版本”。这次发布的一部分是对 Rust 官网的改造。这项工作按时完成，但在发布时引发了一些争议，项目本身对参与者来说也非常困难和耗神。这篇回顾旨在记录从项目中吸取的教训，并为那些感兴趣但未直接参与的人提供项目背景。
这篇回顾旨在做到无责且着眼未来。重新纠缠已经发生的事情毫无益处，我们在此关注的是规划、项目管理和社区方面，而不是批判设计或实现。
吸取的教训
下次我们承担类似项目时，有哪些经验教训？
- 人优先：人比进度更重要；保持团队成员的健康、快乐和高效是项目管理最重要的方面。
- 开放沟通：对于项目沟通，我们应尽早尽可能地开放，即使项目性质意味着我们无法公开所有开发细节。
- 尽早获取反馈，并设定关于哪些反馈有用的期望。Rust 社区一直存在问题，即社区（多数）出于好意的反馈变得过于繁多，甚至达到骚扰的程度；我们对此没有解决方案。
- 做好管理反馈的准备，特别是要确保有足够的人员能够回应。
- 认识到项目的复杂性，并确保适当的项目管理。
- 项目应该有明确的负责人。
- 大型项目不应安排同时完成。
- 迭代工作，而不是追求“大爆炸式”发布。
- 考虑持续维护：有多少工作要做？谁来做？未能考虑这一点意味着首次发布时会面临更大的压力。
事后看来，很多点似乎显而易见。然而，每个决策都是一种权衡，尽管出于好意，但很容易在这些权衡中错误地衡量因素。事后看来，上述因素应该得到更多的重视。
在接下来的部分中，我将对总结中的一些教训进行展开，然后通过描述项目来提供一些背景信息。
沟通
主要关注设计而非其他软件项目的项目，其动态是不同的。例如，存在“委员会设计”的风险。在尝试进行开放开发时，由于“委员会”实际上是整个世界，这种风险会被放大。然而，事后看来，我们在网站项目上做得过度，不够开放。
我们可以更好地沟通项目的动机和限制。到 Beta 版本发布时，社区并没有和项目团队对网站需求有共同的理解。将来，我们可能会创建一个 pre-RFC 来讨论和沟通需求，而无需先开始设计工作。一旦制定了高级别设计，就应该积极向社区宣传。
除了征求反馈（见下文）外，我们还应沟通项目进展并分享贡献机会。回顾 GitHub 仓库时，很难看出进行了多少次迭代，或讨论了哪些问题。但是，如果从一开始就关注仓库，这些事情就会很清楚。
总的来说，沟通应该是一种对话。不幸的是，由于其他正在进行的项目，我们没有足够的时间进行这种对话。我们认为这里重要的教训是不要同时安排大型项目。
项目管理
我们低估了项目的规模，包括要完成的工作量以及需要协调的人数。结果，几个优秀的人员因项目而筋疲力尽。软件估算错误很常见；我们应该将人放在首位——没有哪个项目值得为此失去优秀的人员。之所以没有做到这一点，一个原因是没人觉得有权力退一步重新评估项目。总的来说，项目的所有权不明确，这导致了糟糕的领导力。此外，即便存在的所有权也没有很好地传达给更广泛的社区。
整个项目不仅凸显了我们相对缺乏经验（处理这类项目），也暴露了我们的流程负债。我们没有（并且在很大程度上仍然没有）建立流程和结构来在事情出错时支持项目和人员。这使得小问题滚雪球般变成大问题。对于网站项目，这又因为参与人数不足而加剧——他们工作过度，压力过大，这意味着即使我们知道正确的做法，他们也没有精力来实施良好的项目管理。
反馈
如前所述，我们认为如果在整个项目期间收集社区反馈，而不是将其压缩到最后两周，会更容易管理。除此之外，反馈期需要更好的人员配备。处理反馈是一项极其紧张和困难的经历。将来，我们应该确保有更多的人手，并尽可能地组织反馈，以确保其有用而不是压倒性的。
社区中的少数人超越了可接受的反馈范畴。再加上互联网讨论中的“群起而攻之”效应，这演变成了对网站开发者的骚扰。这种行为是不可接受的，我们期望社区有更好的表现。其中一些效果可能是无意的，这也是影响有争议的 RFC 讨论的问题。目前尚不清楚如何解决这个问题，但这值得我们研究。
背景
网站改造是 2018 版本的一部分。该版本是一项了不起的成就，但也付出了难以置信的工作量。新网站的计划始于当年年初，在版本规划的早期阶段。我们认为新网站及时为版本做好准备很重要，以期获得最大影响，也因为旧网站不符合我们的目标（详见下文）。由于时间安排，可用于网站工作的人员比可能的情况要少，领导和监督的时间和精力也较少，参与其中的人还面临许多相互竞争的项目。
旧网站是在原有基础上逐步添加内容的，但除了首次发布之外，从未在内容或设计上进行过重大工作。本质上，网站重写是一个全新的项目，而我们在这个领域没有组织经验（有一些个人拥有 Web 开发经验，但这些经验没有机会转化为机构知识）。
最初的网站非常适合其目的和受众：向感兴趣的黑客展示一个小型研究项目。然而，随着项目和网站的发展，网站变得越来越不合适。
核心团队一致认为旧网站需要更换。尽管社区中的许多人对其有美好的回忆（毕竟，这是大多数人与 Rust 的第一次接触），但旧网站在几个方面确实客观上不足：信息难以查找，大部分内容过时，页面拥挤且组织混乱，难以更新和本地化（导致信息缺失和过时），并且缺失了社区和生态系统的许多部分（例如，没有任何关于在嵌入式系统中使用 Rust 的提及）。
在设计方面，旧网站简洁整洁，但存在问题——难以突出文本，版块之间对比度低（使其难以阅读），并且缺乏 Rust 生态系统和社区的活力。它是为构建它的那部分受众设计的，而我们对 Rust 的愿景以及网站的受众范围已经变得更广。
2018 版本的目标之一是吸引更广泛的受众。网站是实现这一目标的关键工具。然而，显然设计和大部分内容都需要彻底改造。
这听起来像是一个相对标准的网站项目，旨在制作一个相对较小的网站。然而，事后看来，限制条件非常困难——需要使大量信息易于获取，同时又不让网站内容过多；我们需要服务来自不同背景的新手以及寻找信息的现有 Rust 用户；之前的“小”网站已经变得庞大，有大量内容需要更新或替换。
工作启动缓慢，进展也慢，部分原因是人员不足。内容是从 2018 年年中开始向各团队征集的。我们极大地低估了内容制作和收集的复杂性。内容制作和评审都进展缓慢；存在许多未被认识到的依赖项。我们需要大量的迭代。本质上，网站变成了一个由 50 个人参与的项目，但却像一个只有一两人参与的项目那样进行管理。我们在大部分内容尚未准备好之前就开始构建网站，这是一个众所周知的 Web 开发反模式。
尽管如此，很大程度上由于英雄般的努力，网站还是按时完成了。所有计划中的内容都已到位并经过精心打磨。我们拥有引人注目且充满活力的新设计，以及使得网站更容易保持最新和翻译的实现。重要信息易于查找，网站对更广泛的受众开放，特别是对 Rust 一无所知的开发者、工程管理人员以及更广泛的潜在贡献者群体。
不幸的是，这一切都只是勉强按时完成。这不仅意味着最后阶段的工作紧张而仓促，还意味着我们没有足够的时间进行测试和收集反馈：只有两周时间来收集和处理 Beta 版本的反馈。由于这个原因以及之前沟通不足，涌入了大量评论，其中一些是强烈负面的，一些则是恶意攻击或骚扰。团队没有足够的资源或时间来妥善回应。
当然，作为一个软件项目，存在一些 Bug（其中大部分很快得到了解决），以及一些缺失的功能（特别是本地化，这使得许多非英语母语访客的网站体验变差）。
发布后，对内容和设计进行了完善，修复了 Bug，并尝试组建了一个团队来维护网站。不幸的是，社区中一些不良行为仍在继续。几个参与版本发布、特别是网站项目的成员因精疲力尽而离开了 Rust 或大幅减少了工作。
结论
总之，我们认为网站是一个成功（但不完美）的产品，但交付方式欠佳。许多出错的问题是相当常见的项目管理问题。我们认为最高层次的教训是 Rust 组织应该改进其项目和产品管理。（需要澄清的是，我们认为这是一个组织层面的问题，而不是对任何个人在该领域技能的评价）。我们通常的开发风格是迭代和增量的；在处理更大、不那么增量的项目时，我们需要投入更多资源、管理和协调，以确保成功。项目人员不足，除了显而易见的问题之外，这意味着即使我们知道正确的做法，我们也没有人员、时间或精力去执行。
最后，感谢所有构建网站以及协助撰写这篇回顾的人。