跳到主要內容

問題

這份文件提供指導，說明您如何管理我們的 GitHub 問題，也稱為問題分流。

在進行問題分流時，請發揮您的良好判斷力，最重要的是，請一定記住，在回覆使用者時要令人感到鼓舞、友善且和善。許多使用者是新手，不了解開放原始碼和/或已輸入檢查。我們務必要給予他們正面、令人振奮的經驗。

提示

如果您在問題管理的任何部分感到不確定，請毫不猶豫地找一個有更豐富脈絡的維護人員來幫忙！

治理​

根據下列 貢獻層級與指標 說明

  • 直覺式：根據審查者的決定，可以由任何承諾者或維護人員標記為已核准。這包括文件增強、錯誤修正和功能新增。
  • 非直覺式：可以用兩個承諾者核准或是其中一個維護人員核准標記為已核准。這包括重要的內部重構以及非中斷式公開 API 變更。
  • 「不尋常」類別：需要公開討論，然後由兩個維護人員核准。這包括重大的重構，同時需要考量跨專案和公開 API 的影響。

問題流程​

備註

我們在 .github/replies.yml 提供問題的幾組常見回覆，建議搭配 精選已儲存的回覆 擴充功能一起使用。請不要將這些視為精確的回覆內容：它們只是一個開始複製 + 貼上的幫手。請根據您的個人語氣修改具體回覆，並符合非直覺式問題的執行緒。

待分類的問題 可以使用 triage 標記來搜尋。建立新問題時會自動新增該標記。建立或更新大多數的問題時，都會經過以下審查流程

  1. 維護人員會確認問題有效
    • 如果發布者沒有填寫適當的範本，提供足夠的資訊
      • 新增 請填寫範本 和 等待回覆 標記，並移除 triage 標記
      • 使用 需要更多資訊 回覆，請發布者提供更多資訊
    • 如果問題是已存在的重複問題
      • 新增 重複 標記，並移除 triage 標記
      • 如果是明顯的重複問題，請發布 明顯重複的問題 回覆，連結至現有的問題
      • 如果問題不算是明顯的重複問題，請連結至現有的問題，並說明原因
      • 將問題關閉為 未規劃
    • 如果程式碼運作符合預期
    • 如果處理事項包含類似增強的要求，但不太會在 typescript-eslint 中執行
    • 如果處理事項需要進一步討論或社群參與評估
      • 新增 評估社群參與 標籤，移除 分類 標籤
  2. 如果報告有效，新增 接受拉取要求 標籤，移除 分類 標籤
  3. 如果你知道修正的大致步驟，可以寫意見，附上程式碼庫連結，協助他人合輯修正
  4. 如果你認為修正相對單純，可以考慮另外新增 良好的優先處理事項 標籤

當處理事項等待報告者提供更多資訊時，應該給予 等待回覆 標籤。當更多資訊提供時

  • 如果你有時間重新檢閱分類流程，請這麼做
  • 如果你沒有時間，新增 分類 標籤，移除 等待回覆 標籤
提示

如果你的連結是「永久連結」(包含提交雜湊值，而非分支名稱) 且有行號/行範圍，GitHub 會將程式碼置入意見中。當檢視 GitHub 中的檔案時，按下 y，使用目前的提交雜湊值，更新 URL 為「永久連結」，接著你可以選取相關行，將該 URL 貼上意見中。

尋找重複​

值得注意的是，偶爾使用者會故意提出重複的處理事項，因為他們認為原本的處理事項在不應該關閉時關閉。如果是這種情況，你應該閱讀原本的處理事項，收集脈絡，了解關閉的理由，然後判定新的處理事項是否提出需要處理的任何新觀點或相關觀點。

確認程式碼是否運作正常​

當您開始熟悉程式碼庫，瞭解各種運作方式後，將更能自然地理解，不過一開始這可能要查看文件、程式碼和測試，才能判斷是發生錯誤或者依預期運作。一般來說，如果有一個通過測試或有文件範例，而且與重製程式碼相同或類似，就表示依預期運作。如果您找不到任何符合的選項，請依程式碼的精神自行判斷。

社群參與評估​

在多數情況下，維護人員對於人們如何撰寫程式碼，以及多數使用 typescript-eslint 工具的人員的需求，有相當程度的了解。不過有時候維護人員無法自信地選擇最合理的解決方案來解決特定問題

  • 問題主旨涉及維護人員不熟悉的程式庫/架構。因此，他們不知道與程式庫/架構相關的慣用語法模式。
  • 有新的語法或功能時 - 有時候很難猜測人們會如何使用該功能。
  • 問題即將關閉時，有人提出了令人信服的論點。這需要進一步討論，才能找到多數人認同的觀點。

在標記為 evaluating community engagement 後 3 至 6 個月，會評估社群參與的程度

  • 如果社群活躍且找到共識，就會標記問題為 accepting prs
  • 否則會關閉問題，並標記為 wontfix，以表示未規劃

對於可在 typescript-eslint 外部實作的要求，請務必提及任何相關 API，例如可使用的 自訂規則。

略過步驟​

當您更熟悉程式碼庫以及它的運作方式之後，就可以依您的看法略過步驟或跳過特定程序。例如，您也許可以識別錯誤報告是否「依預期運作」，或者您可以辨識重複的問題，而無需填寫完整的問題。在這些情況下，您可以放棄來回討論，直接跳到關閉步驟。

特定問題類型​

🐛 錯誤報告​

🐞「簡單」錯誤​

單純的錯誤是一款僅透過單一 TS 檔案加上 ESLint 設定（還有可能會包含 TSConfig）就能重現錯誤的方式，換句話說就是可以在我們的遊樂場上重新產生問題。絕大多數的錯誤回報都屬於此類別。

假設你無法藉由使用問題提供的遊樂場重新產生問題，表示所提供的資訊不足夠。不妨考慮寫出類似需要遊樂場重新產生的反饋。

🦟「複雜」錯誤​

複雜錯誤是一款需要多個檔案才能重新產生問題的方式。這類情況較少見，但會在使用者使用程式庫類型時或是類型在導入時出現問題時發生。

這種錯誤應該透過連結到可以簽出以重新產生問題的 GitHub 儲存庫來回報。假設你無法透過使用儲存庫的 README.md 和問題說明來重新產生問題，表示所提供的資訊不足夠。不妨考慮寫出類似需要完整重新產生的反饋。

🏗 功能要求​

對所有功能要求來說，確認所要求的支援不是以下任一種即可：

  • 對於至少一種常見的 TypeScript 執行方式（例如 tsc 建立的 CLI 套件；打包器管理的網頁應用程式）非常實用
  • 與大多數會使用 typescript-eslint 的專案有關

我們會避免下列功能：

  • 僅與少數使用者有關，不太可能值得負擔維護成本
  • 非 TypeScript 專屬（例如應該改在 ESLint 核心
  • 僅與特定的使用者空間架構或程式庫（例如 Jest 或 React）有關
  • 是用於「格式化」功能（我們強烈建議使用者使用專門的格式化程式

✨ 規則增強​

我們通常願意接受符合上述功能要求準則的規則增強。如果某項規則增強會大幅改變規則的目標範圍，請考慮是否應該新增為新規則。該規則的原始名稱現在不正確或某些選項僅與舊功能有關等情況都是常見的徵兆。

可能會導致產生新回報的增強功能會被視為重大變更。我們通常有兩種處理策略

  • 將增強功能視為重大變更，並封鎖合併功能直到下一個主要版本
  • 新增一個用來停用新邏輯的選項：如果要加入時會是重大變更，而要退出時則會是非重大變更
  • 為新邏輯新增啟用選項：若選擇停用，則會發生中斷性變更；若選擇啟用，則不會發生中斷性變更

見 我們能標準化規則選項的邏輯方向嗎？ 以了解命名選項脈絡。

若目的在於限制規則目標節點的類型，請在 RFC：指定類型或值做為規則選項的共通格式 的問題中標示已封鎖。

🚀 新規則​

對於符合上述功能要求準則的新規則，我們通常會接受。最大的例外是那些可以透過 @typescript-eslint/ban-types 和/或 no-restricted-syntax 簡易實作的規則。

精簡舊問題​

時不時，我們會 搜尋開放式問題 等待回應，找出可能已遭遺忘的問題。我們對於等待時間 >=1 個月的問題處理流程是

  1. 利用正在查看中範本訊息，對作者發出 ping
  2. 於問題中加入 stale 標籤
  3. 等待 2 週
  4. 若他們仍然未回應，則利用精簡過期問題範本訊息，關閉問題