Scikit-learn 管理與決策#

本文件的目的是正式化 scikit-learn 專案所使用的管理流程，闡明如何做出決策以及我們社群的各個組成部分如何互動。本文件建立了一個決策結構，該結構考慮了社群所有成員的回饋，並努力尋求共識，同時避免任何僵局。

這是一個任人唯賢、基於共識的社群專案。任何對專案有興趣的人都可以加入社群、為專案設計做出貢獻並參與決策過程。本文件描述了如何參與以及如何在專案社群中獲得價值。

角色與職責#

我們區分了貢獻者、核心貢獻者和技術委員會。它們之間的一個關鍵區別是投票權：貢獻者沒有投票權，而其他兩個群體都擁有投票權，以及與其角色相關的工具的權限。

貢獻者#

貢獻者是社群成員，他們以具體的方式為專案做出貢獻。任何人都可以成為貢獻者，貢獻可以採取多種形式——不僅僅是程式碼——如 貢獻者指南 中詳述。沒有成為貢獻者的流程：一旦有人以任何方式為專案做出貢獻，他們就是貢獻者。

核心貢獻者#

所有核心貢獻者成員都擁有相同的投票權，並且有權提名新成員擔任以下列出的任何角色。他們的成員資格表示為 scikit-learn GitHub 組織的組織成員。

他們也歡迎加入我們的 每月核心貢獻者會議。

新成員可以由任何現有成員提名。一旦被提名，現有的核心貢獻者將進行投票。對新成員的投票是專案私人郵件清單上進行的少數活動之一。雖然預期大多數投票將是一致通過的，但獲得三分之二的多數票就足夠了。投票需要開放至少 1 週。

在過去 12 個月中，沒有為專案做出貢獻的核心貢獻者，將被詢問是否願意成為榮譽退休成員並放棄他們的權利，直到他們再次活躍。成員列表（包括活躍和榮譽退休成員，以及他們開始活躍的日期）在 scikit-learn 網站上公開。發送此類年度提醒電子郵件是活躍核心貢獻者的責任。

以下團隊組成了核心貢獻者群體

  • 貢獻者體驗團隊 貢獻者體驗團隊透過協助對問題和拉取請求進行分類，以及注意人們可能遇到困難的任何重複模式，來改善貢獻者的體驗，並協助改善專案的這些方面。

    為此，他們在 GitHub 上擁有必要的權限來標記和關閉問題。他們的工作對於改善專案中的溝通和限制問題追蹤器的擁擠至關重要。

  • 溝通團隊 溝通團隊的成員協助 scikit-learn 的推廣和溝通。該團隊的目標是發展大眾對 scikit-learn、其功能和使用以及品牌的認識。

    為此，他們可以在各種社群網路上操作 scikit-learn 帳戶並製作材料。他們也擁有我們部落格儲存庫和其他相關帳戶和平台的必要權限。

  • 文件團隊 文件團隊的成員參與專案的文件編寫。他們也可能參與專案的其他方面，但他們對文件貢獻的審查被認為是權威性的，並且可以合併此類貢獻。

    為此，他們擁有在 scikit-learn 儲存庫中合併拉取請求的權限。

  • 維護者團隊 維護者是社群成員，他們透過持續參與社群，表明他們致力於專案的持續開發。他們已經表明他們可以被信任，以謹慎的態度維護 scikit-learn。作為維護者，貢獻者可以更輕鬆地進行與專案相關的活動，因為他們可以直接存取專案的儲存庫。維護者應審查程式碼貢獻、合併已批准的拉取請求、投票贊成和反對合併拉取請求，並參與決定 API 的重大變更。

技術委員會#

技術委員會 (TC) 成員是具有額外責任的維護者，以確保專案順利運作。TC 成員應參與策略規劃，並批准對治理模型的變更。TC 的目的是確保從大局的角度順利進展。確實，影響整個專案的變更需要綜合分析和明確且知情的共識。如果核心貢獻者社群（包括 TC 成員）在要求的時間範圍內未能達成此類共識，則 TC 是解決問題的實體。TC 成員資格由核心貢獻者提名。提名將導致討論，討論時間不得超過一個月，然後由核心貢獻者投票，投票將開放一週。TC 成員資格投票需獲得所有投票的三分之二多數票以及所有現任 TC 成員的簡單多數票批准。不積極參與 TC 職責的 TC 成員應辭職。

scikit-learn 的技術委員會由 Thomas Fan、Alexandre Gramfort、Olivier Grisel、Adrin Jalali、Andreas Müller、Joel Nothman 和 Gaël Varoquaux 組成。

決策過程#

關於專案未來的決策是透過與社群所有成員的討論來做出的。所有非敏感的專案管理討論都在專案貢獻者的 郵件清單和 問題追蹤器上進行。偶爾，敏感的討論會在私人清單上進行。

Scikit-learn 使用「尋求共識」的流程來制定決策。該小組試圖找到一個在核心貢獻者中沒有公開反對意見的解決方案。在討論過程中的任何時間點，任何核心貢獻者都可以要求投票，投票將在要求投票後一個月結束。大多數投票必須得到 SLEP 的支持。如果沒有任何選項可以收集到三分之二的投票，則決策將升級到 TC，TC 又將使用尋求共識的方式，如果在一個月內無法達成共識，則採用簡單多數票的備案選項。這就是我們之後可能稱之為「決策過程」的內容。

決策（除了如上所述新增核心貢獻者和 TC 成員之外）是根據以下規則做出的

  • 次要文件變更，例如錯字修復，或新增/更正句子，但沒有變更 scikit-learn.org 首頁或「關於」頁面：需要維護者 +1，沒有維護者 -1（惰性共識），在問題或拉取請求頁面上進行。如果維護者不確定其他人會同意，則應給予其他人「合理的時間」來對拉取請求發表意見。

  • 程式碼變更和主要文件變更 需要兩位維護者 +1，沒有維護者 -1（惰性共識），在問題或拉取請求頁面上進行。

  • API 原則的變更以及相依性或支援版本的變更 是透過 增強提案 (SLEP) 進行的，並遵循上述決策過程。

  • 治理模型的變更 遵循 SLEP020 中概述的流程。

如果對惰性共識投下否決 -1 票，提案者可以向社群和維護者提出申訴，並且可以使用上述決策程序批准或拒絕變更。

治理模型變更#

治理模型變更透過增強提案或 GitHub 拉取請求進行。增強提案將經歷上一節中描述的「決策過程」。或者，作者可以使用 GitHub 拉取請求直接向治理模型提出變更。在後勤方面，作者可以開啟草稿拉取請求以取得回饋，並透過新的修訂拉取請求進行投票。一旦作者對拉取請求的狀態感到滿意，他們就可以在公共郵件清單上要求投票。在為期一個月的投票期間，拉取請求不能變更。拉取請求批准將被視為正面投票，而「要求變更」審查將被視為負面投票。如果三分之二的投票為正面，則接受治理模型變更。

增強提案 (SLEP)#

對於所有投票，提案必須在投票前公開並經過討論。此類提案必須是一份整合的文件，以「Scikit-Learn 增強提案」（SLEP）的形式呈現，而非針對議題的冗長討論。SLEP 必須以 Pull Request 的形式提交至增強提案，並使用SLEP 範本。SLEP000 更詳細地描述了此流程。