跳到主要內容

治理

本文件概述管理 conda-forge 社群的政策和程序。本文件認知到，儘管套件對於我們所有人來說都非常重要，但 conda-forge 是一個完全由志願者組成的組織。核心成員、任何團隊成員或外部貢獻者都可以選擇參與，並且可以隨時因任何原因或無任何原因而選擇離開。我們深切感謝所有真誠的貢獻。

行為準則​

請參閱行為準則章節以取得更多資訊。

團隊與角色​

此處定義了參與 conda-forge 活動的主要團隊。

  • 核心團隊 (core): 核心團隊是 conda-forge 整個組織的管理機構。核心團隊成員對所有 conda-forge 儲存庫擁有完整權限。核心成員是專案的門面，負責正式地與外部社群、組織、非營利組織和公司接洽。核心團隊可以根據需要創建新的子團隊。每位核心成員在所有選舉事務中都享有一票投票權。
  • 暫存食譜 (staged-recipes): 暫存食譜團隊管理 staged-recipes 儲存庫，並負責審查和創建新的 feedstock。
  • 維護者 (maintainers): 維護者是負責管理一個或多個 feedstock 儲存庫和套件的個人。維護者有權將 pull request 合併到他們維護的套件的 feedstock 中。
  • 外部貢獻者 (external contributors): 這個群體包含所有不在核心團隊、暫存食譜團隊或維護者之列的其他人員。這包括首次貢獻者、協作者和資助者。他們在 conda-forge 組織本身內沒有特殊權利。
  • 榮譽核心成員 (emeritus-core): 在過去六個月內不活躍（提交、GitHub 評論/問題/審查、開發會議和民意調查投票）的核心成員將被詢問是否願意成為榮譽核心開發人員。任何核心成員也可以在他們願意這樣做時（例如，休假或長假）請求成為榮譽成員。榮譽核心成員仍然可以投票，並隨時恢復為活躍核心成員。榮譽投票用於計入法定人數，但法定人數的大小是根據活躍核心團隊的規模計算的。當成員的狀態發生變化時，應更新 core.csv 清單。

子團隊​

核心團隊可以選擇創建新的子團隊來管理組織的日常事務。雖然子團隊可能擁有非核心成員，但每個子團隊必須始終至少有一名核心團隊成員。如果子團隊超過 1 週沒有核心團隊成員，則該團隊將被視為解散。需要由核心團隊建立一個新的子團隊才能恢復活動。

子團隊的章程可以是動態或靜態。

  • 動態章程意味著子團隊在自己的內部政策、程序和成員資格方面是自我組織的。子團隊可以選擇獨立於核心團隊修改其成員資格。例如，「Google 程式碼夏令營」團隊可能是動態章程的良好候選者。或者，基於語言的維護團隊也具有動態章程。
  • 靜態章程意味著所有成員資格決策和非瑣碎的政策變更都必須經過核心團隊的批准。例如，財務團隊可能需要靜態章程。

所有子團隊在任何時候都必須遵守 conda-forge 的治理、政策和程序。

投票​

本節介紹 conda-forge 社群中投票項目的描述和標準。核心團隊是唯一擁有投票權的團隊。核心成員也可以就任何主題發起投票。發起投票的限制如下：

  • 在任何時候，關於特定項目只能有一個投票正在進行。
  • 發起投票的行為本身不能違反行為準則。例如，Sam 在先前的投票未能達成 Sam 的結果後，立即重複發起投票。Sam 試圖脅迫其他核心成員同意，因此違反了行為準則。
  • 投贊成票表示推動提案；投反對票是表達反對提案的唯一方式；不投票是不鼓勵的，但不投票不計為「反對」。
  • 應該始終有棄權投票的選項。

投票項目被標記為標準或敏感。標準項目是公開記錄和討論更可取的項目。敏感投票項目是在投票結束後，投票結果應對投票者保密的項目。敏感投票應在安全的匿名投票平台上進行，以保持選舉的公正性和匿名性。（我們使用過 Polys 和 Helios 投票系統，但對任何安全、匿名的系統持開放態度。）您選擇的投票平台的電子郵件功能應用於發送投票邀請和提醒，您應該使用來自 https://github.com/conda-forge/conda-forge.github.io/blob/main/src/core.csv 和 https://github.com/conda-forge/conda-forge.github.io/blob/main/src/emeritus.csv 的電子郵件清單作為要使用的權威電子郵件清單。

預設投票期限為 1 週（7 天）。這可以在發起投票時修改，但絕不能少於 24 小時。

如果必須處理低投票率，則可能適用其他要求，請參閱下文的「法定人數」。

要發起標準投票，以下是一個範本 PR 評論

@conda-forge/core
This PR falls under the {policy} policy, please vote and/or comment on this PR.
This PR needs {policy_percent} of core to vote yea to pass.
To vote please leave Approve (yea) or Request Changes (nay) reviews.
If you would like changes to the current language please leave a comment or push to this branch.
This vote will end on {date}.

  • 發布結果： 為了維護歷史記錄，任何調用以下「超時」規則的標準投票結果都應記錄在 https://github.com/conda-forge/conda-forge.github.io/tree/main/vote-results 的「vote-results」資料夾中

    每個投票都應該是自己的檔案。檔案名稱應反映主題和投票開始的日期。檔案應至少包含

    • 投票描述
    • 投票政策
    • 投票總數
    • 投票開始和結束日期
    • 給予核心團隊的通知

  • 法定人數： 投票的法定人數可以透過三種方式之一來滿足，具體取決於投票：標準法定人數規則、加速法定人數規則和「超時」法定人數規則。適用於每次投票的具體法定人數規則如下所列。

    標準法定人數規則：以下所有百分比均表示既要求的參與度（佔活躍核心團隊的比例），又表示投票中投贊成票的比例。例如，在需要 50% 法定人數的投票中，若有 18 名活躍核心成員，則至少必須有 9 人投票；如果 9 人投票，則必須有 5 張贊成票。如果 13 名成員投票，則必須有 7 張贊成票。

    加速法定人數規則：對於某些投票，我們允許較低的法定人數水平。對於這些投票，如果投票期超過一週且沒有「反對」票，則可以接受標準法定人數所需規模一半的法定人數。例如，對於需要 50% 法定人數且有 18 名活躍核心成員的投票，至少必須有 5 人投「贊成」票，且必須正好有 0 人投「反對」票。

    超時法定人數規則：未達到法定人數的投票最終將在其設定的結束日期超時。當這種情況發生時，目前的參與程度將被視為現狀，並且贊成票的百分比將根據當時的投票總數計算。為了使超時發生，投票必須： * 開放至少 2 週 * 在核心團隊會議上提出並討論 * 在 Zulip 核心聊天室至少宣傳 3 次（投票期開始時、中期和擬議超時前一天） * 已透過電子郵件發送給核心成員。電子郵件提醒必須以類似於 Zulip 聊天室的方式發送到核心電子郵件清單：至少 3 次，發生在投票期開始時、中期和擬議超時前一天。

    以上述範例為例，如果法定人數需要 9 人，但只有 7 人投票，則在滿足上述條件後，這 7 票可以構成完成投票的基礎。在這 7 票中需要 4 票才能通過投票。

    要發布超時提醒，以下是一個範本評論： md @conda-forge/core 此投票屬於 {policy} 政策，請投票和/或評論此 PR。此投票需要 {policy_percent} 的核心成員投贊成票才能通過。此投票目前有 {current_voters} 位投票者，還需要 {policy_percent * core - current_voters} 位才能達到法定人數。建議此投票將在 {days} 天後，即 {date} 超時並使用當前投票進行評估。要投票，請留下「批准」(贊成) 或「請求變更」(反對) 審查。

    要宣告標準投票「超時」，做出此宣告的人員必須發布一個 pull-request，將投票記錄添加到 vote-results 資料夾。宣告 PR 應由第一位可以驗證超時要求已根據其個人記錄得到滿足的核心成員合併。

  • CFEP 批准： 準備就緒後，提案人可以就現有的 conda-forge 增強提案 (CFEP) 發起投票。這需要超級多數（60%）才能通過，以便接受 CFEP 的決定是明確的，並且我們已確保達成共識。
    • 標準
    • 60% 多數通過
    • 法定人數規則：標準或超時
  • 提名暫存食譜新成員： 提案人必須簡要說明為什麼需要或希望有新成員。
    • 敏感
    • 50% 多數通過
    • 法定人數規則：標準、加速或超時
  • 提名核心團隊新成員： 提案人必須充分說明為什麼應歡迎被提名人加入核心團隊。先前對社群的服務，包括但不限於：擔任暫存食譜審查員、從事關鍵的 conda-forge 基礎架構以及協助橋接不同的社群，是提名過程的重要組成部分。
    • 敏感
    • 66.7% 多數通過
    • 法定人數規則：標準或超時
  • 子團隊成立： 提案人必須指定任何新子團隊的名稱、角色與職責、成員和章程（動態或靜態）。
    • 標準
    • 50% 多數通過
    • 法定人數規則：標準或超時
  • 子團隊解散： 提案人必須指定名稱和解散子團隊的理由。
    • 標準
    • 50% 多數通過
    • 法定人數規則：標準或超時
  • 鎖定問題、Pull Request、討論串： 有時，討論會變得有害，並且與促進 conda-forge 社群的目標背道而馳。核心成員有權以「先斬後奏」的方式鎖定討論串，以便快速處理不良情況。必須在討論串本身中說明鎖定的理由，解釋鎖定原因以及參與者如何提出異議。
    • 標準
    • 鎖定討論串無需投票
  • 封鎖貢獻者： 在極端情況下，例如重複騷擾，可能有必要完全封鎖使用者參與所有 conda-forge 活動。不應輕易執行此操作，但可能需要迅速執行。預計投票期會較短（例如 24 小時）。封鎖提案人必須充分說明為什麼需要這樣做。
    • 敏感
    • 60% 多數通過
    • 法定人數規則：標準或超時
  • 移除暫存食譜成員： 提案人必須說明為什麼應移除暫存食譜成員。
    • 敏感
    • 66.7% 多數通過
    • 法定人數規則：標準或超時
  • 移除核心團隊成員： 提案人必須提供令人信服的理由說明為什麼應移除核心團隊成員。
    • 敏感
    • 75% 多數通過
    • 法定人數規則：標準或超時
  • 整體工作流程和套件政策： 提案人可以選擇使用外部工具發起民意調查，或在相關的 GH 問題上發起投票。投票期必須開放至少一個核心成員會議週期，以便澄清問題和討論。鼓勵友善的投票提醒。
    • 標準
    • 50% 多數通過
    • 法定人數規則：標準、加速或超時
  • 資金支出： 提案人必須指定要支出的資金用途、時限和來源。用途和時限應盡可能概括，以防止過度投票。例如，經常性項目（例如 CI）不應每個月都投票。相反，它們應該存在一段定義的時間（例如，直到當前遷移結束或接下來的一年）。對於此類經常性支出，協調資金支出的人員可以選擇取消支出，如果認為不再必要或不具成本效益，則無需另行投票，但他們應盡合理努力在這樣做之前通知其他核心成員。
    • 標準
    • 50% 多數通過
    • 法定人數規則：標準或超時
  • 修改治理文件： 投票應在相關的 PR 中進行，並且必須呼叫 @conda-forge/core。投票期必須開放至少一個核心成員會議週期，以便澄清問題和討論。
    • 標準
    • 75% 再加上投票人數中的一人通過
    • 法定人數規則：標準或超時

所有其他投票項目均被視為標準項目，需要 50% 多數才能通過，並且僅使用標準或超時法定人數規則。

現任核心成員​

依字母順序排列，

榮譽成員​

依字母順序排列，

文件歷史​

本文件由 Anthony Scopatz 撰寫。

本文件根據 CC-BY 4.0 授權發布。