審查 Pull Request

Pull Request 提交頻繁，代表我們與社群互動的最佳機會。因此，在合併 Pull Request 之前，務必仔細審查，且 Pull Request 上的互動應為正面。

誰可以審查 Pull Request？

任何人，包括團隊成員和公眾，都可以在 Pull Request 上留言。

審查 Pull Request

當 Pull Request 開啟時，機器人會檢查以下項目

1. 提交者是否已簽署 CLA？
2. 提交訊息摘要的格式是否正確？
3. 提交摘要是否太長？

機器人會新增註解，說明它發現的問題。在這些問題解決之前，您不需要進一步查看 Pull Request（不需要在 Pull Request 上留言要求提交者執行機器人要求的動作 - 這就是我們設置機器人的原因！）。

一旦機器人檢查通過，您應檢查以下項目

1. 再次確認 Pull Request 標題是否根據 issue 正確（或者，如果沒有參考 issue，則根據所述問題）。
2. 如果 Pull Request 對核心程式碼進行變更，請確保存在 issue，且 Pull Request 在提交訊息中參考了該 issue。
3. 程式碼是否遵循我們的慣例（包括標頭註解、JSDoc 註解等）？如果沒有，請留下回饋並參考程式碼慣例文件。
4. 對於程式碼變更
   • 是否有測試驗證變更？如果沒有，請要求他們提供。
   • 變更是否需要文件？如果需要，請要求提交者新增必要的文件。
5. 是否有任何自動化測試錯誤？如果有的話，請要求提交者檢查。
6. 如果您已審查 Pull Request 且沒有未解決的問題，請留下註解 “LGTM” 以表示您的核准。如果您希望其他人驗證變更，請註解 “LGTM but would like someone else to verify.”。

注意：如果您是團隊成員且已在 Pull Request 上留下註解，請追蹤確認您的註解是否已獲得處理。

Pull Request 的必要核准

任何 Committer、Reviewer 或 TSC 成員都可以核准 Pull Request，但合併所需的核准取決於 Pull Request 的類型。

合併非破壞性變更需要一位 Committer 核准，該變更屬於

1. 文件變更
2. 錯誤修正（規則或核心程式碼）
3. 依賴項升級
4. 與建置相關
5. 雜項

對於非破壞性功能，Pull Request 需要一位 Reviewer 或 TSC 成員的核准，再加上任何其他團隊成員的另一項核准。

對於破壞性變更，Pull Request 需要兩位 TSC 成員的核准。

在 Triage Board 中移動 Pull Request

當建立 Pull Request 時，無論是由團隊成員還是外部貢獻者建立，它都會自動放置在 Triage board 的 “Needs Triage” 欄位中。Pull Request 應保留在該欄位中，直到團隊成員開始審查為止。

如果 Pull Request 沒有相關的 issue，則應通過正常的 issue triage 流程，標記為已接受。一旦接受，將 Pull Request 移動到 “Implementing” 欄位。

如果 Pull Request 有相關的 issue，則

• 如果 issue 已接受，將 Pull Request 移動到 “Implementing” 欄位。
• 如果 issue 未接受，將 Pull Request 移動到 “Evaluating” 欄位，直到 issue 標記為已接受，屆時將 Pull Request 移動到 “Implementing”。

一旦 Pull Request 獲得一個核准，可能會發生以下三件事之一

1. Pull Request 具有必要的核准，且等待期（見下文）已過，因此可以合併。
2. Pull Request 具有必要的核准，但等待期尚未過，因此應移動到 “Merge Candidates” 欄位。
3. Pull Request 在合併前需要另一個核准，因此應移動到 “Second Review Needed” 欄位。

當 Pull Request 獲得第二個核准時，應合併（如果 100% 準備就緒）或移動到 “Merge Candidates” 欄位，如果還有任何應在下次發佈前審查的未解決問題。

誰可以合併 Pull Request

TSC 成員、Reviewer、Committer 和網站團隊成員可以在 Pull Request 獲得必要的核准後合併，具體取決於 Pull Request 的內容。

網站團隊成員可以在 eslint.org 儲存庫中合併 Pull Request，如果它是

1. 文件變更
2. 依賴項升級
3. 雜項

何時合併 Pull Request

我們使用 “Merge” 按鈕將請求合併到儲存庫中。在合併 Pull Request 之前，請驗證

1. 所有註解都已獲得處理。
2. 任何提出註解的團隊成員都已驗證他們的問題已獲得處理。
3. 所有自動化測試都通過（永遠不要合併測試失敗的 Pull Request）。

在合併之前，務必向提交者表示感謝，特別是如果他們在 Pull Request 上付出了很多努力。

團隊成員可以立即合併 Pull Request，如果它

1. 進行小的文件變更。
2. 是雜項。
3. 修復儲存庫上其他工作的區塊（與建置相關、與測試相關、與依賴項相關等）。
4. 是重要的修復，需要納入修補程式版本。

否則，團隊成員應在合併 Pull Request 之前遵守等待期

• 如果 Pull Request 是在週一至週五開啟，則等待 2 天。
• 如果 Pull Request 是在週六或週日開啟，則等待 3 天。

等待期確保其他團隊成員有機會在 Pull Request 合併之前進行審查。

注意：除非您收到必要的核准，否則不應合併您的 Pull Request。

何時關閉 Pull Request

在幾種情況下，關閉 Pull Request 而不合併是適當的

1. Pull Request 解決了已修復的 issue。
2. Pull Request 已 17 天未更新。
3. Pull Request 提交者不願意遵循專案準則。

在任何這些情況下，請務必留下註解，說明 Pull Request 被關閉的原因。

關閉範例註解

如果 Pull Request 已 17 天未更新

因 17 天沒有活動而關閉。如果您仍然有興趣提交此程式碼，請隨時重新提交。

如果 Pull Request 提交者不願意遵循專案準則。

很遺憾，我們無法接受不遵循我們準則的 Pull Request。我現在將關閉此 Pull Request，但如果您願意按照我們的準則重新提交，我們很樂意審查。