Django使用Trac来管理代码库上的工作。Trac是一个社区倾向的花园的人们发现的错误和人们想看到添加的功能。在任何花园里，有时有杂草被拉，有时有花和蔬菜需要采摘。我们需要你的帮助来整理一个，而最终我们都一起受益。
像所有的花园，我们可以追求完美，但在现实中没有这样的事情。即使在最原始的花园里仍然有蜗牛和昆虫。在社区花园里，也有有益的人，以最好的意图 - 施肥的杂草和毒玫瑰。社区整体的工作是自我管理，将问题降至最低，教育那些进入社区的人，使他们成为有价值的贡献成员。
同样，虽然我们的目标是让Trac成为Django进步状态的完美代表，但我们承认这不会发生。通过将Trac维护的负载分配给社区，我们接受会出现错误。Trac是“大部分准确”，我们给予的事实，有时，这将是错误的允许。没关系。我们是最后期限的完美主义者。
我们依靠社区继续参与，保持门票尽可能准确，并提出问题讨论我们的邮件列表，当有困惑或不同意。
Django是一个社区项目，每一个贡献都有帮助。我们不能在没有您的情况下这样做！
不幸的是，并非机票跟踪器中的所有错误报告和功能请求都提供所有required details。许多票有补丁，但这些补丁不满足good patch的所有要求。
帮助的一种方法是对由其他用户创建的票证进行分类。核心团队和几个社区成员定期工作，但更多的帮助总是感谢。
大多数工作流程基于机票的triage stages的概念。每个阶段描述在其生命中在任何时间给定票券的位置。除了少量的标志，这个属性很容易告诉我们什么和每张票是什么等待。
因为一张图片值得一千字，让我们从那里开始：
我们在这个图中有两个角色：
举例来说，这里我们看到平均票的生命周期：
一些票需要比这更少的反馈，但然后再次一些票需要更多。
下面我们更详细地描述票在其寿命期间可能流过的各个阶段。
票据没有被任何人审查，任何人谁有资格做出判断，票是否包含有效的问题，一个可行的功能，或应该由于各种原因关闭。
大灰色地带！“接受”的绝对含义是，机票中描述的问题是有效的，并且正在处理的某个阶段。除此之外，还有几个注意事项：
已接受+无标志
票是有效的，但还没有人提交补丁。通常这意味着你可以安全地开始为它写一个补丁。这对于接受的错误的情况通常比接受的特征更加真实。已经被接受的错误的票证意味着该问题已经被至少一个triger验证为合法的错误 - 并且如果可能的话应该是固定的。接受的新特征可能仅意味着一个三元组认为该特征将是好的，但是这本身并不代表一致的观点或意味着任何确定性将接受该特征的补丁。如果您有疑问，请在编写大量补丁之前获得更多反馈。
已接受+有补丁
该票正在等待人们查看提供的修补程序。这意味着下载补丁并试用它，验证它包含测试和文档，使用包含的补丁运行测试套件，并在故障单上留下反馈。
已接受+有补丁+需要...
这意味着该票已经过审查，并且已被发现需要进一步的工作。“需要测试”和“需要文档”是不言自明的。“补丁需求改进”通常伴有对票证的解释，说明需要改进代码。
除了提供补丁并发现满足提交就绪补丁的所有要求的人之外，该票据由社区的任何成员审阅。提交者现在需要在提交之前给补丁一个最终审查。请参阅New contributors’ FAQ“我的票券一直在RFC中！我该怎么办？”
此阶段未在图中显示。它只被核心开发者用来跟踪高级想法或长期功能请求。
这些票是不常见的，总体上不太有用，因为它们没有描述具体的可操作问题。它们是增强请求，如果提交了一个优秀的补丁，我们可能会考虑将其添加到框架中。它们不是高优先级。
在票证中可以设置多个在Trac中显示为复选框的标志：
此标志用于具有需要关联文档的修补程序的故障单。功能的完整文档是我们可以将其检入代码库之前的先决条件。
这标志着补丁需要相关的单元测试。同样，这是有效补丁的必需部分。
此标志表示虽然票证具有补丁，但它尚未准备好检入。这可能意味着补丁不再完全适用，实施中存在缺陷，或者代码不符合我们的标准。
门票，需要小，容易，补丁。
票据应分类为组件，指示它们所属的Django代码库的哪个区域。这使得票更好组织和更容易找到。
严重性属性用于标识阻止程序，即在发布下一个版本的Django之前应该解决的问题。通常，这些问题是导致来自早期版本的回退的错误或潜在地导致严重的数据丢失。此属性很少使用，绝大多数票证的严重性为“正常”。
可以使用版本属性来指示在哪个版本中标识了报告的错误。
此标志用于与用户界面和用户体验问题相关的票证。例如，此标志适用于表单中的面向用户的功能或管理界面。
您可以将此用户名或电子邮件地址添加到此字段，以便在对票证进行新捐款时收到通知。
使用此字段，您可以标记具有多个关键字的机票。这可以是有用的，例如，将同一主题的几张票分组。关键字可以是逗号或空格分隔。关键字搜索在关键字的任何位置找到关键字字符串。例如，单击具有关键字“form”的票证将产生用包含诸如“formset”，“modelformset”和“ManagementForm”的字符串的关键字标记的类似票券。
当票证已经完成了其有用的生命周期时，它是关闭它的时候了。但是，关闭机票是一个重大的责任。你必须确保问题真的解决了，你需要记住的是，机票的记者可能不高兴有他们的票关闭（除非它是固定的，当然）。如果你不确定要关闭机票，只需留下你的想法。
如果您关闭机票，您应该始终确保以下内容：
票可以通过多种方式解决：
一旦补丁已经被转换到Django并且问题是固定的，由核心开发人员使用。
如果发现票证不正确，则使用。这意味着票证中的问题实际上是用户错误的结果，或描述了除Django之外的其他问题，或者根本不是错误报告或功能请求（例如，一些新用户提交支持查询门票）。
当核心开发人员决定此请求不适合在Django中考虑时使用。这通常是在django-developers邮件列表中讨论后选择的。随时可以在django-developers邮件列表上开始或加入讨论“wontfix”票证，但请不要重新打开core developer关闭为“wontfix” 。
当另一张票覆盖相同的问题时使用。通过关闭重复的票，我们把所有的讨论在一个地方，这有助于大家。
当票证不包含足够的详细信息以复制原始错误时使用。
当故障单不包含足够的信息以复制报告的问题但可能仍然有效时使用。当提供更多信息时，应重新打开该票。
如果您认为这张票错误关闭了，因为您仍然遇到问题，或者其他地方弹出，或者三人出了错误，请重新打开票证并提供进一步的信息。同样，请不要重新打开已被核心开发人员标记为“wontfix”的票证，并将问题改为django-developers。
分类过程主要由社区成员驱动。真的，ANYONE可以帮助。
核心开发者可以提供他们熟悉的问题的反馈，或者对有争议的问题做出决定，但是他们不负责一般性的票务。
要参与，请从在Trac上创建帐户开始。如果您有帐户但忘记了密码，可以使用密码重置页重置密码。
然后，你可以帮助：
但是，我们要求在票证数据库中工作的所有一般社区成员：
2015年5月13日