工单分类¶
Django 使用 Trac 来管理代码库的工作。Trac 是一个社区维护的平台，用于记录人们发现的 bug 和想要添加的功能。就像任何花园一样，有时需要清除杂草，有时需要采摘花朵和蔬菜。我们需要您的帮助来区分两者，最终，我们都将从中受益。
像所有花园一样，我们可以追求完美，但实际上并不存在完美的事物。即使是最原始的花园里也仍然有蜗牛和昆虫。在社区花园中，也有一些热心的人——出于好意——给杂草施肥，毒害玫瑰。整个社区的任务是自我管理，将问题最小化，并教育进入社区的人，以便他们成为有价值的贡献者。
同样，虽然我们的目标是让 Trac 完美地反映 Django 进度，但我们承认这不会发生。通过将 Trac 维护的工作分配给社区，我们接受了会存在错误的事实。Trac“大体上是准确的”，我们允许有时它会出错。没关系。我们是追求完美的截止日期主义者。
我们依靠社区继续参与，保持工单尽可能准确，并在出现混淆或分歧时，在我们的邮件列表中提出问题进行讨论。
Django 是一个社区项目，每一次贡献都有帮助。没有你，我们无法做到这一点！
分类流程¶
不幸的是，并非问题跟踪器中的所有错误报告和功能请求都提供所有必需的细节。许多工单提出了解决方案，但这些解决方案并不一定符合所有要求贡献指南。
一种帮助方法是对其他用户创建的工单进行分类。
大部分工作流程都基于工单的分类阶段概念。每个阶段描述了给定工单在其生命周期中的任何时间点所处的阶段。结合少量标志，此属性可以轻松地告诉我们每个工单在等待什么和谁。
俗话说，一图胜千言，让我们从这里开始。
在这个图中，我们有两个角色。
合并者：拥有提交权限的人，负责做出最终合并更改的决定。
工单分类者：Django 社区中任何选择参与 Django 开发流程的人。我们的 Trac 安装故意对公众开放，任何人都可以对工单进行分类。Django 是一个社区项目，我们鼓励社区参与分类。
例如，这里我们看到了一个普通工单的生命周期。
Alice 创建了一个工单并发送了一个不完整的拉取请求（没有测试，实现不正确）。
Bob 审核了拉取请求，将工单标记为“已接受”、“需要测试”和“补丁需要改进”，并留下评论告诉 Alice 如何改进补丁。
Alice 更新了拉取请求，添加了测试（但没有更改实现）。她删除了这两个标志。
Charlie 审核了拉取请求，并用另一个关于改进实现的评论重置了“补丁需要改进”标志。
Alice 更新了拉取请求，修复了实现。她删除了“补丁需要改进”标志。
Daisy 审核了拉取请求，并将工单标记为“准备签入”。
Jacob，一个合并者，审核了拉取请求并将其合并。
有些工单需要的反馈少得多，但另一些工单需要的反馈则多得多。
分类阶段¶
下面我们将更详细地描述工单在其生命周期中可能经历的各个阶段。
未审核¶
该工单尚未经过任何认为自己有资格判断该工单是否包含有效问题、可行功能或应因各种原因而关闭的人员的审核。
已接受¶
很大的灰色地带！“已接受”的绝对含义是工单中描述的问题是有效的，并且正在处理的某个阶段。除此之外，还有几个需要考虑的因素。
已接受 + 无标志
该工单有效，但还没有人为此提交补丁。这通常意味着您可以安全地开始编写修复程序。对于已接受的 bug 而言，这通常比已接受的功能更真实。一个已接受的 bug 工单意味着该问题已被至少一位分类者验证为合法的 bug——如果可能，应该修复它。已接受的新功能可能只意味着一位分类者认为该功能很好，但这本身并不代表一致的观点，也不能肯定地暗示该功能的补丁会被接受。如果您有疑问，请在编写大量贡献之前寻求更多反馈。
已接受 + 有补丁
该工单正在等待人们审核提供的解决方案。这意味着下载补丁并试用它，验证它是否包含测试和文档，使用包含的补丁运行测试套件，并在工单上留下反馈。
已接受 + 有补丁 + 需要……
这意味着该工单已审核，并且已发现需要进一步的工作。“需要测试”和“需要文档”是不言自明的。“补丁需要改进”通常会附带在工单上的评论，解释需要改进代码的内容。
准备签入¶
该工单已由社区中的任何成员（提供补丁的人员除外）审核，并发现符合提交就绪贡献的所有要求。合并者现在需要在提交之前进行最终审核。
有很多拉取请求。您的补丁可能需要一段时间才能得到审核。请参阅贡献代码常见问题解答，了解此处的一些想法。
将来考虑/也许¶
此阶段未显示在图中。它很少使用，用于跟踪高级想法或长期功能请求。
这些工单并不常见，而且总体上不太有用，因为它们没有描述具体可操作的问题。它们是我们将来可能会考虑添加到框架中的增强请求，前提是提交了优秀的补丁。它们并不属于高优先级。
其他分类属性¶
可以在工单上设置许多标志，在 Trac 中显示为复选框。
有补丁¶
这意味着该工单有相关的解决方案。将对其进行审核，以确保它们符合已记录的指南。
以下三个字段（需要文档、需要测试、补丁需要改进）仅当提供了补丁时才适用。
需要文档¶
此标志用于需要相关文档的补丁工单。功能的完整文档是我们在代码库中检查它们之前的先决条件。
需要测试¶
此标志将补丁标记为需要相关的单元测试。同样，这也是有效贡献的必要部分。
补丁需要改进¶
此标志意味着，尽管该工单有解决方案，但它还不完全准备好签入。这可能意味着补丁不再干净地应用，实现中存在缺陷，或者代码不符合我们的标准。
容易处理的¶
需要少量、简单的更改的工单。
类型¶
工单应按类型分类，介于：
- 新功能
用于添加新内容。
- 错误
当现有事物损坏或行为不符合预期时。
- 清理/优化
当没有任何东西损坏但某些东西可以做得更干净、更好、更快、更强大时。
组件¶
工单应分类到组件中，指示它们属于 Django 代码库的哪个区域。这使得工单组织得更好，更容易查找。
严重性¶
严重性属性用于识别阻塞程序，即在发布下一个 Django 版本之前应修复的问题。这些问题通常是导致从早期版本出现回归或可能导致严重数据丢失的错误。此属性很少使用，绝大多数工单的严重性为“正常”。
版本¶
可以使用版本属性指示在哪个版本中识别报告的错误。
UI/UX¶
此标志用于与用户界面和用户体验问题相关的工单。例如，此标志适用于表单或管理界面中的面向用户的功能。
抄送¶
您可以将您的用户名或电子邮件地址添加到此字段，以便在对工单进行新的贡献时收到通知。
关键词¶
使用此字段，您可以使用多个关键词标记工单。这可能很有用，例如，将几个关于同一主题的工单分组。关键词可以以逗号或空格分隔。关键词搜索会在关键词中的任何位置查找关键词字符串。例如，点击带有关键词“form”的工单将产生带有包含诸如“formset”、“modelformset”和“ManagementForm”等字符串的关键词的类似工单。
关闭工单¶
当工单完成其有效生命周期后，就该将其关闭了。但是，关闭工单是一项重大责任。您必须确保问题确实已解决，并且您需要记住，工单的报告者可能并不乐意看到他们的工单被关闭（除非它已修复！）。如果您不确定是否要关闭工单，请留下评论说明您的想法。
如果您确实要关闭工单，则应始终确保以下几点：
确保问题已解决。
留下评论解释关闭工单的决定。
如果他们有办法改进工单以重新打开它，请告知他们。
如果工单是重复的，请参考原始工单。还要通过在原始工单中留下评论来交叉引用已关闭的工单——这允许访问有关所报告的错误或请求的功能的更多相关信息。
请礼貌。没有人喜欢他们的工单被关闭。这可能会令人沮丧，甚至令人气馁。避免让人们停止为 Django 贡献的最佳方法是礼貌友好，并为他们将来如何改进此工单和其他工单提供建议。
工单可以通过多种方式解决：
- 已修复 (fixed)
在补丁已集成到 Django 中并且问题已修复后使用。
- 无效 (invalid)
如果发现工单不正确，则使用此状态。这意味着工单中的问题实际上是用户错误的结果，或者描述的是 Django 之外的某些问题，或者根本不是错误报告或功能请求（例如，一些新用户提交支持查询作为工单）。
- 不会修复 (wontfix)
当有人决定该请求不适合在 Django 中考虑时使用。有时，工单会被标记为“wontfix”关闭，并请求报告者在Django 论坛或django-developers邮件列表中开始讨论，如果他们对关闭工单的人提供的理由有不同意见。其他时候，讨论先于关闭工单的决定。在重新打开标记为“wontfix”的工单之前，请务必使用论坛或邮件列表达成共识。
- 重复 (duplicate)
当另一个工单涵盖相同的问题时使用。通过关闭重复的工单，我们将所有讨论都保留在一个地方，这有助于所有人。
- 对我有效 (worksforme)
当工单中没有足够的细节来重现原始错误时使用。
- 需要信息 (needsinfo)
当工单中没有足够的信息来重现所报告的问题，但可能仍然有效时使用。提供更多信息后，应重新打开工单。
如果您认为工单被错误地关闭了——因为您仍然遇到该问题，或者它出现在其他地方，或者分类者犯了错误——请重新打开工单并提供更多信息。再次强调，请不要重新打开已标记为“wontfix”的工单，而是将其问题提交到Django 论坛或django-developers。
如何参与分类？¶
分类流程主要由社区成员驱动。实际上，**任何人都**可以提供帮助。
要参与其中，请先在 Trac 上创建一个帐户。如果您有帐户但忘记了密码，您可以使用密码重置页面重置它。
然后，您可以通过以下方式提供帮助：
将“未审核”工单关闭为“无效”、“对我有效”或“重复”或“不会修复”。
当描述过于简略而无法操作，或者当它们是需要在Django 论坛或django-developers上进行讨论的功能请求时，将“未审核”工单关闭为“需要信息”。
更正工单中设置错误的“需要测试”、“需要文档”或“有补丁”标志。
为规模小且相对简单的工单设置“易于处理”标志。
设置仍未分类的工单的类型。
检查旧工单是否仍然有效。如果工单长时间没有活动，则问题可能已修复，但工单尚未关闭。
识别工单中的趋势和主题。如果有很多关于 Django 特定部分的错误报告，这可能表明我们应该考虑重构代码的那部分。如果出现趋势，您应该在Django 论坛或django-developers上提出讨论（参考相关工单）。
验证其他人提交的解决方案是否正确。如果它们正确，并且包含适当的文档和测试，则将其移动到“准备签入”阶段。如果它们不正确，请留下评论解释原因并设置相应的标志（“补丁需要改进”、“需要测试”等）。
但是，我们确实要求所有在工单数据库中工作的普通社区成员：
请**不要**将您自己的工单提升到“准备签入”。您可以将您已审核的其他人提交的工单标记为“准备签入”，但您应该至少获得另一位社区成员来审核您提交的补丁。
请**不要**在未向Django 论坛或django-developers发布消息以寻求共识的情况下反转决定。
如果您不确定是否应该进行更改，请不要进行更改，而是留下评论说明您在工单上的疑虑，或向Django 论坛或django-developers发布消息。不确定是可以的，但您的意见仍然很有价值。
二分回归¶
回归是在 Django 的某些较新版本中存在但在较旧版本中不存在的错误。一个非常有用的信息是引入回归的提交。了解导致行为变化的提交有助于确定更改是有意的还是无意的副作用。以下是确定此信息的方法。
首先为 Django 的测试套件编写回归测试以解决此问题。例如，我们将假装我们正在调试迁移中的回归。在编写测试并确认它在最新的主分支上失败后，将其放在您可以独立运行的单独文件中。在我们的示例中，我们将假装我们创建了tests/migrations/test_regression.py，可以使用以下命令运行：
$ ./runtests.py migrations.test_regression
接下来，我们将历史记录中的当前点标记为“错误的”，因为测试失败了。
$ git bisect bad
You need to start by "git bisect start"
Do you want me to do it for you [Y/n]? y
现在，我们需要在引入回归之前找到 git 历史记录中的一个点（即测试通过的点）。使用类似git checkout HEAD~100的命令来检出较早的版本（在本例中为 100 次提交之前的版本）。检查测试是否失败。如果是，则将该点标记为“错误的”（git bisect bad），然后检出较早的版本并重新检查。一旦找到测试通过的版本，将其标记为“正确的”。
$ git bisect good
Bisecting: X revisions left to test after this (roughly Y steps)
...
现在我们准备好进行有趣的部分了：使用git bisect run来自动执行其余过程。
$ git bisect run tests/runtests.py migrations.test_regression
您应该看到git bisect使用二分查找来自动检出正确和错误提交之间的版本，直到找到测试失败的第一个“错误的”提交。
现在，在 Trac 工单上报告您的结果，请将回归测试作为附件包含在内。当有人为错误编写修复程序时，他们已经拥有您的测试作为起点。
