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

作者:

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

作者:

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

作者:

乔什·华纳

作者:

弗朗索瓦·布洛涅

作者:

伊曼纽尔·古利亚特

作者:

马克·哈福克

作者:

Lars Grüter

作者:

叶戈尔·潘菲洛夫

作者:

玛丽安·科尔维莱克

状态:

最终

类型:

过程

创建:

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 成员资格。不积极参与 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（见下文）。

改进建议 (SKIPs)#

对于所有投票，正式提案必须在投票前公开并讨论。讨论结束后，提案的主要倡导者必须创建一个总结讨论的综合文档，称为 SKIP，核心团队在此文档上进行投票。SKIP 的生命周期详见 跳过 0 — 目的和过程。

所有现有 SKIP 的列表可在此处找到 这里。

On this page
显示源代码