原文网址
http://www.yegor256.com/2014/11/24/principles-of-bug-tracking.html
比起让所有成员坐在一个办公室，一个工作团队更需要能够能远程获取许多强大的原则。总的来说，我的意思是交流的原则。在team.io, 我们已经远程开发了一款软件至少五年。我们严格地管理任务们通Ticketingsystems（如GitHUB, JIRA, Trac，Basecamp，等）并且，我们不提倡如 Skype网络电话, 电子邮件或打电话这类非正规的交流。每一个Ticket对我来说，其是一个拥有独立生命周期，拥有独立参与和自己目标的孤立任务。通过这些年，我已经学会了一些我想分享的课程，你将会发现这些课程非常有用，如果你也远程地和你的团队一起工作。
1. 面对面（keepit one on one）
每一个Ticket 或者说是BUG， 是定义问题的人和解决问题的人之间的一种联系。如果这是一个BUG,我来进行报告这个BUG，你来进行解决这个BUG。如果这是一个问题，我来进行询求解释，你来进行解释它。如果这是一个任务，我来规定你如何这个任务，你来执行。无论如何，在Ticket解决的这个过程中，只有两个主要的角色具有正规的作用，不论多少人参与到其中。
Ticket 报告者的责任是守住问题，当你报告问题的时候，你需要坚信问题的存在，这个就是你的工作。其他人或许会说你做错了，或则这个问题不存在。他们或许会说他们不能复制这个问题。他们或者会说这个任务的描述太模糊，他们不知道到底是怎么回事。这里会存在很多如此类的问题。我的工作是为了问题的存在而尽我最大的努力。显然，如果这些bug是不可再现的，我被迫结束了它，否则，我将是它的守护天使直到bug被解决：）。
另外一方面，解决问题的人的责任是守卫结论。当Ticket被分配到我身上的时候，我来解决它，我的工作是说服问题的报告者我的结论是足够好的。他或许会说你的结论不是很好，不是够高效，或则未完成，我的工作是坚持我是对的他是错的。当然啦，通过合理的方法，并且为了创建一个易于接收合理的结论。我不得不在第一时间知道问题，调查所有的可能项目，并且建议非常多的良好的实行措施。但是，所有的这些都是其次，最主要的事情是，我将要聚焦在如何说服提出问题的人。我将会记住我主要的目的是解决问题。
我的观点是，无论多少人参与到Ticket的讨论中，需要一直记住，它到底发生了什么——一个人将他的结论出售给其他人。身边的每一个人都是帮或是消遣。
2. 结束它（closeit）
需要牢记Ticket 不是插图，它不是你来讨论的对象，而是你需要解决的对象。当一个问题分配给你的时候，你需要集中精力来尽快地解决它。
当然，你为这个工程所做的最好的工作，集中注意力你将很快地解决问题。许多长时间存在的问题是管理者的噩梦。他们非常难控制和追踪。你可曾见过在那些开源的工程中，已经存在两年，并且具数以百计的评论但还没有被解决的问题？这些问题对工程的管理者和问题的参与者来说就是一个错误。每一个问题需言简意赅 ：1) 一个问题，2)简练问题，3)简短的解释，4)结论，5)解决，感谢所有人，这是一个理想的模型。
直到你意识到你的问题已经进入到大讨论中，努力去尝试尽快地解决它。我能够如何解决它，如果提出问题的人不喜欢你的结论？寻找一个临时性的结论，它满足提出者并能够让你解决问题。利用“TODO” 在你的代码中，或在布满灰尘的工作室，这些都比一个问题长时间的被搁置要强。
一旦你看到一个结论被提出并且它足够满足解决问题的需要，告诉提出问题的人来解决它，明确地需要这样，不要像这样“看起来这个结论好像可以被接受，如果你不在意。”需要明确地在你的意见中指出来结束这个问题并行动起来。试着这样“@jeff请结束这个问题，如果你没有任何进一步的问题。”
3. zhuizhong de d不要结束它！
每一次你提出一个BUG，和创建一个Ticket，你消耗项目资源。每一个问题报告都意味着资金用在项目上:1) 用在你寻找问题和报告它的钱，2) 忙于解决问题和寻找解决问题的人员的项目管理者所用的时间，3)试图了解你的报告和提供结论的问题解决者的时间；还有 4)每一个参与问题讨论人员的时间。
如果你结束一个Ticket，没有任何的疑问，这个Ticket就被恰当地解决了。 你把钱放进了垃圾箱。一旦这个Ticket开始了，是没有回头路的。我们不能只说“纳，忽略它，它不是很重要。”你的Ticket已经消耗了项目的时间和预算资源。为了将它们转换成有用的东西，你需要确保一些结论已经被提交。
这个可能是一个暂时的结论，这个可能是在项目文档中的一个直线改变，这个可能是TODO标记者在代码中所谓的“我们在意这些问题，但是我们因为太懒了而不能解决这个问题。”所有事情都需要有用起来，而不是没事。
从不同的观点看来 ，当你开始了这个Ticket，你必须在意一些事情。一些伴随着结果的东西不是对的。这就是你要报告一个BUG。如果你结束这个Ticket没有任何一个人接触到代码的有问题的区域，在几天或是几年的时间里面，一些人也将会有相同的关注。并且这个项目将会不得不为相识的Ticket或相同问题的讨论而买单。虽然有你已经确信你在代码中找到的这个问题不是真正的问题，要求一个Ticket解决者书在代码中写正确以来防止这些疑惑再次在未来发生。每一次你
4. 避免噪音—提出你的评语
每一次你发信到一个Ticket，请想一些人提出。否者，如果你的发的东西只是为了表达你自己的意见，你的评语将会变成交流噪音。牢记，一个Ticket是一段两个人之间的交流——一个是报告这个问题，另一个去努力去解决这个问题，像这样的评论“我们试着用另一种方式解决怎么样？”或者“我记得在一段时间之前，我有一个类似的问题”，是非常恼人和分心的。让我们诚实一点，没人需要或在意“选项们”，我们都在意的是结论。
如果你觉得Ticket应该被解决，因为所提出的结论已经足够了，你就需要朝Ticket的报告者发表你的评论。用这个作为开头“@jeff，我想这个结论已经足够好，因为······”这样，你将帮助到分配到任务的人结束这个问题和继续进行工作。
如果你觉得这个结论是错的，将你的评论发送给分配到任务的人，开头如下“@jeff 我想你的结论不是很好，因为······”这样你可以帮助Ticket的报告者继续开启这个问题，直到一个合适的结论提出来。
再次，不要用一般的评论来污染空气。取而代之，是非常特别和偏袒的评论——你要么喜欢这个结论希望这个Ticket被结束，或者你不喜欢这个结论，保持问题被开放。模棱两可的事情只会让情况变复杂，不会对工程有帮助。
5. 需要在坏时，第一时间报告
我觉得这点是很有必要的，但我还是将要重申：每一个Bug必须可再现。每一次你报告一个问题，你都需要解释这个产品如何确实地坏掉了。确实，你的工作提供这些：这个软件没有按照目的来工作，这个文档不合理，或没满足需求等等。
每一个BUG的提出需要遵循着一些简单的公式：“这是我们所拥有的，这是需要我们替换的，所以，却解决它。没一个Ticket，成为一个BUG，成为一个任务，成为一个问题，或者一个建议，都需要按照这个方式来排布。当你递交方案的时候，你要求一个方案从A点移动到B点，在A点的一些事情是不对的，对于我们所有人来说，这些事情在B点会更加好。所以非常明显，你不得不解释，哪里是A点，哪里是B点。如过你能够怎么到达这里，怎么再现这些问题并解决，这就让人非常满意。
甚至当你有问题的时候，你也应该遵循着这个格式。如果你有问题，这意味着这个项目文档不能够足够你来寻找答案，这就是坏掉的地方。你需要寻求解决办法。所以说这像这样的话“现在的文档不完整，它没解释道我怎么才能解决X类，请解决”，来代替“为啥我要用X类”。
如果你不来解释怎么到达这里的过程，这样说在一个Ticket“我看到这个类不能够按照它应该的方式工作，但是我不知道怎么复制这个问题并且如何解决”这样将会给所有人一个清楚的信息即你所在意的BUG报告中是不完美。对问题解决者而言，是需要提纯这些问题，并且找到方法来再现问题。如果问题背复制出来，你的bug是能给强行被解决的。
让我们再次重申，每一个Ticket都要从不对的A点拖出来而拖到能够解决它的B点，作为一个问题的报告者，你的工作像画一条线一样，清晰和明确。
相关报告：
你可能会找到一些你感兴趣的报道：
4496
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
