Project Jupyter 之前的治理#
注意
在 2022 年 12 月之前，Project Jupyter 採用的是基於終身仁慈獨裁者 (BDFL) 和指導委員會的治理模式，具體如本文件所述。
此文件的正式版本，以及下文治理部分定義的角色中的個人和機構列表，包含在專案治理倉庫中：
專案#
Jupyter/IPython 專案（以下簡稱“本專案”）是一個隸屬於 501c3 NumFOCUS 基金會的開源軟體專案。本專案的目標是開發開源軟體，併為可復現、探索性和互動式計算部署開放的公共網站與服務。本專案開發的軟體在 BSD（或類似）開源許可下發布，其開發過程公開，並託管在公共 GitHub 倉庫中，分別位於 IPython GitHub 組織 和 Jupyter GitHub 組織 下。專案軟體的例子包括 IPython Notebook、IPython Terminal、IPython.parallel、Jupyter Hub 等。本專案執行的服務包括託管在 jupyter.org 或 ipython.org 域名下的公共網站和網路服務。專案服務的例子包括 Jupyter 和 IPython 網站（https://jupyter.tw 和 https://ipython.org）、nbviewer（https://nbviewer.ipython.org）以及 Jupyter coLaboratory（https://colaboratory.jupyter.org）。
本專案由一個分散式開發者團隊開發，他們被稱為貢獻者。貢獻者是為專案的一個或多個倉庫貢獻了程式碼、文件、設計或其他工作的個人。任何人都可以成為貢獻者。貢獻者可以隸屬於任何法律實體，也可以不隸屬於任何實體。貢獻者透過提交、審查和討論 GitHub 的拉取請求 (Pull Requests) 和問題 (Issues)，以及參與 GitHub、Google+、Hackpad、Gitter 聊天室和郵件列表上開放和公開的專案討論來參與專案。專案參與的基礎是開放和透明。
以下是當前 IPython 主倉庫的貢獻者列表：
Jupyter 和 IPython 專案的其他倉庫日誌中也列出了許多其他貢獻者。
專案社群由專案的所有貢獻者和使用者組成。貢獻者代表更廣泛的專案社群工作並對其負責，我們努力將貢獻者和使用者之間的壁壘降到最低。
本專案正式隸屬於 501c3 NumFOCUS 基金會（https://numfocus.org），該基金會作為其財政贊助方，可以持有專案商標和其他智慧財產權，幫助管理專案捐贈，並作為上級法律實體。NumFOCUS 是唯一與專案有正式關係的法律實體（參見下文的機構合作伙伴部分）。
治理#
本節描述了本專案的治理和領導模式。
專案治理的基礎是：
開放與透明
積極貢獻
機構中立
傳統上，專案領導由一位終身仁慈獨裁者 (BDFL, Fernando Perez) 和一部分被稱為核心開發者的貢獻者提供。這些核心開發者因其積極且持續的貢獻而被授予對專案 GitHub 倉庫的“提交許可權”。通常，所有專案決策都透過核心開發者之間的共識，並徵求社群的意見來做出。BDFL 可以（但很少選擇）否決核心開發者的決定並就某事項做出最終決定。
雖然這種方法一直很有效，但隨著專案的發展，面臨更多的法律和財務決策，以及與其他機構的互動，我們認為需要一個更正式的治理模式。未來，專案領導層將由一位 BDFL 和一個指導委員會組成。我們將此治理模式視為對我們已在做的事情的正式化，而不是方向上的改變。
終身仁慈獨裁者 (BDFL)#
本專案將有一位終身仁慈獨裁者（BDFL, Benevolent Dictator for Life），目前是 Fernando Perez。作為“獨裁者”，BDFL 有權為本專案做出所有最終決定。作為“仁慈的”獨裁者，BDFL 在實踐中選擇將該權力下放給社群討論渠道和指導委員會（見下文）的共識。我們期望並且過去的情況也表明，BDFL 很少會行使其最終決定權。由於很少使用，我們將 BDFL 的最終決定權稱為“特殊”或“否決”投票。當 BDFL 行使否決權時，通常發生在指導委員會陷入僵局，或者指導委員會請求 BDFL 就特定事項做出決定的情況下。為確保 BDFL 的仁慈性，本專案鼓勵持不同意見者在該 BDFL 所採取的整體方向上建立分支 (fork)。BDFL 是指導委員會（見下文）的主席，並可酌情將其在特定決策或一系列決策上的權力委託給任何其他委員會成員。
BDFL 可以指定其繼任者，但期望在做出此決定時會諮詢指導委員會。如果 BDFL 無法指定繼任者，指導委員會將向 NumFOCUS 主理事會提出一個或多個建議。雖然指導委員會和 NumFOCUS 主理事會將在 BDFL 的選舉過程中密切合作，但最終決定將由 NumFOCUS 主理事會做出。
指導委員會#
本專案將設立一個指導委員會，由那些在質量和數量上做出了重大貢獻，且持續貢獻至少一年的專案貢獻者組成。委員會的總體職責是透過與 BDFL 合作並聽取社群意見，確保專案在技術上和社群層面上的長期健康發展。
在專案的日常活動中，委員會成員與所有其他貢獻者和社群成員一樣，以平等的身份參與所有討論、程式碼審查和其他專案活動。在這些日常活動中，委員會成員不因其委員會成員身份而擁有任何特殊權力或特權。然而，由於他們貢獻的質量和數量，以及他們對專案軟體和服務的專業知識，我們期望委員會成員能為可能經驗較少的貢獻者提供有益的指導，無論是在技術上還是在專案方向上。
指導委員會及其成員在某些情況下扮演特殊角色。特別是，委員會可以：
就專案的總體範圍、願景和方向做出決策。
就與其他組織或個人的戰略合作做出決策。
就具體的技術問題、功能、錯誤和拉取請求做出決策。他們是指導程式碼審查過程和合並拉取請求的主要機制。
就本專案執行的服務做出決策，併為專案和社群的利益管理這些服務。
當常規的社群討論在合理時間內未能就某個問題達成共識時做出決策。
委員會成員資格#
要獲得成為指導委員會成員的資格，個人必須是專案貢獻者，其貢獻在質量和數量上都必須是重大的，並且持續至少一年。潛在的委員會成員由現任委員會成員提名，並由現任委員會投票決定。根據成功的投票結果，新當選的成員將被邀請擔任該職位。委員會最初將由截至 2014 年底在過去一年中非常活躍的現有核心開發者組成。
在考慮潛在成員時，委員會將全面審視候選人的貢獻。這包括但不限於程式碼、程式碼審查、基礎設施工作、郵件列表和聊天參與、社群幫助/建設、教育和推廣、設計工作等。我們刻意不設定任意的量化指標（如“在此倉庫中有 100 次提交”），以避免鼓勵那些為了迎合指標而非專案整體福祉的行為。我們希望鼓勵團隊中擁有多樣化的背景、觀點和才能，這就是為什麼我們明確規定程式碼不是評估委員會成員資格的唯一標準。
如果一名委員會成員在專案中連續一年不活躍，他們將被考慮從委員會中除名。在除名前，BDFL 會聯絡不活躍的成員，詢問他們是否計劃恢復積極參與。如果他們不打算恢復，經過委員會投票後將立即被除名。如果他們計劃很快恢復積極參與，將給予一年的寬限期。如果他們在該期限內沒有恢復積極參與，將透過委員會投票除名，不再有寬限期。所有前委員會成員將來隨時都可以像其他任何專案貢獻者一樣被再次考慮成為成員。退休的委員會成員將在專案網站上列出，以表彰他們在委員會活躍的時期。
如果現任成員（BDFL 除外）被認為對專案的福祉造成積極損害，並且溝通和衝突解決的嘗試失敗，委員會有權將其驅逐。
利益衝突#
我們預計 BDFL 和委員會成員將在各種公司、大學和非營利組織中任職。因此，成員可能會有利益衝突。此類利益衝突包括但不限於：
可能影響其在本專案工作的專案外的經濟利益，如投資、僱傭或承包工作。
接觸其僱主的專有資訊，這些資訊可能洩露到他們在專案中的工作中。
個人從專案資源中私下獲利，而專案沒有收益或遭受損失的情況。
包括 BDFL 在內的所有委員會成員，都應向委員會其他成員披露他們可能存在的任何利益衝突。在特定問題上有利益衝突的成員可以參與委員會關於該問題的討論，但必須迴避對該問題的投票。如果 BDFL 在特定決策中迴避，他們將為該決策指定一位臨時代替者。
委員會的私密通訊#
除非有特殊要求，所有委員會的討論和活動都將是公開的，並與專案貢獻者和社群合作進行。委員會將有一個私密郵件列表，該列表將謹慎使用，且僅在特定事項需要保密時使用。當需要私密通訊和決策時，委員會將盡力在刪除不應公開發布到網際網路上的個人/私密/敏感資訊後，向社群總結這些內容。
小組委員會#
委員會可以建立小組委員會，為專案的特定方面提供領導和指導。與整個委員會一樣，小組委員會應以公開和透明的方式開展業務，除非有特殊的保密要求。小組委員會的私密通訊應在委員會的主要私密郵件列表上進行，除非有特殊要求。
問題：如果 BDFL 不在某個小組委員會中，他們是否仍然擁有否決權？
建議：他們有否決權，但應指定一名代表在大多數時候扮演該角色，只有當委員會不同意該代表的決定且團隊內部無法達成解決方案時，才尋求 BDFL 的明確干預。這與 BDFL 為特定決策（或迴避情況）指定代表不同，後者是 BDFL 將其權力完全移交給他人。這更像是 Linus Torvalds 在其“副手”模型中使用的模式。
NumFOCUS 小組委員會#
委員會將維持一個職能範圍狹窄的小組委員會，以管理其與 NumFOCUS 的互動。
NumFOCUS 小組委員會由 5 人組成，負責管理透過 NumFOCUS 獲得的專案資金。預計這些資金的使用方式將符合 NumFOCUS 的非營利使命以及由全體委員會決定的專案方向。
該小組委員會不得就專案的方向、範圍或技術方向做出決策。
該小組委員會將有 5 名成員，其中 4 名為現任委員會成員，1 名為指導委員會外部人員。小組委員會成員中，向同一個人彙報工作（透過僱傭或承包關係）的人數不得超過 2 人（包括彙報物件本人，即彙報物件 + 1 人是上限）。這可以避免有效多數票掌握在一人手中的情況。
機構合作伙伴與資金#
BDFL 和指導委員會是專案的主要領導層。沒有任何外部機構、個人或法律實體有能力擁有、控制、篡奪或影響專案，除非透過作為貢獻者和委員會成員參與專案。然而，由於機構是專案的主要資金來源，正式承認機構在專案中的參與非常重要。這些機構就是機構合作伙伴。
機構貢獻者是指任何作為機構合作伙伴官方職責一部分為專案做出貢獻的個人專案貢獻者。同樣，機構委員會成員是指任何作為機構合作伙伴官方職責一部分為專案做出貢獻的專案指導委員會成員。
根據這些定義，機構合作伙伴是指在美國或其他地方任何僱傭了至少一名機構貢獻者或機構委員會成員的受承認的法律實體。機構合作伙伴可以是營利性或非營利性實體。
機構透過僱傭作為其官方職責一部分積極為本專案做出貢獻的個人，從而有資格成為機構合作伙伴。換句話說，機構合作伙伴影響專案的唯一方式是，在與社群其他貢獻者和委員會成員平等的條件下，積極參與專案的開放式開發。僅僅在機構環境中使用 Jupyter/IPython 軟體或服務並不能使一個實體成為機構合作伙伴。財務捐贈也不能使一個實體成為機構合作伙伴。一旦一個機構有資格成為機構合作伙伴，指導委員會必須提名並批准該合作關係。
如果一個現有的機構合作伙伴不再有貢獻的員工，他們將獲得一年的寬限期，以便其他員工開始做出貢獻。
機構合作伙伴可以透過任何合法途徑為其在本專案上的工作尋求資金。這可能涉及非營利組織向私人基金會和捐贈者籌款，或營利性公司利用專案軟體和服務構建專有產品和服務。機構合作伙伴為參與本專案而獲得的資金稱為機構資金。然而，機構合作伙伴獲得的任何資金都不能凌駕於專案 BDFL 和指導委員會之上。如果一個合作伙伴有資金進行 Jupyter/IPython 相關工作，而委員會決定不將該工作作為專案的一部分，該合作伙伴可以自行開展。但在這種情況下，該合作伙伴的工作部分將不屬於 Jupyter/IPython 的範疇，也不能以暗示存在正式關係的方式使用專案商標。
為了表彰機構的貢獻，機構合作伙伴分為兩個級別，並享有相關權益：
第一梯隊 = 擁有至少一名機構委員會成員的機構
在 Jupyter/IPython 網站、演講和 T 恤衫上予以鳴謝。
能夠在 Jupyter/IPython 網站、演講和 T 恤衫上鳴謝其自身的資金來源。
可以無限制地參加在（計劃的）年度 Jupyter 專案務虛會期間舉行的年度機構合作伙伴研討會。這允許機構合作伙伴邀請任意數量的自家員工、資金來源方和合作者，即使他們不是專案貢獻者或委員會成員。
能夠透過其委員會成員的參與來影響專案。
委員會成員受邀參加半年一次的 Jupyter/IPython 開發者會議。
第二梯隊 = 擁有至少一名機構貢獻者的機構
享有與第一梯隊合作伙伴相同的權益，但是：
只有機構貢獻者受邀參加機構合作伙伴研討會和半年一次的 Jupyter/IPython 開發者會議。
更改治理檔案#
對治理檔案的更改透過向本專案的治理檔案 GitHub 倉庫 jupyter/governance 提交 GitHub 拉取請求 (pull request) 來進行。該過程分為兩個階段：
討論階段 從提交者首次開啟拉取請求時開始。在此期間，拉取請求必須處於草稿狀態。拉取請求會根據公眾的評論和審查進行完善，目標是在社群中達成共識。
當拉取請求的作者認為已經獲得了足夠的反饋和迭代時，可以發起投票。這透過將拉取請求從草稿狀態轉為活躍狀態來觸發。此操作將啟動投票階段。
投票階段 從拉取請求進入活躍狀態時開始。拉取請求中提議的更改將被凍結，在投票開始後不得進行實質性修改。在投票階段，指導委員會投票決定是批准更改併合並拉取請求（接受提議的更改），還是關閉拉取請求而不合並（拒絕提議的更改）。
所有投票的期限為投票階段開始後的 4 周。在 4 周結束時，如果 2/3 的票數表示贊成（票數的小數部分向上取整），則提案透過；否則提案被拒絕，拉取請求被關閉。在 4 週期限之前，如果至少 80% 的指導委員會成員已投票，且 2/3 的票數表示贊成（票數的小數部分向上取整），則提案透過。由於 BDFL 在本專案中擁有最終決定權，BDFL 有權單獨行動，接受或拒絕更改，或否決指導委員會的決定。