新子專案流程#
本文件描述了新子專案在 Jupyter 組織內建立或從其他地方遷移至此的過程。有關 Jupyter 社群當前子專案的列表，請參閱子專案列表。
注意
在 jupyter-incubator 組織下進行孵化的流程已過時。其中可能包含指向已歸檔程式碼倉庫的連結，以及引用舊版 Jupyter 治理模型的措辭。我們計劃審查這些語言，並根據 Jupyter 新的運作結構進行更新。
在此期間，如有任何問題或提案，請在 Jupyter 軟體指導委員會團隊指南中提出 issue。
建立新子專案有兩種方式
-
例如，當一個現有子專案的貢獻者決定為相關但可分離的程式碼建立一個新的 Git 程式碼倉庫時
-
例如，當 github.com/jupyter-incubator 中一個專案的貢獻者提交一份提案，申請併入某個官方 Jupyter 組織，並獲得指導委員會的批准時
例如，當一個第三方專案的貢獻者提交一份吸納提案，並獲得指導委員會的批准時
請注意，github.com/jupyter-incubator 中的專案在滿足以下標準並透過本文件後面詳述的吸納流程之前，**不被**視為官方支援和維護的子專案。
官方子專案標準#
以下標準將用於評估子專案是否可以併入某個官方 Jupyter 組織。這些標準適用於任何子專案，無論其開發者是誰。子專案應：
擁有一個活躍的開發者社群，為未來發展提供可持續的模式。
擁有一個活躍的使用者社群。
採用可靠的軟體工程實踐，文件和測試託管在適當的技術平臺上（例如 Read The Docs 和 Travis）。
展現出持續的增長和發展。
能與其他官方子專案良好整合。
根據此處記錄的 Jupyter 治理和貢獻模型進行開發。
有明確定義的範圍。
使用適當的技術進行打包，如 pip、conda、npm、bower、docker 等。
作為一項通用準則，我們支援改進現有子專案，而不是將相互競爭的子專案吸納到本專案中。
評估子專案是否能成為官方子專案的最重要問題是：社群和指導委員會是否就我們將以官方身份開發和維護該子專案達成廣泛共識？
下面詳細介紹建立官方子專案的兩種途徑。
直接建立子專案#
在某些情況下，指導委員會成員可以立即在主要的 Jupyter 組織中建立新的官方子專案。當新子專案明顯屬於 Project Jupyter 現有範圍、活動和開發的一部分時，將使用此選項。
直接建立子專案的過程是精簡且非正式的：指導委員會成員應對子專案的建立達成共識，並將其建立的訊息通知主要的 Jupyter 郵件列表。
吸納現有的外部子專案#
在其他情況下，提議吸納的子專案可能已經在官方 Jupyter 組織之外作為開源軟體存在並開發了一段時間。本節描述了對這些現有外部子專案的吸納流程。此流程適用於在 jupyter-incubator GitHub 組織下孵化的子專案（見下文）、在其他 GitHub 組織下開發的子專案，或在其他公共場所作為開源軟體開發的子專案。
當一個子專案被吸納後，它將成為 Project Jupyter 官方支援和維護的一部分，並被遷移到本文件開頭提到的某個 GitHub 組織中。
吸納提案#
如果在某個 Jupyter 組織團隊內部能夠直接就採納達成共識，並且滿足上述標準，那麼專案可能會被立即採納。這種共識可以透過在該組織的 team-compass 程式碼倉庫中建立一個 Issue 來建立。如果需要更多討論，將使用以下更正式的提案流程：
子專案團隊應向 jupyter/enhancement-proposals 程式碼倉庫提交一個拉取請求（pull request），其中包含一份增強提案，建議將該子專案納入某個主要的 Jupyter 組織。該增強提案應說明該子專案如何滿足上述各項標準。
社群將使用該拉取請求討論吸納提案。
指導委員會（SC）將透過共識提出建議。
如果 SC 建議吸納，子專案隨後需提交一個拉取請求，將新專案新增到
jupyter/governance程式碼倉庫中的子專案列表中。[1]執行委員會隨後必須透過合併或拒絕該拉取請求來做出決定。
時間線： SC 應盡一切努力迅速做出決定。如果提案有積極的討論和反饋，應讓其繼續進行並聽取各方意見。但為避免因等待所有人投票而造成不必要的延誤，應遵循以下準則：
提案提出後，給予一週時間徵集潛在的反對意見（當然也歡迎明確表示同意）。如果沒有反對意見，則將沉默視為同意。
如果一個月過去後仍存在持續且活躍的分歧，這應被視為專案尚未準備好畢業的強烈訊號（如果認為有必要，仍可由 BDFL 做出接受的決定）。
指導委員會可能提出的建議包括：
整合到現有的官方子專案中。
吸納為新的官方子專案。
進一步進行內部或外部孵化（見下文），並附上團隊為未來吸納可以採取的步驟建議。
拒絕。如果指導委員會認為提議的子專案沒有進展或永遠不適合被吸納，將使用此選項。如果一個被拒絕的子專案一直在 jupyter-incubator GitHub 組織下孵化，其程式碼倉庫將在過渡期後從該組織中移除。
吸納#
當一個現有的外部子專案被吸納為新的官方子專案時，將採取以下步驟：
程式碼倉庫將被轉移到某個主要的 Jupyter GitHub 組織下。
將為該子專案建立一個 GitHub 團隊，該子專案團隊將擁有對其程式碼倉庫的讀/寫許可權。
團隊將向主要的 Jupyter 郵件列表傳送一封電子郵件，宣佈新子專案的訊息。
標準的 Project Jupyter 許可證檔案（維護在此治理程式碼倉庫中）將被新增到該程式碼倉庫。
各個檔案中的版權宣告應更新為我們的 Project Jupyter 許可證中描述的標準格式。
子專案的孵化#
孵化是指子專案最初在官方 Jupyter 組織之外進行開發的過程。對於具有以下特點的新子專案，建議進行孵化：
存在重大的未解決技術問題或不確定性，需要進行探索。
全新的方向、範圍或想法，尚未經過社群的審查。
已存在龐大的程式碼庫，但尚不清楚該子專案將如何與 Jupyter 的其餘部分整合。
孵化還使得更廣泛的社群能夠輕鬆區分出穩定的、官方支援和維護的子專案（在主要的 GitHub 組織中）與新興的、為未來納入而正在開發的子專案。
如果對於某個子專案是否適合孵化存在疑問，相關方應直接在主要的 Jupyter 郵件列表上發起討論，以獲取社群和指導委員會的反饋。
在 jupyter-incubator 組織中進行孵化#
如果一個子專案團隊從一開始就知道最終希望其子專案成為某個官方 Jupyter 組織的一部分，那麼它可以在 jupyter-incubator 組織中進行孵化。
在 jupyter-incubator 組織中進行孵化的目標如下：
貢獻者可以快速、輕鬆地將其程式碼展示給 Jupyter 社群，同時遵守個人和組織的貢獻限制。
貢獻者可以與社群和指導委員會合作，儘早並頻繁地收集反饋，這將有助於他們制定和完善一個清晰簡潔的整合提案。
讓社群能夠區分官方支援的子專案和社群成員進行的實驗性子專案。
孵化器專案的程式碼倉庫管理政策#
專案可能時常希望建立新的程式碼倉庫來探索各種想法。對此的基本政策如下：
如果專案名為
foo，它可以建立名為foo-X的新程式碼倉庫，而無需請求進一步授權。專案可以自行決定是否在更廣泛的 Jupyter 渠道上宣佈該倉庫，如果它認為有足夠的興趣（顯然這些倉庫仍然是公開的，並對所有人開放參與）。如果專案希望建立一個名為
bar的倉庫（這是一個其他人可能感興趣的頂級名稱），它應該在主要的 Jupyter 郵件列表上發帖。提案將進行討論，前提是，除非有人提出嚴重反對，否則這些請求將被儘快批准。
孵化提案#
子專案團隊可以透過提交孵化提案來啟動 jupyter-incubator 的孵化過程。這個過程設計得輕量而快捷：
提議者必須透過向 jupyter-incubator/proposals 程式碼倉庫提交拉取請求來填寫一份孵化申請。
提議者必須透過在主要的 Jupyter 郵件列表上發帖向社群宣佈其意圖。
提議的子專案必須有一位活躍的指導委員會成員作為倡導者。倡導者的角色是將子專案團隊介紹給 Jupyter 社群，並幫助他們完成孵化過程。倡導者可以參與子專案的實際開發和設計，但這不是必需的。
孵化提案將由社群討論，並由指導委員會的共識批准或拒絕。
如果獲得批准，提案的拉取請求將被合併。如果被拒絕，它將被關閉。
孵化期#
一旦一個子專案被批准在 jupyter-incubator 組織中孵化，將採取以下步驟：
將在 jupyter-incubator 組織下建立一個 GitHub 程式碼倉庫。
將建立一個 GitHub 團隊，擁有對該倉庫的讀/寫許可權，包括倡導者。
標準的 Jupyter 許可證檔案（維護在此治理程式碼倉庫中）將被新增到新的程式碼倉庫中。
指導委員會的一名成員將在主要的 Jupyter 郵件列表上宣佈新孵化的子專案。
孵化期的目標是證明該子專案將發展出一個活躍的開發者和使用者社群。孵化沒有特定的時間長度要求，但預計大多數子專案將在孵化期內停留至少六個月到一年。
外部孵化#
在 jupyter-incubator 組織之外進行孵化也是可能的。在這種情況下，沒有正式的流程。任何個人或組織都可以簡單地在自己的個人 GitHub（或其他版本控制系統）倉庫上建立一個新專案，並按自己的意願進行開發。如果這樣一個外部建立和孵化的子專案希望成為官方 Jupyter 組織的一部分，則必須滿足本文件開頭列出的標準，並遵循相同的吸納流程。