# 提交者 作為所有開源項目中唯一正式的明確階層，需要對提交者格外關注。提交者是系統中不可避免的對鑒別的讓步，而其他角色則是盡可能的非鑒別。但是“鑒別”這里絕無輕視的含義。提交者發揮的功能是絕不可少的，我不相信一個項目會在沒有這個角色的情況下取得成功。我們需要質量控制，是的，控制。總會有許多人覺得自己具備對某個程序修改的能力，但實際上只有少數人確實具備。項目不能依賴人們自己的判斷，必須設置標準并為達到標準的人賦予提交權限[[28](#)]。 另一方面，要讓可以直接提交變更的人與不能設置明顯權利變化的人一起工作。這種變化必須是受管理的，這樣才不會損害項目。 在[Chapter?4, *社會和政治的基礎架構*](# "Chapter?4.?社會和政治的基礎架構")的[the section called “誰進行表決？”](# "誰進行表決？")，我們已經討論考慮過新提交者的機制。這里我們會討論潛在的新志愿者必須被判斷的標準，以及在一個大的社區中如何展示這個過程。 ### 選擇提交者 在Subversion項目，我們主要根據希波克拉底原理選擇提交者：*首先，不要傷害*。我們的主要標準不是技術技巧或對代碼的認識，僅僅是提交者展示出好的判斷。判斷僅意味著知道不要做什么。一個人可以只發布小的補丁，修正代碼中的小問題；但只要這個補丁能夠干凈的應用，不會帶來新的bug，能夠最大程度的符合項目的日志信息和代碼習慣，而且有足夠多的補丁可以展示明顯的模式，則現有的提交者通常會提議為該人賦予提交權限。如果至少三個人贊成，且沒有人反對，則提議通過。誠然，也許我們沒有證據證明這個人有能力解決代碼基所有部分的復雜問題，但這并不重要：他所做的已經證明他至少能對自己的能力有正確的判斷。技術技巧可以習得（和講授），但無法獲得最重要的判斷。然而，在賦予一個人提交權限之前，這是你需要確保某人所具備的能力。 當一個新的提交者提議引起了討論，通常不會是關于技術能力，而是關于該人在郵件列表或IRC中的行為方式。有時，某人展示了技術能力和按照項目正式方針工作的能力，以及在公共論壇中一致的好戰或不合作性。這需要認真的關注；如果即使經過了回復的提示，這個人也一直未能改變，我們不會將其添加為提交者，無論其技巧怎樣高。在一個志愿者團隊中，社會技巧，或者說在“沙盒中玩耍的”能力，與原始的技術能力同樣重要。因為任何東西都會進入版本控制，添加一個不該添加的提交者不會在代碼層面帶來太多的問題（評審可以迅速定位這些問題），但那樣會導致最終強制項目收回該人的提交權限—這絕不是一項讓人愉快的行為，有時會讓人失望。 許多項目堅持潛在的提交者展示了特定級別的技術專業技能和持久性，通過提交一定數量的非瑣碎補丁—也就是項目不僅僅希望知道他不會傷害項目，而且希望知道他會使項目在代碼基上獲益。這樣很好，但是要小心，不要將提交權變為一個排他俱樂部的身份。每個人的腦子中都應該有一個問題：“怎樣做才會為代碼帶來最好的結果？”而不是“認可這個人是否會降低提交權關聯的社會狀態的價值？”如果您有100個提交者，10個進行常規的較大的變更，而其他90個則僅僅是每年修正幾個拼寫和小的bug，依然比只有10個提交者更好。 ### 收回提交權限 關于收回提交權限首先要做到：嘗試不要一開始就進入這種情況。取決于誰的權限將會被收回，以及收回的原因，相關的討論將會顯著不同。即使沒有不同，這也將會是有效率工作的一項費時的分心的工作。 然而，如果您必須如此，一定要確保討論必須處于將會為該人*賦予*權限進行投票的人之間，無論他們擁有怎樣的投票風味。一定不要包含本人。這似乎否定了針對保密性的禁令，但在這種情況下這是必要的。首先，沒有人能夠以別的方式自由言論。其次，如果行動失敗，你不會希望讓此人知道這被考慮過，因為這會帶來一些問題（“誰站在我這邊？ 誰反對我？”），會導致最壞類型的黨派主義。在一些罕見的情形下，團隊會希望某人知道收回提交權限的過程正在進行中，作為警告提示，但一定要確保這種公開是團隊決策的結果。任何人不應當擅自行動，將別人認為是秘密的討論信息和表決透漏出去。 一旦收回了某人的權限，結果必然要公開（見本章后面的[the section called “避免神秘”](# "避免神秘")），你需要嘗試盡可能謹慎的公布于眾。 ### 部分提交權限 有些項目提供細粒度的提交權限。例如，有些貢獻者的提交權限限于文檔，而不能是代碼。常見的部分提交權限包括文檔、翻譯、其他語言的綁定代碼，打包的特定文件（例如RedHat RPM規范文件等等），以及其他即使發生錯誤也不會導致核心項目問題的地方。 因為提交權限不僅僅關于提交，而且事關選舉資格（見[Chapter?4, *社會和政治的基礎架構*](# "Chapter?4.?社會和政治的基礎架構")的[the section called “誰進行表決？”](# "誰進行表決？")），自然回帶來另一個問題：部分提交者能夠為何投票？沒有一個正確的答案；這取決于你的項目有何種部分提交領域。在Subversion中，我們盡可能讓事情簡單：一個部分提交者只可以參加提交者領域的部分投票，其他地方則不行。更重要的，我們有一個可以覆蓋建議投票的機制（其實質在于，表決時提交者可以寫"+0"或"+1?（非綁定）"，而不僅僅是"+1"）。...................... 完全提交者可以為任何事情投票，就像他們可以任意提交一樣，只有完全提交者可以為添加所有類型的提交者投票。在實踐中，通常這種添加新部分提交者的能力通常會被代理：任意完全提交者可以“發起”一個新的部分提交者，而且某個領域的部分提交者通常會為同一領域選擇新的提交者（這在保證翻譯工作正常運行時特別有益）。 你的項目可能有些許不同的安排，這取決于你所作工作的特性，但相同的原理適用于所有的項目。每個提交者必須能為她提交權限相關的事物進行投票，不相關的則不能，而且程序上的問題默認由完全提交者表決，除非有原因（要由完全提交者決定）來擴大投票范圍。 關于部分提交權限的強制性：最好*不要*讓版本控制系統約束提交領域，即使技術上可行。原因請見[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")的[the section called “授權”](# "授權")。 ### 休眠提交者 一些項目會在提交者在一定時間（例如一年）內未能提交任何東西時，自動刪除其提交權限。我認為這樣沒有太大幫助，甚至有不良的后果，有以下兩個原因。 首先，這會誘使人們提交可接受但不必要的變更，僅僅為了保住將要過期的提交權限。其次，這樣沒有意義。如果賦予提交權限的主要標準是判斷力，為何僅僅因為他離開了項目就認為其判斷力的下降？即使他完全的消失了幾年，沒有看任何代碼或跟蹤開發討論，但當他重新出現時，他會*知道*他已經多久未從聯系，并以此行動。你原來相信他的判斷，為何不永遠相信他？如果高校的文憑不會過期，那么提交權限也不應該。 有時，一個提交者會要求將其刪除，或在提交者列表中明確的標記為休眠狀態（關于該列表的更多信息見后面的[the section called “避免神秘”](# "避免神秘")）。在這種情況下，項目當然必須答應個人的意愿。 ### 避免神秘 盡管圍繞添加特定新提交者的討論必須保持機密，其規則和步驟本身不應該保密。實際上，最好公開，這樣人們可以意識到提交者并不是什么神秘的秘密法庭，也不是凡人免進，而是任何人可以參與，僅需要發布一些好的補丁，并指導如何在社區中交流。在Subversion項目中，我們將信息放在開發指南文檔中，因為那些希望為項目貢獻代碼的人們對如何賦予提交權限最有興趣。 除了發布步驟，也要發布提交者*列表*。該文件的傳統位置是項目代碼樹頂級目錄中叫做`MAINTAINERS`或`COMMITTERS`的文件。它首先必須列出所有的提交者，緊跟是多個部分提交域以及其中的提交者。要列出每個人的名字，如果該人愿意，也包括郵件地址，地址可以為防止垃圾郵件進行編碼（見[Chapter?3, *技術基礎設施*](# "Chapter?3.?技術基礎設施")的[the section called “歸檔中的地址隱藏”](# "歸檔中的地址隱藏")）。 因為完全提交者和部分提交者訪問權限有著明顯的區別，也做出了明確的定義，所以這個列表也應該列出這種區別。除此以外，該列表不應當試圖表明項目中不可避免會出現的非正式的區別，例如誰更具影響力。它是公共記錄，不是致謝文件。請使用字母順序或其出現順序列出提交者。 [[28](#)] 請注意，在非集中式的版本控制系統中，提交權限的含義有些區別，在非集中式系統中，任何人可以建立與項目關聯的版本庫，并為自己設置到該庫的訪問權限。然而，提交權限的*概念*依然適用：“提交權限”是“改變軟件下一次發布中輸送代碼的權利”的縮寫。在集中式版本控制系統中，這意味著直接的提交權限；在非集中式系統中，這表示了將某人的變更默認拖入主發布。其實是相同的含義；其實現的機制并不重要。