刺儿头

# 刺儿头 在电子论坛对付刺儿头并不比在现实中容易。这里“刺”不是“无礼”。无礼的人很讨厌，但不一定难对付。本书已经介绍了如何处理他们：在第一时间回复无礼行为，之后，选择忽略他们或者同其他人一样对待他们。如果他们继续无礼，他们会让自己更加不受欢迎，并在项目中毫无影响力，所以这是他们自己的问题。 真正的问题不是完全无礼的人，而是那些操弄或滥用项目进程，消耗他人时间和能量，而不会为项目带来任何利益的人。这些人经常会寻找项目规程中的楔点，而释放在其他地方无法获得的影响力。这比单纯的无礼更加狡猾，因为其导致的行为或损害都不是随意的观察者能够发现的。一个经典的案例是filibuster，某人会一直声称讨论的事情还没有准备好解决，并一直提供更多的解决方案，以及对旧方案的新视点，而实际上是他感到会达成共识或投票，而他可能无法保持领先。另一个例子是当一个辩论无法达成一致，但是团队尝试至少理清异议并为所有人制作一份以后可以参考的总结时。蓄意阻挠者知道总结会导向他不期望的结果，所以会通过反对合理的建议或引入意料之外的新条目来夸大问题的复杂性，试图延迟总结。 ### 处理刺儿头 为了中和这种行为，我们需要理解从事这种行为的心理。人们并不是有意识的这样做。没有人会在早晨起床并对自己说：“今天，我会处理规程表单，从而成为恼人的蓄意阻挠者。”相反，这种行为经常是出于希望在项目互动和决策中发表意见的半偏执的情绪。有些人感觉自己没有被重视，或者（更严重的情况）认为存在一个针对自己的阴谋集团—其他项目成员决定成立一个排他的俱乐部，而他不是其成员。然后作为辩护，在他的思想中，认为按照字面意思遵循项目的规则，并参与到项目规程的正式处理中，从而让所有其他的人*可以*重视他。在极端的例子中，某些人甚至会认为自己正在为拯救项目而孤军奋战。 不是所有的人在同一时间可以看到这种攻击，某些人可能会完全看不到，除非提供了强有力的证据。这意味着中和它需要大量的工作。说服自己它的发生并不足够；你也需要配置足够的证据说服他人，并使用考虑周到的方法分发这些证据。 考虑到有大量的工作，最好不要容忍太长时间。考虑到它的寄生性，但只是温和的疾病：感染时并不会对项目造成过大的损害，药物反而可能有严重的副作用。然而，如果损害变得无法容忍，就应该采取行动。从收集见到的模式的记录开始。确保包含对公共归档的引用—这是项目保留这些记录的原因，所以你也可以利用它们。一旦建立了好的案例，开始与其他参与者的私下对话。不要告诉他们你所观察的；相反，首先要询问他们所观察的。这恐怕是你最后一次收集他人对于麻烦制造者行为未过滤反馈的机会；一旦你开始对此事的公开讨论，意见就会分化，没人会记得过去对于此事的想法。 如果私下讨论表明至少有其他人也发现了这个问题，则是时候行动了。你应当*十分*小心，因为很容易给这些人机会让你显得对他们不够公平。无论你做什么，不要指控他们因为偏执狂恶意滥用项目的规程，或者任何你怀疑他们的事情。你的策略是必须保持合理性和对于项目整体利益考虑，以改良个人的行为或使之离开作为目标。取决于其他开发者，以及你与他们的关系，首先在私下里获取同盟者是一个优势。或者如果不是；则只能会暗中的破坏，如果人们认为你正在从事一项不当的政治诽谤活动。 要牢记，尽管是另外一个人具有破坏性，但如果你不能支持你的公开指控，那么*你*就会看起来是那个破坏者。请确保你拥有足够多的实例来描述你所说的，并在直接说出的情况下尽可能的保持礼貌。你可能无法说服有问题的人，但只要能说服所有其他人就足够了。 ### 案例学习 我只记得一次，在10年的自由软件工作中，事情变得太坏，以至于我们必须要求某人停止发布文章。更常见的情况是，他并不是无礼，只是希望更有益。他只是不知道何时发布何时不发布。我们的邮件列表对公众公开，但是他发布的太频繁，在许多不同的主题中提出问题，成为了社区的噪音问题。我们已经和蔼的告诉他在发表文章前对文章多做一点研究，但是没有效果。 最终有效的策略是如何根据中立、定量的数据构建强大案例的完美案例。我们的一个开发者研究了一些归档，然后将如下信息私下发送给了一些开发者。冒犯者（在列表中的姓显示为“J. Random”）在项目中的历史不多，没有贡献任何代码或文档。然而他是邮件列表中第3活跃的用户： ~~~ From: "Brian W. Fitzpatrick" <fitz@collab.net> To: [... recipient list omitted for anonymity ...] Subject: The Subversion Energy Sink Date: Wed, 12 Nov 2003 23:37:47 -0600 In the last 25 days, the top 6 posters to the svn [dev|users] list have been: 294 kfogel@collab.net 236 "C. Michael Pilato" <cmpilato@collab.net> 220 "J. Random" <jrandom@problematic-poster.com> 176 Branko Čibej <brane@xbc.nu> 130 Philip Martin <philip@codematters.co.uk> 126 Ben Collins-Sussman <sussman@collab.net> 我可以说这些人中的5位会在不久的将来将Subversion带到1.0。 我也必须说我们中的一位也在消耗另外5人的时间和精力，更不用说整个 邮件列表，因而（虽非故意）也延缓了Subversion的开发。我没有做线索分析 但是通过vgrep我的Subversion邮件，我发现此人的每个邮件都会被上面5人中 的2人回复过。 我觉得有必要做一次根本的干预，即使我们会吓跑前面提到的这个人，和蔼 和友好的方法被证明没有效果。 dev@subversion是辅助进行版本库控制系统开发的邮件列表，而不是一个团队 心理治疗会议。 -Fitz，尝试从堆积了3天的svn邮件中费力前行 ~~~ 尽管一开始还不明显，但J. Random的行为是滥用项目规程的典型案例。他不会像filibuster一个表决那样明显，但是他利用了邮件列表中成员自我评审的政策。我们依赖每个个体的判断。因此，我们没有规程资源可以处理某人是否没有或没有练习这种判断。没有可以让某人指出并说某个家伙违反的规则，但每个人知道他过于频繁的文章已经成为一个严重问题。 Fitz的策略是专横的事后回想。他收集了定量的证据，然后谨慎的将其首先发送给那些在任何过激行动中都会对支持起关键作用的人。他们认可有必要采取行动，最后我们在电话上联系了J. Random，直接描述了这个问题，告知他停止发表文章。他从未真的理解原因；如果能够理解，他可能会尝试首先进行合适的判断练习。但是他认可停止发布文章，邮件列表又变得可用了。这个策略可以发挥作用的部分原因或许是我们可以限制其发表的隐含威胁，我们可以通过软件的审核功能来防止垃圾邮件（看[Chapter 3, *技术基础设施*](# "Chapter 3. 技术基础设施")的[the section called “垃圾邮件防护”](# "垃圾邮件防护")）。但是我们能够让该选择作为备用的原因是Fitz已经从关键人物那里收集了必要的支持。