在我的公司，这些规则适用：
您正在使用什么错误跟踪流程？它对你有用吗？
我们使用 BugZilla 进行错误跟踪，并且有如下规则：
任何人都可以报告错误，任何微小的变化都应该通过错误跟踪系统。如果是产品中的增强，则应将错误标记为增强，并应遵循错误跟踪系统。
任何人都可以将错误分配给其他任何人，这意味着如果错误存在于其他人的代码中，则可以轻松地将问题路由给其他人。可能存在需要在多个地方修复错误的情况，即首先要修复其他人的代码，然后再修复他/她的代码。在这些情况下，错误会被分配给首先需要完成工作的人，然后他/她通过重新分配将错误重新路由给适当的人。
如果一个问题出现在多个地方并且后面的代码不同但问题显然是相同的，则会克隆该错误，以便可以单独跟踪所有更改。
技术主管负责根据特定修复的需求确定错误的优先级。
测试人员/QAE 负责为错误分配严重性，即严重/主要/次要等。
所有错误都经过错误跟踪系统。来自客户的错误通过自定义标志单独分类以指示客户错误。客户错误大多存在于较旧的发布版本中，并且为它们创建了补丁，因此，它们是分开的。
通过这种方式，我们确保我们同时跟踪源代码控制系统（即 TFS 顺便说一句）和 Bugzilla 中的所有更改，以便将来需要时可以将任何更改追溯到原始代码更改/所有者。
听起来相当复杂。我们大致使用以下流程：
这是一个轻量级的过程，鼓励开发人员对他们的问题负责。
除此之外，无论更改请求的来源和类型如何，我们都为更改软件中的任何内容的过程制定了多项质量保证措施。这尤其包括：
我使用了大量的问题跟踪系统，包括 gnats（啊！）、Bugzilla（稍微少一点啊）、Trac、Jira，现在还有 FogBugz。我最喜欢 Trac，但这可能是因为我不是 FogBugz 的管理员，而且它在当前版本中被严重误用。
让工作流程正确是非常重要的，奇怪的是，它从决定在错误跟踪器中放入什么以及如何标记放入其中的东西开始。一旦你有了客户，所有的开发团队都会真正跟踪三种问题：
真实客户注意到的问题（实时错误）。
当前正在开发的新软件的问题（开发错误）。
我们将来想做的事情（功能）。
当然，这三类问题中的每一类都有自己的优先事项。只是按钮上的拼写错误的“实时错误”可能比阻止公开发布的版本或限制其他开发、测试等的“开发错误”重要得多。
问题的严重性描述了副作用的可怕程度。根据我的经验，这归结为：
该程序正在破坏某些东西。数据，客户被错误地计费，错误的药物被分配。这已经很糟糕了。我曾经在一个系统上工作过，其中一个软件命令将一个液压臂从一名军人的中间收回。这已经很糟糕了。
该程序正在崩溃，我们没有解决方法，但在此期间它并没有破坏任何东西（除了停机）。如果停机导致某些事情被破坏，请使用严重性 #1。
该程序行为不端，但我们有一个确定的解决方法，可以实际使用。
该程序以令人讨厌但不影响结果的方式行为不端。
该程序需要以某种明确定义的方式变得更好：更易于使用、实现新功能、运行更快等。
在这些系统中经常出现的另一个问题是“角色”的概念。应用于问题跟踪系统时，角色归结为允许谁做事。谁来制造问题？谁可以更改状态，谁可以将它们重新分配给另一个用户，谁可以关闭它们等等。
在我与之密切合作的中小型团队中，这套通用规则运行良好：
任何人都可以创建问题。创建者可以在创建问题时将问题分配给任何（或大多数）收件人。默认收件人是问题分类小组。开发人员可以通过这种方式记录他们在代码中发现的错误，并将错误分配给他们自己，以跟踪他们更改代码的原因。
分类团队开会（在此处指定时间间隔）以评估和分配问题。Triage 团队专门寻找重复的报告，在这种情况下，新问题会“汇总”到现有问题链中；对于现场未复制的问题，分配给 QA 进行复制；以及来自客户的高严重性问题。
错误的始作俑者是唯一可以关闭它的人。由 QA 或 CSR 发起的错误报告不能由开发人员关闭。是的，这意味着 CS 和开发团队不同意的错误仍未解决。当人们不同意时，为什么问题跟踪器将问题报告为已解决？如果你想要一个谎言的数字存储库，你有 C-SPAN。
一些团队可能希望将问题从一个部门转移到另一个部门到经理，其他团队可能允许任何团队成员将问题转移到（或返回）另一个团队。这可能归结为管理层的怀疑，或者仅仅是允许谁分配工作时间。
分类过程是关键。Triage 团队本质上是您组织中的任何人，他们决定谁从事什么工作，以及接下来要做什么。让团队定期开会有助于确保不会错过真正重要的事情，并且不会因为疏忽而放弃平凡的事情。如果 Triage 队列中没有任何内容，会议领导者可以取消会议（concall、netmeeting，无论实施如何）。
如果您正在使用 Scrum，那么 Triage 团队可能是 Scrum 主管，他们决定是否将某个问题拉入当前的 sprint，并在它进入积压工作时正确分配优先级。
等等，你写：
如果开发人员的问题被其他开发人员的代码阻止，她必须在错误跟踪系统之外解决此问题。
所以有一些错误超出了正常的错误流程。然后你有第二个系统来跟踪这些错误，或者这些都是临时的？
听起来您的错误跟踪系统实际上是一个用户缺陷跟踪系统。
它对您有用还是正在寻找替代品？
我认为客户也应该能够创建问题，不区分错误报告和功能请求。
问题的分配不应由开发人员自己执行：决定哪些问题必须为下一个版本修复应该是客户和经理的责任。
其他做法可以在Joel Spolsky的Painless Bug Tracking中找到。
在过去的 10 年中，我使用了几种不同类型的错误跟踪系统，包括无、word 文档、FogBugz、Bugzilla 和 Remedy。FogBugz 是迄今为止最好的一个。在那项工作中，任何人都可以输入错误，并且任何人都可以将错误分配给其他任何人。我发现这很有效，特别是如果我在我的代码中发现了一个小错误。与其花一个小时写电子邮件和填写表格并让其他几个人参与，我可以快速记录我发现并修复了一个错误。这鼓励我输入我发现的所有错误并快速修复它们。如果一个错误需要大量工作，那么我会将其分配给我的经理，以便他可以优先处理我的其他工作。
在我使用 Bugzilla 的工作中，每次创建、分配或更改错误时，都会向所有开发人员和经理发送一封电子邮件。这产生了相反的效果，它阻止了我在系统中查找和输入错误。
记录错误与速度有关 - 只是调查/复制错误所需的最少信息量
对于网络项目，这归结为：1）描述性错误标题，2）发生错误的页面，3）问题描述+屏幕截图或复制问题的分步说明（如果屏幕截图未提供）
屏幕截图非常强大有两个原因：1）一张图片说了一千个字，2）它为错误报告提供了可信度（曾经调查过一个你无法复制的错误并认为“看起来客户又在编造东西”？）
我有一篇博客文章进一步探讨了这个主题：像专业人士一样记录错误
我的小商店使用一个非常简单的工作流程：
这样，所有内容都会记录在错误跟踪系统中，并且我们通过不限制更新来保持效率。通过这种方式，您最终可能会收到一些“错误垃圾邮件”，但这比在我的经验中制造瓶颈要好。
我们使用 JIRA 作为我们的错误跟踪器 - 可以在 JIRA 中设置各种自定义工作流来强制执行您的特定流程，但我从未发现在较小的组织中需要这样做。
您正在使用什么错误跟踪流程？