管理和解决讨论
我们鼓励 MDN 社区就 MDN Web Docs 文档 发起和参与讨论。有些讨论不需要解决或达成一致，但如果需要，发起者自然会希望他们的提议能得出合乎逻辑的结论。大多数这类讨论能很快达成广泛共识。然而，有些讨论可能因为缺乏明确的解决路径，或因为意见分歧而陷入停滞。本文提供指导方针；建议一些流程和策略，以帮助您在合理的时间内将讨论推向解决，避免陷入僵局。
将讨论推向解决
大多数讨论不需要正式的解决流程。这些 MDN 讨论指南是为那些需要及时解决、已陷入停滞、有陷入停滞风险，或否则没有朝着结论发展并将从正式流程中受益的讨论而设。
-
每次讨论都会在 GitHub 讨论区 进行/植根。此 GitHub 讨论作为该主题的“事实来源”。
- 为保持连续性，请记住在此 GitHub 讨论串中记录任何会议和异步讨论的摘要和笔记。
-
每个讨论主题都需要一个牵头人。牵头人通常是讨论的作者，也可以是致力于解决该讨论的其他人。牵头人负责
- 引导对话。
- 让人们知道讨论的存在。
- 设定反馈、时间表，告知大家，根据需要更改时间表，并酌情遵守时间表。
- 通知所有相关渠道 - Slack、Discord、GitHub 上的提及，以及其他合适的渠道 - 需要在特定日期前提供反馈。
- 在社区和每周会议上提出该主题。
- 如果需要（如果存在分歧），组织一次同步的在线面对面会议（参见 #3）。面对面会议应是罕见的，并且仅在需要时召开。
- 在 讨论区 中总结面对面会议的结论。
- 引导讨论结果的实施，或与相应团队负责人合作，确保结果得到实施。
-
关于讨论的面对面会议应仅在存在分歧时召开。
- 面对面会议必须在所有相关的 沟通渠道 公布，例如 Slack、Discord、GitHub 讨论等。
- 每次面对面会议的结论必须录入 GitHub 讨论区，这是讨论的事实来源。
- 牵头人负责召集会议、通知所有相关方，并将结果报告回 GitHub 讨论区。
一旦达成共识，就可以宣布解决方案，关闭讨论，并将实施解决方案的计划付诸行动！
讨论进展和时间表
每次讨论的时间表会因主题的复杂性和共识水平而异。理想情况下，大多数讨论应在两个月内得到解决，以便在各种内部会议上处理该主题。这个时间框架确保了考虑了不同的观点，并且每个感兴趣的人都有机会参与讨论。
- 发布讨论。
- 指定一位牵头人。如果牵头人不是讨论的发起者，则确定牵头人。
- 识别任何关键利益相关者和所需的批准者（需要就该主题发表意见并批准的人员），如果有的话。
- 告知批准者和其他重要人员有关讨论和您建议的时间表。如有必要，在 2 周后再次联系他们，之后每周联系一次，直到他们提供反馈。
- 将讨论主题添加到相关会议的议程中。
- 一个月后，整理反馈、讨论和共识，并制定一个初步计划，将反馈纳入可行的行动计划。
- 重新告知并再次请求所有相关方（包括以任何方式参与讨论的每个人）对提议的计划提供反馈。
- 在第二个月期间，持续向社区征求关于提议计划的反馈，并根据新的反馈对计划进行更新。重复此过程。
- 如果存在争议点，安排一次在线的、同步的、面对面的会议来解决任何剩余的分歧（如讨论串中所记录）。
- 在第二个月期间，在努力与社区达成解决方案的过程中，保持讨论串的活跃。
- 创建问题以实施解决方案计划并付诸行动。（报告问题指南）
- 关闭讨论。
如果讨论涉及联系专家并获得反馈，则上述时间表可以根据需要延长。
无定论的解决方案
达成解决方案很重要，但也要记住，并非所有讨论都能产生可实施的解决方案。讨论的解决方案可能是“不作任何决定”或“一年后我们再重新讨论”。这些都是有效的解决方案！
当讨论结束时没有可实施的解决方案，请在讨论中注明，然后将讨论标记为已解决。