# 共識為基礎的民主（Consensus-based Democracy） 隨著項目的成長，通常會從慈善獨裁模型轉為更開放的民主系統。這不一定是源于對某個BD的不滿，借用一個生物學的隱喻，可以簡單的認為團隊基礎的管理更加“進化穩定”。每當一個慈善獨裁者引退，或嘗試將決策責任更均勻的分配出去，這就是團隊選定一個新的非獨裁系統的好機會—也就是要建立一套憲法。團隊可能錯過了第一次機會、或者第二次，但是最終會這樣做；一旦做了，這個決定就不太會反轉過來。常識解釋了原因：如果某個N位成員的團隊給某個人特殊的權利，也就意味著有N?-?1位成員都愿意降低自己的個人影響。人們通常不愿意這樣做。即使他們這樣做了，所產生的獨裁統治仍然是有條件的：團隊推舉了BD，團隊也可以罷免BD。因此，一個項目的領導權一旦從某個魅力個人轉移為更正式的團隊為基礎的系統，就很少會走回頭路。 這類系統的工作細節有很大的區別，但是有兩個共同的元素：首先，團隊大多數時候在達成共識的情況下工作，其次，在無法達成共識時有一個正式的表決機制。 *共識*僅僅意味著每個人都能夠接受的一種協議。它不是一種含混的狀態：當有人提出某個共識已經達成，而且沒有人提出反對意見，我們說一個團隊對某個問題達成了共識。當然，提出共識的人應當詳細說明共識的內容，如果不是顯而易見的話，還要說明后續的動作。 一個項目的大多數對話是關于技術主題的，例如修正bug的正確方法、是否添加某個特性、以及文檔接口有多嚴格等等。共識為基礎的管理之所以可以工作正常，是因為它無縫的混入了技術討論當中。在一個討論的最后，通常是確定方向的協定。某些人會創建一個結論帖，作為所作決定的總結，同時也是隱含的共識提議。這也給了某人最后一次機會說“等等，我對此并不同意。我們應該再討論一下。” 對于小的有爭議的決議，這種共識的提議是隱含的。例如，當一個開發者本能的提交了一個bug修正，提交本身就是一個共識提議：“我料定我們都認可這個bug需要修正，而這就是我做的修正。”當然，開發者不會真的這么說；她只是提交修正，而項目中的其他人無需表明立場，因為沉默代表了認可。如果有人提交的結果*沒有*導致共識，結果就是項目會象這個變更沒有提交一樣進行討論。這個方法可以正常工作的原因請看下一個小節。 ### 版本控制意味著你可以放輕松 如果項目源代碼已經納入版本控制，這意味著大多數決定都可以輕易的取消。一個常見的情況是某人自以為提交了一個別人會喜歡的變更，但實際上并不如此。通常始于反對者對于遺漏某個預先討論的道歉開始，當然，如果反對者在郵件列表歸檔中沒有發現此類討論的紀錄，可以省略這一步。另一個方法是，變更是否已經提交沒有理由影響我們討論的基調。所有的變更都可以回退，至少在引入依賴的變更之前都沒有問題（例如，在移除原來的變更后會破壞新代碼）。版本控制系統讓項目有能力收回錯誤或倉促判斷的后果。這也釋放了人們，使他們對于做任何事情之前所需要的反饋可以相信自己的直覺。 這也意味著達成共識的過程不需要非常正式。許多項目跟著感覺處理。小的變更可以直接引入，而無需討論，或者只需要通過最少的討論來點頭確認。對于重要的變更，特別是有可能造成大量代碼不穩定的變更，人們應當需要等待一兩天才能達成共識，不應當因為某人沒有足夠頻繁的檢查郵件，而將其排斥在對話之外。 因此，當某人相信他知道應該做什么，他應當繼續前進和完成它。這不僅僅適用于軟件修正，也可以用于網站更新、文檔變更和其他任何不會引起爭議的事情。通常情況下，需要進行回退操作的情況很少，應當根據實際情況處理。當然，不應當鼓勵人們剛愎自用。正在討論和已經生效的決定會造成一定的心理差異，即使它在技術上是可逆的。人們一直認為動力等同于行動，相對于回退變更，人們更情愿在開始的時候阻止它。如果開發者濫用這個事實，過于快速的提交有爭議的變更，不管怎樣，人們可以也必然會抱怨，會將開發者置于更嚴格的標準，直到事情改進。 ### 如果無法達成共識，那么表決！ 不可避免的，一些爭論無法達成共識。當打破死鎖的所有其他方法都已經失效，最后的方案就是表決。但是，在表決之前，一定要理清表決的選項。這里一切又重演了，技術討論的正常過程會混合項目決策程序的偶然發現。此類需要表決的問題通常會很復雜，具有多方面的問題。在所有此類復雜討論中，需要有一兩個人扮演*誠實的中間人*的角色：定期發布各種論點的摘要，并保持對于分歧（和一致意見）核心論點的跟蹤。這些摘要可以幫助每個人評估所做工作的進展，并提醒每個人還需要解決什么問題。如果需要表決，這些摘要也可以作為表決表格的原形。如果誠實中間人的任務完成的好，當時機成熟就可以發布表決的可信請求，而團隊會希望使用以他們對于此問題的摘要為基礎的表決表格。中間人自己也可以參與辯論；只要他們可以理解并公平的表示其他人的觀點，不會因黨派觀點而影響以中立地態度總結辯論的狀態，就沒必要讓他們脫離爭論。 表決的實際內容通常不應當是有爭議的。當表決時刻到來，分歧通常會歸納為一些包含可識別的標簽和簡短描述的關鍵問題。偶爾某個開發者會反對表決本身的形式。有時候他的考慮是有道理的，例如，一個選項被遺漏了或描述的不夠精確。但是還有一些時候，開發者僅僅希望避開這個表決，因為他知道表決不會得到自己期望的結果。如何處理此類蓄意阻撓可以看[Chapter?6, *交流*](# "Chapter?6.?交流")的[the section called “刺兒頭”](# "刺兒頭")。 要記住指明表決系統，因為有許多不同的類型，人們很容易錯誤的假定使用某個步驟。大多數情況下的較好選擇是*同意表決（approval voting）*，也就是每個表決者可以選擇多個中意的選項。同意表決易于解釋和統計，也不會像其他方法那樣，它只有一輪表決。關于同意表決和其他表決系統的更多細節可以看[http://en.wikipedia.org/wiki/Voting_system#List_of_systems](http://en.wikipedia.org/wiki/Voting_system#List_of_systems)，但是要避免陷入使用何種表決系統的長期辯論（因為，當然你會發現你陷入了使用何種表決系統選擇表決系統的辯論！）。同意表決是正確選擇的一個原因是任何人都很難反對—作為表決系統它足夠公平。 最后，公開引導表決。沒有必要對公開討論的事務進行秘密或匿名的表決。讓每個參與者在項目郵件列表中發布自己的表決，這樣每個觀察者都可以自己檢查結果，而且所有的內容都會記錄到歸檔中。 ### 何時表決 最難的事情是決定何時開始表決。通常情況下，很少會進行表決—是其他方法都失敗后的補救方法。不要將表決當作解決爭辯的重要方法。它不是。它可以終結討論，也會結束關于此問題的創造性思考。只要討論還會繼續，就有可能會有人得出所有人滿意的解決方案。這經常令人吃驚：活躍的爭論可以產生關于問題的新方法，也會得出使每個人都滿意的提議。即使沒有出現新的提議，通常采納某種妥協也比舉行表決要好。經過妥協，每個人都或許會有點不高興，但是表決過后，有些人會開心，還有些人會失望。從政治視角，前一種狀態更可取：至少每個人都會感到為自己的不快萃取了一定的價值。他會不滿意，但其他人也一樣。 表決的主要優點是最終可以解決問題，這樣每個人都可以繼續前進。但是通過數人頭，而不是通過有理性的對話解決問題，導致每個人得出相同的結論。開源項目中的人越有經驗，就會越發現他們越不會急于用表決解決問題。相反，他們會嘗試考察以前未考慮的解決方案，或者對以前計劃的方法進行較大的妥協。有許多技術手段可以防止過早的表決。最明顯的方法是說“我覺得還沒有準備好開始表決，”然后解釋為什么還不行。另一個方法是要求進行非正式（無約束力的）的舉手表決。如果結果明確傾向到一邊，就會讓某些人立刻更希望進行妥協，以避免正式的表決。但是最有效率的方法是簡單的提供一個新的方案，或者一個較早建議的新視點，所以人們可以重新審視問題，而不是簡單的不斷重復同樣的論點。 在某些很罕見的情況中，每個人都認為所有折中的解決方案都比任何一個非折中方案要差。當這種情況發生時，表決就會有較少的異議，不僅僅因為它能夠得到一個高人一等的解決方案，而且是因為這樣不會導致所有人對結果感到不高興。盡管那樣，表決也不應該匆忙進行。導致表決的討論可以教育全體選民，所以過早的結束討論會降低結果的質量。 （要注意前面所說的表決建議不適用于[Chapter?7, *打包、發布和日常開發*](# "Chapter?7.?打包、發布和日常開發")的[the section called “穩定發布版本”](# "穩定發布版本")中描述的變更包含表決。此時，表決更像是一種交流機制，一種在變更評審過程注冊某人參與的方法，這樣每個人都可以說出對于一個變更收到了多少評審。） ### 誰進行表決？ 有了表決系統就會出現一個全民選舉的問題：誰應該表決？這有可能成為敏感的問題，因為它強制項目正式識別出一些更應該參與的人，也就是比其他人更有判斷力的人。 最好的方法是采用已存在的劃分，提交訪問，并為他們附加表決特權。在提供完全和部分提交訪問的項目中，部分提交者是否可以表決的問題，很大程度上取決于部分提交訪問被賦予的過程。 如果項目自由處理，例如，在版本庫中維護許多第三方貢獻工具的方法，那時就應當澄清部分提交訪問只是關于提交，而不是表決。相反的暗示自然也成立：因為完全提交者*會*有提交特權，他們應當不僅僅是程序員，而且是全民選舉的成員。如果某人在郵件列表中有分裂或破壞傾向，那么要小心將其加為提交者，即使這個人在技術上非常嫻熟。 表決系統本身應當用來選擇新的提交者，包括完全和部分提交者。但這是一個不太常見的需要注意保密性的情況。你不能為一個潛在的提交者在公共郵件列表表決，因為不能傷害候選者的感情（和榮譽）。相反，通常的方法是某個現有的提交者在只包含提交者的私有郵件列表中發布一個私有郵件，建議給某人附加提交權限。其他提交者可以自由發表意見，他們清楚討論是私下進行的。通常沒有異議，因而沒有表決的必要。在等待幾天之后，確保每個提交者有機會回應之后，提議者通知候選者并賦予其提交權限。如果存在異議，因而出現其他問題的討論，可能會導致表決。因為這個過程需要開放和坦白，所以發生討論的事實應當完全保密。如果被考慮的人知道事情的進展，然后沒有提供提交權限，他可能認為他已經在表決中失敗，會感到受到傷害。當然，如果某人明確的要求提交權限，沒有其他的選擇，要么同意，要么拒絕。如果是后者，應當盡量的有禮貌，并使用清晰的解釋：“我們喜歡你的補丁，但是還沒有看到足夠的補丁，”或者“我們感謝你的補丁，但是在實際使用之前需要相當大的調整，所以我們覺得現在還不能放心給你提交權限。我們希望下一次會有些改觀。”請記住，你所說的會是一個打擊，這要看個人的自信心水平。應當從他們的角度想想如果你看到那些郵件的感覺。 因為添加新提交者不是那種一次性決定，會有后續的結果，某些項目會有表決的特殊要求。例如，他們會要求提議至少獲得*n*個肯定的表決，而且沒有否定的表決，或半數以上的贊同票。精確的參數并不重要；主要的思想是在添加提交者時需要讓團隊小心處理。類似的，或更嚴格的，特別的需求也可以應用到選舉*移除*提交者上，盡管很希望那永遠沒有必要發生。關于添加和移除提交者的非表決方面的信息可以看[Chapter?8, *管理志愿者*](# "Chapter?8.?管理志愿者")的[the section called “提交者”](# "提交者")。 ### 民意調查與表決 對于特定類型的表決，有時候擴展選民會很有用。例如，如果開發者只是不能確定哪種界面符合人們實際使用軟件的方式，一個方法就是詢問項目郵件列表中的所有人進行表決。這更應該叫做*民意調查*而不是表決，但是開發者可能將結果視為有約束力的。在任何民調中，要確保參與者可以附加選項：如果某人對于民調問題想到了更好的選項，她的回應會成為最重要的民調結果。 ### 否決權 某些項目允許一種特殊的表決類型，稱為*否決權*。否決權是一種開發者停止倉促或考慮不夠充分變更的方法，至少希望每個人能夠再進行一些討論。考慮到否決權介乎于強烈反對和阻撓之間。它確切的含義對于每個項目都不盡相同。有些項目讓否決很難被逾越；有些則允許經過強制的更多討論延遲后，被普通的多數投票替代。任何否決必須伴隨完整的解釋；任何沒有這類解釋的否決都應當被認為是無效的。 否決權會帶來對其的濫用。有時候開發者會急迫的通過否決權來為自己的論點加重砝碼，而真正需要的是更多的討論。你可以通過自己對于否決權的勉強使用來防止對于否決的濫用，并有禮貌的警告某人太過頻繁的使用否決權。如果必要，你可以提醒團隊，否決權只在團隊也認可的時候有效—畢竟，如果很明顯大多數開發者希望X，那么就應該采納X。否決的開發者要么自己讓步，要么讓團隊決定削弱否決權的作用。 你可能會看到人們寫了一個“-1”來表示否決。這種方法來自擁有高度復雜表決和否決過程的Apache軟件基金會，具體內容可以看[http://www.apache.org/foundation/voting.html](http://www.apache.org/foundation/voting.html)。Apache標準也傳播到了其他項目，你可以看到他們的習慣在開源世界的許多地方以不同的面貌出現。從技術上講，即使根據Apache標準，“-1”也不是表示正式的否決，而只是一種表達否決或強烈反對的非正式方法。 類似于表決，否決權也可以是追加的。如果有問題的變更已經提交，行動已經執行（除了一些不可挽回的事情，例如新聞發布），不應該以此為理由反對一個否決。另一方面，如果否決在事情發生幾周后才出現，它也不會被重視，而且這種情況根本不應該發生。