問題分級處理

BeeWare 會定期從遇到問題的使用者收到問題報告。當收到新的問題回報時，該回報需要 triaged - 也就是說，我們需要有人閱讀該回報，根據回報者提供的資訊，嘗試重現所描述的問題。

不幸的是，雖然問題報告的出發點通常是好的，但往往不完整或混亂。分流程序的目的就是要填補原始報告的不足。這表示要麼產生足夠的詳細資料，讓我們可以確認問題如何可以重現；要麼確認原始報告者的報告有誤。

分流問題並不表示您必須修復問題。根據問題的不同，分流甚至可能不需要撰寫程式碼。您可以在對 BeeWare 認識不深的情況下分流問題，因為您應該可以遵循報告中包含的步驟，重現所描述的問題。

貢獻問題分流

重現問題

如果一開始就沒有問題，就無法解決問題。因此，重現問題是修復問題的先決條件。在軟體中，問題通常被稱為 "bug「，而問題通常被稱為 」bug 報告"。

有人提供了錯誤報告。您需要驗證報告人所描述的步驟是否會導致所報告的錯誤。您是否可以完全按照報告中的描述重現相同的結果？如果不能，您需要找出原因。

程式碼中的錯誤

在理想的情況下，您會擁有與回報錯誤的人相同的設定，您會遵循步驟，並能夠重現所述的錯誤。但在很多情況下，這並不是那麼簡單。許多 bug 報告只包含含糊的解釋，以及一組含糊的條件。問題是，許多 bug 會根據所涉及的一系列條件而有所不同，包括與它們互動的方式、各種先決條件、作業系統、作業系統版本、CPU 架構，或使用者的機器是又舊又慢還是又新又快。對於圍繞錯誤的情況，我們掌握的資訊越多越好。嘗試重現報告者提供的一系列情況。如果您無法這樣做，下一步可能需要向回報錯誤的人索取更多資訊。

重現錯誤的最佳方式是使用仍能顯示問題的最小範例。大多數情況下，報告者不會提供最小的可行範例；如果他們提供任何範例，都是直接從他們的「真實世界」應用程式中複製出來的。您的目標是將報告縮減到能顯示問題的最簡單形式。最好的重現案例就是最小的程式。這種還原本身就很有幫助，因為它可以決定實際的問題是什麼。任何人都可以使用最小的範例，執行它，他們就會觀察到所描述的錯誤。

文件中的錯誤

文件中的錯誤可能有不同的表現方式。有些是格式上的問題，會導致呈現問題。有時候，這甚至不是一個錯誤；有關人員可能誤讀了文件，或是真的犯了一個錯誤。這不一定表示文件沒有問題。內容可能不清楚或不精確，留下混淆或誤解的空間。也有可能應該討論的概念沒有討論，因為它完全沒有文件記載。

當文件問題的 bug 被歸檔時，您會想要確認所報告的問題是否真的仍然存在。如果是渲染問題，您需要建立文件，看看是否可以重現問題。內容問題則需要閱讀以確認是否有人提交更新。

更新問題

分流程序的最後一步是在問題上留下評論，以記錄您的發現。

如果您能夠完全依照所描述的方式重現問題，這就是您需要說的。請留下評論，說明您已確認您看到相同的問題，而且與原始報告者所描述的方式完全相同。

如果您能夠提供任何額外的背景，請包含該背景的詳細資訊。這可能包括能夠在不同的作業系統上重現問題，或使用某些相關軟體的不同版本，或任何其他與原始報告不同的地方。

如果原始報告遺漏了重現報告所需的詳細資訊，請包含*這些詳細資訊。這可能包括提供原始報告沒有提供的作業系統或版本詳細資訊、更完整的日誌或堆疊追蹤，或更清楚的指示重現問題所需的確切操作順序。如果您已經開發出重製問題的更簡單方法 (或原始報告者沒有提供重製案例)，您可以包含該重製方法的詳細資訊。

若您無法重現該問題，也請留下評論說明您嘗試過的解決步驟。了解問題不存在的位置與存在的位置同樣重要，這有助於縮小可能的成因範圍。 若您對無法重現問題的原因有任何推測——例如認為是使用方式錯誤，或近期作業系統更新已解決此問題——請將這些推論一併納入留言說明。

最後，您可以向核心團隊提出任何建議。如果您認為原始報告有誤，建議應該關閉此問題；如果您對問題的成因有自己的看法，也可以提出建議。您的意見將有助於核心團隊找出如何將問題推進到下一步。