社群角色 ¶

提交者 ¶

Subversion 專案的提交者是指擁有直接提交變更至我們的版本控制資源的權限的那些人。這個專案是依據能力主義，這表示（其中之一）專案治理是由負責工作的人員處理。有兩種類型的提交權限：完全和部分。完全表示在樹狀結構中的任何地方，部分表示僅在該提交者的特定專業領域中。雖然無論來源如何，每項貢獻都受到重視，但並非每個為 Subversion 貢獻程式碼的人員都會獲得提交權限。

COMMITTERS 檔案列出所有提交者，包括完全和部分提交者，並說明每個部分提交者的網域。

如何授予完全提交權限 ¶

在某人成功貢獻幾個非瑣碎的修補程式後，一些完全提交者（通常是檢閱並套用該貢獻者最多修補程式的人）會提議他們獲得提交權限。此提議僅會傳送給其他完全提交者，隨後的討論是私密的，因此每個人都可以安心表達自己的想法。假設沒有異議，則會授予該貢獻者提交權限。此決定是透過共識決定的；沒有規範此程序的正式規則，但通常如果有人強烈反對，則不會提供權限，或是在臨時基礎上提供。

完全提交權限的主要標準是良好的判斷力。

您不必成為技術奇才，或證明對整個程式碼庫有深入的了解，才能成為一位全權提交者。您只需要知道自己不知道什麼。如果您的修補程式符合此檔案中的準則，遵守所有通常無法量化的編碼規則（程式碼應可讀、健全、可維護等），並尊重「首先，不造成傷害」的希波克拉底原則，那麼您很可能會很快獲得提交權限。修補程式的規模、複雜性和數量並不重要，重要的是您在避免錯誤和將對程式碼其他部分的影響減到最低時所表現出的謹慎程度。許多全權提交者並未做出重大的程式碼貢獻，而是做了許多小的、乾淨的修正，每一項修正都是對程式碼的明確改善。（當然，這並不表示專案需要一堆非常微不足道的修補程式，其唯一目的是取得提交權限；知道什麼值得發布修補程式，什麼不值得發布，是展現良好判斷力的一部分 :-)。）

為了協助開發人員發現新的提交者，我們會以特殊計分格式記錄修補程式和其他貢獻，然後再進行剖析，以產生瀏覽器友善的貢獻清單，並在每晚更新。如果您打算提議某人取得提交權限，並想查看他們的所有變更，那麼貢獻清單可能是最方便的地方。

如何授予部分提交權限 ¶

一位全權提交者贊助部分提交者。通常這表示全權提交者已對部分提交者的提議區域套用多個修補程式，並了解如果該人員直接提交，事情會變得更容易。建議贊助者在發出邀請前，先在 private@ 提出此建議，但並非必要；贊助者會謹慎判斷。

贊助者會觀察部分提交者的前幾個提交，以確保一切順利進行。

部分提交者提交的修補程式，即使超出該人員的領域，也可以由該提交者提交。這需要至少一位全權提交者的核准（通常表示為 +1 投票）。在這種情況下，應在記錄訊息中註明核准，如下所示

   Approved by: lundblad

任何全權提交者都可以隨時提供任何人提交存取權限，以存取實驗性分支。實驗性分支不一定要有很高的機率併入主幹（儘管這始終是值得追求的目標）。同樣重要的是，全權提交者（實際上是所有全權提交者）將這些分支視為新開發人員的訓練場，並提供提交意見回饋。這些分支的目標是將新程式碼納入 Subversion，並讓新開發人員加入專案。另請參閱輕量級分支部分，以及這封郵件

   https://svn.haxx.se/dev/archive-2007-11/0848.shtml
   From: Karl Fogel <kfogel@red-bean.com>
   To: dev@subversion.tigris.org
   Subject: branch liberalization (was: Elego tree conflicts work)
   Date: Tue, 20 Nov 2007 10:49:38 -0800
   Message-Id: <87y7cswy4d.fsf@red-bean.com>

contrib/ 區域 ¶

當工具被接受到 contrib/ 區域時，我們會自動提供其作者部分提交存取權限，以維護該處的工具。任何全權提交者都可以贊助此操作。通常不需要討論或投票，但如果有反對意見，則適用一般的決策程序（先嘗試達成共識，如果無法達成共識，則在全權提交者之間投票）。

contrib/ 下的程式碼必須為開放原始碼，但不需要與 Subversion 本身擁有相同的授權或著作權持有者。

「顯而易見的修正」規則 ¶

任何提交者，無論是完全或部分，都可以提交修正明顯的拼寫錯誤、文法錯誤和格式化問題，無論它們出現在何處 — 網頁、API 文件、程式碼註解、提交訊息等。我們依賴提交者的判斷來決定什麼是「顯而易見的」；如果您不確定，請詢問。

每當您援用「顯而易見的修正」規則時，請在您的提交的記錄訊息中說明。例如

------------------------------------------------------------------------
r32135 | stylesen | 2008-07-16 10:04:25 +0200 (Wed, 16 Jul 2008) | 8 lines

Update "check-license.py" so that it can generate license text applicable
to this year.

Obvious fix.

* tools/dev/check-license.py
  (NEW_LICENSE): s/2005/2008/

------------------------------------------------------------------------

訪客提交者 ¶

Subversion 是 ASF 的一部分，並與 100 多個其他 ASF 專案共用相同的存放庫。雖然在這些專案上提交的人員不被視為 Subversion 的完全或部分提交者，但歡迎他們提交明顯的修正，以及他們提交的修補程式，前提是這些修補程式已收到完全提交者的 +1（或來自其領域內的部份提交者）。在兩種情況下，請遵循我們的記錄訊息指南。

版本管理員 ¶

Subversion 專案中版本管理員的角色是處理讓程式碼穩定、封裝和發布給一般大眾的程序。如果我們正在建造飛機，版本管理員將會是查看施工清單、在機身上噴上航空公司標誌，並將成品交付給客戶的人。

因此，擔任 RM 並沒有真正的開發工作。您必須做的所有工作都是非編碼工作：協調人員、集中資訊，並作為公開發布新穩定版本的發言人。RM 必須執行的許多任務都是重複性的，而且沒有自動化，原因可能是因為還沒有人分解並撰寫工具，或者因為這些任務需要人工驗證，這使得自動化有點多餘。您可以在製作 Subversion 版本一節中閱讀有關發布流程的更多資訊。

您可能在這個階段認為 RM 的職責並不光彩，您也對了一半。如果您正在尋找一個能帶來名利雙收的專案職位，您最好實作主幹上真正需要完成的工作。如果您正在尋找真正能幫助不在乎版本的人專注於程式碼的工作，那麼 RM 就是您的最佳選擇。

為了鼓勵更廣泛地傳播版本管理知識，RM 角色目前在不同的 ~~受害者~~ 志工之間輪替。

修補程式管理員 ¶

Subversion 通常會有一位修補程式管理員，其工作是觀看 dev@ 郵件清單，並確保沒有任何修補程式「從縫隙中溜走」。

這表示要觀看包含「[PATCH]」郵件的每個執行緒，並根據執行緒的進度採取適當的行動。如果執行緒自行解決（因為補丁已提交，或因為共識認為不需要套用補丁，或其他原因），則不需要採取進一步的行動。但如果執行緒在沒有明確決定的情況下消失，則需要將補丁儲存在問題追蹤器中。這表示將在追蹤器中某些問題中新增該補丁周圍的任何討論執行緒摘要，以及相關郵件清單檔案的連結。對於處理現有問題追蹤器項目的補丁，會將補丁儲存到該項目。否則，會歸檔正確類型的「DEFECT」、「FEATURE」或「ENHANCEMENT」（不是「PATCH」）的新問題，將補丁儲存到該新問題，並在問題中記錄「patch」關鍵字。

補丁管理員需要對 Subversion 有基本的技術了解，以及瀏覽執行緒並大致了解是否已達成共識，以及如果是，達成何種共識的能力。不需要實際的 Subversion 開發經驗或提交權限。選擇使用自己的郵件閱讀軟體的專業知識，但建議使用 :-).

目前的補丁管理員是：Gavin 'Beau' Baumanis <gavin@thespidernet.com>。