Debian 憲章歷史版本 v 1.7

Debian 項目憲章的歷史版本（v1.7）

1.7版本 批准於2016年08月14日。

被以下版本取代：1.8版本 批准於2022年01月28日 和當前的1.9版本 批准於2022年03月26日。

取代以下版本： 1.6版本 批准於2015年12月13日， 1.5版本 批准於2015年01月09日， 1.4版本 批准於2007年10月07日， 1.3版本 批准於2006年09月24日， 1.2版本 批准於2003年10月29日， 1.1版本 批准於2003年06月21日 和 1.0版本 批准於1998年12月02日。

1. 簡介

Debian 項目是一個由擁有共同理念的個人組成的協會， 其目的是創建一個自由的操作系統。

本文件描述了關於項目正式決策的組織結構。它沒有描述項目的目標或如何實現這些 目標，也沒有包含任何政策（與決策過程直接相關的政策除外）。

2. 決策機構與決策人

項目中的每個決策都是由以下一個或多個決策者做出的：

  1. 開發人員，透過一般性決議或選舉產生；
  2. 項目負責人；
  3. 技術委員會和/或其主席；
  4. 從事特定任務的開發人員；
  5. 項目負責人指定的具體任務負責人；
  6. 項目秘書。

本文件剩餘部分中的大部分將概述這些機構的權力、組成和任命及其決策程序。 個人或組織的權力可能會受到他人的審查和/或限制；審查機構和審查人的條目會 説明這一點。 在上述列表中，個人或團體通常列在他們可以否決其決定或他們（幫助） 任命的任何人或團體之前，但不是所有前面列出的人都可以否決後面的人。

2.1. 一般規則

  1. 本憲章未規定任何人有義務為項目工作。不想做被委派或分配給他們的 任務的人可以不去做。 但是，他們不能主動故意違反這些規則和根據這些規則做出的決定。

  2. 一個人可以擔任多個職位，但項目負責人、項目秘書和技術委員會主席 必須是不同的，且負責人不能委派自己做自己的代表。

  3. 任何人可以隨時透過公開聲明離開項目或辭去其所擔任的特定職位。

3. 個人開發人員

3.1. 權力

個人開發人員 可以：

  1. 對自己的工作作出技術性或非技術性的決定；
  2. 提出議案或提出一般性決議草案；
  3. 在選舉中提名自己為項目負責人候選人；
  4. 就一般性決議和負責人選舉投票。

3.2. 組成和任命

  1. 開發人員是志願工作，他們自願參與項目工作、進一步實現項目目標， 並維護套件或做項目負責人代表認為有價值的其他工作。

  2. 項目負責人的代表可以選擇不招收新的開發人員，或者開除現有的開發人員。 如果開發人員認為代表在濫用其權力，他們可以透過一般性決議 推翻決定——見 §4.1(3)，§4.2 節。

3.3. 程序

開發人員可以在他們認為適當的時候做出這些決定。

4. 一般性決議或選舉選出的開發人員

4.1. 權力

同樣的，開發人員 可以：

  1. 任命或罷免項目負責人。

  2. 以超過四分之三的多數票修改憲章。

  3. 做出或推翻由項目負責人或代表授權的任何決定。

  4. 以超過三分之二的多數票做出或推翻技術委員會授權的任何決定。

  5. 發佈、更新和撤銷非技術性政策文件和聲明。

    這些文件包括描述項目目標、與其他自由軟件實體的關係以及非技術性政策 的文件，如 Debian 軟件必須滿足的自由軟件許可條款。

    它們還可能包括關於當天議題的立場聲明。

    1. 基礎文件即對項目任務和目的至關重要的文件或聲明。
    2. 基礎文件為： Debian 社羣契約 與 Debian 自由軟件指導方針。
    3. 基礎文件需要超過四分之三多數票才能更新。 透過修改本章程中的基礎文件清單， 以發佈新的基礎文件、撤銷現有基礎文件。

  6. 決定 Debian 相關信託資產的用途。（見 §9. 節）。

  7. 若項目負責人和現任秘書之間存在分歧，則任命一名新的秘書。

4.2. 程序

  1. 開發人員遵循以下標準決議程序。 若由任何開發人員提出並由至少 K 名其他開發人員附議/支持， 或者由項目負責人或技術委員會提出，則可提出決議或修正案。

  2. 推遲項目負責人或其代表的決定：

    1. 若項目負責人或其代表、或技術委員會已做出決定，則開發人員可透過 決議推翻這些決定；見 §4.1(3) 節。
    2. 若此決議是由至少 2K 個開發人員發起的，或者是由技術委員會提出的， 則該決議會立即擱置決定（前提是決議本身也如此要求）。
    3. 若最初的決定是改變討論期限或投票期限，或者決議是推翻技術委員會， 那麼只需有 K 個開發人員需要發起該決議，便能立即擱置該決定。
    4. 若決定被擱置，則需立即進行表決，以決定在對該決定進行全票表決前， 該決定是否繼續有效，或原決定的執行是否將推遲到那時。 本次即時程序性投票沒有法定人數要求。
    5. 若項目負責人（或其代表）撤回了最初的決定，則投票由於毫無意義 而不再進行。

  3. 投票由項目秘書負責。投票、計票和結果在投票期間不公佈； 投票結束後，項目秘書列出最終投票結果。 投票期限為 2 周，但可由項目負責人最多更改 1 周。

  4. 最短討論期限為 2 周，但可由項目負責人最多更改 1 周。 項目負責人有決定性的一票。法定人數為 3Q。

  5. 提案、附議、修正案、投票和其他正式行動都是透過項目負責人或代表指定 的公開可讀的通信論壇發佈通知。任何開發人員皆可在該列表上發表。

  6. 投票以秘書方便的方式透過電子郵件進行。 秘書決定每一次投票的投票者是否可以更改他們的投票。

  7. Q 是當前開發人員人數平方根的一半。K 在 Q 或 5 中取較小值。 Q 和 K 不必是整數且不捨入。

5. 項目負責人

5.1. 權力

項目負責人 可以：

  1. 任命代表或將決定委託給技術委員會。

    負責人可以確定一個持續的責任範圍或一個具體的決定， 並將其委託給另一個開發人員或技術委員會。

    一旦某項特定決定被授權並實行，項目負責人不得撤回該授權； 但是，他們可以撤回對特定責任領域的持續授權。

  2. 授權給其他開發人員

    項目負責人可在被要求或其他情況下，對觀點或為項目的其他成員發表 支持聲明； 當且僅當項目負責人有權做出相關決定時，這些聲明才具有效力。

  3. 做出任何需要緊急行動的決定。

    這不適用於由於缺乏相關行動而逐漸變得緊急的決定， 除非有固定的截止日期。

  4. 做出無人負責的決定。

  5. 提出一般性決議草案和修正案。

  6. 與技術委員會一起，任命新的委員會成員。（見 §6.2. 節）

  7. 在開發人員投票時使用決定性的一票。

    項目負責人在無記名投票中也有正常的投票權。

  8. 改變開發人員投票的討論期限（如前所述）。

  9. 引導開發人員進行討論。

    項目負責人應嘗試以一種有益的方式參與開發人員之間的討論， 以期將討論帶到手頭的關鍵問題上。 項目負責人不應利用領導職位來宣傳自己的個人觀點。

  10. 在與開發人員協商後，做出 Debian 相關信託資產用途的決策 （見 §9. 節）。此類決定由項目負責人或其代表傳達給成員。 在支付資金之前，應在通信論壇上提出並討論主要支出。

  11. 在受信組織（見 §9.3 節）列表中添加或刪除有權接受和持有 Debian 資產的組織。在項目負責人或其代表指定的通信論壇上進行評估和討論， 任何開發人員皆可該列表上發表。在將一個組織添加到受信組織列表之前， 至少有兩週的討論期。

5.2. 任命

  1. 項目負責人由開發人員選舉產生。
  2. 選舉在負責人職位空缺前六週開始，或者立即開始（如果已經遲了）。
  3. 在第一週，任何開發人員都可以提名自己為候選項目負責人， 並總結他們任期內的計劃。
  4. 此後三週內不再提名候選人；候選人應利用這段時間進行競選和討論。 如果提名期結束時沒有候選人，則提名期再延長一週，必要時可重複。
  5. 接下來的兩週是投票期，開發人員可以投票。 負責人選舉的投票是保密的，即使在選舉結束後亦然。
  6. 選票上的選項為那些已經提名且尚未退出的候選人，再加上一項以上皆不選。 如果以上所有人都沒有贏得選舉，則選舉程序將重複，必要時可多次進行。
  7. 使用 標準決議程序 第 §A.6 節規定的方法作出決定。 法定人數與一般決議（§4.2）相同，默認選項為以上皆不選。
  8. 項目負責人從他們當選起任期一年。

5.3. 程序

項目負責人應儘量做出與開發人員意見一致的決策。

在可行的情況下，項目負責人應非正式地徵求開發人員的意見。

項目負責人在以領導的身份做出決策時，應避免過分強調自己的觀點。

6. 技術委員會

6.1. 權力

技術委員會 可以：

  1. 決定任何技術政策問題：

    包括技術政策手冊的內容、開發人員的參考資料、示例套件和非實驗性包 構建工具的行為。（不過一般情況下，相關軟件或文件的常規維護者會 做出最初決定；見 6.3(5) 節）。

  2. 決定開發人員管轄權重疊的任何技術問題。

    在開發人員需要解決技術策略或立場衝突的情況下（例如，如果他們對： 衝突包的優先級、命令的歸屬問題、哪個包負責兩邊維護人員都發現的 缺陷、誰做維護者等有不同意見），技術委員會可決定該事項。

  3. 在被要求時做出決定。

    任何人或團體均可將其自己的決定委託給技術委員會做，或向其徵求意見。

  4. 否決開發人員（需要四分之三多數）

    技術委員會可在開發人員不願意的情況下要求其採取特定的技術措施， 但這需要四分之三多數票。 例如，委員會可以確定提交者對缺陷的投訴是合理的， 並且應該實施提交者提出的解決方案。

  5. 提供建議。

    技術委員會可正式宣佈其對任何事項的意見。 委員個人可就他們的意見和委員會可能的意見發表非正式聲明。

  6. 與項目負責人一起，任命委員會新成員或移除現有成員。（見 §6.2. 節）

  7. 任命技術委員會主席。

    主席由委員會從其成員中選出。委員會的所有成員都是自動提名的； 委員會在該職位空缺前一週投票（如已經太遲，則立即投票）。 委員會成員可以透過公開歡迎贊成方式投票給任何其他委員會成員， 包括他們自己；沒有默認選項。當所有成員投票或投票期限結束時，投票結束。 使用標準決議程序第 A.6 節規定的方法確定結果。

  8. 主席可與秘書一起代理負責人。

    如 §7.1(2) 節所述，若負責人缺位， 技術委員會主席和項目秘書可共同代理負責人。

6.2. 組成

  1. 技術委員會通常由 8 名開發人員組成，最少應由 4 人組成。

  2. 當成員少於8人時，技術委員會可向項目負責人推薦新成員， 項目負責人可選擇（部分）任命或不任命。

  3. 當委員人數不超過 5 人時，技術委員會可任命新委員， 直至委員人數達到 6 人。

  4. 當成員人數小於等於 5 名持續至少一週時，項目負責人可任命新成員， 直到成員數量達到6名，每次任命至少間隔一週。

  5. 如果開發人員在過去 12 個月內曾是技術委員會的成員，則他們不能（再次） 被任命為技術委員會成員。

  6. 如果技術委員會和項目負責人同意，他們可以撤換技術委員會的現有成員。

  7. 任期限制：

    1. 在每年的 1 月 1 日時，任職超過 42 個月（即 3.5 年）且是兩位 最高級委員中的一位的委員，其任期將於當年 12 月 31 日屆滿。

    2. 若技術委員會的一名成員被任命的更早，或者同時被任命但成為 Debian 項目成員的歷史更長，則該成員的級別要高於另一個成員。 若某成員被任命不止一次，則以最近一次的任命為準。

6.3. 程序

  1. 技術委員會採用標準決議程序。

    決議草案或修正案可由技術委員會的任何成員提出。 沒有最短討論期；投票期為一週，或直到結果無異議為止。 成員可以更改他們的投票。法定人數為兩人。

  2. 投票相關細節

    主席有決定性的一票。 當技術委員會投票決定是否推翻同時也是委員會成員的開發人員時， 該成員不得投票（除非他們是主席，此情況下他們只能投決定性的一票）。

  3. 公開討論和決策。

    討論、決議草案和修正案以及委員會成員的投票將在技術委員會 公開討論列表上公佈。 委員會不設單獨的秘書。

  4. 任命的保密。

    技術委員會可透過私人電子郵件、私人通信論壇或其他方式秘密討論委員會 的任命。但是，對任命的投票必須是公開的。

  5. 不參與細節設計工作。

    技術委員會不參與新提案和政策的設計。 此類設計工作應由個人單獨或共同進行， 並在一般的技術政策和設計論壇上討論。

    技術委員會僅限於在於其他地方提出並經合理徹底討論的解決方案和決定 之間作出選擇或採取折衷辦法。

    技術委員會的成員可以代表他們自己參與設計和政策工作的任何方面。

  6. 技術委員會做決定只作最後手段。

    技術委員會在試圖透過協商一致方式解決該問題的努力失敗之前， 不會作出技術性決定，除非通常負責該決定的人或機構要求它作出決定。

7. 項目秘書

7.1. 權力

秘書 可以：

  1. 按照憲章要求，在開發人員中舉行投票，並確定開發人員的人數和身份。

  2. 可以同技術委員會主席一起代替負責人。

    如果項目負責人缺位，則技術委員會主席與秘書可透過共同協商做出必要決定。

  3. 裁決有關憲章解釋的任何爭議。

  4. 可將其部分或全部權力委託給他人，或隨時撤回此類授權。

7.2. 任命

項目秘書由項目負責人和現任項目秘書任命。

如果項目負責人和現任項目秘書不能就新的任命達成一致，他們必須透過一般決議 要求開發人員任命一名秘書。

如果沒有項目秘書或現任秘書缺席，且沒有授權作出決定，則該決定可由技術委員會 主席作為代理秘書作出決定或委託。

項目秘書的任期為 1 年，到期必須對其（重新）任命或任命另一秘書。

7.3. 程序

項目秘書應做出公平合理的決定，最好與開發人員的共識一致。

當共同代理缺席的項目負責人時，技術委員會主席和項目秘書應僅在絕對必要的情況下 做出決定，且只有在與開發商的一致意見一致的情況下才能做出決定。

8. 項目負責人代表

8.1. 權力

項目負責人代表 可以：

  1. 有項目負責人授予的權力；
  2. 可能會做出某些負責人可能不會直接做出的決定，包括批准或開除開發人員 或指定不維護套件的開發人員。 這是為了避免權力集中，特別是決定開發人員資格的權力， 集中在項目負責人手中。

8.2. 任命

代表由項目負責人任命，可由項目負責人自行更換。 項目負責人不得以代表的特定決定作為代表職位的條件， 也不得在代表做出決定後凌駕於代表的決定之上。

8.3. 程序

代表可以在他們認為合適的情況下做出決定， 但應致力於實施良好的技術決策和/或遵循一致意見。

9. Debian 信託資產

在世界上大多數司法管轄區，Debian 項目無法直接持有資金或其他財產。 因此， 財產必須由 §9.2 節中記載的多個組織中的任何一個持有。

傳統上，SPI 是唯一授權持有 Debian 項目資產的機構。SPI 成立於美國， 目的是在那裏託管資金。

SPI 和 Debian 是兩個獨立的組織， 但有着共同的目標。Debian 感謝 SPI 提供的法律支持框架。

9.1. 與關聯組織的關係

  1. Debian 開發人員不會僅由於是 Debian 開發人員而成為 Debian 託管資產 的組織的代理人或僱員，或彼此的代理人或僱員，或 Debian 項目中的 權威人士的代理人或僱員。 作為開發人員的個人所做上述行為僅代表其自己。 這些組織可以自行與同時也是 Debian 開發者的個人建立關係。

9.2. 權利

  1. 為 Debian 持有資產的組織無權干涉 Debian 的技術性或非技術性決定， 同時 Debian 對該組織代持的任何財產的任何決定均不得要求其在其 法律權限之外行事。

  2. Debian 無權干涉為 Debian 持有資產的組織，除了對託管的 Debian 財產的 使用權。

9.3. 受信組織

對 Debian 項目的任何捐贈必須提供給項目負責人（或代表）指定的一批組織中的 任何一個，以授權其處理用於 Debian 項目的資產。

為 Debian 託管資產的組織應承擔處理此類資產的合理義務。

Debian 維護着一份為 Debian 接受捐贈並託管資產（包括有形財產和知識產權）的 受信組織的公開名單，其中包含了這些組織就如何處理這些資產所作的承諾。

A. 標準決議程序

這些規則適用於由上述委員會和成員投票的公共決策。

A.0. 提案

正式程序從按要求提出決議草案併成為提案時開始。

A.1. 討論與修正

  1. 提案提出後，可對決議進行討論。 根據新決議的要求，修正案可以根據新決議 的要求提出和支持，也可以由原決議的提出者直接提出。
  2. 正式修正案可被決議提出者接受，此情況下，正式決議草案立即照此更改。
  3. 如果正式修正案未獲接受，或該決議的支持者之一不同意提出者接受正式修正案， 則該修正案仍將作為修正案予以表決。
  4. 如果原提出者接受的修正案不符合其他人的喜好，他們可以提出另一項修正案 來推翻先前的變更（同樣，他們必須滿足提出者和支持者的要求）。
  5. 決議提出者可以建議修改修正案措辭；修正案提出者同意且提出者無異議的， 該等修改生效。此情況下，將對修改後的修正案進行表決。
  6. 決議提出者可以在 24 小時內對較小錯誤（例如，印刷錯誤或不一致）進行修正 或作不改變含義的更改，需無人在 24 小時內提出異議。 此情況下，最短討論期限不會重新計算。

A.2. 要求投票

  1. 動議或修正案的提出者或支持者可要求投票，前提是最短討論期（如有）已結束。
  2. 決議的提出者或任何支持者可要求對該決議及其所有相關修正案進行表決。
  3. 要求投票的人應陳述他們認為的決議和任何相關修正案的內容，以及投票應採取 的形式。 不過秘書擁有投票形式的最終決定權——見 7.1(1)，7.1(3) 和 A.3(4) 節。
  4. 最短討論期從最後一次正式修正案被接受時算起，或在沒有提出和接受修正案的 情況下自決議提出之日起計算。

A.3. 表決程序

  1. 每項決議及其相關修正案均以單次投票方式進行表決，其中包括原決議、 每項修正案和默認選項（如適用）。
  2. 默認選項不得有任何絕對多數票要求。 無明確絕對多數要求的選項遵循 二分之一多數要求。
  3. 根據 A.6 節中的規則計票。除非另有規定，默認選項為進一步討論。
  4. 如有疑問，項目秘書應決定程序事項。

A.4. 撤回決議或不被接受的修正案

決議或未獲接受的修正案的提出者得撤回之。 此情況下，一個新的提出者可繼續提出以延續它， 第一個這樣做的人將成為新的提出者，後續的人將成為成為支持者（若現在不是）。

決議或修正案（除非已被接受）的支持者可以撤回其決定。

如果提出者和/或支持者退出以致一項決議沒有提出者或支持者不足，則需在決議 到期前解決，否則將不予表決。

A.5. 到期

如果提出的決議在 4 周內未經討論、修正、表決或以其他方式處理，秘書可發佈聲明 説明該問題將被撤回。若一週內無其支持者反對，該議題將被撤回。

如有必要，秘書可就如何繼續進行提出建議。

A.6. 計票

  1. 每個投票者都需要對選票上的選項進行排序。 不必排序所有選項，但被排序的選項視為優先於所有未排序的選項。 投票者可將選項排成平級。未評級的選項被認為是平級的。 如何填寫選票的細節將包含在投票要求中。
  2. 如果投票要求法定人數 R，那麼除默認選項外的任何選項若未獲得至少 R 票， 則該選項高於默認選項時的排名將不予考慮。
  3. 任何選項（非默認）如未依要求的多數票比例勝過默認選項，則不予考慮。
    1. 給定兩個選項 A 和 B，V(A,B) 為選擇 A 項多過選擇 B 的投票者的人數。
    2. 若 V(A,D) 大於等於 N*V(D,A) 且 V(A,D) 嚴格大於 V(D,A)，則 選項 A 以多數比例 N 勝過默認選項 D。 譯註：多數比例 N 為 贊成/反對，不是 贊成/總數。
    3. 如果 A 需要 S:1 的絕對多數，那麼其多數比例為 S； 否則其多數比例為 1。
  4. 在未排除的選項中，生成一個一對一的選項勝負表。
    1. 如果 V(A,B) 嚴格大於 V(B,A) 則選項 A 勝過選項 B。
  5. 從未排除選項之間的勝負表中，產生傳遞勝敗集合。
    1. 若選項 A 勝過 C 或 A 勝過 B 而 B 傳遞勝過 C，則 A 傳遞勝過 C。
  6. 從傳遞勝敗集合中構造 Schwartz 集合。
    1. 對 Schwartz 集合中的任意 A、B 選項，要麼 A 傳遞勝過 B， 要麼 B 傳遞勝過 A。
  7. 若 Schwartz 集合中選項之間存在勝敗關係，則從一對一選項勝負表中刪除 最弱的勝敗關係對，然後回到步驟 5。
    1. 如果 V(A,X) 小於 V(B,Y)，則勝敗關係對 (A,X) 弱於勝敗關係對 (B,Y) 。 同樣地，如果 V(A,X) 等於 V(B,Y) 且 V(X,A) 大於 V(Y,B)， 則 (A,X) 弱於 (B,Y) 。
    2. 最弱的勝敗關係對指沒有比它更弱的勝敗關係。這可能不止一對。
  8. 若 Schwartz 集合中選項之間無勝敗關係，那麼則從 Schwartz 集合中選出 獲勝選項。 若只有一個這樣的選項，即是它。 若有多個選項，由投決定性一票的成員決定選擇哪個選項。

注意：排在默認選項之上的選項是投票者認為可以接受的選項， 排在默認選項之下的為其不可接受的選項。

當使用標準決議程序時，提及該程序的文本必須具體説明什麼足以使一項 決議草案得到提議和/或支持，最短討論期限是多長，以及投票期限是多長。 它還必須指定要使用的任何“絕對多數”和/或法定人數（以及默認選項）。

B. 措辭和行文

一般現在時（例如：是）意味着這項聲明是本憲章的一項規定。 能夠或可以表示表示個人或團體有自由裁量權。 應當意味着若遵守此條會被認為較好，但它並不具有約束力。 標記為引文的文本（如本段）用於解釋原因，不構成憲章的一部分。 在有疑義的情況下，只能用於輔助解釋。