票券分類¶
Django 使用 Trac 來管理程式碼庫上的工作。Trac 是一個由社群維護的園地，記錄人們發現的錯誤和希望新增的功能。就像任何花園一樣，有時需要拔除雜草，有時則需要採摘花朵和蔬菜。我們需要您的幫助來區分兩者，最終，我們大家都會一起受益。
如同所有的花園，我們可以渴望完美，但現實中並沒有這種東西。即使在最原始的花園裡，仍然會有蝸牛和昆蟲。在社群花園中，也有好心人—出於最好的意圖—為雜草施肥並毒害玫瑰。社群的整體工作就是自我管理、將問題降到最低，並教育進入社群的人，使他們能夠成為有價值的貢獻成員。
同樣地，雖然我們的目標是讓 Trac 完美呈現 Django 進展的狀態，但我們承認這不會發生。透過將 Trac 維護的負擔分攤給社群，我們接受將會發生錯誤。Trac「大致準確」，而且我們允許它有時會出錯。這沒關係。我們是追求完美、有截止期限的人。
我們仰賴社群繼續參與，盡可能保持票券的準確性，並在出現困惑或分歧時，在我們的郵件列表中提出問題進行討論。
Django 是一個社群專案，每一份貢獻都有幫助。沒有您，我們做不到！
分類工作流程¶
不幸的是，並非所有在票券追蹤器中的錯誤回報和功能請求都提供了所有所需的詳細資訊。許多票券都提出了解決方案，但這些解決方案不一定符合所有貢獻指南的要求。
一種協助方式是分類其他使用者建立的票券。
大多數的工作流程都基於票券的分類階段概念。每個階段都描述了指定票券在其生命週期中任何時間點所處的位置。連同一些標記，此屬性可以輕鬆告訴我們每個票券正在等待什麼和誰。
由於一圖勝千言，讓我們從這裡開始。
我們在此圖表中有兩個角色
合併者：具有提交權限的人員，負責做出合併變更的最終決定。
票券分類員：Django 社群中任何選擇參與 Django 開發流程的人。我們的 Trac 安裝是故意向公眾開放的，任何人都可以分類票券。Django 是一個社群專案，我們鼓勵社群進行分類。
舉例來說，在這裡我們看到一個一般票券的生命週期。
Alice 建立一個票券並發送一個不完整的拉取請求（沒有測試、實作不正確）。
Bob 檢閱拉取請求，將票券標記為「已接受」、「需要測試」和「修補程式需要改進」，並留下評論告訴 Alice 如何改進修補程式。
Alice 更新拉取請求，新增測試（但未變更實作）。她移除兩個標記。
Charlie 檢閱拉取請求，並使用另一則關於改進實作的評論重設「修補程式需要改進」標記。
Alice 更新拉取請求，修正實作。她移除「修補程式需要改進」標記。
Daisy 檢閱拉取請求，並將票券標記為「準備簽入」。
Jacob，一個合併者，檢閱拉取請求並合併它。
有些票券所需的意見回饋比這少得多，但有些票券則需要多得多。
分類階段¶
以下我們將更詳細地描述票券在其生命週期中可能經歷的各個階段。
未檢閱¶
票券尚未經過任何認為有資格判斷票券是否包含有效問題、可行功能或因各種原因應關閉的人員檢閱。
已接受¶
灰色地帶！「已接受」的絕對意思是票券中描述的問題有效，並且正在進行某個階段的處理。除此之外，還有一些考量
已接受 + 無標記
票券有效，但尚未有人為其提交修補程式。通常這表示您可以安全地開始為其編寫修復程式。這對於已接受的錯誤案例通常比已接受的功能案例更為真實。已接受的錯誤票券表示該問題已至少由一位分類員驗證為合法錯誤—如果可能，應該加以修復。已接受的新功能可能僅表示一位分類員認為該功能很好，但僅此並不能代表共識意見，也不能確定將接受該功能的修補程式。如果您有疑問，請在編寫大量貢獻之前尋求更多意見回饋。
已接受 + 有修補程式
票券正在等待人們檢閱提供的解決方案。這表示下載修補程式並試用，驗證其是否包含測試和文件，使用包含的修補程式執行測試套件，並在票券上留下意見回饋。
已接受 + 有修補程式 + 需要 ...
這表示票券已檢閱，並且發現需要進一步處理。「需要測試」和「需要文件」不言而喻。「修補程式需要改進」通常會附帶票券上的評論，說明需要改進程式碼的內容。
準備簽入¶
票券已由社群中除了提供修補程式的人員以外的任何成員檢閱，並發現符合提交就緒貢獻的所有要求。合併者現在需要進行最終檢閱，才能提交。
有很多拉取請求。您的修補程式可能需要一段時間才能獲得檢閱。請參閱貢獻程式碼常見問題集，取得一些相關想法。
有朝一日/也許¶
此階段未顯示在圖表中。它會少量使用，以追蹤高階想法或長期功能要求。
這些票券並不常見，而且整體來說不太有用，因為它們沒有描述具體的、可執行的問題。它們是增強要求，如果提交了出色的修補程式，我們可能會考慮在某天將其新增至框架。它們不是高優先順序。
其他分類屬性¶
Trac 中會以核取方塊形式顯示的許多標記可以設定在票券上
有修補程式¶
這表示票券有相關的解決方案。這些將經過檢閱，以確保其符合文件化的指南。
以下三個欄位（需要文件、需要測試、修補程式需要改進）僅在提供修補程式時適用。
需要文件¶
此標記用於需要相關文件的修補程式票券。功能的完整文件是將其簽入程式碼庫的先決條件。
需要測試¶
此標記表示修補程式需要相關的單元測試。同樣地，這是有效貢獻的必要部分。
修補程式需要改進¶
此標記表示雖然票券有解決方案，但尚未準備好簽入。這可能表示修補程式不再順利套用、實作存在缺陷，或程式碼不符合我們的標準。
容易處理¶
需要小型、容易變更的票券。
類型¶
票券應按類型分類為
- 新功能
用於新增新事物。
- 錯誤
用於現有事物損壞或未按預期運作時。
- 清除/最佳化
用於沒有任何損壞，但有些事物可以變得更乾淨、更好、更快、更強大時。
元件¶
票券應分類為元件，指示其屬於 Django 程式碼庫的哪個區域。這會使票券更有組織且更容易找到。
嚴重性¶
嚴重性屬性用於識別阻礙因素，也就是說，應該在發佈下一個 Django 版本之前修正的問題。通常這些問題是導致先前版本回歸的錯誤，或可能導致嚴重資料遺失的錯誤。此屬性很少使用，絕大多數票券的嚴重性為「一般」。
版本¶
可以使用版本屬性來指示在哪個版本中識別出回報的錯誤。
UI/UX¶
此標記用於與使用者介面和使用者體驗問題相關的票券。例如，此標記適用於表單或管理介面中面向使用者的功能。
副本¶
您可以在此欄位中新增您的使用者名稱或電子郵件地址，以便在對票券做出新貢獻時收到通知。
關鍵字¶
您可以使用此欄位來標記具有多個關鍵字的票券。例如，這可用於將相同主題的數個票券分組。關鍵字可以使用逗號或空格分隔。關鍵字搜尋會找到關鍵字字串在關鍵字中的任何位置。例如，按一下具有關鍵字「form」的票券會產生類似的票券，並標記包含「formset」、「modelformset」和「ManagementForm」等字串的關鍵字。
關閉票券¶
當一個工單完成其有效生命週期後，就該關閉它了。然而，關閉工單是一項重大的責任。您必須確定問題確實已解決，並且需要記住，工單的提交者可能不樂意他們的工單被關閉（除非問題已修復！）。如果您不確定是否應該關閉工單，請先留下您的想法作為評論。
如果您確實要關閉工單，您應該始終確保以下事項：
確定問題已解決。
留下評論解釋關閉工單的決定。
如果他們有辦法可以改進工單以重新開啟，請告知他們。
如果工單是重複的，請參考原始工單。同時在原始工單中留下評論，交叉引用已關閉的工單，這樣可以存取更多關於回報的錯誤或請求功能相關的資訊。
保持禮貌。沒有人喜歡他們的工單被關閉。這可能會令人沮喪甚至感到氣餒。避免讓人們不想為 Django 做出貢獻的最好方法是保持禮貌和友善，並提供關於他們未來如何改進這個工單和其他工單的建議。
工單可以用多種方式解決：
- fixed（已修復）
當修補程式已納入 Django 且問題已修復時使用。
- invalid（無效）
如果發現工單內容不正確時使用。這表示工單中的問題實際上是用戶錯誤造成的，或描述的是與 Django 無關的問題，或根本不是錯誤報告或功能請求（例如，一些新用戶將支援查詢當作工單提交）。
- wontfix（不修復）
當有人決定該請求不適合在 Django 中考慮時使用。有時工單會以「不修復」為由關閉，並要求提交者在 Django 論壇 或 django-developers 郵件列表中發起討論，如果他們對關閉工單的人提供的理由有不同意見。其他時候，討論會在關閉工單的決定之前進行。在重新開啟標記為「不修復」的工單之前，請務必先在論壇或郵件列表中取得共識。
- duplicate（重複）
當另一個工單涵蓋相同的問題時使用。透過關閉重複的工單，我們可以將所有討論集中在同一個地方，這對大家都有幫助。
- worksforme（對我來說有效）
當工單沒有足夠的詳細資訊來重現原始錯誤時使用。
- needsinfo（需要資訊）
當工單沒有足夠的資訊來重現回報的問題，但可能仍然有效時使用。當提供更多資訊時，應重新開啟工單。
如果您認為工單被錯誤關閉 – 因為您仍然遇到該問題，或它在其他地方再次出現，或負責分類的人員犯了錯誤 – 請重新開啟工單並提供更多資訊。同樣，請不要重新開啟標記為「不修復」的工單，並將問題帶到 Django 論壇 或 django-developers 郵件列表。
我如何協助分類？¶
分類流程主要由社群成員推動。實際上，任何人都可以提供協助。
要參與，請先在 Trac 上建立帳戶。如果您有帳戶但忘記了密碼，可以使用 密碼重設頁面 重新設定密碼。
然後，您可以透過以下方式提供協助：
將「未審閱」工單關閉為「無效」、「對我來說有效」或「重複」或「不修復」。
當描述過於稀少而無法採取行動，或當它們是需要在 Django 論壇 或 django-developers 上進行討論的功能請求時，將「未審閱」工單關閉為「需要資訊」。
更正工單中錯誤設定的「需要測試」、「需要文件」或「有修補程式」標籤。
為小型且相對簡單的工單設定「容易上手」標籤。
設定仍未分類的工單的類型。
檢查舊工單是否仍然有效。如果工單長時間沒有任何活動，則問題可能已修復，但工單尚未關閉。
識別工單中的趨勢和主題。如果有很多關於 Django 特定部分的錯誤報告，這可能表示我們應該考慮重構該部分程式碼。如果出現趨勢，您應該在 Django 論壇 或 django-developers 上提出討論（參考相關工單）。
驗證其他人提交的解決方案是否正確。如果它們是正確的，並且也包含適當的文件和測試，則將它們移至「準備簽入」階段。如果它們不正確，則留下評論說明原因並設定相應的標籤（「修補程式需要改進」、「需要測試」等）。
但是，我們要求在工單資料庫中工作的所有一般社群成員執行以下操作：
請不要將您自己的工單提升為「準備簽入」。您可以將您已審閱的其他人的工單標記為「準備簽入」，但您應該至少讓另一位社群成員審閱您提交的修補程式。
請不要在未向 Django 論壇 或 django-developers 發布訊息以尋求共識的情況下，撤銷決定。
如果您不確定是否應該進行變更，請不要進行變更，而是留下帶有您擔憂的評論在工單中，或向 Django 論壇 或 django-developers 發布訊息。不確定是可以的，但您的投入仍然很有價值。
二分法尋找回歸錯誤¶
回歸錯誤是在某些較新版本的 Django 中存在，但在較舊版本中不存在的錯誤。一個非常有用的資訊是引入回歸錯誤的提交。知道導致行為變更的提交有助於識別變更是有意為之還是無意造成的副作用。以下是如何確定這一點的方法。
首先，為該問題在 Django 的測試套件中編寫回歸測試。例如，我們假設我們正在偵錯遷移中的回歸錯誤。在您編寫測試並確認它在最新的主分支上失敗後，將其放在可以單獨運行的單獨檔案中。在我們的示例中，我們假設我們創建了 tests/migrations/test_regression.py，可以使用以下命令運行：
$ ./runtests.py migrations.test_regression
接下來，我們將歷史記錄中的目前點標記為「錯誤」，因為測試失敗
$ git bisect bad
You need to start by "git bisect start"
Do you want me to do it for you [Y/n]? y
現在，我們需要找到回歸錯誤引入之前的 git 歷史記錄中的一個點（即測試通過的點）。使用類似 git checkout HEAD~100 的命令來簽出較早的版本（在本例中為早 100 次提交）。檢查測試是否失敗。如果是，將該點標記為「錯誤」（git bisect bad），然後簽出較早的版本並重新檢查。一旦找到測試通過的版本，將其標記為「良好」
$ git bisect good
Bisecting: X revisions left to test after this (roughly Y steps)
...
現在我們準備好進行有趣的部分：使用 git bisect run 自動完成剩下的流程
$ git bisect run tests/runtests.py migrations.test_regression
您應該會看到 git bisect 使用二分搜尋來自動簽出良好提交和錯誤提交之間的版本，直到找到第一個測試失敗的「錯誤」提交。
現在，在 Trac 工單上報告您的結果，並請將回歸測試作為附件。當有人編寫錯誤的修復程式時，他們已經有您的測試作為起點。
