管理和解决讨论

大多数讨论不需要正式的解决流程。这些 MDN 讨论指南适用于需要及时解决、已停滞、有陷入停滞风险或其他未朝着结论方向发展且可以从正式流程中获益的讨论。

1. 每个讨论都保存在 / 根植于GitHub 上的讨论中。此 GitHub 讨论充当主题的“真相来源”。
   • 为了保持连续性，请记住将任何会议和异步讨论的摘要和笔记记录到此 GitHub 讨论线程中。
2. 每个讨论主题都需要一个驱动者。驱动者通常是讨论的发起者，但也可能是另一位致力于解决讨论的人。驱动者的职责包括：
   • 引导对话。
   • 让大家知道讨论的存在。
   • 设定反馈和时间线，告知大家，根据需要更改时间线，并在适当的时候坚持时间线。
   • 在所有相关渠道（例如 Slack、Discord、在 GitHub 上标记人员以及其他适当的渠道）中告知特定日期所需的反馈。
   • 在社区和每周会议上提出该主题。
   • 如有必要，组织一次同步的在线面对面会议（如果有分歧）。面对面会议应该很少，只有在必要时才进行（见第 3 点）。
   • 在Discussions上相关讨论中总结面对面会议的结论。
   • 指导讨论结果的实施或与相应的团队负责人合作，以确保结果得到实施。
3. 关于讨论的面对面会议仅在存在分歧时才应召开。
   • 必须在所有相关的沟通渠道（例如 Slack、Discord、GitHub 讨论等）中宣布面对面会议。
   • 每次面对面会议的结论必须输入 GitHub 讨论中，该讨论是讨论的真相来源。
   • 驱动者负责召集会议，通知所有相关人员，并将结果报告回 GitHub 讨论中。

达成一致后，即可宣布解决方案，结束讨论，并开始执行实施解决方案的计划！

每个讨论的时间线都不同，具体取决于主题的复杂性和共识水平。理想情况下，大多数讨论应在两个月内解决，以便在各种内部会议上处理该主题。此时间框架确保考虑不同的观点，并让所有相关人员有机会参与讨论。

1. 发布讨论。
2. 指定驱动者。如果驱动者与讨论发起者不同，则确定驱动者。
3. 确定任何关键利益相关者和所需的审批者（需要对主题发表意见并批准的人员），如果有的话。
4. 告知审批者和其他重要人员讨论内容以及您提出的时间线。如有必要，两周后再次联系他们，然后每周联系一次，直到他们提供反馈。
5. 将讨论主题添加到相关会议的议程中。
6. 一个月后，筛选反馈、讨论和协议，并制定一个初步计划，将反馈合并到可能的行动计划中。
7. 重新告知所有相关方（包括以任何方式参与讨论的每个人）并重新请求反馈。
8. 在第二个月期间，继续与社区联系，征求他们对拟议计划的反馈，并根据任何新的反馈更新计划。重复此过程。
9. 如果存在争议点，请安排在线同步面对面会议以解决任何剩余的分歧（如讨论线程中所记录的）。
10. 在第二个月期间保持讨论线程活跃，同时与社区合作以寻求解决方案。
11. 创建解决实施计划的问题并付诸实施。（问题报告指南）
12. 关闭讨论。

如果讨论涉及联系专家并征求他们的反馈，则可以根据需要延长上述时间线。

达成解决方案很重要，但也要记住，并非所有讨论都能达成可实施的解决方案。讨论的解决结果可能是“未做出任何决定”或“让我们一年后再重新审视此事”。这些都是有效的解决方案！

当讨论以无可实施的解决方案结束时，请在讨论中注明，然后将讨论标记为已解决并关闭。