工作组

工作组是临时性的社区倡议，致力于完成特别复杂、庞大或重要的任务。这可能包括：

• 进行重大重构。
• 添加非常复杂的新功能。
• 将生态系统 crate 上游化。
• 准备新版本发布。
• 启动新的主要文档工作。

正如您所见，这些并非纯粹的编程任务！维护一个主要的游戏引擎所涉及的许多困难、工作和争议都集中在日常或社交任务上。协调这些任务的工作可能与协调添加一个花哨的新功能一样重要！

基本规则

参与工作组时，请牢记以下几点：

• 工作组中没有领导者；工作组的创建者不拥有它。
• 这些是社交空间，任何人都可以受邀加入并参与聊天。
• 工作组是“即来即走”的。没有承诺，最少的时间压力，每个人都尽其所能贡献。
• 工作组做出的决定应该在小组中没有争议，并得到所有主要利益相关者的普遍同意，然后再提交给主题专家。
• 小组之间的沟通非常重要，因为一群了解设计流程的人会让您比平时更容易通过我们的审查流程。

工作组生命周期

工作组会经历三个松散的阶段：

1. 初步提案。
2. 设计和批准阶段。
3. 最后是大部分的实现工作。

这些阶段旨在轻量级，有时仅仅是一种形式。

提出建议

任何人都可以创建工作组，您只需要召集一些朋友并提交提案。

1. 确定工作组将专注于什么。这应该是紧密聚焦且可实现的！
2. 至少召集 3 人，包括您自己，愿意加入工作组。
3. 在 Discord 的 #engine-dev 频道中 Ping @Maintainer 角色，宣布你们的共同意图以及对计划的一两句话描述。

维护者将与相关的主题专家协商，对提案进行简要评估，并根据 Bevy 是否可以且想在此时探索该提案，给出支持或反对的意见。在这个阶段，您不需要具体的计划，只需要一个合理的论据，说明“为什么这对 Bevy 有用”以及“为什么在不久的将来实施该提案没有严重的障碍”。如果他们赞成，维护者将为您创建一个论坛频道，然后就可以开始工作了。

编写设计文档

您的首要任务是编写设计文档：阐述工作范围和总体实现策略。这是一个 设计文档的可靠示例，但您可以随意使用最适合您团队的格式。

准备就绪后，从相应的主题专家和维护者那里获得对广阔的愿景和目标的认可。这是主要的审查步骤：即使维护者和主题专家持怀疑态度，也应该保持宽容和支持，直到获得合适的文档进行评估。

实现设计文档

获得认可后，将设计文档发布到 GitHub Discussions，并添加 C-Design-Doc 标签 以供存档，并开始实施工作。将需要审查的 PR 发布到您小组的论坛线程中，寻求建议，并分担工作。有争议的 PR 仍然是 X-Controversial，但有了原则上的认可，事情应该会更顺利。

如果工作停滞不前，倡议失败，维护者可以（与主题专家和工作组本身协商）结束工作组。这是正常且预期的——项目会因为各种原因失败！但是，重要的是要保持工作组数量相对较少，并确保它们处于活跃状态，因为它们在吸纳新贡献者方面发挥着至关重要的作用。

一旦您在最初的设计文档中概述的实现工作完成，就可以结束工作组。不过，您可以随意创建另一个工作组来处理您宏伟愿景中的下一步！