SKIP 1 — scikit-image 治理和决策#

作者:

Juan Nunez-Iglesias <juan.nunez-iglesias@monash.edu>

作者:

Stéfan van der Walt <stefanv@berkeley.edu>

作者:

Josh Warner

作者:

François Boulogne

作者:

Emmanuelle Gouillart

作者:

Mark Harfouche

作者:

Lars Grüter

作者:

Egor Panfilov

作者:

Marianne Corvellec

状态:

最终

类型:

过程

创建:

2019-07-02

解决:

2019-09-25

解决方案:

scikit-image/scikit-image#4182

skimage-版本:

0.16

修订:

2024-06-09

摘要#

本文档旨在规范 scikit-image 项目使用的治理流程，以澄清如何做出决策以及我们社区的各个元素如何互动。

这是一个基于共识的社区项目。任何对该项目感兴趣的人都可以加入社区，为项目设计做出贡献，并参与决策过程。本文档描述了这种参与方式，如何达成共识以及如何解决僵局。

角色和责任#

社区#

scikit-image 社区由以任何方式使用或参与该项目的人员组成。

贡献者#

社区成员可以通过以下具体方式与项目互动，成为贡献者，例如：

以及其他可能性。任何社区成员都可以成为贡献者，并鼓励所有成员这样做。通过为项目做出贡献，社区成员可以直接帮助塑造项目的未来。

鼓励贡献者阅读 贡献指南。

核心开发者#

核心开发者是社区成员，他们通过持续的贡献证明了对项目的持续承诺。他们已经证明他们可以信赖来谨慎维护 scikit-image。成为核心开发者允许贡献者合并已批准的拉取请求，对合并拉取请求进行投票，并参与决定 API 的重大变更，从而更容易继续进行与项目相关的活动。核心开发者作为组织成员出现在 scikit-image GitHub 组织 中。核心开发者应在遵守 核心开发者指南 的前提下审查代码贡献。

任何现有核心开发者都可以提名新的核心开发者。关于新核心开发者提名的讨论是项目私有管理列表中进行的少数活动之一。邀请新核心开发者的决定必须由所有回应的现有核心开发者“懒惰共识”做出，即一致同意。邀请必须在最初提名后至少一周进行，以便现有成员有时间表达任何异议。

指导委员会#

指导委员会 (SC) 成员是核心开发者，他们承担额外责任以确保项目顺利运行。SC 成员应参与战略规划，批准治理模型的变更，并对授予项目本身的资金做出决定。（社区成员的资金由他们自己寻求和管理。）SC 的目的是确保从宏观角度顺利推进。影响整个项目的变更需要通过对项目和更大生态系统有长期经验的分析来提供信息。当核心开发者社区（包括 SC 成员）在合理的时间范围内无法达成共识时，SC 是解决问题的实体。

指导委员会的人数固定为五名成员。这将来可能会扩大。scikit-image 的初始指导委员会由 Stéfan van der Walt、Juan Nunez-Iglesias、Emmanuelle Gouillart、Josh Warner 和 Zachary Pincus 组成。SC 成员资格每年 1 月重新审视。未积极参与 SC 职责的 SC 成员应辞职。新成员由核心开发者提名加入。被提名人应证明他们对项目及其 价值观 的长期、持续的承诺。提名将导致讨论，讨论时间不超过一个月，然后通过共识加入 SC。

scikit-image 指导委员会可以通过以下方式联系：skimage-steering@groups.io.

决策过程#

关于项目未来的决策是通过与所有社区成员的讨论做出的。所有非敏感的项目管理讨论都在项目 开发者论坛 和 问题跟踪器 上进行。偶尔，敏感的讨论可能会在私有列表中进行。

决策应符合 scikit-image 项目的 使命、愿景和价值观。

scikit-image 使用“寻求共识”的流程来做出决策。该小组试图找到一个解决方案，该解决方案在核心开发者中没有公开的反对意见。核心开发者应区分对提案的根本性反对意见和他们可以接受的轻微感知缺陷，并且不要为了后者而阻碍决策过程。如果找不到没有反对意见的选项，则将决策升级到 SC，SC 将使用寻求共识来达成解决方案。在不太可能的情况下，如果仍然存在僵局，如果该提案得到 SC 绝大多数成员的支持，则该提案将继续前进。任何投票必须以 scikit-image 提案 (SKIP) 为依据。

除了增加核心开发者和 SC 成员资格外，决策是根据以下规则做出的

  • 轻微的文档变更，例如拼写错误修正或添加/更正句子（但不包括 scikit-image.org 着陆页或“关于”页的变更），需要由核心开发者批准以及在问题或拉取请求页面上没有核心开发者反对或要求变更（懒惰共识）。如果核心开发者不确定其他人是否会同意，他们应等待一两天让其他人发表意见。

  • 代码和主要的文档变更以及对 API 的变更需要两位核心开发者的同意以及在问题或拉取请求页面上没有核心开发者反对或要求变更（懒惰共识）。如果出现反对意见或要求变更，如果核心开发者不确定其他人是否会同意，他们应等待至少 5 天让其他人发表意见。

  • 对 API 原则的变更需要一个 SKIP 并遵循上面概述的决策过程。但是，在这种情况下，反对期应为一个月。

  • 对该治理模型或我们的使命、愿景和价值观的变更需要一个 SKIP 并遵循上面概述的决策过程，除非核心开发者对变更达成一致意见。

如果在懒惰共识中提出异议，提案者可以向社区和核心开发者提出申诉，变更可以通过升级到 SC 来批准或拒绝，如果需要，还可以使用 SKIP（见下文）。

改进提案 (SKIP)#

对于所有投票，正式提案必须在投票之前公开提出并讨论。在讨论后，提案的关键倡导者必须创建一份整合文档，总结讨论，称为 SKIP，核心团队将在其上投票。SKIP 的生命周期在 SKIP 0 — 目的和流程 中详细说明。

所有现有 SKIP 的列表可在 此处 获取。

本页内容
显示源代码