在线项目中一个常见的陷阱是认为你需要回复所有的东西。你不必如此。首先，一般会有太多你无法同时跟踪的线索，至少是经过它开始的几个月后。其次，即使你已经决定参与，人们说的大多数话都无需回应。开发论坛都会不同程度的由下列三类信息占据：
提出重要事物的信息
提出对他人曾经说过的话表示支持或反对的信息
总结信息
上述信息并不是必定需要一个回应，特别是当你根据到目前为止的线索，很确定其他人会说出以前你说过的话时。 （如果你担心别人也使用这个策略，而落入等待-等待的循环，不必如此；几乎总会有某人愿意跳出来解决问题。） 回复应该由明确的目的激发。首先要问自己，是否知道所期望的完成的任务？其次，是否如果没有你的话，这个事情就无法完成。
在线索中发出你的声音的有两个理由，包括a) 当你在提议中发现了一个瑕疵，你怀疑你是唯一看到它的人，另外b) 你发现他人之间错误交流，并且知道你可以通过澄清文章修正它。通常在邮件中仅仅表明对某人工作的感谢或者只是说“我也是！”，因为读者可以立刻确认此类文章无需任何回应或进一步的动作，所以当读者达到邮件的最后一行，一个干净的结束符合他的心理需求。但是即使到了此时，说话之前也要再三考虑；一定要让别人觉得你说的太多而不是太少。（在忙碌的邮件列表中工作的更多想法的第二部分请看Appendix C, 为什么我要关注车棚的颜色？）
在忙碌的邮件列表中，你有两个诫命。第一，很明显，要指出哪些需要关注，哪些需要忽略。第二，要避免产生噪音的方式：不仅仅是你希望自己的文章保持较高的信噪比，你也希望这些信息可以刺激其他人也保持同样的信噪比，或者干脆不发表文章。
为了展示这是如何发生的，考虑一下事情发生的上下文。非多产的线索的特征是什么？
发生的争论是在重复，仿佛发布者认为没有人听说过。
随着赌注的缩小，夸大和连累的升级。
大部分评论来自做过很少事情或没做过事情的人，而能帮助完成事情的人则保持沉默。
大多数想法的讨论都没有作出明确的提议。 （当然，任何有趣的想法都是从不清晰的远见开始；重要的问题是之后的方向。讨论是否将远见变得更具体，或者分裂为更小的远见，副远见和本体论的争论？）
不要因为某个线索开始不够多产而认为它是浪费时间。它可能是一个重要的主题，正因为他非常棘手所以难以做出进展。
将线索引向有用而不是蛮干是一项艺术，仅仅是告诉人们不要浪费时间，或者告诉他们在没有形成建设性的内容前不要说话并没有用。你或许可以在私下这样想一想，但是如果你大声的说出来就会成为一种冒犯。相反，你必须促成进一步进展的条件—给人们一条路，一条可以将结果导向期望的路，而无需发出指挥命令。这样的基调将会大为不同。例如，这样很不好：
这个讨论已经跑的漫无边际了。我们可以暂停这个主题，直到某人能够提交一个补丁实现这些建议吗？没有理由继续反复说同一件事情。代码比单词更有力，伙计们。
然而这样很好：
线索浮现出了多个提议，但都没有完成所有的细节，至少还不足以形成表决。然而现在我们也说不出新东西了；只是在反复重复以前说过的东西。此时，为了进一步的讨论，最好提供提议的完整规格或补丁。然后我们至少有明确的动作可以做（即对规格达成一致，或应用和测试补丁）。
第二种方法与第一种方法完全相反。第二种方法不会让你与他人发生联系，也不要指责他们将讨论带入了螺旋。无论你在之前是否参与到线索的讨论，都要说是“我们”，因为即使你一直在线索中保持沉默，线索的结果也有你的份。它描述了为什么线索到了乌有之地，这样做并没有轻蔑或判决的含义—它只是不带感情的对事实的描述。最重要的，它提供了一个行动的正面课程，这样人们就不会感觉到讨论被关闭了（对于他们可以被诱惑去造反的限制），而会感到获得了一个方法可以将对话带入更有建设性的水平。这是人们自然会期望遇到的标准。
你不会一直希望让线程进入更有建设性的水平—有时，你只是希望它赶快离开。文章的目的只是从中选择一个，放弃另一个。如果你能断定线索离题太远，而且没有能实际上去完成你所建议的步骤，那么你的文章会有效的终止线索，而且不需要这样做。当然，没有关闭线索的安全方法，即使有，你也不会希望去使用。但是询问参与者在作出可见的进展和停止讨论之间做出选择则是完美可防卫的，如果可以圆滑完成的话。然而，还是要小心永久的平息线索。一些纯理论的讨论可能会十分多产，取决于主题，而且如果过快的要求解决也会扼杀创造过程，也会让你看起来不够耐心。
不要期望线索会立刻停止。在你的文章之后，还是会有些文章，一方面因为邮件是排队传递的，另一方面是因为人们想说最后一句话。不必为此担心，你不用再说一遍。只需要让它逐渐消失或不消失，这取决于具体的情况。你不可能有完全的控制；另一方面，你可以期望在大量线索的统计上有显著的效果。
尽管讨论会在任何主题上缓慢前进，但是随着主题技术难度的降低，缓慢前进的可能性就越高。毕竟，技术难度越大，能够理解的参与者也就越少。这些参与者更有可能是最有经验的开发者，他们已经参加过无数次这样的讨论，知道如何才能与每个人达成共识。
因此，如果技术问题易于理解或容易得出自己的意见，或者是诸如组织、公开性和资金的软主题，就很难达成共识。人们可以永远参与到这种辩论中，因为这事没有门槛，没有决定（甚至在之后）正确或错误的明确方法，而且因为等待其他讨论者结束是一个成功的策略。
对于长期的主题，讨论的数量与主题的复杂度成反比的原理，被非正式的称为Bikeshed效用。这里是Poul-Henning Kamp为BSD开发者作出解释的著名文章：
这是一个很长的故事，或者说是一个老故事，但它实际上很短。C. Northcote Parkinson在20世纪60年代初编写了一本叫做“Parkinson定律”的书，包含了许多管理动态性的真知灼见。
[...]
这些例子中包括自行车棚，另一个更重要的组件是核电站，我猜这描述了本书的年龄。
Parkinson展示了如何进入董事会，并得到建造花费几百万，甚至几十亿美元核电站的许可，但如果你希望建造自行车棚，则会陷入无休止的讨论。
Parkinson解释了这是因为核电站太大、太贵和太复杂了，人们无法掌握，所以不会去尝试，转而会假设某人会在需要时检查所有的细节。Richard P. Feynmann在他的书中提供了一些关于洛斯阿拉莫斯（美国新墨西哥州中北部一个无法人地位的社区，位于圣菲市西北。1942年被选作核研究基地，生产了第一批原子弹。从1947年至1962年原子能委员会统治着这个城镇。）的有趣而且非常到位的例子。
另一方面是自行车棚。所人都可以在周末建一个车棚，而且还有时间看电视上的比赛。所以无论准备的多好，无论你的提议是多么的有道理，人们会抓住机会展示他在做自己的工作，他正在关注，他就在这里。
在丹麦，我称之为“配置你的指纹”。它关于自尊和声望，关于能够指向某事并说“这里！我那样做的。”这是政客的典型特征，但是现在很多人都会这样。想想湿水泥中的足迹。
（他的完整文章也十分值得阅读。请看Appendix C, 为什么我要关注车棚的颜色？，以及http://bikeshed.com。）
任何参加过团队决策的人都会知道Kamp所说的东西。然而，通常还是不可能说服每个人避免喷刷自行车棚。最好你能指出这是一个必然存在的现象，并在你发现它时，说服高级开发者—这些文章拥有最高权重的人—尽早丢下他们的刷子，或至少不要添加噪音。自行车棚喷涂的聚会永远不会完全消失，但是你可以通过在项目文化中传播这个现象的知识让这种事变得时间更短，频率更低。
一场圣战是一场争论，经常但不会一直是相对的小问题，一般不会通过辩论得到解决，但是有人会充满热情的继续辩论，期望他们一方会获胜。圣战并不与自行车棚完全一样。人们粉刷车棚通常是突然跳出来的意见（因为他们可以），但是他们不必强烈的感觉必须如此，并且以后会表达其他的意见，互相矛盾的意见，以展示他们理解问题的所有方面。而另一方面，在圣战中，理解对方则是示弱的表现。在圣战中，每个人认为有一个唯一正确的答案；他们只是不认可是什么。
圣战一旦开始，通常就不可能让每个人都满意。在正在进行的圣战中指出这点并没有好处。每个人都已经知道。不幸的是，但是对于通过连续的讨论能否解决争论这一问题，是圣战并不认可的一个常见特性。从外部看来，很明显没有一方可以改变另一方的意见。而从内部看，则认为另一方太过蠢笨，也没有想清楚，但是经过足够的恫吓则能回心转意。现在，我没有说在圣战中永远没有正确的一方。有时确实有—在我参加的圣战中，真理当然永远属于我这一边。但是没有关系，因为没有算法可以令人信服的描述某一方是正确的。
人们试图解决圣战的一个常见的，但是不能令人满意的方法是说“我们的讨论已经浪费了过多的时间和精力！我们能不能把它忘掉？”这样有两个问题。首先，时间和精力已经投入，不可能收回了—现在唯一的问题是还有更多的力量吗？如果某人感觉更多的讨论会结束这个问题，那么继续就还有意义（从他们的角度看）。
另一个要求这件事必须丢弃的问题是这通常等同于允许某一方打破现状，通过无为宣布胜利。在某些情况下，现状无论如何是不能接受的，每个人都认为需要作出决定，必须有所行动。为每个人丢弃这个主题通常比任何人放弃论点更坏。但是因为这种两难可以平等的应用到所有人，所以仍有可能永久结束辩论。
那么你应当如何处理圣战？
第一个回答是，做好准备避免其发生。看起来并不是完全没有希望：
你可以预期到一些标准的圣战：可能关于编程语言、许可证（见Chapter 9, 许可证，版权和专利的the section called “GPL和许可证兼容性”）、回复处理（见Chapter 3, 技术基础设施的the section called “伟大的Reply-to辩论”）和一些其他主题。每个项目可能都有自己的圣战，长期开发者会很快熟悉。停止圣战，或者减少其危害的技巧在大多数地方都是相同的。即使你肯定你属于正确的一方，可以试着寻找一些方法展示自己对对方的同感，并理解另一方的论点。通常问题是在圣战中的每一方都尽可能高的建筑自己的墙，而使其他见解看起来是完全的愚蠢，放弃或改变思想的行动在心理学上变得不可忍受：这样做不仅仅是承认错误，而是必然并且会一直错下去。将这种承认变得可口的方法是展示你的不确定性—精确的展示你理解他们的辩论，发现他们至少很敏感，即使最终并不是令人信服。作出为回应姿态留出空间的姿态，通常情况会得到改善。也许你不会得到期望的技术结果，但是你可以避免对于项目士气的非必要相关损害。
当圣战不可避免时，尽早决定你要关注多少，并乐意公开放弃。当你这样做，你可以说你正在退出，这场圣战毫无价值，而不要展示出挖苦，并且不要利用这个机会对对方的辩论做最后一次攻击。只有优雅的去做才能有效的放弃。
编程语言的圣战有些特殊，因为虽然其本身的高技术性，然而很多人感觉自己有资格参与其中，因此结果可能取决于项目编码编写较好的部分的语言。最好的解决方案是尽早选定语言，由初始的有影响的开发者引入，根据你最舒服的语言，而不是因为其优于其他语言而使用。不要将对话退化为经典的编程语言比较（通常是当某人因为某些原因提出Perl。）；那是死话题，你应该明确的拒绝涉及。
关于圣战的更多历史背景，可以看http://catb.org/~esr/jargon/html/H/holy-wars.html，Danny Cohen的论文普及了这个术语，http://www.ietf.org/rfc/ien/ien137.txt。
在所有的邮件列表讨论中，都有一些少数派不断用大量冗长的邮件血洗列表，给人存在大量异议的印象。有些像filibuster（一种议会程序，阻挠议案的通过），但是这种广泛异议的幻想更加强大，因为它分割了任意数量的不连续文章，大多数人无法跟踪何人在什么时间说了什么。他们会产生主题存在严重争议的直觉印象，并等着小题大做的平息。
中和这种效应的最好方法是明确指出并提供证据证明这种异议的数量与认可的数量相比是微不足道的。为了增大这种差距，你或许会希望私下调查大多数时候会保持沉默，但是你怀疑是认可大多数的人。不要说这些持异议者是故意夸大这种印象。他们一般不会是故意，即使故意，指出来也没有策略上的好处。你只需要指出双方实际数字的比较，人们就会认识到他们对于形势的直觉与现实不符。
这个建议并不是只能应用到具备明确支持和反对位置的问题。它可以应用到所有小题大做的问题上，但是如果大多数人认为讨论的问题不是一个问题时，则不是这么清楚。如果经过一段时间，你认为这个问题并不值得行动，并且看到它无法获得更多的吸引力（即使有了大量的邮件），你可以公开评论其没有吸引力。如果“吵闹的少数派”正在工作，你的文章就会像一缕清风。大多数人对于这个讨论的印象都会有一些阴郁：“好象是发生了一些大事，因为有很多文章，但是我看不出有什么进展。”通过解释讨论的形式使其显得比实际上更加吵闹，你给其新的面貌，人们可以重新修订自己对于发生问题的理解。