# 處理成長 開源世界中成功的價值很重。隨著你的軟件的流行，搜尋信息的人也會急劇增加，而能夠提供信息的人則增長的慢很多。此外，即使比率能夠保持平衡，在大多數開源項目中處理交流也依然存在基礎擴展問題。以郵件列表為例。大多數項目有一個一般用戶問題的郵件列表—有時，列表的名稱是“users”、“discuss”、“help”或其他。無論名稱是什么，列表的目的相同：為人們獲取問題的答案提供一個場所，同時其他人可以觀看并通過觀察這種交換（假設的）獲取知識。 這種郵件列表可以在數千用戶和每天幾百文章的情況下工作良好。但之后不久，這個系統就會出現問題，因為每個訂閱者看到的文章會超過單個訂閱者每天可以處理的數量，這個列表成為了其成員的負擔。想象一下，如果微軟有一個針對Windows XP的郵件列表。Windows XP有數億的用戶，如果僅有千分之一的用戶在24小時內有問題，那么這個假設的列表每天也會有數十萬的文章！不可能有這種列表，因為不可能有人會一直訂閱它。問題不僅僅限于郵件列表；同樣的邏輯也可以應用到IRC頻道，在線討論論壇，以及所有從單個人獲取問題的團隊。其暗示并不吉利：大規模并行支持的普通開源模型不能擴展到支配全世界的級別。 當論壇達到臨界點時并不會發生爆炸。只有一個靜悄悄的負面反饋效果：人們會取消列表的訂閱，或者離開IRC頻道，或者不再去咨詢問題，因為他們無法去聽所有的噪音。因為有越來越多的人作出了理性的選擇，論壇的活動會看起來一直處于可管理的級別。但是，它精確的處于可管理級別是因為理性的（或僅僅是有經驗的）人會去尋找其他地方獲取信息—而缺乏經驗的人會留下來繼續發表文章。換句話說，隨著項目的成長，如果仍使用未擴展的交流模型，那就會產生詢問和回答的平均質量逐漸下降的副作用，感覺就好象新用戶比原來更呆了，但實際上并不是如此。只是高人口論壇的收益/花費比變得更低，自然那些有經驗的人會開始在其他地方尋找答案。根據項目的成長調整交流機制包含兩個相關的策略： 1. 識別出論壇特定部分，甚至整個論壇正在經歷有限制的增長，將這部分分割為新的更專業的論壇（也就是說不要讓壞的拖累好的）。 1. 確保有許多自動的信息來源，并組織有序、更新及時和易于查找。 策略（1）通常并不難。大多數項目有一個主要論壇開始：一個一般的討論郵件列表，會包含所有的特性構想、設計問題和編碼問題。項目的參與者都會在這個列表上。經過一段時間，整個列表就會很清晰的進化為基于不同主題的子列表。例如，一些線索很明顯是關于開發和設計；而另外一些是諸如“如何完成X？”的用戶問題；或許還有第三類關于如何處理bug報告和增強請求的主題；等等。對于每一個個體，或許會參與到許多不同的線索類型，但是這些類型之間沒有過多的重疊。他們可以劃分到不同的列表，而不會造成嚴重的割據問題，因為這些主題極少會跨越主題的邊界。 實際上這種分割是兩步驟的過程。你創建新的列表（或者IRC頻道，或任何其他的東西），然后你要花必要的時間有禮貌的嘮叨和提醒人們*使用*新的更合適的論壇。后一個步驟會持續幾周，但是最終人們會明白。你只需對所有發送到錯誤目標的人解釋這個問題，然后因為大家都看到得到，人們就會被鼓勵例行公事一樣去幫助解決。當然，提供一個所有列表的指南網頁也非常有用；你的回復可以直接引用網頁，然后作為獎勵，接收者會在發表文章前通過指南學習到一些東西。 策略（2）是一個持續的過程，會伴隨項目的一生，需要許多參與者。當然，它部分依賴于是否擁有及時的文檔（[Chapter?2, *起步*](# "Chapter?2.?起步")的[the section called “文檔”](# "文檔")），并能夠指引人們去觀看。但不僅僅如此；這個小節的后面會詳細討論這個策略。 ### 歸檔的顯著使用 通常來說，開源項目中的所有交流（除了一些IRC的對話）都應該歸檔。歸檔應該公開且可搜索，并要具備引用的穩定性：也就是一旦信息記錄到了特定的地址，就可以永遠使用這個地址。 盡可能多的使用那些歸檔，越顯著越好。即使你知道某個問題的答案就在你的腦中，但如果你知道歸檔中有一個包含此答案的引用，那么請找到并展示出來。每次你使用公開可見的方式完成，有些人就會知道歸檔，并會在其中尋找答案。另外，通過引用歸檔而不是重寫建議，可以加強對于復制信息的社會標準。為什么同一個答案會出現在不同的地方？當可以找到答案的地方還比較少，人們就更可能會記住地址并再次查找。精心放置的引用也可以幫助改進搜索結果的質量，因為他們可以加強目標資源在互聯網搜索引擎中的權重。 當然有時復制信息也有意義。例如，在歸檔中已經有了一個來自別人的回應說： ~~~ 看起來你的Scanley索引開始fronbnicated。為了unfrobnicate，可以按照如下步驟： 1. 關閉Scanley服務器。 2. 運行Scanley的'defrobnicate'程序。 3. 啟動服務器。 ~~~ 然后，幾個月之后，你看到另外一篇文章顯示某人的索引變得frobnicated。你搜索歸檔并發現了上面這個較早的回復，但是你認識到它遺漏了一些步驟（或許是因為誤解，也可能是因為軟件在那篇文章之后發生了改變）。最經典的方式是發表一篇新文章，更完整的指導，并明確的廢棄較早的那篇文章： ~~~ 看起來你的Scanley索引已經變得frobnicated。我們在7月份看到過這個問 題，而且J. Random在http://blahblahblah/blah發布過一個解決辦法。下面 是根據J. Random的指導unfrobnicate你的索引的方法，有一些擴展： 1. 關閉Scanley服務器。 2. 成為通常運行Scanley服務器的用戶。 3. 作為該用戶，在索引上運行'defrobnicate'程序。 4. 手工運行Scanley，并查看索引是否工作。 5. 重啟服務器。 ~~~ （在理想的世界，可以為原來的文章附加一個注釋，說明有較新的信息，并指向新文章。然而，我不知道有什么歸檔軟件支持“廢棄”特性，或許因為在不違反歸檔逐條的歸檔完整性的情況下實現有一點狡猾。這是設置一個專門的網頁回答常見問題的另一個原因。） 歸檔可能經常被用來查找技術問題的答案，但是他們對于項目的重要性不僅如此。如果說項目的正式指南的法定法律，那么歸檔就是不成文法：所有決策如何制定和如何得出的記錄。對于任何重現的討論，從歸檔搜索開始是義不容辭的。這允許你從當前狀態、期望的目標、舉反證和發現你沒有想到立場的摘要開始討論。另外，其他參與者會*期望*你已經做了歸檔搜索。即使之前的討論沒有結果，在你重新提出這個主題時也要指出它們，這樣人們就可以自己看到a) 討論沒有結果，并且b) 你做了功課，那么現在說一些沒說過的話吧。 ### 將所有的資源視為歸檔 之前的所有建議不只是能應用到郵件列表歸檔。零散的信息都位于穩定，便利和可查詢的地址，這必須成為項目所有信息的組織原則。我們以項目FAQ為例進行研究。 人們如何使用FAQ？ 1. 他們希望在其中查找特定的單詞和短語。 1. 他們希望進行瀏覽，獲取信息，而不是去尋找特定問題的答案。 1. 他們希望諸如Google之類的搜索引擎可以知道FAQ的內容，所以可以搜索到FAQ條目。 1. 他們希望在FAQ中直接為其他人提供特定項目的引用。 1. 他們希望為FAQ提供新的材料，但是注意到添加比查詢回答要少許多—FAQ更多的是閱讀，而不是編寫。 第1點暗示我們FAQ一定要以文本格式存在。第2和第3點暗示FAQ應當以HTML格式存在，第2點也說明HTML必須針對可讀性進行設計（即你會希望控制起觀感），而且必須有目錄。第4點意味著FAQ的每個條目都賦予了一個HTML*命名的Anchor*，一個用戶可以到達頁面特定位置的標記。第5點說明FAQ的源文件必須用便利的方法存在（見[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")的[the section called “版本化所有的東西”](# "版本化所有的東西")），并使用易于編輯的格式。 **命名的Anchor和ID屬性** 有兩種方法可以讓瀏覽器跳到網頁的特定位置，命名的Anchor和id屬性。 *命名的anchor*只是普通的HTML anchor元素（`<a>...</a>`），但包含一個“name”屬性： ~~~ <a?name="mylabel">...</a> ~~~ 更多現在版本的HTML都支持原始的*id屬性*，可以附加到任何HTML元素，不僅僅是`<a>`。例如： ~~~ <p?id="mylabel">...</p> ~~~ 命名的anchor和id屬性以同樣的方法應用。通過在URL后追加井號和標簽，可以讓瀏覽器直接跳轉到頁面的定點位置： ~~~ http://myproject.example.com/faq.html#mylabel ~~~ 事實上，所有瀏覽器都支持命名的anchor；絕大多數現代瀏覽器支持id屬性。安全起見，我會建議要么單獨使用命名的anchor，要么同時使用命名的anchor*和*id屬性（當然要每一對使用相同的標簽）。命名的anchor不能自關閉—即使元素中沒有文本，你還是需要寫成兩部分的形式： ~~~ <a?name="mylabel"></a> ~~~ ...盡管一般都會有些文本，例如小節的標題。 無論你是用命名的anchor、還是id屬性、或者兩者皆有，請牢記那些沒有使用標簽的人看不到這些標簽。但是這些人會希望知道特定位置的標簽，這樣他們就可以將某個FAQ的URL發送給自己的朋友。為此，需要為添加了“name”和/或“id”屬性的元素添加*title屬性*。 ~~~ <a?name="mylabel"?title="#mylabel">...</a> ~~~ 當鼠標指針移到有title屬性的元素時，大多數瀏覽器會彈出小方框顯示這個title。我通常會包含井號，提醒用戶這就是添加在URL之后，從而可以在下次直接跳轉的該位置。 格式化FAQ只是如何讓一個資源可以展示出來的例子。同樣的屬性—直接的咳嗽索性、主要搜索引擎的存在性、可瀏覽性、引用穩定性和（合適的地方）可編輯性—可以應用到其他網頁、源代碼樹和bug跟蹤系統等等。只是在不久之前大多數郵件列表歸檔軟件才認識到了這些屬性的重要性，也是郵件列表傾向于本身具備這些功能的原因，其他格式或許需要維護者花費更多的經歷（[Chapter?8, *管理志愿者*](# "Chapter?8.?管理志愿者")討論了如何在多個志愿者間分擔負擔）。 ### 編制法律的傳統 隨著項目的日積月累和復雜化，每個新來的參與者必須吸收的數據量大增。那些伴隨項目很長時間的人能夠根據以前的經歷認識到和發明項目的習俗。他們會本能的意識到積累了大量傳統，并會為新來者的大量過失而感到驚訝。當然，問題不是新來者的質量降低了；而因為他們面對的是比以前更多的積累負擔。 一個項目積累的傳統取決于他們交流和保存信息的方法，以及他們的編碼標準和其他技術備忘錄。我們已經看了兩種標準，分別在[Chapter?2, *起步*](# "Chapter?2.?起步")的[the section called “開發者文檔”](# "開發者文檔")和[Chapter?4, *社會和政治的基礎架構*](# "Chapter?4.?社會和政治的基礎架構")的[the section called “寫下所有的內容”](# "寫下所有的內容")，也都有各自的例子。本小節關注的是如何在項目進化中保持指南的及時性，特別是關于如何管理交流的指南，因為這些指南會隨著項目規模和復雜性的成長發生最顯著的變化。 首先，關注人們陷入混淆的模式。如果你看到同樣的情形屢次發生，特別是發生在新參與者身上時，就是需要記錄指南的機會了。其次，不要厭煩反復說同樣的話，也不要*表現出*對說這些話的厭煩。你和其他項目老兵都需要經常的重復自己；這是新手到來時不可避免的副作用。 每個網頁、每個郵件列表信息和每個IRC頻道必須考慮廣告空間—不是商業廣告，而是自己項目資源的廣告。你所放置的內容取決于會觀看它的人口統計數據。一個針對用戶問題的IRC頻道，其中通常是那些從未與項目交互的人—通常是只安裝了軟件，需要立刻獲得問題答案的人（畢竟，如果他們可以等待，他們可以發送到郵件列表，整體上他將會花費較少的時間，盡管那樣會需要更長的時間得到回答）。人們通常不會在IRC頻道作出永久投資，他們會露面，詢問問題，然后離開。 因而，頻道的主題必須針對那些希望*立刻*尋找軟件技術回答的人，而對那些以長期方式參與項目的人，社區交流指南或許更合適。下面是真正忙碌頻道的處理方式（[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")的[the section called “IRC / 實時聊天系統”](# "IRC / 實時聊天系統")）： ~~~ 你現在位于#linuxhelp 關于#linuxhelp的主題請閱讀 http://www.catb.org/~esr/faqs/smart-questions.html && http://www.tldp.org/docs.html#howto 詢問問題之前 | 頻道規則 在http://www.nerdfest.org/lh_rules.html | 升級到內核2.6.x 請看 http://kerneltrap.org/node/view/799 | 內存讀可能性: http://tinyurl.com/4s6mc -> 更新到2.6.8.1或2.4.27 | 哈希算法災難: http://tinyurl.com/6w8rf | reiser4放出 ~~~ 在郵件列表中，“廣告空間”是追加在每封郵件后的小注腳。大多數項目會在這里放置訂閱/取消訂閱的指導，也可能是項目主頁或FAQ的鏈接。你或許會認為所有訂閱列表的人都會知道如何做，很可能是—但是會有更多不是訂閱者的人會看到郵件列表信息。一個歸檔的文章會被鏈接到許多地方；實際上，某些文章最終會變得家喻戶曉，有遠多于列表訂閱者的閱讀者。 格式化可以產生明顯的區別。例如，在Subversion項目，我們在[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")的[the section called “Bug跟蹤的預過濾”](# "Bug跟蹤的預過濾")中描述的使用bug過濾技術，取得了有限的成功。經驗不足的人會一直發起許多虛假的bug報告，每當發生這種情況，檔案管理員必須像他之前的500人那樣對此有足夠的認識。某天，我們的某個開發者終于忍無可忍，對那些不閱讀問題跟蹤系統指南的倒霉用戶開始發火，另一個開發者則決定這種情況不應該再發生了。他建議重新調整問題跟蹤首頁的布局，這樣最要的部分，也就是在提交之前必須在郵件列表中討論bug的命令，將會使用較大和粗體紅色字體，亮黃色背景，頁面居中突出顯示處理。我們這樣做了（你可以在[http://subversion.tigris.org/project_issues.html](http://subversion.tigris.org/project_issues.html)看到結果），結果是虛假問題的錄入率大大降低。我們依然會得到虛假的問題，當然—我們一直會—但是比例顯著降低，甚至是在用戶數大增的情況下。結果不僅是bug數據庫中的垃圾大大減少，而且那些響應問題的人也得到了好情緒，也就更容易在面對罕見的虛假bug時保持友好。這樣不僅改善了項目的形象，也改善了志愿者的心理健康。 僅僅是寫出指導方針的課程對于我們來說還遠遠不夠。我們也必須讓最需要的人看到這些東西，它們的狀態要像介紹材料一樣格式化處理，這樣對項目不熟悉的人們也可以立刻清晰明了。 靜態網頁不是發布項目習慣唯一的維納斯。一定數量的的交互政策（友情提示的感覺，而不是冷冰冰的手銬腳鐐）也是必需的。所有的同級評審，甚至[Chapter?2, *起步*](# "Chapter?2.?起步")的[the section called “實踐明顯的代碼評審”](# "實踐明顯的代碼評審")描述的提交評審，都應該包括對于人們是否遵守項目規范的檢查，特別是與交流習慣相關的。 Subversion項目的另一個例子：我們在版本控制版本庫設定了“r12908”表示“修訂版本12908”的習慣。小寫的“r”前綴很容易輸入，又因為它只有數字的一半高度，所以與數字在一起時非常易于識別。當然，設定了習慣并不意味著每個人都會一直以正確的方式使用它。因而，每當有這樣包含日志信息的提交郵件時： ~~~ ------------------------------------------------------------------------ r12908 | qsimon | 2005-02-02 14:15:06 -0600 (Wed, 02 Feb 2005) | 4 lines Patch from J. Random Contributor <jrcontrib@gmail.com> * trunk/contrib/client-side/psvn/psvn.el: Fixed some typos from revision 12828. ------------------------------------------------------------------------ ~~~ ...某些提交評審者就會說“順便說一句，請使用‘r12828’，而不是修訂版本（revision）12828引用過去的變更。這不是賣弄學問；重要的是自動解析和人類閱讀。 通過遵循一般的原理，包括對常見實體的權威參考方法，以及必須放之四海皆準參考方法，這個項目輸出特定的標準。這些標準使得人們可以編寫工具用更有價值的方式展現項目交流—例如，一個格式為“r12828”的修訂版本可以在版本庫瀏覽工具中被轉化為可用的鏈接。但是如果修訂版本寫成“revision 12828”，則這項工作將會難許多，一方面因為鏈接會在換行處分隔，另一方面也因為限制不足（單詞“revision”會經常單獨出現，一組數字也會單獨出現，而他們的組合“r12828”則只意味著修訂版本號碼）。類似的，同樣的關注面也適應于問題號碼，FAQ項目（提示：在[命名的Anchor和ID屬性](# "命名的Anchor和ID屬性")描述的，使用命名錨點的URL）等等。 即使對于沒有簡短和權威形式的實體，也要鼓勵人們提供一致的關鍵細節信息。例如，當引用到一個郵件列表信息時，不要只給出發送者和主題；請也給出歸檔URL*和*信息的ID頭。這樣可以讓那些雖然自己也有郵件列表拷貝（人們有時會保存離線備份，例如在旅行中使用筆記本時）的人，能夠明確無誤的定位到正確的信息，甚至無須訪問他們自己的歸檔。發送者和主題并不足夠，因為一天里同一個人可能為某一個線索發表過許多文章。 項目愈大，愈是需要這類一致性。一致性意味著人們會在所有的地方，看到被以相同的方式遵循的模式，這樣他們知道自己也需要遵循這些模式。作為回報，減少了回答問題的必要。擁有幾百萬讀者的負擔并不比僅僅一個更大；擴展性的問題源于一定比例的讀者開始提問了。隨著項目的成長，必須依靠增加信息的密度和可訪問性，才能減少這種比例，這樣人們才能更容易的找到答案，而無需提問。