管理議題和提取請求

新的議題和提取請求被頻繁地提交，而我們如何回應這些議題直接影響專案的成功。成為專案團隊的一份子意味著協助分類和處理湧入的議題，以便專案可以繼續順利運行。

注意事項

1. 友善一點。 即使人們在議題中粗魯或具有侵略性，身為專案團隊成員，您也必須在對話中表現成熟。盡您所能與每個人合作，無論他們的風格如何。請記住，糟糕的措辭選擇也可能是不太懂英語的人的跡象，因此在嘗試判斷某人訊息的語氣時，請務必考慮到這一點。粗魯無禮，即使在別人對您粗魯時也是如此，也會對團隊和整個專案產生不良影響。
2. 保持好奇心。 每當有不清楚的地方時，就在議題中提出問題。如果缺少詳細資訊，請不要假設您理解正在報告的內容。每當您不確定時，最好要求更多資訊。
3. 並非所有請求都是平等的。 我們不太可能滿足每個請求，因此不要害怕說有些事情不符合專案的範圍或不切實際。如果情況確實如此，最好給予此類回饋。
4. 在適當的時候關閉。 不要害怕關閉您認為不會完成的議題，或者當從對話中清楚地表明沒有進一步工作要做時。如果議題被錯誤地關閉，始終可以重新開啟，因此在適當的時候可以隨時關閉議題。只需務必留下評論，解釋為什麼要關閉議題（如果不是由提交關閉）。

議題和提取請求的類型

主要有五個類別

1. 錯誤：某些東西無法按照預期的方式運作。
2. 增強功能：對已存在事物的變更。例如，為現有規則新增一個新選項，或修復規則中的錯誤，修復錯誤將導致規則報告更多問題（在這種情況下，同時使用「錯誤」和「增強功能」）。
3. 功能：新增尚不存在的東西。例如，新增新規則、新格式器或新命令列標誌。
4. 文件：新增、更新或移除專案文件。
5. 問題：關於某事物如何運作的詢問，不會導致程式碼變更。我們希望人們使用 GitHub Discussions 或 Discord 來提問，但有時他們會開啟議題。

評估議題或提取請求的第一個目標是確定議題屬於哪個類別。

分類流程

ESLint 的所有議題和提取請求，跨越所有 GitHub 儲存庫，都在我們的 分類專案 中管理。請使用分類專案而不是議題列表來審查議題，以確定要處理的事項。分類專案有幾個欄位

• 需要分類：尚未被任何人審查的議題和提取請求。
• 分類中：已被某人審查但尚未完全分類的議題和提取請求。
• 準備好給開發團隊：已分類且擁有開發團隊查看所需的所有資訊的議題和提取請求。
• 評估中：開發團隊正在評估這些議題和提取請求，以確定是否繼續進行。
• 需要回饋：團隊成員正在請求團隊其他成員提供更多意見，然後再繼續進行。
• 等待 RFC：流程的下一步是撰寫 RFC。
• RFC 已開啟：已開啟 RFC 以解決這些議題。
• 已封鎖：由於某些依賴關係，議題無法繼續進行。
• 準備實作：這些議題具有開始實作所需的所有詳細資訊。
• 實作中：每個議題都有一個已開啟的提取請求，或者這是一個已批准的提取請求。
• 需要二次審查：已經獲得一個批准的提取請求，並且批准者正在請求在合併之前進行二次審查。
• 合併候選：已經獲得至少一個批准且至少一個批准者認為提取請求已準備好合併到下一個版本，但仍然希望 TSC 成員驗證的提取請求。
• 已完成：議題已關閉（透過提取請求合併或團隊手動關閉議題）。

我們盡一切努力自動化盡可能多欄位之間的移動，但有時移動議題需要手動完成。

當議題或提取請求被開啟時

當議題或提取請求被開啟時，它會自動新增到分類專案中的「需要分類」欄位。需要評估這些議題和提取請求，以確定後續步驟。支援團隊或開發團隊中的任何人都可依照這些步驟正確分類議題。

注意： 如果議題或提取請求位於「分類中」欄位，則表示有人已經在分類它，您應該讓他們完成。除非有人要求協助，否則無需在「分類中」欄位的議題或提取請求上發表評論。

分類議題或提取請求的步驟如下

1. 將議題或提取請求從分類專案中的「需要分類」移動到「分類中」。
2. 檢查：議題範本中的所有資訊是否都已提供？
   • 否： 如果議題範本中缺少資訊，或者您無法判斷請求的內容，請要求作者提供缺少的資訊
     • 將「需要資訊」標籤新增到議題，以便我們知道此議題由於缺少資訊而停滯不前。
     • 在提供必要的資訊之前，不要繼續執行其他步驟。
     • 如果議題作者在 7 天後仍未提供必要的資訊，請關閉議題。機器人將新增一則評論，說明議題因缺少資訊而被關閉。
   • 是
     • 如果議題實際上是一個問題（而不是開發團隊需要變更的事項），請將其轉換為討論。您可以將對話作為討論繼續進行。
     • 如果議題報告錯誤，或者提取請求正在修復錯誤，請嘗試按照議題中的指示重現該問題。如果您可以重現該錯誤，請新增「repro:yes」標籤。（機器人將自動移除「repro:needed」標籤。）如果您無法重現該錯誤，請要求作者提供有關其環境的更多資訊或澄清重現步驟。
     • 如果議題或提取請求報告的內容按預期運作，請新增「works as intended」標籤並關閉議題。
     • 請新增描述受影響的 ESLint 部分的標籤
       • 第三方外掛程式：與第三方功能（外掛程式、解析器、規則等）相關。
       • 建置：與建置期間運行的命令（測試、linting、發布腳本等）相關。
       • cli：與命令列輸入或輸出或 CLIEngine 相關。
       • 核心：與內部 API 相關。
       • 文件：與 eslint.org 上的內容相關。
       • 基礎架構：與建置或部署所需的資源（VM、CI 工具、機器人等）相關。
       • 規則：與核心規則相關。
     • 請根據議題或提取請求的重要性分配初始優先順序。如果您不確定，請使用您的最佳判斷。我們隨時可以更改優先順序。
       • P1：緊急且重要，我們需要立即處理。
       • P2：重要但不緊急。應由 TSC 成員或審查者處理。
       • P3：錦上添花但不重要。可以由任何團隊成員處理。
       • P4：我們希望擁有的一個好主意，但團隊可能需要一段時間才能實現。
       • P5：核心團隊無法承諾的一個好主意。可能需要由外部貢獻者完成。
     • 請分配初始影響評估（做出您最好的猜測）
       • 低：不影響許多使用者。
       • 中：影響大多數使用者或對使用者體驗有明顯影響。
       • 高：影響大量使用者、是重大變更，或以其他方式對使用者非常明顯。
     • 如果您無法正確分類議題或提取請求，請將議題移回分類專案中的「需要分類」欄位，以便其他人可以分類它。
     • 如果提取請求引用了已接受的議題，請將其移動到分類專案中的「實作中」欄位。
     • 如果您已分類議題，請將議題移動到分類專案中的「準備好給開發團隊」欄位。

評估流程

當議題被移動到「準備好給開發團隊」欄位時，任何開發團隊成員都可以挑選該議題開始評估。

1. 將議題移動到「評估中」欄位。
2. 後續步驟
   • 錯誤：如果您可以驗證錯誤，請新增「accepted」標籤，並詢問他們是否願意提交提取請求。
   • 新規則：如果您願意支持該規則（表示您認為該規則應包含在 ESLint 核心中，並且您將負責包含該規則的流程），請新增評論說明您將支持該議題，將議題分配給自己，並遵循下面的 指南。
   • 規則變更：如果您願意支持該變更，並且該變更不會是重大變更（需要主要版本增量），請新增評論說明您將支持該議題，將議題分配給自己，並遵循下面的 指南。
   • 重大變更：如果您懷疑或可以驗證變更將是重大變更，請將其標記為「Breaking」。
   • 重複：如果您可以驗證議題是重複的，請新增評論提及重複的議題（例如，「Duplicate of #1234」）並關閉議題。
3. 無論上述情況如何，始終留下評論。不要只是新增標籤；透過提出問題（必要時請求更多資訊）或陳述您對議題的看法來與開啟議題的人互動。如果是已驗證的錯誤，請詢問使用者是否願意提交提取請求。
4. 如果議題由於需要更新外部依賴關係或需要等待另一個議題解決而無法實作，請將議題移動到「已封鎖」欄位。
5. 如果議題已被接受並且下一步需要 RFC，請將議題移動到「等待 RFC」欄位，並在議題上評論說明需要 RFC。

注意： 「Good first issue」議題旨在幫助新貢獻者感到受歡迎並有權為 ESLint 做出貢獻。為了確保新貢獻者有機會處理這些議題，標記為「good first issue」的議題必須在從議題被標記之日起開放 30 天，團隊成員才能處理它們。

接受議題和提取請求

當議題符合以下條件時，可能會被標記為「accepted」

• 您已能夠重現和驗證的錯誤（即您確定它是錯誤）。
• 您正在支持的新規則或規則變更，並且已就其包含在專案中達成 共識。

如果適合路線圖，TSC 成員將為其他議題新增「accepted」標籤。

當議題被接受並且可以開始實作時，應將其移動到「準備實作」欄位。

支持議題

新規則和規則變更需要支持者。作為支持者，您的工作是

• 從 ESLint 團隊就納入達成 共識。
• 指導規則建立流程直到完成（因此僅支持您有時間實作或協助其他貢獻者實作的規則）。

一旦就納入達成共識，請新增「accepted」標籤。可選地，根據需要新增「help wanted」和「good first issue」標籤。

共識

當至少有三位團隊成員認為變更是一個好主意，並且沒有人認為變更是一個壞主意時，議題就達成共識。為了表示您對議題的支持，請在原始議題描述上留下 +1 反應（豎起大拇指），以及您可能有的任何評論。

何時提交給 TSC

如果無法就議題達成共識，或者議題的進度停滯不前，並且不清楚是否應關閉議題，則您可以將議題提交給 TSC 進行決議。若要這樣做，請將「tsc agenda」標籤新增到議題，並新增包含以下資訊的評論

1. 對到目前為止的討論進行一段摘要。這應該以「TSC Summary:」開頭。
2. 您希望 TSC 回答的問題。這應該以「TSC Question:」開頭。

該議題將在下一次 TSC 會議上討論，決議將發佈回該議題。

評估核心功能和增強功能（僅限 TSC 成員）

除了上述內容外，對核心（包括 CLI 變更）的變更，如果會導致次要或主要版本發布，則必須經由標準 TSC 動議獲得 TSC 批准。將標籤「tsc agenda」新增到議題，它將在下一次 TSC 會議上討論。一般來說，請求應符合以下標準才能被考慮

1. 該功能或增強功能在專案範圍內，應新增到路線圖中。
2. 有人承諾在明年內包含該變更。
3. 對於誰將完成這項工作有合理的確定性。

當建議過於雄心勃勃或需要花費太多時間才能完成時，最好不要接受該提案。堅持小的、漸進式的變更，並制定您希望專案最終走向的路線圖。不要讓專案陷入需要很長時間才能完成的大型功能中。

重大變更： 注意可能會造成重大變更的變更。代表重大變更的議題應標記為「breaking」。

向 TSC 請求回饋

若要向 TSC 請求回饋，團隊成員可以 ping @eslint/eslint-tsc 並在議題或提取請求上新增標籤「tsc waiting」。除非另有要求，否則每位 TSC 成員都應針對 標記為「tsc waiting」的議題 提供回饋。如果 TSC 成員無法及時回應，他們應發布評論，說明他們預計何時可以留下回饋。最後一位對標記為「tsc waiting」的議題提供回饋的 TSC 成員應移除該標籤。

何時關閉議題

所有團隊成員都可以根據議題的解決方式關閉議題。

如果符合以下條件，團隊成員可以立即關閉議題

1. 該議題是現有議題的重複項。
2. 該議題只是一個問題並且已獲得解答。

團隊成員可以關閉共識為不接受議題的議題，在等待期過後（以確保其他團隊成員有機會在議題關閉前審查議題）

• 如果議題是在星期一至星期五開啟的，則等待 2 天。
• 如果議題是在星期六或星期日開啟的，則等待 3 天。

為了使議題積壓工作保持在可管理的範圍內，如果符合以下條件，團隊成員也可以關閉議題

• 未接受：在開啟 21 天後關閉，因為這些議題沒有足夠的支持來繼續進行。
• 已接受：如果團隊或社群中沒有人願意挺身而出並負責完成工作，則在 90 天後關閉。
• 需要協助： 如果在 90 天後仍未完成，則關閉。