# 刺兒頭 在電子論壇對付刺兒頭并不比在現實中容易。這里“刺”不是“無禮”。無禮的人很討厭，但不一定難對付。本書已經介紹了如何處理他們：在第一時間回復無禮行為，之后，選擇忽略他們或者同其他人一樣對待他們。如果他們繼續無禮，他們會讓自己更加不受歡迎，并在項目中毫無影響力，所以這是他們自己的問題。 真正的問題不是完全無禮的人，而是那些操弄或濫用項目進程，消耗他人時間和能量，而不會為項目帶來任何利益的人。這些人經常會尋找項目規程中的楔點，而釋放在其他地方無法獲得的影響力。這比單純的無禮更加狡猾，因為其導致的行為或損害都不是隨意的觀察者能夠發現的。一個經典的案例是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已經從關鍵人物那里收集了必要的支持。