几年来，我们一直在忠实地使用Trac，而我们的“活动票”列表已增长到近200个。这些错误包括优先级太低且暂时无法修复的错误，已推迟的功能请求，从未真正引起投诉的问题，但每个人都同意应该有朝一日修复，计划的代码重构以及我们不愿意做的其他设计问题不想迷路，等等。
结果，在其中近200个问题中，这个列表几乎是不堪重负的。它不再是当前需要处理的工作的来源。
跟踪此类问题的最佳方法是什么？
问题的部分原因是其中某些问题的优先级较低，以至于它们可能永远无法解决。我讨厌丢失这些物品（类似于不想在我的房子里扔东西，以防有一天可能需要它）；我是否需要将它们扔掉（通过将它们标记为wontfix），并假设将来需要时可以找到它们？
Answers:
首先，让每个开发人员查看每个项目并检查/测试每个项目是否仍然存在问题（将这些项目分配给所有人可能是最好的方法）。然后，关闭不再是问题或已由其他开发工作解决的问题。
现在确保将每个标记都标记为大型，中型或小型开发工作。这是一个非常粗略的估计，仅用于更轻松地对项目进行分类并帮助将它们组合在一起。如果一切都已估算，那么它将有所帮助，但不要浪费时间。只需快速进行肠道检查即可。通常，它可以使开发人员进入一个房间，然后仔细检查每个项目，并使用大多数人认为适当的努力。
复查三个工作组中的每个工作组，并在优先级中将其标记为“关键”，“高业务价值”，“高技术价值”，“中值”，“低价值”和“永不修复”。
至此，您真正了解了清单，并且真正了解了积压中涉及的工作，并且您可以开始真正决定如何处理这些项目。将所有标记为永不修复的项目从存档中排除。
现在，当您计划要发布到下一个版本中的项目时，可以将关键和高度重要的项目用作发布的核心。查看中优先级和低优先级项目的列表，并添加与列表中其他项目可以同时处理的任何项目，因为开发人员已经在系统的该部分中进行工作。
标有中优先级或低优先级的项目列表可以用作人们在有空闲时间时要从事的工作的列表，或用作新员工的培训。我总是发现，在每次迭代过程中只有一个人参与这些项目并在必要时为团队的其他成员提供帮助是一件很高兴的事情。这样，您仍然可以完成当前迭代的工作，但是要有一个灵活的人，可以在需要时扑灭火灾，但可以处理通常不会引起注意的问题。
我们发现很好的一件事是，在每次迭代之间，我们有一个短短的2周时间，整个团队只能处理带有少量开发工作的项目。我们将集中精力在短时间内关闭大量门票。
Trac是否有优先级设置？对于主要的表演停止者来说，大约是1，对于某个时候可以做的事情大约是5，大约吗？
如果您可以按优先级排序，则可以暂时忽略优先级较低的内容。
阅读：http : //en.wikipedia.org/wiki/5S_%28methodology%29
将它们放在阁楼上，等待一年，然后搬家。那就是我所做的。
认真地说，如果您不打算修复它，那就别管它了。请参阅极限编程。
但是对于有关代码的项目。您可以将它们放在代码检查系统中，以作为轻微的观察。可以设置该系统来在系统的那部分进行编辑时标记问题。我发现这对同事没有用，认为这是预期的，没有解决审查意见。
唯一的方法就是无情的优先排序。现在就做，还是别打扰。
实际上，这不是版本控制问题，而是工作流程和业务优先级问题。跟踪已知是错误的事情是一个好主意，即使它们不太可能“永远”修复也有一些好处。一方面，这意味着QA（如果您有单独的QA团队）知道不为其记录新的错误。另一个好处是，如果出现新问题，但其根本原因是由于其中一个“我们知道但它的优先级较低”问题，则已经跟踪了对该修复程序的任何分析-这可以使更新，更高，该错误的优先级版本更容易修复。
这方面的另一个方面是，无论现在还是将来，在处理某些工作上都可能会有一些余地。也许有一天您会得到一个实习生，并且可以给他们分配一些简单的实习生作为介绍，以使他们在代码库中专心致志。
如果开发人员认为这些问题可以解决（例如，如果它们代表技术债务），并且可以使代码库更易于修复，但它们没有任何商业价值，则可能值得讨论与业务利益相关者合作，查看是否可以达成协议，以使那些积压的项目确实会偶尔出现。我已经看到了Scrum团队所做的事情，例如将“技术积压”项目的每个sprint速度限制为3-5个点-根据开发团队与业务利益相关者之间的关系，这可能需要进行一些政治上的罚款，但是我已经看到它工作得很好。