# 從志愿者中獲取最多 志愿者為什么要為自由軟件項目工作？[[24](#)] 當被詢問時，許多人聲稱自己只是因為希望制作好軟件，或希望自己修復所需要的bug。但是這些原因并不是完整的故事。畢竟，你能想象如果沒有人欣賞他的工作或傾聽他的討論，這個志愿者還會呆在這個項目嗎？當然不會。很明顯，人們在自由軟件上花費時間的原因不僅僅是單純的對生產良好代碼的渴望。理解志愿者的真實動機將會幫助你能夠合理的安排，以確保吸引和保持他們。對生產優秀軟件的渴望、在復雜問題上獲取的挑戰和學習價值也許都是動機。但是人們有與其他人一起工作的內在期望，并在合作活動中提供和獲取尊重。從事合作活動的團隊必須進化出行為的標準，能夠通過幫助團隊的活動獲取并保持那種地位。 這些標準并不總能自己出現。例如，在一些項目中—資深的開源開發者可以從頂級人員中去除幾個人—人們明確的感覺到是通過頻繁并詳細的發布取得的這種地位。他們并不是偶然得到這個結論；這是因為他們曾經因進行長時間的，復雜的辯論中而得到尊重的回報，即使對項目沒有實際的幫助。下面是一些創建氛圍的技術，可以讓獲取地位的活動與建設性活動一致起來。 ### 委派 委派并不僅僅是將工作分散的方法；它也是政治和社會工具。考慮你要求某人做什么事情的所有效應。最明顯的效應是如果他接受，就是他完成任務不是你。但是另一個效應則是他意識到你信任他能夠處理這個任務。此外，如果你是在公共論壇發起這樣的請求，那么他也知道團隊中的其他人也表明了對他的信任。他也能感受到需要接受一些壓力，這意味著你詢問時要使用一種允許他拒絕的方式，如果他確實不想做這個工作的話。如果這個任務需要在項目中協調，你這樣做可以有效的提議他更深入的參與進來，形成其他方式無法形成的契約，而且也有可能成為項目某個子領域權威的起源。增加的參與或許令人畏懼，也或者會導致他以其他方式參與進來，例如對于整體承諾的更多感覺。 因為所有這些效應，所以即使你認為你可以完成的更好更快，讓其他人來完成也很有意義。當然，也有一個嚴謹的經濟學效率作為論據：或許你自己完成的機會成本太高—在同一時間里你可以完成許多更重要的事情。但即使機會成本的論據并不適應，你*還是*會希望其他人完成這個任務，因為從長期來看你希望人們更深入的參與到項目當中，即使一開始需要花費更多的時間關注他們。相反的技術也適應：如果你偶然志愿完成其他人不喜歡或沒時間完成的工作，你會得到他的友好關系和尊敬。委派和代理并不僅僅是要完成單個任務；他們也是將人們引入到項目核心的方法。 ### 明確區分調查和指派 有時可以很明確的期待某人會接受特定的任務。例如，如果某人編寫的代碼帶來了bug，或者提交的代碼明顯未能符合項目的指導方針，那么直接指出問題，那么之后你可以認為他會小心避免此類問題。但是在一些情況下，沒有明確的方法可以確保你獲得期望的行動。這個人可以聽你的，也可以不聽。因為沒有人喜歡被熟視無睹，你需要敏感的察覺到這兩種情形的區別，并以此為依據調整你的請求。 你讓某人做某事，如果你采用的方式讓人感覺這是他理所當然的責任，而實際上他并不是這么想的時，幾乎一定會立刻讓他們感到非常的厭惡。例如，分配的問題可能會帶來很多討厭的事。項目的參與者通常知道誰是某個領域的專家，所以當出現了bug報告，通常會有大家都知道的一兩個人可以立刻快速的修正它。然而，如果你沒有得到先前的許可就將問題分配給她，她會感覺自己處于一個不舒服的地位。她會感受到這種被期望的壓力，而且感覺她是由于其專業技能而被懲罰了。畢竟，獲取技能的方法就是通過修正bug，所以某人會接受這個問題！（請注意，在問題跟蹤系統中根據bug報告的信息自動分配的問題通常并不太冒犯，因為每個人知道分配是自動的過程，并不代表人們的預期。） 雖然應該盡可能將負擔均勻的分配，但有時你需要鼓勵能夠以最快速度修正bug的 人。考慮到你可能無法承受為每個這種分配進行這種交流的負擔（“你愿意看一下這個bug嗎？” “可以。” “好的，一會兒吧這個問題分配給你。” “好的。”），你應當以詢問的形式進行分配，不要傳遞出任何壓力。事實上所有的問題跟蹤系統都允許為任務分配的問題作出評論。在那個評論中，你可以這樣說： > 把這個分配給你，jrandom，因為你可能是最熟悉這些代碼的。如果沒時間，盡管踢回來。（如果你想在以后接受這中請求，請讓我們知道。） *請求*完成工作與某人*接受*工作有明顯的區別。在這里觀眾不僅僅是被分配工作的，而是所有人：整個團隊可以看到被安排工作的人的專業技能得到了公開的確認，但是這些信息也明確的表明他可以自由的接受或者拒絕這種責任。 ### 指派后要繼續跟蹤 當你要求某人做一些事情時，請牢記所做的，并無論如何要繼續跟蹤他。大多數請求是在公共論壇中做出的，形式大體上類似“你能處理一下X嗎？我們只是要獲知；如果你不行，那么沒問題，我們只需要知道。 ”不一定會得到回應。如果你得到的回應是負面的，則環路可以關閉—你需要嘗試其他的策略來處理X。如果有正面的回應，那就需要繼續關注這個問題的進展，并為可見和不可見的進展作出評論（當知道其他人會欣賞他的作品時，每個人都會做的更好）。如果幾天內沒有回應，可以再次詢問，或者發表文章說明你沒有得到回應，希望找其他人做這件事。或者直接自己完成，但也要說明最初的詢問未能獲得回應。 公開提示缺乏回應的目的并*不是*要羞辱任何人，你的評論一定不要造成這種效果。目的僅僅是說明你還在跟蹤自己征求的問題，而且你已經注意到了一些反應。這樣做可以增大人們在下一次說同意的機會，因為他們會知道（即使只是無意的）你會注意到他們所做的任何工作，包括許多不太起眼的，人們會忽略的事件。 ### 通知感興趣的人 另一件可以讓人們高興的事情就是通知他們所感興趣的事情—通常情況下，你注意到并記住某人的個性方面越多，他會越覺得舒適，他也就越會希望參與你的團隊一起工作。 例如，在Subversion項目有一個非常有明顯區別的劃分，期望達到決定性的1.0發布的人，和那些主要希望添加新特性，并完成感興趣的問題，但對1.0并不太關心的人。兩者的地位相當；他們只是不同類型的開發者，都在項目中完成了大量工作。但是很快認識到我們絕*不能*假設所有的人都是由1.0發布的喜悅所驅動的。電子媒介可能很有迷惑性：在你感覺到共同目標的氛圍中，實際上只是你與談過話的人有共同的目標，而其他人則有完全不同的優先級。 你對人們對于項目的期望了解越多，你就越能有效發出請求。即使僅僅是描述一下他們所期望目標的理解，甚至不必發出任何相關的請求，也非常有用，這樣可以確保所有人不僅僅是無差別群眾中的粒子。 ### 贊揚和批評 贊揚和批評并不矛盾；在大多數情況下，是類似的。都是關注的形式，越是明確就越有效。二者必須在牢記實在目標的情況下實施。兩者都有可能因為夸大而削弱：贊揚過多或太頻繁會使贊揚貶值；對批評也是同樣，盡管在實踐中，批評通常會有反作用，因而更加不容易貶值。 一個重要的技術文化特性是將詳細的，不帶偏見的批評當作一種贊揚（正如在[Chapter?6, *交流*](# "Chapter?6.?交流")的[the section called “識別無禮”](# "識別無禮")中所討論的），因為這隱含了接收者的工作值得花時間去分析。然而，兩種條件—*詳細的*和*不帶偏見的*—必須同時滿足。例如，如果某人對代碼做了些馬虎的修改，如果只是說“很馬虎”是毫無用處（而且通常是有害的）的。馬虎最終是*人*的一種特性，而不是作品的，應該將反應集中到作品上。更有效的方法是描述變更中所有錯誤的地方，巧妙而無惡意。如果這是某人連續第3，或者第4次作出疏忽的修改，則可以再說一次這些事—不必發怒—批評的最后，要清楚的說明同樣的模式早已經被注意到了。 如果某人對于批評不做任何改進，解決辦法不應該是更多或更強的批評。對于團隊來說，解決方法是將這個人從不能勝任的位置刪除，并盡可能使用一種不會造成情緒傷害的方法；見[the section called “轉化”](# "轉化")本章后面的例子。但實際上，這種情況通常很少發生。大多數人可以很好的回應批評，當然批評必須要特定，詳細并有明確的（即使沒有說出來）改進預期。 贊揚不會傷害任何人的感情，但并不意味著使用時可以不像批評那樣小心。贊揚是一種工具：在使用之前，要問自己*為什么*你希望使用它。作為一條戒律，不應該因為人們經常做的事情，或正常的和參與到團隊中應當要做的行動贊揚他。如果你這樣做，估計就停不下來了：你因為普通的事情而贊揚*每個人*？畢竟，如果你漏掉了某人，他們會問為什么。如果能珍惜你的贊揚和感激會更好，要針對不尋常或意料之外的努力，以鼓勵此類努力為目的。當某個參與者永久的進入了更高生產力的狀態，要根據此人調整贊揚的閥值。對普通的行為進行反復的贊揚會變得毫無意義。相反，這個人也應該感覺到自己較高的生產力水平已經是正常和自然的，只有超出這個范圍的才會被特別關注。 當然，這并不是說不應該感謝某人的貢獻。但是請牢記，如果項目設置正確，這個人做的任何事情都會看到，所以這個團隊會知道（這個人也會知道團隊中的其他人所知道的）所有她所做的。除了直接的贊揚，我們也有其他的方法感謝某人的工作。你也可以采用曲折戰術，在討論相關主題時，她已經給定領域做了許多工作，成為了領域專家；你可以公開的向她咨詢代碼的問題；或者更有效的，你可以大張旗鼓的進一步利用她的工作，這樣她就會為別人依賴于她的工作結果而感到舒服。通常不必在這些問題上精打細算。那些有規律的為項目作出貢獻的人知道自己會自然的得到有影響的地位。通常沒有必要為此采取明確的步驟，除非你感覺到無論出于什么原因，貢獻者都無法得到正確的評價時。 ### 防止割據 請留意那些試圖在項目中獨占某一領域，或希望完成某一領域所有工作的參與者。此類行為已開始看起來很健康。畢竟，在表面上似乎是某人在肩負更多的責任，并展示在特定領域增長的活動。但從長期來看，則并沒有建設性。當人們感覺到“禁止入內”的標志時，他們就會離開。這種結果會減少這個領域的檢查，會使之更加脆弱，因為孤單的開發者成為失敗的單獨一點。更嚴重的，它會削弱項目的合作，平等精神。理論上應該歡迎任何開發者在任何時間幫助完成任何任務。當然，在實踐中會有些不同：人們在不同領域的影響總有差別，非專家通常與項目特定領域的專家不同。但關鍵是這都是自愿的：非正式的權威是根據競爭性和證明的判斷能力賦予的，而不可以主動的*獲取到*。即使某人期望的權威是能夠勝任的，仍然需要她非正式的保持權威，通過團隊的共識和那種永遠不會將其他人排除在該領域之外的權威。 當然，因為技術原因反對或編輯某人的工作則是完全另外一回事。決策因素是工作的內容，而不應該是誰恰好是守門人。也許也是同一個人完成恰好完成了最多的工作，但只要他沒有阻止其他人完成這個工作，就沒有問題。 為了對抗地方主義的萌芽，許多項目采用禁止在源代碼文件中包含作者名或維護者簽名的方法。我完全認可這種實踐：我們在Subversion項目中也遵循這個方法，這也算是Apache基金會的一種正式政策。ASF成員Sander Striker是這樣做的： > *在Apache軟件基金會中我們不鼓勵在源代碼中使用作者標簽。除了法律分歧以外，還有多方面的原因。協作開發是以一個團隊一起工作，將整個項目看作一個團隊。給予信譽非常好，必須有人這么做，但是必須使用不會允許錯誤歸因的方式，即使是通過暗示的方式。何時添加或刪除作者標簽沒有明確的標準。在你修改注釋后添加你的名字？或者是添加了一行的修正？在你重構了代碼，改變了95%時就可以刪除其他作者的標簽？當人們去接觸每一個文件，修改足夠多的內容以達到名字標簽的限額，這樣他們的名字就會出現在每個地方時，你會怎么做？* > *提供信譽可以有更好的辦法，我們推薦這些。從技術觀點上講，作者標簽并不是必需的；如果你希望知道哪個人寫了某段代碼，版本控制工具可以提供。作者標簽也經常失去時效性。你希望被私下咨詢5年前編寫，而且已經希望遺忘的代碼？* 軟件項目的源代碼文件時身份的核心。必須要反映整個開發社區為此負責，而不僅僅是簡單的各自的封地。 人們有時會為源代碼中作者或維護者標簽的風格而爭論，他們認為這些東西是所做工作的可見信譽。這種論點有兩個問題。首先，不可避免的要面對多少工作量才可以進入這個列表的尷尬問題。其次，這樣會將信譽的問題與權威合并了：過去曾經完成了工作并不意味著對于曾經工作區域的所有權，但是如果單個人的名字出現在源文件的頂部，想避免這種暗示就變得幾乎不可能。在任何情況下，信譽信息都可以從版本控制日志和其他諸如郵件列表歸檔等外帶機制中獲取，所以在源代碼文件中禁止其出現不會損失任何信息。[[25](#)] 如果你的項目禁止在源代碼文件中包含姓名，請務必不要過分執著。例如，許多項目會有一個保存小工具和輔助腳本的`contrib/`區域，通常由與本項目不相關的人編寫。這些文件可以包含作者姓名，因為他們完全不是由項目維護的。另一方面，如果貢獻的工具被項目的其他人修改了，最終你希望將其從孤立的位置移出，如果原始作者許可，就可以刪除作者名稱，這樣代碼就像其他社區維護的資源一樣了。如果作者對此有些敏感，折衷的方案也是可以接受的，例如： ~~~ # indexclean.py: 從Scanley索引刪除舊數據。 # # 原始作者: K. Maru <kobayashi@yetanotheremailservice.com> # 現在維護者: Scanley項目組<http://www.scanley.org/> # 和K. Maru。 # # ... ~~~ 但是最好避免此類折衷，如果可能，大多數作者會被說服，因為他們都會樂于自己的貢獻更緊密的成為項目的一部分。 重要的是請牢記項目的核心和外圍是一個連續體。項目的主要源代碼文件顯然是核心部分，會被認為應當是由社區維護的。在另一方面，伙伴工具或一些文檔則可能是單獨某個人的作品，始終獨自維護，即使這些作品是與項目關聯，甚至是與項目一起分發的。沒有必要應用一個適用于所有文件的規則，只要堅持社區維護的資源不允許成為個人領土的原理就可以了。 ### 自動化率 努力不讓人做機器可以做的事情。作為一種經驗法則，將一項工作自動化花費的工作量即使十倍于手工執行也是值得的。對于非常頻繁或復雜的任務，這個比率可以輕松的達到20倍或更高。 將自己想象為“項目管理員”，而不僅僅是開發者，可能是一個有效的態度。有時，單個開發者會過于沉溺于較底層次的工作，而無法看到全局圖并意識到每個人都在手工執行自動化任務上浪費了大量精力。即使那些意識到的人也可能不會花時間解決問題：因為每個個體都不會感覺此類任務是一個巨大的負擔，沒有人已經厭煩到要為此做些什么。使自動化如此引人注目的是每個很小的負擔需要乘上每個開發者執行的次數，然后還要乘上開發者的*數量*。 這里，我廣泛的使用的術語“自動化”，并不僅僅是重復每次只需要修改1到2個變量的動作，而且包括任何輔助人們的技術基礎架構。最低標準的自動化需要按照[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")中描述的方式運行一個現在的項目，但是每個項目也都有自己的特殊問題。例如，一組編寫文檔的人會希望有一個網站能夠在任何時間都顯示最新版本的文檔。因為文檔通常由如XML的標記語言編寫，會有一個編譯步驟，通常非常復雜，包括創建可顯示或可下載的文檔。組織這種會在每次提交時進行此類編譯的網站可能會有點復雜和花費時間—但是這樣很值得，即使這要花費你一天或更多的時間。擁有最新網頁的整體收益是巨大的，即使*沒有*的代價僅僅是每個開發者需要每次多一些很小的煩惱。 進行這種步驟不僅僅可以消除時間的浪費，也可以確保消除在執行手工操作時步驟出錯（不可避免的會發生）時的痛苦和沮喪。多步的，確定的操作恰好是發明計算機的目的；將人們拯救出來可以做更有意義的事情。 ### 自動測試 自動測試對任何軟件項目都有用，特別是開源軟件項目，因為自動測試（特別是回歸測試）可以讓開發者舒服的修改自己不熟悉的代碼，因而鼓勵了探索性的開發。因為手工檢測損壞是這樣困難—需要從本質上猜測可能損壞的事情，而且必須嘗試多種實驗證明其沒有損壞—通過自動化方法檢測這種損壞為項目節省了*大量*時間。它也可以讓人們可以更放松的大幅度重構代碼，從而對軟件的長期可維護性貢獻良多。 **回歸測試** *回歸測試*指的是判斷已修正bug是否重新出現的測試。回歸測試的目的是減少代碼變更以不可預料的方式破壞軟件的機會。隨著軟件項目的增大和復雜，這種不可預料的副作用會急劇增長。好的設計可以減少隨著變更增長帶來的這種比率，但是不能完全消除這種問題。 結果就是許多項目都有了一個*測試套*，一個單獨的可以按照過去模仿bug發生的方式進行調用的程序。如果測試套成功的使某個bug出現，這被稱作*回歸*，意味著某人的變更意外的將以前修正的bug又修正回來了。 請看[http://en.wikipedia.org/wiki/Regression_testing](http://en.wikipedia.org/wiki/Regression_testing)。 回歸測試并不是萬能藥。首先，它非常適于批量樣式界面的程序。對于主要使用圖形用戶界面操作的軟件很難程序化驅動。回歸測試的另一個問題是測試套框架本身可能非常復雜，自己有一定的學習曲線和維護負擔。減少這種復雜性是你可以做的一件非常有用的事，即使這需要花費相當多的時間。將新測試添加到測試套越簡單，就會有越多的開發者這樣做，發布中漏網的bug也就會越少。在使測試更簡單上的努力將會在項目的生命周期中得到成倍的回報。 許多項目有一個*“不要破壞構建！”*的規則，意思是：不要提交會使軟件不能編譯或運行的變更。成為破壞構建的人通常會導致溫和的窘迫和取笑。擁有回歸測試套的項目通常有一個推論的規則：不要提交會導致測試失敗的任何變更。如果整個測試套會自動每夜運行，隨著結果發送到開發列表或專門的測試套列表，這類失敗可以輕松定位；這是自動化價值所在的另一個實例。 大多數志愿開發者會愿意用額外的時間編寫回歸測試，只要測試系統是可理解的并易于使用。變更搭配測試可以理解為一種責任，也是協作的一種簡單的機會：通常要由兩個開發者分擔bug修正的工作，其中一個編寫修正本身，另外一個編寫測試。后一個開發者通常要以更多的工作結束任務，因為編寫測試并沒有實際的修正那樣讓人愉悅，測試套不應當使測試體驗超出本來應有的痛苦。 一些項目走的更遠，*每個*bug修正或新特性都要伴隨新的測試。這是否是個好主意取決于許多因素：軟件的特性，開發團隊的組成和編寫新測試的難度。CVS（[http://www.cvshome.org/](http://www.cvshome.org/)）團隊一直有這樣一個規則。在理論上這是一個好政策，因為CVS是版本控制軟件，所以非常希望規避處理或誤處理用戶數據可能性的風險。問題是在實踐中CVS的回歸測試套是一個單獨的巨大shell腳本（好笑的是叫做`sanity.sh`），難于閱讀，也難于修改或擴展。增加新測試的難度，以及對于新增補丁必須包含測試的要求，決定了CVS有效的阻礙了補丁。當我在CVS上工作時，我見過有人著手，甚至完成了一個CVS自己代碼的補丁，但是當被告知需要在`sanity.sh`增加新測試時則放棄了。 編寫新的回歸測試比修正原來的bug花費更多的時間非常正常。但是CVS將這種現象發揮到了極致：一個人需要花費數小時才能正確的設計自己的測試，但仍然得到錯誤的結果，因為修改這樣一個35000行的Bourne shell腳本有太多不可預測的復雜情況。即使是長期的CVS開發者也會為增加新測試而感到郁悶。 這種情況源于我們對于自動化比率考慮的失敗。轉換到一個真正的測試框架—無論是自定義的還是成品的—都會成為一種主要的動力。[[26](#)]隨著時間的推移，這種忽視給項目帶來更多的代價。有多少bug修正和新特性*未能*進入現在的CVS，僅僅因為這尷尬的測試套的阻礙？我們不知道精確的數量，但是一定遠大于開發者為了開發新測試系統（或集成一個成品的系統）而會放棄的bug修正或新特性數量。這個任務只會耗費有限的時間，但如果無動于衷，則使用現有測試套的懲罰將會永遠持續下去。 重點不在于強制編寫測試是錯誤的，也不是說編寫Bourne shell腳本的測試系統必然是不好的。它可能工作的很好，這取決于你的設計和測試的需要。重點僅僅是說當測試系統成為開發的明顯障礙時，必須要有行動。同樣的道理適用于所有成為障礙或瓶頸的常規過程。 ### 將每個用戶當作潛在的志愿者 與用戶的每次交流都是發展新志愿者的好機會。當一個用戶花時間在項目郵件列表上發表文章或報告bug時，他已經認為自己比大多數用戶（那些項目永遠聽不到回音的人）有更大參與的可能。緊跟這種潛力：如果他描述了一個bug，感謝他的報告，并詢問他是否有興趣自己修正它。如果他說FAQ中漏掉了一項重要問題，或者程序的文檔有些不足，請坦率的承認問題（假定確實存在），并詢問他是否有興趣自己編寫遺失的材料。很自然，大多數時候這個用戶不會同意。但是多問一句也不累，而且只要你每次都這么問，也會提醒論壇中的其他聽眾參與到項目當中是每個人都可以做的。 不要將你的目標限制在新開發者和文檔編寫者上。例如從長期來看，即使訓練人們編寫優秀的bug報告也是值得的，如果你沒有在每個人身上花費*太*多時間，而且如果在將來繼續提交更多的bug—如果第一次報告時能獲得建設性的互動，以后更有可能這么做。建設性的互動不必是對于bug的修正，盡管那樣是理想的；它可以僅僅是一種要求更多信息的懇請，或僅僅是那種行為*是*bug的確認。人們希望被傾聽。其次，他們希望自己的bug被修正。你可能無法一直及時的給予后者，但你（或者說整個團隊）可以給他們前者。 一個推論就是開發者不能向出于好意提出含糊bug報告的人們表現出憤怒。這是我個人很氣惱的事情。我在許多不同的開源郵件列表中看到許多開發者一直這樣做，危害是顯而易見的。一些倒霉的新手會發布無用的報告： > 嗨，我沒法運行Scanley。每當我啟動它，就會報錯。有人遇到過這個問題嗎？ 一些開發者—可能已經遇到此類報告幾千次了，但絲毫不考慮這個新手從未遇到過—會這樣回復： > 這么點信息我們能怎么做？天吶。請給點細節，例如Scanley的版本、你的操作系統和錯誤信息。 開發者無法從用戶的角度看待事物，也未能考慮到這種反應對于觀看這種交互的*其他*人的效果。很自然，對于沒有編程經驗的用戶，之前沒有報告bug的經驗，當然不知道如何編寫bug報告。對于這種人該怎樣正確處理呢？教育他們！要使用會促使他們回來獲取更多信息的方式： > 很遺憾你遇到了困難。我們需要更多信息才能找出發生的問題。請告訴我們Scanley的版本，您的操作系統和錯誤的精確文本。最好能提供一份你所運行命令的腳本，以及對應的輸出。更多信息請看http://www.scanley.org/how_to_report_a_bug.html。 這種從用戶那里榨取信息的響應方法遠談不上有效率，因為它是從用戶的角度編寫的。首先，它展示了同情：*你遇到了問題；我們也感到痛*。（即使在bug報告回應中也不是必須的；這取決于問題的嚴重程度以及感覺到的用戶的傷心程度。）其次，沒有對她不知如何報告bug表示輕視，而是告訴她如何，以及怎樣的詳細程度才會實際有效—例如，許多用戶并不理解“請給些細節”的意思是“展示錯誤的精確文本”，不要遺漏或刪節。當你第一次與這樣一個用戶工作時，你需要說明這些。最后，應該提供到更加詳細和完整的報告bug指導的鏈接。如果你成功的讓用戶感覺在為她考慮，她通常會花時間閱讀該文檔并按照你所說的去做。當然，這通常意味著你需要預先就準備好文檔。必須說清楚哪種類型的信息是開發團隊在每個bug報告中希望看到的。理想情況下，可能需要通過回應多個這樣的用戶，逐漸的查漏補缺，使之更好地為項目服務。 Subversion項目的bug報告指導可以說是這類形式的標準案例（見[Appendix?D, *報告bug的樣例指導*](# "Appendix?D.?報告bug的樣例指導")）。請注意他們是如何以請求提供一個bug的補丁或修正結束的。這不是因為這種請求將會導致更高的補丁。報告率—大多數能夠修正bug的用戶都知道如果能提供補丁會受到歡迎，無需告知他們。請求的真實目的是為了向所有讀者，特別是剛來到項目，或者剛來到自由軟件的人強調，這個項目是通過志愿者的貢獻運營的。這是許多新用戶通常不熟悉的一個關鍵點。一旦他們意識到這一點，他們就更有可能在發生時幫助完成修正，即使不能提供代碼，也會提供更完整的重現步驟，甚至是為其他人發布的內容測試修正。目標是讓每個用戶認識到他們和為項目工作的人沒有*天生*的區別—問題只是他們能投入多少時間和力量，而不在于是誰。 對于憤怒回應的告誡不能適用于粗暴的用戶。偶爾會有一些人會發送毫無信息量的bug報告或投訴，表現對項目某些失誤的蔑視。通常此類人會在輕蔑與諂媚之間轉換，例如Subversion郵件列表的這個人： > 為什么幾乎6天了還沒有Windows平臺的二進制程序？！？每次都是同樣的故事，確實讓人灰心。為什么這類工作就不能自動化，可以立刻出現。？？當你發布“RC”構建時，我想你們的意思的是讓用戶測試構建，但是你們沒為此事做任何事。如果你們沒提供測試方法，又何必搞一個浸潤期？？ 對于這種激動文章的最初回應是令人吃驚的克制：人們指出該項目有自己的發布政策，不會提供官方的二進制文件，并告訴他如果要改變惱人的程度，他應該志愿自己編譯代碼，如果真的對他很重要的話。相信與否，這段話屬于他的下一次發布： > 首先，我要說我認為Subversion很彪悍，很感謝每個參與者的努力。 [...] ...然后他*再次*繼續為項目沒有提供二進制，現在仍然沒有志愿者做這件事而斥責項目。之后，大約50人跳了出來，我必須說我確實注意到這一點了。在[Chapter?2, *起步*](# "Chapter?2.?起步")的[the section called “防無禮于未然”](# "防無禮于未然")提出的，針對粗魯行為的“零容忍”政策，已經潛移默化的應用到每個人的交互中。但是，當人們認清他一開始就要當一個噴子時，沒人能給他好臉色。 很幸運，這些情形非常罕見，很少需要被項目特別關注，并投入力量去保持用戶建設性的和有禮貌的交互。 [[24](#)] 這個問題已經被詳細研究，Karim Lakhani和Robert G. Wolf的一篇論文有非常有趣的結果，題目為*Why Hackers Do What They Do: UnderstandingMotivation and Effort in Free/Open Source SoftwareProjects*。見[http://freesoftware.mit.edu/papers/lakhaniwolf.pdf](http://freesoftware.mit.edu/papers/lakhaniwolf.pdf)。 [[25](#)] 但是郵件列表中鏈接為[http://groups.google.com/group/sage-devel/browse_thread/thread/e207ce2206f0beee](http://groups.google.com/group/sage-devel/browse_thread/thread/e207ce2206f0beee)的*“having authors names in .py files”*的這篇文章是一個很好的抗辯，作者是William Stein。我認為關鍵在于許多作者來自一種將信譽直接取自源代碼視為標準并高度評價的文化。在那種環境中，可能有必要將作者的名字置于源代碼中，并精確的描述每個作者的貢獻，因而大多數潛在的貢獻者會希望有這種樣式的承認。 [[26](#)] 請注意，沒有必要將所有已存在的測試轉化到新框架；二者可以和平共處，只需要轉化需要改變的測試。