章程

本文件定義 Apache Hadoop 專案運作的章程。它定義專案的角色和責任、誰有投票權、投票方式、如何解決衝突等事項。

Hadoop 是 Apache 軟體基金會 的一個專案。基金會擁有「Hadoop」名稱的商標和 Apache 程式碼的著作權，包括 Hadoop 程式碼庫中的程式碼。基金會常見問答集 說明基金會的運作和背景。

Hadoop 是 Apache 專案的典型，它遵循一套原則運作，合稱為「Apache 準則」。如果您是 Apache 開發的新手，請參閱 孵化器專案，以取得更多關於 Apache 專案運作方式的資訊。

角色和責任

Apache 專案定義一組具有相關權利和責任的角色。這些角色規範個人在專案中可以執行哪些任務。這些角色定義在以下各節中

• 使用者

  專案中最重要的參與者是使用我們軟體的人。大多數的開發人員一開始都是使用者，並從使用者的角度指導他們的開發工作。

  使用者透過提供錯誤回報和功能建議的形式，將意見回饋提供給開發人員，進而貢獻給 Apache 專案。此外，使用者透過在郵件列表和使用者支援論壇協助其他使用者，參與 Apache 社群。

• 貢獻者

  所有為 Hadoop 專案貢獻時間、程式碼、文件或資源的志工。對專案做出持續且受歡迎的貢獻的貢獻者可能會被邀請成為提交者，不過此類邀請的確切時機取決於許多因素。

• 提交者

  專案的提交者負責專案的技術管理。提交者可以存取所有子專案的 Subversion 儲存庫。提交者可以對任何子專案的任何技術討論進行具有約束力的投票。

  提交者存取權僅限於受邀者，且必須獲得活躍 PMC 成員的共識核准。提交者會自行宣告或在六個月以上未以任何形式對專案做出貢獻時，即被視為榮譽提交者。榮譽提交者可以向 PMC 要求恢復提交存取權。此類恢復需經活躍 PMC 成員的共識核准。

  重大且普遍的功能通常會在儲存庫的推測分支中開發。在計畫進行期間，PMC 可以授予分支的持續貢獻者提交權限。分支提交者負責將其功能引導至活躍版本，且不會在專案中進行具有約束力的投票或否決。

  所有 Apache 提交者都必須在 Apache 軟體基金會備有已簽署的貢獻者授權合約 (CLA)。有一個提交者常見問答集，其中提供了更多有關提交者要求的詳細資訊

  對專案做出持續貢獻的提交者可能會被邀請成為 PMC 的成員。貢獻的形式不限於程式碼。它還可以包括程式碼檢閱、在郵件清單上協助使用者、文件、測試等。

• 發行管理員

  發行管理員 (RM) 是自願根據HowToRelease製作發行候選版本的提交者。RM 應在common-dev@清單上發布發行計畫，說明他們打算製作發行候選版本的來源分支，且必須在製作前至少一週發布。RM 負責針對發行候選版本的內容建立共識，以達成成功的產品發行投票。

• 專案管理委員會

  Apache Hadoop 的專案管理委員會 (PMC) 是由 Apache 董事會在 2008 年 1 月創建的，當時 Hadoop 移出 Lucene 並成為 Apache 的頂級專案。PMC 對董事會和 ASF 負責管理和監督 Apache Hadoop 程式碼庫。PMC 的責任包括

  • 決定什麼是 Apache Hadoop 專案的產品。特別是所有版本都必須經 PMC 核准
  • 維護專案的共用資源，包括程式碼庫儲存庫、郵件清單、網站。
  • 代表專案發言。
  • 解決專案產品的授權爭議
  • 提名新的 PMC 成員和提交者
  • 維護這些細則和其他專案指南

  PMC 會員資格僅限受邀請者，且必須經由現任 PMC 成員的共識核准。PMC 成員若自行宣告或超過六個月未對專案做出任何形式的貢獻，即視為「榮譽會員」。榮譽會員可以要求恢復 PMC 會員資格。此類恢復資格須經現任 PMC 成員的共識核准。

  PMC 主席由 ASF 董事會任命。主席是 Apache 軟體基金會的幹部（Apache Hadoop 副總裁），並對董事會負有管理 Hadoop PMC 範圍內專案的主要責任。主席每季向董事會報告 Hadoop 專案的發展狀況。

  PMC 主席每年輪調。當主席輪調或現任 PMC 主席辭職時，PMC 會投票推薦一位新主席，採用單一可轉移投票 (STV) 投票方式。有關詳情，請參閱 https://wiki.apache.org/general/BoardVoting。此決議必須經 Apache 董事會批准。

決策制定

在 Hadoop 專案中，不同類型的決策需要不同的核准形式。例如，上一節說明了幾項需要「共識核准」的決策。本節定義了投票執行方式、核准類型，以及哪種類型的決策需要哪種類型的核准。

• 投票

  有關專案的決策是由主要專案開發郵件清單 (general@hadoop.apache.org) 上的投票所做成。必要時，PMC 投票可以在私人的 Hadoop PMC 郵件清單上進行。投票會清楚地標示在主旨行，開頭為 [VOTE]。投票可能包含多個核准項目，且應清楚分開。投票是透過回覆投票郵件來進行。投票可能有四種形式

  • +1「是」、「同意」或「應執行此動作」。一般而言，此投票也表示投票者願意「讓事情發生」
  • +0 此投票表示願意讓所考慮的動作繼續進行。然而，投票者無法提供協助。
  • -0 此投票表示投票者通常不同意所建議的動作，但並未擔心到足以阻止此動作繼續進行。
  • -1 這是負面投票。對於需要共識的問題，此投票計為否決。所有否決都必須包含否決適當性的說明。沒有說明的否決無效。-1 票也可能適當地包含替代行動方案。

  鼓勵 Hadoop 專案中的所有參與者透過投票表達他們對特定行動的同意或反對。對於技術決策，只有活躍提交者的投票具有約束力。非約束性投票對於具有約束力投票的人來說仍然有用，以便了解 Hadoop 社群中對某項行動的看法。對於 PMC 決策，只有 PMC 成員的投票具有約束力。

  投票也可以應用於對 Hadoop 程式碼庫所做的變更。這些通常會在提交時發送的提交訊息中以否決 (-1) 的形式出現。

• 核准

  這些是可以尋求的核准類型。不同的行動需要不同類型的核准

  • 共識核准 - 共識核准需要 3 個約束性 +1 票且沒有約束性否決。
  • 懶惰共識 - 懶惰共識不需要 -1 票（「沉默表示同意」）。
  • 懶惰多數 - 懶惰多數投票需要 3 個約束性 +1 票，且約束性 +1 票比 -1 票多。
  • 懶惰 2/3 多數 - 懶惰 2/3 多數投票需要至少 3 票，且 +1 票比 -1 票多兩倍。

• 否決

  有效且具有約束力的否決無法被推翻。如果提出否決，則必須附上說明否決原因的有效理由。如果否決的有效性受到質疑，則任何具有約束力投票權的人都可以確認。這並不一定表示同意否決 - 僅表示否決有效。

  如果您不同意有效的否決，您必須遊說提出否決的人撤回他們的否決。如果否決未被撤回，則任何已被否決的行動都必須及時逆轉。

• 行動

  本節說明專案中執行的各種行動、該行動所需的對應核准，以及對該行動具有約束力投票權的人員。

  • 程式碼變更

    提交者對專案程式碼庫所做的變更並提交。這包括原始碼、文件、網站內容等。

    積極提交者的共識核准，但至少需要一個 +1。在第一個 +1 之後即可提交程式碼，除非程式碼變更代表從分支合併，這種情況需要三個 +1。

  • 產品版本

    當專案產品之一的版本準備就緒時，需要投票才能接受該版本作為專案的官方版本。

    PMC 積極成員的懶惰多數

  • 採用新程式碼庫

    當現有已發布產品的程式碼庫要替換為其他程式碼庫時。如果這樣的投票未獲得核准，現有的程式碼庫將持續使用。

    這也涵蓋在專案中建立新的子專案

    PMC 成員的懶惰 2/3 多數

  • 新分支提交者

    當分支提交者被提議加入 PMC 時

    PMC 積極成員的懶惰共識

  • 新提交者

    當新提交者被提議加入專案時

    PMC 積極成員的共識核准

  • 新 PMC 成員

    當提交者被提議加入 PMC 時

    PMC 積極成員的共識核准

  • 分支提交者移除

    當尋求移除提交權限或當分支合併到主線時

    PMC 積極成員的懶惰 2/3 多數

  • 提交者移除

    當尋求移除提交權限時。注意：PMC 主席也會將此類行為轉介給 ASF 董事會

    PMC 積極成員的懶惰 2/3 多數（如果 PMC 成員是問題提交者，則不包括在內）。

  • PMC 成員移除

    當尋求移除 PMC 成員時。注意：PMC 主席也會將此類行為轉介給 ASF 董事會。

    PMC 積極成員的懶惰 2/3 多數（不包括問題成員）

  • 修改章程

    修改此文件。

    PMC 積極成員的懶惰多數

• 投票時程

  投票開放 7 天，讓所有積極投票者有時間考慮投票。與程式碼變更相關的投票不受嚴格時間表約束，但應盡可能及時進行。

  • 產品版本 - 投票時程

    僅版本投票執行 5 天。所有其他投票都受上述 7 天時程約束。