這是細則的版本 1。
本文件定義 Apache ZooKeeper 專案運作的細則。它定義專案的角色和責任、誰可以投票、投票方式、如何解決衝突等。
ZooKeeper 是 Apache 軟體基金會 的一個專案。基金會擁有 Apache 程式碼的著作權，包括 ZooKeeper 程式碼庫中的程式碼。基金會常見問答集 說明基金會的運作和背景。
ZooKeeper 是 Apache 專案的典型範例，它在稱為 Apache Way 的一組原則下運作。如果您是 Apache 開發的新手，請參閱 孵化器專案，以進一步了解 Apache 專案的運作方式。
Apache 專案定義一組具有相關權利和責任的角色。這些角色管理個人可以在專案中執行的任務。角色定義在以下各節中。
專案中最重要的參與者是使用我們軟體的人。我們的大部分貢獻者一開始都是使用者，並從使用者的角度指導他們的開發工作。
使用者透過提供意見回饋給貢獻者（例如錯誤報告和功能建議）的方式，來對 Apache 專案做出貢獻。此外，使用者也會在郵件清單和使用者支援論壇上協助其他使用者，進而參與 Apache 社群。
所有自願提供時間、程式碼、文件或資源給 ZooKeeper 專案的志工。持續且受到歡迎的貢獻者可能會受邀成為提交者，但此類邀請的確切時機取決於許多因素。
專案的提交者負責專案的技術管理。提交者可以存取指定子專案的存放庫。子專案的提交者可以對任何與該子專案相關的技術討論進行有約束力的投票。
提交者存取權僅限受邀請者，且必須獲得 PMC 現任成員的懶人共識批准。提交者如果自行宣告或超過六個月未審查或提交專案的程式碼變更，則會被視為榮譽提交者。榮譽提交者可以向 PMC 要求恢復提交存取權，但必須獲得 PMC 現任成員的懶人共識批准。
所有 PMC 現任成員（除了有問題的提交者本人，如果他或她也是 PMC 成員）可以一致投票撤銷提交存取權。
所有 Apache 提交者都必須向 Apache 軟體基金會提交已簽署的貢獻者授權合約 (CLA)。有一個提交者常見問答集，其中提供更多有關提交者需求的詳細資訊。
持續對專案做出貢獻的提交者可能會受邀成為 PMC 成員。貢獻的形式不限於程式碼。它也可以包括程式碼審查、在郵件清單上協助使用者、文件等。
PMC 對董事會和 ASF 負責管理和監督 Apache ZooKeeper 程式碼庫。PMC 的職責包括
PMC 的成員資格可以由所有活躍 PMC 成員（不含問題成員）一致投票撤銷。
PMC 主席由 ASF 董事會任命。主席是 Apache 軟體基金會的職務持有者（Apache ZooKeeper 副總裁），並對董事會負有管理 ZooKeeper PMC 範圍內專案的主要責任。主席每季向董事會報告 ZooKeeper 專案的發展狀況。
當現任 PMC 主席辭職時，PMC 會投票推薦一位新主席，並採用懶人共識，但此決定必須獲得 Apache 董事會批准。
在 ZooKeeper 專案中，不同類型的決策需要不同的核准形式。例如，前一節描述了需要「懶人共識」核准的幾項決策。本節定義投票執行方式、核准類型，以及哪些類型的決策需要哪種類型的核准。
有關專案的決策是透過主要專案開發郵件清單 dev@zookeeper.apache.org 上的投票進行。必要時，PMC 投票可以在私人 ZooKeeper PMC 郵件清單 private@zookeeper.apache.org 上進行。投票會清楚地標示在主旨行，開頭為 [VOTE]。投票可能包含多個核准項目，且應清楚分開。投票是透過回覆投票郵件進行。投票可以有四種形式。
| 投票 | 意義 |
|---|---|
| +1 | 「是」、「同意」或「應執行此動作」。一般而言，此投票也表示投票者願意「促成此事」。 |
| +0 | 此投票表示願意讓正在考慮的動作繼續進行。然而，投票者無法提供協助。 |
| -0 | 此投票表示投票者通常不同意提議的動作，但並未反對到足以阻止動作繼續進行。 |
| -1 | 這是否定投票。在需要共識的問題上，此投票算作否決。所有否決都必須包含否決適當的理由。沒有說明的否決無效。-1 投票也可以適當地包含替代方案。 |
鼓勵 ZooKeeper 專案的所有參與者透過投票表達他們是否同意特定動作。對於技術決策，只有活躍提交者的投票具有約束力。非約束性投票對於具有約束力投票的人來說仍然有用，因為他們可以了解 ZooKeeper 社群對某項動作的看法。對於 PMC 決策，只有 PMC 成員的投票具有約束力。
投票也可以應用於已對 ZooKeeper 程式碼庫所做的變更。這些通常會在提交時傳送的提交訊息中，以否決票 (-1) 的形式呈現。請注意，這應該很少發生。在提交程式碼之前，應盡一切努力討論問題，當它們仍為修補程式時。
有幾種可以尋求的核准類型。不同的動作需要不同類型的核准。
| 核准類型 | 定義 |
|---|---|
| 共識 | 要通過此項，所有具有約束力投票的投票者都必須投票，且不得有任何約束力否決票 (-1)。由於要讓所有符合資格的投票者都投票並不切實際，因此很少需要共識投票。 |
| 懶惰共識 | 懶惰共識需要 3 個約束力 +1 票，且沒有約束力否決票。 |
| 懶惰多數 | 懶惰多數投票需要 3 個約束力 +1 票，且約束力 +1 票多於 -1 票。 |
| 懶惰核准 | 具有懶惰核准的動作在未收到 -1 票的情況下會被默許，此時，依據動作類型，必須取得懶惰多數或懶惰共識核准。 |
| 2/3 多數 | 某些動作需要 2/3 的活躍提交者或 PMC 成員通過。此類動作通常會影響專案的基礎（例如，採用新的程式碼庫來取代現有產品）。較高的門檻旨在確保此類變更獲得強力的支持。要通過此投票，需要至少 2/3 的約束力投票持有者投票 +1。 |
有效的約束力否決票無法被推翻。如果投下否決票，則必須附上有效的理由說明否決的原因。如果否決票的有效性受到質疑，則任何具有約束力投票的人都可確認其有效性。這並不一定表示同意否決票，僅表示否決票有效。
如果您不同意有效的否決票，您必須遊說投下否決票的人撤回其否決票。如果否決票未被撤回，則必須及時撤銷已否決的動作。
本節說明專案中執行的各種動作、該動作所需的對應核准，以及對該動作具有約束力投票權的人。它還指定投票必須保持開放的最短時間，以營業日為單位。一般而言，不應在已知專案的相關成員無法參與時發起投票。
| 動作 | 說明 | 核准 | 具約束力票數 | 最小長度（天數） |
|---|---|---|---|---|
| 程式碼變更 | 對專案程式碼庫所做的變更，並由提交者提交。這包括原始碼、文件、網站內容等。 | 懶散核准（不計算貢獻者的票數），如果收到 -1，則轉為懶散多數 | 活躍提交者 | 1 |
| 發行計畫 | 定義發行時間表和動作。計畫也會提名一位發行經理。 | 懶散多數 | 活躍提交者 | 3 |
| 產品發行 | 當專案產品之一的發行準備就緒時，需要投票接受發行作為專案的正式發行。 | 懶惰多數 | 活躍 PMC 成員 | 3 |
| 採用新程式碼庫 | 當現有已發佈產品的程式碼庫要替換為替代程式碼庫時。如果此類投票未獲得核准，現有的程式碼庫將繼續使用。這也涵蓋在專案中建立新的子專案。 | 2/3 多數 | 活躍 PMC 成員 | 6 |
| 新提交者或恢復職位 | 當為專案提議一位新提交者時。 | 懶散共識 | 活躍 PMC 成員 | 3 |
| 新 PMC 成員或恢復職位 | 當一位提交者被提議加入 PMC 時。 | 懶散共識 | 活躍 PMC 成員 | 3 |
| 提交者移除 | 當尋求移除提交權限時。注意：此類動作也會由 PMC 主席轉介至 ASF 董事會。 | 共識 | 活躍 PMC 成員（如果 PMC 成員是問題提交者，則排除在外）。 | 6 |
| PMC 成員移除 | 當尋求移除 PMC 成員時。注意：此類動作也會由 PMC 主席轉介至 ASF 董事會。 | 共識 | 活躍 PMC 成員（排除有問題的成員）。 | 6 |
| 修改章程 | 修改此文件。 | 2/3 多數 | 活躍 PMC 成員 | 6 |