GitHub Issues 的分流處理
首先查看需要分流處理的 issue，這些 issue 已被標記為 "Needs: Triage" 標籤。
- 這是一個關於個別應用程式的程式碼層級協助請求嗎？這是否更適合在 Stack Overflow 上提問？如果是，請套用 "Resolution: For Stack Overflow" 標籤。
- 這個 issue 是否適當地使用了範本？如果沒有，請套用 "Needs: Template" 標籤。
- 這個 issue 是否提及了使用的 React Native 版本？如果沒有，請套用 "Needs: Environment Info" 標籤。
- 這個 issue 是否包含 Snack、程式碼範例或重現 issue 的步驟列表？如果沒有，請套用 "Needs: Repro" 標籤。
我們有時會收到一些 issue，它們不太適合 GitHub issue 追蹤器。新增 "Type: Invalid" 標籤，機器人將自動關閉該 issue。
一旦到了這個階段，您可以開始解析 issue 本身的內容。這個 issue 是否包含問題的清晰描述？
如果沒有，請禮貌地要求 issue 作者更新他們的 issue 並提供必要的資訊，並套用 "Needs: Author Feedback" 標籤。
我們的目標是始終保持友善和樂於助人，並期望社群的每位成員也能如此。
改善 Issue
如果 issue 包含所有必要的資訊，請花點時間考慮是否可以透過某種方式改善 issue。格式是否正確？您可以根據需要輕微編輯 issue 以提高可讀性。
如果 issue 包含未格式化的程式碼區塊，請用三個反引號 (```) 將其包圍，以將其轉換為 markdown 程式碼區塊。
是否有任何標籤可以新增以幫助更好地分類它？如果 issue 僅影響 Android 應用程式，您可以新增 "Platform: Android" 標籤。也許 issue 僅在 Windows 上開發時才會出現，在這種情況下，您可以新增 "Platform: Windows" 標籤。
我們有一個很長的標籤列表，請查看一下，看看是否有任何標籤適用！
處理重複 Issue
當您處理這些 issue 時，您將開始更好地了解報告的問題類型。您甚至可能開始注意到相同的 issue 被重複報告。
在這些情況下，您可以關閉 issue 並新增評論，內容為 "Duplicate of #issue"。透過遵循此慣例，GitHub 將自動將 issue 標記為重複。
評估影響
接下來，我們需要確定 issue 的嚴重程度。
這是否為潛在的發布阻礙因素？
這些 issue 應在一到兩週內解決，因為它們可能會阻止發布協調員發布乾淨的候選版本。
可能被標記為此類型的 issue 可能是導致我們其中一項 pre-commit 測試失敗的回歸。如果 issue 已存在一段時間（如果 issue 已經存在於一個或多個版本中，則根據定義，它不可能是 RC 阻礙因素），請避免將 issue 標記為發布阻礙因素。
這是否會導致應用程式崩潰？
這些 issue 會導致 React Native 意外崩潰。如果不及早發現，這些可能會導致不良的使用者體驗。
這是否為一個 bug？
描述某些未按預期運作的事情。在某個時候修復它會很好，但它還不夠嚴重到會阻礙發布進程。即使 issue 導致崩潰，如果存在可行的解決方案，也可以將其歸類為常規 bug。
這是否為一個 適合新手的 issue？
這些 issue 不需要對儲存庫有深入的理解和熟悉度。GitHub 會將這些 issue 推薦給有興趣成為貢獻者的人。請記住，以這種方式標記的 issue 可能不會立即得到修復。