このページでは、チケット（バグや機能拡張のリクエスト）がJIRAチケットシステムを通過し、最終的にClojure、ClojureScript、ClojureCLRの一部となるまでの全体的なワークフローについて説明します。
ここで説明する全体的なプロセスには、いくつかの目標があります。
Clojureの品質を維持する
ユーザーにとって重要な問題を解決する
コミュニティを巻き込み、可能な限り最高のClojureを目指して協力する
このプロセスには、責任のレベルに応じていくつかのグループが関わっています。
誰でも - Clojure JIRAアカウントを作成すれば、誰でもClojureにバグや機能拡張のリクエストを提出できます。
貢献者 - 貢献者契約に署名した人は誰でも、パッチを提供したり、チケットの改善に取り組むことができます。
選別者 - 信頼できる少人数のグループに、特にトリアージと選別活動において、プロセスの（一部の）ステージをチケットを進める権限が付与されています。
BDFL - Rich Hickeyは、Clojureに何が取り込まれるかを決める、創設者であり慈悲深い終身独裁者です。Stuart Hallowayも特別なアクセスレベルを持っており、通常はClojureにパッチをコミットします。
チケットには、以下のワークフローにおける「状態」を共同で決定する重要なフィールドがいくつかあります。知っておくべき重要なフィールドを以下に示します。
JIRAステータス - デフォルトのJIRAワークフローを管理し、オープン、進行中、再オープン、解決済み、クローズで構成されます。
Clojureワークフローでは、これらのステータスは、一般的なオープン/クローズの区別以外には、あまり区別されません。
承認 - （主に）選別者がチケットの状態を変更する方法であるカスタムフィールドです。
なし - 新しいチケット
トリアージ済み - 選別者が、チケットに取り組む価値があると承認しました。
事前選別済み - 選別者がチケットを承認し、レビューのためにパッチを選別しました。
審査済み - 選別者とRichが、チケットに取り組む価値があると承認しました。
選別済み - 選別者が、Richによるレビューのためにチケットのパッチを承認しました。
不完全 - 選別者が、チケットまたはパッチの改善をリクエストしました。
OK - Richが、チケットの取り込みを承認しました。
パッチ - 添付されているパッチの種類を修飾します。
なし - パッチなし
コード - コードのみ、テストなし
コードとテスト - コードとテスト
修正バージョン
リリースX.X - 特定のターゲットリリース
バックログ - 将来のリリースで検討します
解決 - チケットがクローズされると、解決策が設定されます。
却下 - 作業のためにチケットを受け入れませんでした。
重複
完了
未解決
以下の図は、チケットがシステムを通過するプロセスを示しています。丸みを帯びたボックスは、ワークフローの状態を表しています。これらは明確に定義された基準（複数のフィールドをカバーする場合もある）を持っており、それぞれの状態をレポート化できます。一般的に、単一行の状態は承認状態を示します。追加のフィールドが関係している場合は、状態の後にリストされます。
色のついたブロックは、異なるグループによって実行されるアクティビティを表しています。色はグループに対応しています（オレンジ=貢献者、青=選別者、緑=BDFL）。ひし形は、アクティビティ中に下される決定を表しています。アクティビティについては、図の下で詳しく説明します。
トリアージ
担当者：選別者
レポート：オープンチケット
目標：チケットに記載されているバグや機能拡張が実際にバグなのか機能拡張なのかを判断する。
プロセス（チケットの作成を参照）
チケットは1つのことについてですか？そうでない場合は、チケットを自分で分割するか、提出者に分割を依頼してください。
チケットは問題を明確に statedていますか？そうでない場合は、自分で更新するか、提出者に更新を依頼してください。
大規模な機能拡張/機能の場合は、提出者にclojure-devに投稿し、デザインwikiにページを作成することをお勧めします。
バグの場合は、問題が実際に存在することを示すもの（REPLからの出力、テストなど）が必要です。Clojureの現在のリリースで問題が存在することを確認してください。
チケットには、他の関連する議論（clojure-devスレッド、IRC会話など）へのリンクが含まれていますか？
この段階では、パッチがあること、またはパッチが問題を修正することを検証する必要はありません。
アクション、いずれかを選択
チケットにコメントして、詳細情報、より良い説明、問題のより良いデモンストレーションなどを依頼する
解決=却下でクローズ、理由
バグではない：提出者が機能を誤解または誤用したか、チケットが意味をなさない
スコープが大きすぎる：機能は、チケットではなくデザインwikiにページを作成する方が適切な場合があります。
機能拡張は不要：機能拡張は、私たちが行いたいことではありません。
重複：既存のチケットと重複している
多すぎる：このチケットを小さな部分に分割する
承認=トリアージ済みに設定 - 問題はOK
必要に応じて、チケットの作成の基準に合わせてチケットを調整する
事前選別
担当者：選別者
レポート：トリアージ済みチケット
目標：Richが審査を行う前にチケットを改善し、パッチを選別することで、プロセスの残りの部分をより速く通過できるようにする
アクション
承認=事前選別済みに設定 - パッチはOK
パッチの問題に関するチケットにコメントする（トリアージ済みのまま）
審査
リリーススケジューリング
担当者：Rich
レポート：審査済みチケット
目標：チケットが次のリリースの範囲内にあるか、バックログに入れるべきかを判断する
アクション
開発パッチ
担当者：貢献者（署名済みCAを持つすべての人）
レポート
目標：検討のために高品質なチケットとパッチを作成する（以下のセクションを参照）
アクション
コメントに基づいて問題やギャップに対処するために、チケットを編集するかパッチを更新する。
新しいパッチを追加し、「パッチ」属性を「コード」または「コードとテスト」に変更すると、パッチは自動的に「パッチが必要」から「選別可能」なチケットのリストに移動します。ただし、不完全なチケットにパッチを追加しても、移動しません。Alex Millerは定期的に不完全なチケットをスキャンして、選別可能に戻す準備ができているかどうかを確認し、手動で状態を変更します。
選別
担当者：選別者
レポート
目標：チケットとパッチがRichのレビューの準備ができていることを確認する。品質基準は高く、チケットとパッチは完璧である必要があります。
チェック（チケットの作成、パッチの開発、チケットの選別を参照）
パッチはありますか？
テストはありますか？
著者はCAに署名していますか？
パッチを現在のソースツリーに適用できますか？
すべてのテストは合格しますか？
パッチはクリーンですか（問題の範囲外に余分な空白や変更はありませんか）？
ドキュメント文字列はまだ正確ですか？
パフォーマンスへの影響はありますか？もしそうなら、どのようなベンチマークが実行されましたか？
ソリューションはコードガイドラインに従っており、スタイルが周囲のコードと似ていますか？
ソリューションは、他の場所でも同様の変更が必要になる可能性を示唆していますか？
ソリューションは、考慮または文書化する必要がある新しい障害状態を導入していますか？
ソリューションは、ユーザーに影響を与える可能性のある外部または内部APIを変更していますか？
アクション
承認=不完全を設定し、必要な改善点を説明するコメントを追加する
承認=選別済みに設定 - チケットとパッチは完璧であり、Richはレビューする必要があります
最終選別
担当者：Rich
レポート：選別済みチケット
目標：Richが変更を承認する
アクション
承認=不完全を設定 - チケットまたはパッチの改善が必要
承認=OKに設定 - すべて良好、コミットの準備完了
コミット
担当者：Stu H（通常）
レポート：OKチケット
目標：変更の最終レビューとClojureソースへのコミット
アクション
正しいパッチがあることを確認してください
著者がCAに署名していることを確認してください
パッチが正常に適用され、ローカルでビルドされることを再確認してください
パッチをコミットしてプッシュする
コミットは、別のローカルリポジトリから行うのが最も安全です。開発と選別のためのプッシュ権限のない "clojure" gitクローンと、コミットのための別の "clojure-for-commit" チェックアウトがあります。これにより、私の筋肉の記憶が間違ったタイミングで "git push" を生成する可能性が低くなります。
承認=承認済みに設定し、チケットをクローズする
バックログレビュー
担当者：Rich（主に）
レポート：バックログチケット
目標：バックログに登録されたチケットを次のリリースに取り込む必要があるかどうかを確認する
アクション
修正バージョンをバックログから現在のリリースに設定する
（または、バックログに残す場合は設定しない）