跳到主要内容

治理

本文档概述了管理 conda-forge 社区的政策和程序。本文档承认，尽管打包对我们所有人至关重要，但 conda-forge 是一个完全由志愿者组成的组织。核心团队、任何团队或外部贡献者的成员可以选择参与，也可以随时出于任何原因或无原因地选择离开。我们衷心感谢所有善意的贡献。

行为准则​

请参阅行为准则部分以获取更多信息。

团队与角色​

此处定义了参与 conda-forge 活动的主要团队。

  • 核心团队： 核心团队是整个 conda-forge 组织的管理机构。核心团队成员对所有 conda-forge 仓库拥有完全权限。核心团队成员是项目的代表，负责与外部社区、组织、非营利组织和公司进行官方对接。核心团队可以根据需要创建新的子团队。每位核心团队成员在所有选举事项中都享有一票。
  • staged-recipes： staged-recipes 团队管理 staged-recipes 仓库，并负责新 feedstock 的审查和创建。
  • 维护者： 维护者是负责管理一个或多个 feedstock 仓库和软件包的个人。维护者有权将拉取请求合并到他们维护的软件包的 feedstock 中。
  • 外部贡献者： 此组包括所有不在核心团队、staged-recipes 团队或维护者之列的人员。这包括首次贡献者、合作者和资助者。他们在 conda-forge 组织本身内没有特殊权利。
  • 荣誉核心成员： 过去六个月内不活跃（提交、GitHub 评论/问题/审查、开发会议和投票）的核心团队成员将被询问是否愿意成为荣誉核心开发者。任何核心团队成员也可以在愿意的情况下请求成为荣誉成员（例如，休假或长假）。荣誉核心成员仍然可以投票，并随时返回活跃核心团队。荣誉成员的投票用于计入法定人数，但法定人数的大小是根据活跃核心团队的大小计算的。当成员状态发生更改时，应更新 core.csv 列表。

子团队​

核心团队可以选择创建新的子团队来管理组织的日常业务。虽然子团队可能拥有非核心成员，但每个子团队必须始终至少有一名核心团队成员。如果子团队超过 1 周没有核心团队成员，则该团队将被视为解散。需要由核心团队建立一个新的子团队才能恢复活动。

子团队的章程可以是动态的或静态的。

  • 动态章程意味着子团队是自组织的，关于其自身的内部政策、程序和成员资格。子团队可以选择独立于核心团队修改其成员资格。例如，Google Summer of Code 团队可能是动态章程的良好候选者。或者，基于语言的维护团队也具有动态章程。
  • 静态章程意味着所有成员资格决定和非琐碎的政策变更都必须得到核心团队的批准。例如，财务团队可能需要静态章程。

所有子团队必须始终遵守 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}）超时，并根据当前投票进行评估。要投票，请留下“批准”（赞成）或“请求更改”（反对）评论。

    要声明标准投票“超时”，做出此声明的人员必须发布一个拉取请求，将投票记录添加到 vote-results 文件夹。声明 PR 应由第一位有空的核心团队成员合并，以根据他们自己的个人记录验证是否已满足超时的要求。

  • CFEP 批准： 准备就绪后，提案人可以就现有的 conda-forge 增强提案 (CFEP) 发起投票。这需要绝对多数（60%）才能通过，以便接受 CFEP 的决定是明确的，并且我们已确保达成共识。
    • 标准
    • 60% 多数票通过
    • 法定人数规则：标准或超时
  • 提名 staged-recipes 新成员： 提案人必须简要说明为什么需要或希望有新成员。
    • 敏感
    • 50% 多数票通过
    • 法定人数规则：标准、加速或超时
  • 提名核心团队新成员： 提案人必须充分说明为什么应欢迎被提名人加入核心团队。先前为社区提供的服务，包括但不限于：担任 staged-recipes 审查员、从事关键的 conda-forge 基础设施工作以及帮助弥合不同社区之间的差距，是提名过程的重要组成部分。
    • 敏感
    • 66.7% 多数票通过
    • 法定人数规则：标准或超时
  • 子团队组建： 提案人必须指定任何新子团队的名称、角色与职责、成员以及章程（动态或静态）。
    • 标准
    • 50% 多数票通过
    • 法定人数规则：标准或超时
  • 子团队解散： 提案人必须指定子团队的名称以及应解散该子团队的理由。
    • 标准
    • 50% 多数票通过
    • 法定人数规则：标准或超时
  • 锁定问题、拉取请求、线程： 有时，讨论会变得有害，并且与促进 conda-forge 社区的目标背道而驰。核心团队成员有权以“先斩后奏”的方式锁定线程，以便快速处理不良情况。必须在线程本身中说明锁定的理由，并附带文本解释锁定原因以及参与者如何对此提出异议。
    • 标准
    • 锁定线程无需投票
  • 阻止贡献者： 在极端情况下，例如反复骚扰，可能需要完全阻止用户参与所有 conda-forge 活动。不应轻易这样做，但在必要时可能需要迅速这样做。预计投票期会较短（例如 24 小时）。阻止的提案人必须充分说明为什么需要这样做。
    • 敏感
    • 60% 多数票通过
    • 法定人数规则：标准或超时
  • 移除 staged-recipes 成员： 提案人必须说明为什么要移除 staged-recipes 成员。
    • 敏感
    • 66.7% 多数票通过
    • 法定人数规则：标准或超时
  • 移除核心团队成员： 提案人必须提供令人信服的理由说明为什么要移除核心团队成员。
    • 敏感
    • 75% 多数票通过
    • 法定人数规则：标准或超时
  • 总体工作流程和打包政策： 提案人可以选择使用外部工具创建投票或在相关的 GH 问题上发起投票。投票期必须至少开放一个核心团队成员会议周期，以便进行澄清问题和讨论。鼓励友好的投票提醒。
    • 标准
    • 50% 多数票通过
    • 法定人数规则：标准、加速或超时
  • 资金支出： 提案人必须指定要支出的资金的目的、时限和来源。目的和时限应足够概括，以防止过度投票。例如，经常性项目（例如 CI）不需要每月都进行投票。相反，它们应该在定义的时期内存在（例如，直到当前迁移结束，或持续到明年）。对于此类经常性支出，协调资金支出的人员可以选择取消支出，如果认为不再必要或不划算，则无需再次投票，但他们应尽合理努力在这样做之前通知核心团队的其他成员。
    • 标准
    • 50% 多数票通过
    • 法定人数规则：标准或超时
  • 修改治理文档： 投票应在相关的 PR 中进行，并且必须调用 @conda-forge/core。投票期必须至少开放一个核心团队成员会议周期，以便进行澄清问题和讨论。
    • 标准
    • 75% 加上投票人数中的一人通过
    • 法定人数规则：标准或超时

所有其他投票项目均被视为标准项目，需要 50% 多数票才能通过，并且仅使用标准或超时法定人数规则。

当前核心团队成员​

按字母顺序排列，

荣誉成员​

按字母顺序排列，

文档历史​

本文档由 Anthony Scopatz 编写。

本文档根据 CC-BY 4.0 许可证发布。