從專案開始之初，ESLint 就一直要求每個包含程式碼的 pull request 都必須有 issue。這有很多原因，主要與我們如何分類和處理收到的請求，以及 GitHub issue 追蹤器的限制有關。自那時以來，GitHub issue 和 pull request 追蹤器已進行許多改進，因此，我們得以做出一些變更。
大多數 Pull Request 不再需要 Issue
我們已取消所有 pull request 都需要 issue 的限制。對於幾乎所有類型的變更，您現在可以直接提交 pull request，而無需 issue。我們新增了一個 pull request 範本，只要您填寫該範本中的必填資訊，就可以隨時提交 pull request，而無需事先開啟 issue。
但是，仍有兩種變更類型需要 issue
- 任何重大變更。
- 任何核心變更。
重大變更和核心變更很有可能影響終端使用者，因此我們仍然希望在人們花時間編寫程式碼之前，先了解這種影響。
Issue 的生命週期終止期限
我們從貢獻者那裡聽到的一件事是，當 issue 陷入僵局而沒有解決方案時，會令人感到沮喪。從一開始，我們就嘗試盡快對 issue 和 pull request 提供回饋。然而，隨著 ESLint 的成長，issue 和 pull request 的數量也變得非常龐大，使得團隊難以處理。
開源社群中的不同團隊以不同的方式處理這個問題。有些團隊選擇永遠不關閉 issue，而是讓所有 issue 無限期地保持開啟狀態，以防有人想修復它們。有些團隊使用機器人自動關閉超過設定時間的 issue。ESLint 團隊對這些選擇不太滿意，因此我們採用了更手動的流程，這是兩者的混合。
我們的首要目標是快速提供回饋，由於大多數 issue 都是要求 ESLint 團隊進行變更，我們想讓您知道我們是否會進行該變更。最好的方法是關閉 issue 並附上適當的評論。我們制定的規則如下
- 未被接受的 issue 可能會在 21 天後關閉。（只有被接受的 issue 才會進入路線圖。）
- 如果沒有人同意實作，已接受的 issue 可能會在 90 天後關閉。
雖然我們希望能夠承諾實作每個 ESLint 的好想法，但現實情況是，許多請求最終不會進入正式的路線圖。ESLint 團隊是一個由志願者組成的團隊，他們在閒暇時間工作，因此，可用的工作時間很少。我們認為，關閉 issue 並明確表示不會進行請求的變更，比讓 issue 永遠保持開啟狀態，以防有人決定他們想要貢獻變更，更為誠實。根據我們的經驗，開啟超過 90 天或更長時間的 issue 很少被處理，只會讓所有人對其狀態感到困惑。
注意： 如果您對某項變更充滿熱情，請考慮提交 pull request 而不是 issue。很多時候，我們只是沒有額外的頻寬來處理重大請求，但我們可以引導其他人完成變更。提交 pull request 會增加您的變更被採納的機會（儘管這不能保證）。
持續學習
一如既往，我們將根據 ESLint 團隊和整個社群的回饋，繼續評估我們的 issue 和 pull request 政策。我們希望這些新變更將有助於 ESLint 社群持續成長，方法是簡化接受貢獻的流程。
