此頁面說明問題單（錯誤和增強要求）如何透過 JIRA 問題單系統，最終成為 Clojure、ClojureScript 和 ClojureCLR 的一部分。
此處說明的整體流程有幾個目標
維護 Clojure 品質
修正對使用者很重要的問題
讓社群參與合作，朝向最佳的 Clojure 邁進
這個流程包含了幾個群組，責任程度逐漸提升
任何人 - 只要建立了 Clojure JIRA 帳戶，任何人都可以向 Clojure 提交錯誤或增強要求
貢獻者 - 任何已 簽署貢獻者協議 的人，都可以提供修補程式或協助改善問題單
篩選者 - 較小的一群受信任個人已被授予權限，可以將問題單移至（部分）流程階段，特別是分類和篩選活動
BDFL - Rich Hickey 是 Clojure 的創建者和終生仁慈獨裁者。Stuart Halloway 也有特殊存取權限，通常會提交修補程式至 Clojure。
問題單上有幾個重要欄位，共同決定其在下方工作流程中的「狀態」。以下是一些需要了解的重要欄位
JIRA 狀態 - 這些狀態管理預設的 JIRA 工作流程，包括開啟、進行中、重新開啟、已解決、已關閉
Clojure 工作流程並未真正區分這些狀態，除了常見的開啟/關閉區分
核准 - 一個自訂欄位，（大多數）篩選者用來變更問題單狀態
無 - 新問題單
已分類 - 篩選者已核准問題單值得處理
已預先篩選 - 篩選者已核准問題單，並篩選修補程式以供審查
已審查 - 篩選者和 Rich 已核准問題單值得處理
已篩選 - 篩選者已核准問題單的修補程式，供 Rich 審查
未完成 - 篩選者已要求改善問題單或修補程式
確定 - Rich 已核准問題單以供納入
修補程式 - 說明所附加修補程式的種類
無 - 沒有修補程式
程式碼 - 只有程式碼，沒有測試
程式碼和測試 - 程式碼和測試
修正版本
版本 X.X - 特定的目標版本
待辦事項 - 將在未來的版本中考慮
解決方案 - 當問題單關閉時，它會有解決方案
已拒絕 - 未接受問題單進行處理
重複
已完成
未解決
下方的圖表說明問題單如何通過系統的流程。圓角方塊代表工作流程中的狀態。它們有明確定義的準則（有時涵蓋多個欄位），因此這些狀態中的每個狀態都可以有報告。一般來說，單行狀態表示核准狀態。如果還有其他欄位在使用中，則會在狀態後列出。
彩色區塊代表不同小組執行的活動 - 顏色對應小組（橘色 = 貢獻者，藍色 = 篩選者，綠色 = BDFL）。菱形代表活動中要做的決定。活動在圖表下方有更詳細的說明。
分類
誰：篩選者
報告：開啟的票證
目標：決定票證中描述的錯誤或增強功能是否實際上是真正的錯誤或增強功能。
流程（請參閱：建立票證）
票證是否關於 1 件事？如果不是，請自行拆分票證或要求提交者這麼做。
票證是否清楚說明問題？如果不是，請自行更新或要求提交者這麼做。
對於較大的增強功能/功能，建議提交者發布到 clojure-dev，然後在設計 wiki 上建立一個頁面會更好。
對於錯誤，應該有一些證明問題實際存在（來自 repl、測試等的輸出）。驗證問題存在於 Clojure 的當前版本中。
票證是否包含連結到其他相關討論（例如 clojure-dev 討論串、IRC 對話等）？
在此階段，不需要有修補程式或驗證它是否解決了問題。
動作，選擇下列其中一項
在票證上留言，要求提供更多資訊、更好的說明、更好的問題證明等
以 Resolution=Decline、原因關閉
不是錯誤：提交者誤解或誤用功能，或票證沒有意義
範圍太大：建立設計 wiki 中的頁面可能比在票證中建立頁面更適合此功能
不想要的增強功能：增強功能不是我們想做的
重複：現有票證
太多事情：將此票證拆分成較小的部分
設定 Approval=Triaged - 問題沒問題
如有需要，將票證調整為建立票證中的標準
預先篩選
誰：篩選者
報告：已分類的票證
目標：在 Rich 審查之前改善單據並篩選補丁，讓流程的剩餘部分能更快速通過
動作
設定核准=預先審查 - 補丁沒問題
針對補丁問題在單據上留言（保留在已分類中）
審查
版本排程
人員：Rich
報告：已審查的單據
目標：確定單據是否在下次發行的範圍內，或應列入待處理事項
動作
開發人員補丁
人員：貢獻者（任何有簽署 CA 的人）
報告
目標：建立高品質的單據和補丁以供審查（請參閱以下各節）
動作
編輯單據或更新補丁以根據留言處理問題或差距。
新增補丁並將「補丁」屬性變更為「程式碼」或「程式碼和測試」會自動讓補丁從「需要補丁」移到「可篩選」的單據清單。不過，將補丁新增到未完成的單據並不會這樣做。Alex Miller 會定期掃描未完成的單據，查看它們是否已準備好回到可篩選狀態，並手動變更這些狀態。
篩選
誰：篩選者
報告
目標：驗證票證和修補程式是否已準備好供 Rich 檢閱。品質標準很高 - 票證和修補程式應完美無缺。
是否有修補程式？
是否有測試？
作者是否已 簽署 CA？
您是否可以將修補程式套用至目前的原始碼樹狀結構？
所有測試是否都通過？
修補程式是否乾淨（沒有多餘的空白或超出問題範圍的變更）？
文件字串是否仍然準確？
是否有潛在的效能影響？如果有，已執行哪些基準測試？
解決方案是否遵循程式碼準則，且在樣式上看起來與周圍程式碼相似？
解決方案是否暗示其他地方可能需要類似的變更？
解決方案是否會引進新的失敗情況，可能需要考慮或記錄？
解決方案是否會變更可能會影響使用者的外部或內部 API？
動作
設定核准=不完整，並新增說明描述所需的改進事項
設定核准=已篩選 - 票證和修補程式完美無缺，Rich 應予以檢閱
最後篩選
人員：Rich
報告：已篩選票證
目標：Rich 同意變更
動作
設定核准=不完整 - 票證或修補程式需要改進
設定核准=確定 - 一切良好，準備提交
提交
誰：Stu H（通常）
報告：確定票證
目標：變更的最後檢閱，並提交至 Clojure 原始碼
動作
確定您擁有正確的修補程式
確定作者已簽署 CA
再次檢查修補程式是否已乾淨套用並在本地建置
提交並推送修補程式
我發現從一個獨立的本地儲存庫進行提交最安全。我有一個「clojure」git clone，它沒有 dev 和 screening 的推送權限，以及一個獨立的「clojure-for-commit」簽出用於提交。這可降低我的肌肉記憶在錯誤的時間產生「git push」的機率。
設定核准=已接受，並關閉票證
積壓檢閱
誰：Rich（主要）
報告：積壓票證
目標：查看是否應將積壓的票證拉入下一個版本
動作
將積壓的修正版本設定為目前的版本
(或不設定，留在積壓中)