跳过1--科学工具包--形象治理和决策

作者

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

作者

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

作者

乔什·华纳

作者

弗朗索瓦·布洛涅

作者

伊曼纽尔·古亚特

作者

马克·哈福什

作者

拉尔斯·格鲁特

作者

埃戈尔·潘菲洛夫

状态

最终

类型

过程

已创建

2019-07-02

已解决

2019-09-25

分辨率

https://github.com/scikit-image/scikit-image/pull/4182

SKIMAGE-版本

0.16

摘要

本文件的目的是正式确定SCRICKIT-IMAGE项目使用的治理流程，阐明决策是如何做出的，以及我们社区的各种元素是如何互动的。

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

角色和责任

社区

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

贡献者

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

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

我们鼓励投稿人阅读 contributing guide 。

核心开发者

核心开发人员是社区成员，他们通过持续的贡献展示了对项目的持续承诺。他们已经表明，他们可以被信任，会小心地维护科技形象。成为核心开发人员允许贡献者合并批准的拉请求，投票赞成和反对合并拉请求，并参与决定对API的重大更改，从而更轻松地继续他们的项目相关活动。核心开发人员在SCRICKIT-IMAGE上显示为组织成员 GitHub organization 。核心开发人员应该审查代码贡献，同时遵守 core developer guide 。

新的核心开发人员可以由任何现有的核心开发人员提名。关于新的核心开发人员提名的讨论是该项目的私人管理列表上为数不多的活动之一。邀请新的核心开发人员的决定必须由“懒惰的共识”做出，这意味着所有响应的现有核心开发人员都一致同意。邀请必须在最初提名后至少一周内发出，以便现有成员有时间表达任何反对意见。

督导委员会

督导委员会的成员是核心发展商，他们有额外责任确保工程顺利进行。SC成员应参与战略规划，批准对治理模式的更改，并就授予项目本身的资金做出决定。(对社区成员的资助是他们的追求和管理。)常委会的目的是从大的角度确保进展顺利。影响整个项目的更改需要根据项目和更大生态系统的长期经验进行分析。当核心开发者社区(包括SC成员)未能在合理的时间框架内达成这样的共识时，SC是解决问题的实体。

督导委员会的规模固定为五名成员。这在未来可能会扩大。SCRKIT-IMAGE的最初指导委员会由Stéfan van der Walt、Juan Nunez-Iglesias、Emmanuelle Gouillart、Josh Warner和Zachary Pincus组成。每年1月，SC成员资格都会重新讨论。没有积极参与SC职责的SC成员将被要求辞职。新成员由核心开发人员通过提名添加。被提名者应表现出对该项目及其 values 。提名将经过不超过一个月的讨论，然后以协商一致的方式进入常委会。

可以通过以下地址联系SCRICKIT-IMAGE指导委员会 skimage-steering@groups.io 。

决策过程

有关这项计划未来的决定，是透过与社会各界人士讨论而作出的。所有不敏感的项目管理讨论都在项目上进行 mailing list 以及 issue tracker 。偶尔，个人分发名单上可能会发生敏感讨论。

决策应根据 mission, vision and values 科学工具包图像项目的。

SCHKIT-IMAGE使用“寻求共识”的过程来制定决策。该组织试图找到一个在核心开发者中没有公开反对意见的解决方案。核心开发商被期望区分对提案的根本反对意见和他们可以接受的细微缺陷，而不是阻碍后者的决策过程。如果在没有异议的情况下找不到任何选择，则将决定上报给常设委员会，后者本身将利用协商一致寻求达成解决方案。在不太可能的情况下，如果仍然存在僵局，如果提案获得SC的简单多数支持，它就会向前推进。任何投票都必须有一个 scikit-image proposal (SKIP) 。

决策(除了添加核心开发者和SC成员外，如上所述)按照以下规则进行：

  • 较小的文档更改 ，例如修正打字错误，或添加/更正句子(但不更改SCISKIT-Image.org登录页面或“关于”页面)，需要核心开发人员的批准 and 核心开发人员在问题或拉取请求页面上没有分歧或要求更改(懒惰共识)。如果核心开发者不相信其他人会同意，他们应该给其他人“合理的时间”来表达他们对拉请求的意见。

  • 代码更改和主要文档更改 要求在以下情况下同意 two 核心开发人员 and 核心开发人员在问题或拉-请求页面上没有异议或要求更改(懒惰共识)。

  • 对API原则的更改 需要一个 改进建议(跳过) 并遵循上面概述的决策过程。

  • 这种治理模式或我们的使命、愿景和价值观的变化 需要一个 改进建议(跳过) 并遵循上面概述的决策过程， 除非 核心开发人员一致同意这一改变。

如果对懒惰的共识提出反对，建议者可以向社区和核心开发商提出上诉，通过升级到SC来批准或拒绝更改，如果需要，还可以跳过(见下文)。

改进建议(跳过)

对于所有投票，必须在投票前公布并讨论正式提案。在进行讨论后，提案的主要倡导者必须创建一份总结讨论的综合文件，称为跳过，核心团队对此进行表决。中详细介绍了跳跃的使用寿命 跳过0-目的和过程 。

所有现有跳过的列表均可用 here 。