管理議題與 Pull Request

新的議題與 pull request 會頻繁地提出，而我們如何回應這些議題會直接影響專案的成功。成為專案團隊的一份子，意味著協助分類並解決進來的議題，以便專案能夠繼續順利運行。

應記住的事項

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

議題與 Pull Request 的類型

主要有五個類別

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

評估議題或 pull request 時的第一個目標是確定該議題屬於哪個類別。

分類流程

ESLint 的所有議題與 pull request，跨越所有 GitHub 儲存庫，都在我們的 分類專案 上進行管理。請在使用分類專案而不是議題列表來審閱議題，以確定要處理的內容。分類專案有幾個欄位

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

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

當議題或 Pull Request 開啟時

當開啟議題或 pull request 時，它會自動新增到分類專案中的「需要分類」欄位。需要評估這些議題與 pull request，以確定後續步驟。支援團隊或開發團隊中的任何人都可遵循這些步驟來正確分類議題。

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

分類議題或 pull request 的步驟為

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

評估流程

當議題移至「準備給開發團隊」欄位時，任何開發團隊成員都可以選取該議題開始評估它。

1. 將議題移至「評估中」欄位。
2. 後續步驟
   • 錯誤（Bugs）：如果您可以驗證錯誤，請加上「accepted」標籤，並詢問他們是否願意提交 Pull Request。
   • 新規則（New Rules）：如果您願意支持這個規則（表示您認為它應該包含在 ESLint 核心中，並且您將負責處理將其納入的流程），請加上註解說明您將支持此議題，將議題指派給自己，並遵循下方的指導方針。
   • 規則變更（Rule Changes）：如果您願意支持此變更，且此變更不會是重大變更（需要增加主版本號），請加上註解說明您將支持此議題，將議題指派給自己，並遵循下方的指導方針。
   • 重大變更（Breaking Changes）：如果您懷疑或可以驗證某個變更會是重大變更，請將其標記為「Breaking」。
   • 重複議題（Duplicates）：如果您可以驗證此議題是重複的，請加上註解提及重複的議題（例如：「與 #1234 重複」），並關閉此議題。
3. 無論上述情況為何，請務必留下註解。不要只是加上標籤，要與提出議題的人互動，可以提出問題（必要時要求更多資訊）或陳述您對此議題的意見。如果是已驗證的錯誤，請詢問使用者是否願意提交 Pull Request。
4. 如果議題因為需要更新外部相依性，或需要等待另一個議題解決才能實作，請將議題移至「已封鎖」欄位。
5. 如果議題已被接受，且下一步需要 RFC，請將議題移至「等待 RFC」欄位，並在議題中註解說明需要 RFC。

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

接受議題與 Pull Request

當議題符合以下條件時，可以標記為「已接受」：

• 您可以重現並驗證的錯誤（也就是說，您確定它是錯誤）。
• 您正在支持的新規則或規則變更，且其納入專案已達成共識。

如果議題適合路線圖，TSC 成員也會將「已接受」標籤新增到其他議題。

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

支持議題

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

• 在納入議題方面取得 ESLint 團隊的共識。
• 引導規則建立過程直到完成（因此，只支持您有時間實作或協助其他貢獻者實作的規則）。

一旦在納入議題方面達成共識，請新增「已接受」標籤。可選地，根據需要新增「歡迎協助」和「適合新手」標籤。

共識

當至少有三名團隊成員認為該變更是好主意，且沒有人認為該變更是壞主意時，即達成議題的共識。為了表示您對議題的支持，除了您可能有的任何註解之外，請在原始議題描述上留下 +1 反應（豎起大拇指）。

何時發送至 TSC

如果無法就議題達成共識，或議題的進展停滯不前，且不確定是否應關閉該議題，您可以將該議題提交給 TSC 進行決議。要執行此操作，請在議題上新增「tsc agenda」標籤，並新增包含以下資訊的註解：

1. 到目前為止的討論摘要，以一個段落描述。此段落應以「TSC 摘要：」開頭。
2. 您希望 TSC 回答的問題。此問題應以「TSC 問題：」開頭。

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

評估核心功能與增強功能 (僅限 TSC 成員)

除了上述內容之外，對核心（包括 CLI 變更）進行會導致小版本或主版本發布的變更，都必須經過 TSC 的標準 TSC 動議批准。在議題上新增「tsc agenda」標籤，它將在下一次 TSC 會議上討論。一般而言，請求應符合以下標準才能被考慮：

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

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

重大變更：留意會是重大變更的變更。代表重大變更的議題應標記為「breaking」。

請求 TSC 的回饋

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

何時關閉議題

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

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

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

團隊成員可以在達成不接受該議題的共識後，經過一段等待時間後關閉議題（以確保其他團隊成員有機會在關閉議題之前審閱該議題）。

• 如果議題是在週一到週五開啟，請等待 2 天。
• 如果議題是在週六或週日開啟，請等待 3 天。

為了保持議題待辦事項的可管理性，如果符合以下條件，團隊成員也可以關閉議題：

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