一个拥有10多年历史的开源框架，成千上万的用户，以及复杂性，你能从中得到什么？一个拥有超过3000个未解决工单的JIRA实例；（微笑）。这个数字表明软件质量低吗？当然不是。但问题就在这里。绝大多数的工单已经不再是问题，不再相关，或者重复。由于数量庞大，几乎无法全部清理。
因此，最近，我投入了一些精力来尝试清理这些事情。这包括对工单的手动审查、识别可能重复项的脚本，以及各种形式的JIRA查询，试图展示“陈旧”的问题。到目前为止，我已经将未分配、未解决的工单数量减少了近1000个。迄今为止，只有少数这些工单在ORM 4+中仍然是有效的问题。
此外，我还实施了一些政策，这对贡献者和整个社区都非常有帮助（并将继续帮助）。最值得注意的是，任何没有提供测试用例的新BUG工单都将立即进入“等待测试用例”状态。如果大约3个月内没有收到任何东西，我们已经开始自动拒绝它们。尽管大多数贡献者通常都欣赏独立或扩展ORM现有单元测试（最好是）的复现者，但至少提供足够的细节（实体、映射、代码片段等）是最低要求。
沿着同样的思路，我们一直在邮件列表中讨论可能的策略[2]。我们希望将所有ORM 3工单推到“等待测试用例”状态，并要求在ORM 4或5上提供复现。这将影响以下BUG：1.) 设置为仅ORM 3的affectedVersions（不是ORM 4/5） 2.) 未分配的 3.) 在过去90天内未更新。这些将落入我们自动拒绝工单的政策中，如果工单在3个月内没有收到测试用例。请参阅邮件列表中的讨论以及将要使用的查询。如果有任何反对尝试这种方法的意见，请提出。
还值得重申的是，不应该用JIRA来代替用户论坛[3]或StackOverflow等问答网站。请只为简洁的问题创建工单，包括重现测试用例（或者当然，新功能和可能的改进）。
如果您对我的实际清理过程中采取的步骤感兴趣，这里有一个较为详细的说明：[a href="http://www.3riverdev.com/blog/man-vs-jira-the-3000-issue-tracker-fight" target="" class="regularLink">http://www.3riverdev.com/blog/man-vs-jira-the-3000-issue-tracker-fight
如果您有任何问题或想法，请与我联系！在Freenode IRC上的brmeyer是最合适的联系方式，以及在此帖子的评论。谢谢！
[1] https://github.com/3RiverDevelopment/bug-tracker-duplicate-utils
[2] http://lists.jboss.org/pipermail/hibernate-dev/2014-March/011238.html
[3] https://forum.hibernate.org/viewforum.php?f=1
