此页面描述了任务（错误和增强请求）如何通过 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 关闭，提供原因
不是缺陷：提交者误解或误用了功能或工单没有意义
范围太大：该功能更适合在设计维基中创建一个页面，而不是工单
不希望的增强：增强不是我们想要做的事情
重复的：现有工单
太多事情：将此工单分解成更小的部分
设置 Approval=Triaged - 问题是正常的
如果需要，请调整工单以满足Creating Tickets中的标准
预筛选
谁：审阅人员
报告：已分类的工单
目标：在 Rich 进行审查之前改进工单并筛选补丁程序，以便更快速地通过流程的剩余部分
操作
设置 Approval=Prescreened - 补丁程序正常
就补丁程序问题对工单发表评论（保留在 Triaged 中）
审查
发布计划
人员：Rich
报告：已审查的工单
目标：确定工单是下一版本中的范围还是应该作为积压
操作
将修复版本设置为“Backlog” - 不想在下一版本中修复它
将修复版本设置为当前版本
如果没有补丁程序，它将显示在Needs Patch报告中
如果有补丁程序，它将显示在Screenable报告中
开发者补丁程序
人员：贡献者（任何有签名 CA 的人）
报告
Needs Patch - 对于需要补丁程序的工单
Incomplete工单 - 对于有补丁程序但需要修改的工单
目标：创建一个高质量的工单和补丁程序以供考虑（请参阅下面的部分）
操作
根据评论编辑工单或更新补丁程序以解决问题或差距。
添加一个新补丁并将“Patch”属性更改为“Code”或“Code and Test”会自动使补丁从“Needs Patch”移动到“Screenable”工单列表中。但是，将补丁添加到不完整的工单不会这样做。Alex Miller 会定期扫描不完整的工单，看看它们是否已准备好返回到可筛选的工单，并手动进行这些状态更改。
筛选
谁：审阅人员
报告
目标：验证工单和修补程序是否已准备好由 Rich 审核。质量标准很高 - 工单和修补程序应该是完美的。
是否有修补程序？
是否有测试？
提交者是否已签署 CA？
您能将修补程序应用到当前源代码树中吗？
所有测试是否都通过？
修补程序是否简洁（没有多余的空格或超出问题范围的更改）？
文档字符串是否仍然准确？
是否存在潜在的性能影响？如果是，已执行哪些基准测试？
该解决方案是否遵循代码准则并在外形上与周围的代码类似？
该解决方案是否暗示在其他地方可能存在类似的更改？
该解决方案是否引入了可能需要考虑或记录的新故障条件？
该解决方案是否更改了可能影响用户的外部或内部 API？
操作
将批准设为“未完成”，并添加描述所需改进的评论
将批准设为“已筛选” - 工单和修补程序完美无缺，Rich 应审核
最终筛选
人员：Rich
报告：已筛选工单
目标：Rich 通过变更
操作
将批准设为“未完成” - 工单或修补程序需要改进
将批准设为“确定” - 一切就绪，准备提交
提交
谁：通常为 Stu H
报告：确定工单
目标：对更改进行最终审核并提交到 Clojure 源
操作
确保您拥有正确的修补程序
确保提交者已签署 CA
仔细检查修补程序是否可以干净地应用并进行本地构建
提交并推送修补程序
我发现从单独的本地存储库进行提交是最安全的。我有一个“clojure”git 克隆，它对 dev 和 screening 没有推送权限，还有一个用于提交的单独“clojure-for-commit”签出。这减少了我的肌肉记忆在错误的时间产生“git push”的可能性。
将批准设为“已接受”，并关闭工单
待办事项审查
谁：主要是 Rich
报告：待办事项工单
目标：了解积压工单是否应并入下个版本
操作
将修复版本从待办事项设为当前版本
（或者不设来保留在待办事项中）