# 像分擔技術任務一樣分擔管理任務 運行項目時要像分擔技術負擔那樣分擔管理負擔。隨著項目的成長，就會有更多關于管理人員和信息流程的工作。沒有道理不分擔這些負擔，這并不一定需要一種自頂向下的階級組織—實踐中更多是同級的網絡拓撲結構，而不是軍隊式的命令結構。 有時管理角色是正式的，有時則是自然發生的。在Subversion項目中，我們有一個補丁管理員，一個翻譯管理員，文檔管理員和問題管理員（盡管是非正式的）以及一個發布管理員。有時這些角色是經過認真考慮才開始的，而有些則完全是自發的；隨著項目的成長，我相信會增加更多的角色。下面我們會詳細審視這些角色，以及一些其他的角色（除了在本章前面的[the section called “發布經理”](# "發布經理")和[the section called “發布所有者獨裁”](# "發布所有者獨裁")中介紹的發布管理員）。 就像你看到的角色描述，請注意沒有人獨占控制其所在領域。問題管理員并沒有防止其他人在問題數據庫中做出修改，FAQ管理員也不必是編輯FAQ的唯一人選。他們的角色都是非壟斷的責任。每個領域管理員所作工作的重要組成部分是提醒在該領域工作的人，訓練他們按照管理員的方式工作，這樣多種力量就可以互相加強，而不是發生沖突。領域管理員必須記錄他們工作的過程，這樣當他們離開時，別人就可以立刻接班。 有時會發生一種沖突：兩個或更多的人希望同一個角色。現在沒有人處理這件事。你可以建議每個志愿者寫一個計劃（一個“申請”），讓所有的提交者選出最佳。不過這樣有些笨拙，而且可能有些尷尬。我發現最好的方法只是告訴多個候選者自己處理。他們通常能夠，也會更滿意自己得出的結果，而不是別人施加的結果。 ### 補丁管理員 在一個接收許多補丁的自由軟件項目，跟蹤到達的補丁以及所做的決定會成為一場噩夢，特別當通過非集中方式完成時。大多數補丁是以郵件的形式出現在項目開發列表（盡管可能有些最早出現在問題跟蹤系統，或外部站點）的，在補丁到達時有許多不同的處理補丁的例程可以選擇。 有時，某人評審了補丁，發現了問題，然后踢回給原作者整理。這通常會導致一個交互過程—都在郵件列表中可見—原始的作者一直發布修正的補丁版本，直到評審者無法找到更多的問題。有時很難說清楚這個過程已經結束：如果評審者提交了補丁，則可以說整個周期已經結束。但是如果她沒有，或許僅僅因為她沒有時間，或者沒有提交權限，而且無法拉其他開發者做這件事。 另一個對補丁的常見回應是輕快的討論，不必是針對補丁本身，而是關于補丁之后的概念。例如，補丁可能修正了一個bug，但項目希望用另一種方式修正這個bug，作為解決一個更普通類型問題的一部分。通常一開始這都是未知的，只是補丁激發了探索。 偶然情況下，發布的補丁可能會遇到完全的沉默。通常是因為沒有開發者有時間*在那個時刻*去評審這個補丁，都希望其他人能去做這件事。因為每個人等待其他人撿起這個球的時間并不一定，而其他優先的事情不斷出現，很容易會造成補丁被漏掉的情況，但這是任何人都不會希望發生的事情。項目可能以這種方式錯誤可用的的補丁，也有其他有害的副作用：會打擊作者，他為補丁做了許多工作，讓他覺得整個項目難以靠近，特別是對于其他考慮編寫補丁的人。 補丁管理員的工作就是確保補丁不會漏掉。這是通過跟蹤每個補丁的穩定狀態實現的。補丁管理員觀察郵件列表中每個由提出補丁引發的線索。如果最終以補丁的提交完成，他不需要做任何事。如果進入了評審/修正迭代，以補丁的最終版本結束，但是沒有提交，他發起一個指向最終版本以及相關郵件列表的問題，這樣之后跟進的所有開發者都有了一個永久的記錄。如果補丁定位了一個現有的問題，他會將相關信息注釋到該問題，而不會開一個新事物。 如果某個補丁沒有回應，補丁管理員應該等待幾天，然后詢問是否有人會去評審它。通常會有響應：某個開發者會解釋她認為該補丁不必應用，然后給出原因，或者她會去評審它，。如果還是沒有回應，補丁管理員可以發起，也可以不發起一個補丁的問題，要根據他自己的判斷，但至少最初的提交者得到了*一些*回應。 擁有一個補丁管理員為Subversion開發團隊節省了大量時間和心力。如果沒有指定的人負責，每個開發者需要一直擔心“如果我沒有時間現在回應補丁，我能指望別人做嗎？我是否要一直盯著？ 但如果有別人盯著，同樣的原因，這樣是否是沒必要的重復。” 每個開發者在第一次看到這個補丁的時候都要做這樣的決定。如果她希望跟進評審，她就可以這樣做—補丁管理員會根據情況調整他的行為方式。如果她希望完全忽略這個補丁，也沒問題；補丁管理員會確保它沒有被遺忘。 因為這個系統只有在補丁管理員不發生失誤的情況下才能運作正常，所以這個角色必須正式任命。在Subversion，我們在開發和用戶郵件列表中廣而告之，得到了許多志愿者，并選了第一個回復的。當那個人請辭后（本章后面的[the section called “轉化”](# "轉化")），我們重復了這個步驟。我們一直沒有試圖讓多個人分擔這個角色，因為他們之間會需要交流的負擔；但是如果補丁提交的規模更大，則一個多頭的補丁管理員就會有意義。 ### 翻譯管理員 在軟件項目中，“翻譯”可能指的是兩件完全不同的事。它可能指的是將軟件文檔翻譯為其他語言，或者指的是翻譯軟件本身—也就是讓程序使用用戶選中的語言顯示錯誤和幫助信息。兩者都是復雜的任務，不過一旦建立了正確的基礎架構，則可以很大程度上與其他開發分離。因為這些任務非常類似，所以設置一個單獨的翻譯管理員處理兩部分任務就非常有意義（取決于你的項目），亦或者更好的方式是設置兩個不同的管理員。 在Subversion項目，我們有一個處理兩部分的翻譯管理員。他自己并不編寫翻譯，當然—他可以幫助一兩個，但是在寫這些話時，如果他希望與他們所有人一起工作，他需要講10種語言（12種方言）。因而，他管理志愿翻譯者：他幫助他們互相協調，以及他們團隊與項目其余部分的協調。 設置翻譯管理員的一個原因是翻譯者是與開發者不同的人。他們有時只有有限的甚至沒有任何在版本控制版本庫中工作的經驗，也沒有與分布式志愿團隊一起工作的經驗。但在另一方面，他們通常是最好的一類志愿者：擁有特定領域知識，可以看到需求，選擇參與進來。他們也通常愿意學習，對工作充滿熱情。所需要只是有人告訴他們如何做。翻譯管理員確保翻譯不會沒必要的干擾日常的開發。每當開發者必須被告知需要為支持翻譯工作提供技術變更時，他也要作為翻譯者作為一個統一整體的代表。 因此，這個位置最重要的技能是外交能力，而不是技術能力。例如，在Subversion我們有一個政策，每種語言的翻譯都必須至少有兩個人正在參與，否則，就沒有人可以檢查文本。譬如說，有新的志愿者請求提供Subversion馬達加斯加語翻譯時，翻譯管理員必須提示他去與六個月前某個表達過馬達加斯加語翻譯意向的人建立聯系，或者有禮貌的詢問志愿者去尋找*另一個*馬達加斯加翻譯者與其搭檔工作。當有了足夠的人手，管理員就可以為他們設置正確的提交訪問權限，告知他們項目的慣例（例如如何編寫日志文件），然后緊盯他們是否遵循了這些慣例。 翻譯管理員和開發者之間，以及翻譯管理和翻譯團隊之間的對話通常使用項目原先的語言—也就是所以翻譯的源語言。對于大多數自由軟件項目，就是英語，但是是什么語言并不重要，只要項目認可即可。（對于希望吸引廣泛國際開發社區的項目，英語可能是最好的語言。） 在特定翻譯小組*中的*對話通常使用它們共享的語言，然而翻譯管理員的另一個任務就是為了每個團隊設定一個專門的郵件列表。通過這種方式，翻譯者可以自由的討論他們的工作，而不會打擾項目郵件列表中的人，他們可能根本不理解他們的翻譯語言。 **國際化還是本地化** *國際化*(*I18N*)和*本地化*(*L10N*)都指的是采用非原軟件編寫的語言和環境使用程序的過程。這兩個術語通常是可以互相替換的，但是實際上他們并不是同一回事。就像[http://en.wikipedia.org/wiki/G11n](http://en.wikipedia.org/wiki/G11n)所說的： > 它們之間的區別是微小的，但是非常重要：國際化指的是為*潛在的*用于所有地方的產品改造，而本地化是為用于*特定*地域的特別特性附加。 例如，將您的軟件修改為實現對Unicode([http://en.wikipedia.org/wiki/Unicode](http://en.wikipedia.org/wiki/Unicode))文本編碼無損處理是一種國際化行動，因為它并不是關于特定的語言，而是關于接受來自任意數量語言的文本。另一方面，當檢測到軟件是運行于斯洛文尼亞語環境時，便以斯洛文尼亞語打印錯誤信息，則是本地化的行動。 因此，翻譯管理員的任務從原理上是關于本地化的，而不是國際化。 ### 文檔管理員 保持軟件文檔的實效性是一項無法結束的任務。每個進入代碼的新特性或改進都可能會導致文檔的變更。另外，一旦項目文檔達到了一定級別的完整性，就會發現許多人發來的補丁是針對文檔的，而不是代碼。這是因為許多人是在文章中修正了bug，而不是在代碼中：所有的用戶都是讀者，但僅有少數是程序員。 文檔補丁通常比代碼補丁更易于檢查和應用。僅需要少許或無需測試，而且可以快速的通過檢查評價變更的質量。因為數量很多，但是檢查的負擔相對較低，文檔補丁中有效工作的管理負擔比率遠比代碼補丁高。此外，大多數補丁需要一些調整，才能保持文檔中作者語氣的一致性。在大多數情況下，補丁通常會覆蓋或影響其他補丁，在提交之前需要根據之間的關系進行調整。 出于處理文檔補丁的緊迫性，以及需要持續監控代碼基以便保持文檔的實效性，有必要讓某個人或一個小組專門從事這項任務。他們需要精確的保存文檔在何處滯后于軟件的記錄，而且他們可以用一種整體方式的實踐步驟來處理大量的補丁。 當然，這樣不會阻礙項目中的其他人在工作中應用文檔補丁，特別是時間允許時一些小的補丁。同一個補丁管理員（見本章前面提到的[the section called “補丁管理員”](# "補丁管理員")）可以同時跟蹤代碼和文檔補丁，當開發和文檔團隊希望時完成它們。（如果補丁的總數已經超出了單個人可以跟蹤的容量，最好的一個步驟可能就是將補丁管理員分為代碼和文檔。）文檔團隊的關鍵是使人們把保持文檔組織性、實效性和一致性當作自己的責任。在實踐中，這意味著對于文檔的熟悉，關注*其他人*提交給文檔的變更，關注到來的文檔補丁，并使用所有這些信息源完成保持文檔健康的所有必要工作。 ### 問題管理員 項目bug跟蹤系統中問題的數量是隨著使用產品的人數同比例增加的。因而，即使你在一個快速成長的健壯程序中修正bug并裝運，您還是會看到大量開放的問題漫無邊際的產生。重復問題，以及不完整或描述糟糕的問題也會頻繁發生。 問題管理員通過關注進入數據庫的信息，定期的清除特定問題有助于緩和這種問題。他們的大多數常見行為可以修正進入的問題，一方面因為報告者未能正確的處理部分字段，另一方面也因為問題與數據庫中的一個問題已經重復。很明顯，問題管理員對項目bug數據庫越熟悉，他就越能有效率的檢測到重復問題—這也是設置一小部分人專門關注bug數據庫，而不是讓每個人都*特別*參與其中的原因。當團隊試圖按照非集中式的方式完成這項任務時，就不會有任何一個人具備對于數據庫內容的深入專業知識。 問題管理員可以幫助我們映射問題和個別開發者。當有大量bug報告進入時，不是每個開發者會以平等的態度讀取問題通知郵件列表。然而，如果某人知道開發團隊緊盯著所有進入的問題，她可以將注意力放到特定合適的bug上。當然，這需要對項目所有開發的事情，接受者期望和性情都很敏感。因而，問題管理員最好也是開發者的一分子。 取決于你的項目如何使用問題跟蹤系統，問題管理員也可以調整該數據庫以反映項目的優先級。例如，在Subversion我們將問題排入未來的特定發布，這樣每當有人詢問“某個bug X何時可以修復時？”我們可以說“之后的兩個發布，”即使我們不能說出確切的日期。這個發布在問題跟蹤系統中以目標里程碑的形式展示，也就是IssueZilla中的一個字段。[[27](#)]作為一個規則，每個Subversion發布都有一個新的特性和一組特定的bug修正。我們為該發布的所有問題賦予一個合適的目標里程碑（包括新特性—它也會得到一個問題），這樣人們就可以通過發布計劃查看bug數據庫。這些目標很少情況下會保持靜止。隨著新bug的到來，等級會發生切換，而且有些bug必須移到另一個里程碑，以保證每個發布的可管理性。再次，最好由對項目數據庫的內容以及問題之間的關系有著整體意識的人完成。 問題管理員的另一項值得關注的任務是管理廢棄的問題。有時，某個bug會因為軟件一個不相關變更而意外的修正，或者有時項目對于特定行為是否為bug的意見發生改變。尋找廢棄的問題并不簡單：唯一的系統方法是清理數據庫中的所有問題。隨著問題數量的增長，完全的清理會變得越來越不可行。在達到某個點時，保持數據庫健康的唯一方法就是分而治之：根據進入數據庫的情況將問題分類，并直接分配給合適的開發者或團隊。然后接受者負責問題余下的工作，根據需要決定是解決還是廢棄。如果數據庫足夠大，問題管理員的工作就更傾向于協調，將會花費較少的時間用于自己查找問題，而是花更多的時間使之到達正確的人手中。 ### FAQ管理員 FAQ維護是一項出人意料的困難工作。項目中其他文檔的內容都是由作者預先計劃得到的，而FAQ則完全是被動的文檔（見[維護FAQ](# "維護FAQ")）。無論它變得如何巨大，你永遠不知道何時會再一次添加。而且因為它總是零零散散的添加，它很容易變得不夠一致并缺乏組織，甚至會包含重復的或半重復的條目。即使它沒有任何此類的明顯問題，項目之間也通常會有不引人注目的互相依賴—必須有鏈接，但是沒有—因為與關聯的項目添加的時間相差一年。 FAQ管理員的角色是雙重的。首先，通過至少對所有問題的標題保持熟悉，她維護了FAQ的整體質量，這樣每當有人添加的新條目與原來的條目重復或者相關，可以作出合適的調整。其次，她關注著項目的郵件列表和其他論壇中重復發生的問題或疑問，并根據這些輸入編寫新的FAQ條目。后一項工作可能非常復雜：必須能緊跟線索，識別出其中的核心問題，發表一個提議FAQ條目，組合來自其他人的評論（因為FAQ管理員不可能是FAQ包含的所有主題的專家），并感知何時結束這個過程并將其添加到FAQ。 FAQ管理員通常也會成為FAQ格式的默認專家。有許多保持FAQ結構的小細節（見[Chapter?6, *交流*](# "Chapter?6.?交流")的[the section called “將所有的資源視為歸檔”](# "將所有的資源視為歸檔")）；當某人編輯了FAQ，他們可能會忘記這些細節。但只要FAQ管理員能夠在之后查漏補缺，這樣便沒有任何問題。 許多自由軟件可以用于輔助維護FAQ的過程。只要能夠保證FAQ的質量，就可以選一個來使用，但是要避免過度自動化。一些項目試圖完全自動化FAQ維護的過程，使用類似wiki的模式允許每個人貢獻和編輯FAQ條目（見[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")的[the section called “Wikis”](# "Wikis")）。我曾經遇到過在Faq-O-Matic上發生的這種情況（[http://faqomatic.sourceforge.net/](http://faqomatic.sourceforge.net/)），盡管我看到原因僅僅是對Faq-O-Matic超出本來目的的濫用。在任何情況下，雖然完全的分布式FAQ維護可以減少項目的負擔，但也會導致較差的FAQ。沒有人具備整個FAQ的廣泛視野，沒有人注意到了哪個條目需要更新或變得完全不可用，每個人看到的都是孤立的條目。結果是FAQ經常會無法為用戶提供他們所需要查找的東西，甚至會誤導他們。您可以使用任何必須的工具維護項目FAQ，但是不要因為工具便利性的誘惑而損害FAQ的質量。 見Sean Michael Kerner在[http://osdir.com/Article1722.phtml](http://osdir.com/Article1722.phtml)的文章*The FAQs onFAQs*，描述和評估了開源FAQ維護工具。 [[27](#)] IssueZilla就是我們使用的問題跟蹤系統；它是BugZilla的后繼。