管理和解決討論
我們鼓勵 MDN 社群就 MDN Web Docs 文件 發起和參與討論。有些討論不需要解決或達成一致，但如果需要，發起者自然會希望他們的提議能得出合乎邏輯的結論。大多數這類討論能很快達成廣泛共識。然而，有些討論可能因為缺乏明確的解決路徑，或因為意見分歧而陷入停滯。本文提供指導方針；建議一些流程和策略，以幫助您在合理的時間內將討論推向解決，避免陷入僵局。
將討論推向解決
大多數討論不需要正式的解決流程。這些 MDN 討論指南是為那些需要及時解決、已陷入停滯、有陷入停滯風險，或否則沒有朝著結論發展並將從正式流程中受益的討論而設。
-
每次討論都會在 GitHub 討論區 進行/植根。此 GitHub 討論作為該主題的“事實來源”。
- 為保持連續性，請記住在此 GitHub 討論串中記錄任何會議和非同步討論的摘要和筆記。
-
每個討論主題都需要一個牽頭人。牽頭人通常是討論的作者，也可以是致力於解決該討論的其他人。牽頭人負責
- 引導對話。
- 讓人們知道討論的存在。
- 設定反饋、時間表，告知大家，根據需要更改時間表，並酌情遵守時間表。
- 通知所有相關渠道 - Slack、Discord、GitHub 上的提及，以及其他合適的渠道 - 需要在特定日期前提供反饋。
- 在社群和每週會議上提出該主題。
- 如果需要（如果存在分歧），組織一次同步的線上面對面會議（參見 #3）。面對面會議應是罕見的，並且僅在需要時召開。
- 在 討論區 中總結面對面會議的結論。
- 引導討論結果的實施，或與相應團隊負責人合作，確保結果得到實施。
-
關於討論的面對面會議應僅在存在分歧時召開。
- 面對面會議必須在所有相關的 溝通渠道 公佈，例如 Slack、Discord、GitHub 討論等。
- 每次面對面會議的結論必須錄入 GitHub 討論區，這是討論的事實來源。
- 牽頭人負責召集會議、通知所有相關方，並將結果報告回 GitHub 討論區。
一旦達成共識，就可以宣佈解決方案，關閉討論，並將實施解決方案的計劃付諸行動！
討論進展和時間表
每次討論的時間表會因主題的複雜性和共識水平而異。理想情況下，大多數討論應在兩個月內得到解決，以便在各種內部會議上處理該主題。這個時間框架確保了考慮了不同的觀點，並且每個感興趣的人都有機會參與討論。
- 釋出討論。
- 指定一位牽頭人。如果牽頭人不是討論的發起者，則確定牽頭人。
- 識別任何關鍵利益相關者和所需的批准者（需要就該主題發表意見並批准的人員），如果有的話。
- 告知批准者和其他重要人員有關討論和您建議的時間表。如有必要，在 2 周後再次聯絡他們，之後每週聯絡一次，直到他們提供反饋。
- 將討論主題新增到相關會議的議程中。
- 一個月後，整理反饋、討論和共識，並制定一個初步計劃，將反饋納入可行的行動計劃。
- 重新告知並再次請求所有相關方（包括以任何方式參與討論的每個人）對提議的計劃提供反饋。
- 在第二個月期間，持續向社群徵求關於提議計劃的反饋，並根據新的反饋對計劃進行更新。重複此過程。
- 如果存在爭議點，安排一次線上的、同步的、面對面的會議來解決任何剩餘的分歧（如討論串中所記錄）。
- 在第二個月期間，在努力與社群達成解決方案的過程中，保持討論串的活躍。
- 建立問題以實施解決方案計劃並付諸行動。（報告問題指南）
- 關閉討論。
如果討論涉及聯絡專家並獲得反饋，則上述時間表可以根據需要延長。
無定論的解決方案
達成解決方案很重要，但也要記住，並非所有討論都能產生可實施的解決方案。討論的解決方案可能是“不作任何決定”或“一年後我們再重新討論”。這些都是有效的解決方案！
當討論結束時沒有可實施的解決方案，請在討論中註明，然後將討論標記為已解決。