治理#
概述#
sktime 是一个基于共识的社区项目。任何对项目感兴趣的人都可以加入社区，为项目做出贡献，并参与治理过程。本文档描述了参与的方式、我们在社区中的角色、我们如何做出决策以及我们如何认可贡献。
我们特别致力于支持新人和/或焦虑的贡献者，那些希望学习和提升技能的人，以及在科技领域中代表性不足的群体成员。更多详情请访问我们的 贡献指南 。
部分 |
目的 |
|---|---|
行为准则 |
我们期望 sktime 社区的所有成员如何互动 |
角色 |
我们在 sktime 社区中担任的角色以及他们拥有的权利和责任 |
决策制定 |
决策如何制定以及由谁制定 |
致谢贡献 |
我们如何认可贡献 |
我们未来可能会改变的内容 |
行为准则#
我们重视社区中每一位成员的参与，并希望确保每一位贡献者都能有一个愉快和充实的体验。因此，所有参与 sktime 项目的人都应始终对其他社区成员表现出尊重和礼貌。
我们要求社区的所有成员遵守我们的 行为准则。
角色#
我们区分以下社区成员可能行使的关键角色。对于每个角色，我们将在下面更详细地描述他们的权利和责任，以及任命过程。
角色 |
权利/责任 |
任命 |
|---|---|---|
贡献者 |
- |
具体贡献 |
算法维护者 |
算法维护、对算法变更的投票权和否决权 |
当前维护者的算法贡献或任命 |
核心开发者 |
直接写入权限、问题/PR管理、否决权、投票、提名 |
核心开发者提名，核心开发者投票，2/3 多数通过 |
行为准则委员会成员 |
行为准则维护、调查与执行 |
核心开发者提名，核心开发者投票，2/3 多数和简单的 CoC 多数 |
冲突解决，技术领导，项目管理 |
核心开发者提名，核心开发者投票，2/3 多数和简单 CC 多数 |
|
CC 通信的全景视图，CC 决策的直接输入 |
核心开发者提名，CC成员投票，简单多数CC通过 |
贡献者#
贡献者是那些以具体方式为项目做出贡献的社区成员。任何人都可以成为贡献者，贡献可以采取多种形式——不仅仅是代码——正如 贡献指南 中所详细描述的那样。
有关我们如何认可贡献的更多详情，请参见下面的 致谢贡献。
所有贡献者都列在 CONTRIBUTORS.md 中。
算法维护者#
算法维护者是那些已经贡献了算法的人。他们在其算法方面拥有与核心开发者相同的投票权。
在 sktime 中，算法被封装在具有特定接口要求的类中，并被称为估计器。为了便于维护问题，我们尽可能将算法写在单独的文件中。
需要澄清的是，上述意义上的“算法”指的是“已实现的估计器类”。也就是说，算法维护者对该Python代码拥有权利和责任。他们不会获得任何关于抽象方法的权利，例如，在类实现第三方发明的方法的情况下。
特别是，算法维护者在其估计器类中对同一方法论的其他潜在实现不获得权利或责任。
权利与责任#
权利/责任 |
描述 |
|---|---|
关于其算法的决策制定 |
算法维护者可以通过否决更改和就其算法提议的更改进行投票来参与决策过程。这不包括对通用框架和API提议的更改。 |
维护 |
他们负责维护其算法的代码和文档，包括错误修复、单元测试、编码风格、符合通用API、文档字符串、文档和教程笔记本。 |
支持 |
他们是用户和其他贡献者在所有关于他们算法的疑问、问题和建议方面的第一个联系点。 |
回顾一下，“算法”指的是估计器类。
因此，上述权利和责任排除了对相同或类似方法的进一步潜在实施的任何权力。
例如，类 X 中实现的算法 A 的维护者不能禁止在类 Y 中实现算法 A。他们只能对类 X 的更改做出决定。类 Y 可以由不同的算法维护者拥有。
特别是，可以有多个类实现算法 A，而类 X 的算法维护者不能禁止实现或对类 Y 做出决定。
期望#
不受资格限制，通常期望算法维护者对其维护的算法有非常好的技术和方法论理解。
这种理解通常存在于该算法的创造者或支持者中，但成为算法的维护者并不一定需要是该算法的创造者。
资格#
任何人都有资格成为算法维护者。
任何人都符合成为特定算法的维护者的资格，前提是该算法目前没有维护者。
特定抽象算法的具体实现的存在，并不妨碍任何人成为同一（或相似）抽象算法的不同实现的算法维护者。
任命#
贡献算法的贡献者将自动被任命为该算法的首位维护者。
算法维护者列在估计器类的 "maintainers" 标签中，通过他们的 GitHub ID。GitHub ID 可以通过 all-contributorsrc 文件链接到更多信息。该标签可以直接在类的源代码中检查，或者通过 EstimatorName.get_class_tag("maintainers")。反向查找，例如“维护者 M 维护哪些算法”，可以使用 registry.all_estimators 进行。
当算法维护者辞职时，他们可以任命另一位贡献者为新的算法维护者。不需要投票。这一变更应在 "maintainers" 标签中反映。
算法维护者可以通过CC简单多数任命，对于任何没有维护者的算法。
任期结束#
如果算法维护者无法再履行其维护职责，维护者应辞职。
在3个月内无回应的算法维护者将自动放弃其作为算法维护者的权利和责任。
无响应性定义为：
未在合理的时间框架内参与决策程序
在十个工作日内不回应与算法相关的问题或错误报告
核心开发者#
核心开发者是指那些通过持续参与社区活动，展示出他们对项目持续发展承诺的贡献者。
当前的核心开发者列在 GitHub 上 sktime 组织的 core-developers 团队 中。
权利与责任#
权利/责任 |
描述 |
|---|---|
直接访问 |
作为核心开发者，通过直接访问项目的仓库，可以让贡献者更容易地继续他们的项目相关活动。 |
问题/PR 管理 |
核心开发者负责审查和管理问题和拉取请求。这包括对问题发表评论、审查代码贡献、合并已批准的拉取请求，以及在问题解决后关闭它们。 |
决策 |
他们可以通过否决变更和投票参与决策过程。 |
提名 |
他们可以提名新的核心开发者、行为准则委员会成员和CC成员。 |
资格#
任何人都有资格成为核心开发者。
任命#
新的核心开发者可以由任何当前的核心开发者提名。一旦被提名，当前的核心开发者将进行投票。
在项目的私人通信渠道上进行的少数活动之一是投票任命。投票将是匿名的。
虽然大多数投票预计会是全票通过，但只要获得三分之二以上的投票即可。投票需要开放五天，不包括周末。
任期结束#
核心开发者可以随时自愿辞职，只需以书面形式通知CC。
在过去一年内未对项目做出贡献的核心开发者将自动成为 不活跃 状态，并放弃其权利和责任。当他们再次活跃时，可以无需任命重新担任其角色。
在上述意义上变得不活跃意味着在期间内不通过以下方式贡献：
创建拉取请求
对拉取请求或问题进行评论
参加定期会议之一
在上面的意义上变得活跃（在变得不活跃之后）需要以下之一：
由核心开发者提交的已批准的拉取请求
对社区的一次贡献，记录在定期会议之一中
CoC 委员会成员#
CoC 成员是拥有特殊权利和责任的贡献者。CoC 委员会的当前成员列在 CoC 中。
权利与责任#
CoC 委员会成员负责调查潜在的 CoC 事件并执行 CoC。他们是报告潜在 CoC 事件的联系点。
此外，他们负责维护和改进行为准则（CoC）。
资格#
任何人都有资格成为行为准则委员会成员。
任命#
CoC 的成员资格由核心开发者提名并通过所有核心开发者的投票决定。提名将导致讨论，讨论将持续 5 天（不包括周末），然后由核心开发者进行投票，投票将持续 5 天（不包括周末）。CoC 委员会成员投票受以下条件约束：
所有投票的三分之二多数，以及
所有现任行为准则委员会成员的简单多数批准。
投票将在私人通讯渠道中进行，并且将是匿名的。
为了避免死锁，如果CoC委员会成员数量为偶数，其中一名成员将拥有打破平局的特权。
CC 成员#
CC (社区委员会) 成员是核心开发者，他们拥有额外的权利和责任，以避免僵局并确保项目的顺利进展。
当前的 CC 成员列在 GitHub 上 sktime 组织中的 community-council 团队 内。
权利与责任#
权利/责任 |
描述 |
|---|---|
决策制定：冲突解决 |
见下方 阶段-3 |
技术方向 |
战略规划，发展路线图 |
项目管理 |
资金、与外部组织的合作、社区基础设施（聊天服务器、GitHub 仓库、持续集成账户、社交媒体账户） |
资格和任命#
社区理事会由 sktime 的贡献者在定期选举中选举产生。
选举过程详见 社区委员会选举仓库。
链接的仓库包含选举过程的信息，包括选举日程、选举规则和过去的选举结果。
通信#
CC 定期举行公开会议，欢迎整个社区成员参加。会议在项目的社交频道上举行，目前是在 Discord 上。
有关我们会议的更多详情及以往会议的纪要，请访问我们的 社区委员会仓库。
如需直接联系CC，请发送电子邮件至sktime.toolbox@gmail.com。
CC 观察员#
CC (社区委员会) 观察员是拥有额外权利和责任的核心开发者。当前的 CC 观察员名单列在 `社区委员会观察员 <https://www.sktime.net/en/latest/about/team.html`__ 中。
权利与责任#
CC 观察员可以全面查看保留的 CC 程序、私人 CC 频道和 sktime 电子邮件账户。CC 观察员可以在私人 CC 频道上参与讨论，以确保社区中有更多成员能够直接对 CC 决策提出意见。
CC 观察员的责任包括对 CC 决策进行批判性审查，并就社区利益或福利相关事项提供意见。
CC 观察员不具备全职 CC 成员的投票或决策权。
资格#
只有核心开发者才有资格被任命为CC观察员。非核心开发者可以被提名，但这必须伴随着核心开发者提名的同时，并且需要进行核心开发者任命投票（见下文）。
任命#
CC 观察员的成员资格由核心开发者提名并通过 CC 成员投票决定。提名将导致 CC 成员进行投票，投票将持续 5 天，不包括周末。CC 观察员成员资格的投票需获得当前所有 CC 委员会成员的简单多数批准。
在平局情况下，任期最短的CC成员打破平局。
特殊操作角色：财务主管#
财务主管是 sktime 项目中的一个任命角色。这主要是一个支持和增强透明度的角色。
如果财务主管职位空缺超过一个月，CC 必须以委员会的形式履行财务主管的职责。
权利与责任#
财务主管将与CC密切合作，设定财务目标，分配资源，并确保财务管理的道德性。
职责包括预算编制、财务管理、财务报告、内部政策合规以及现金管理。
财务主管的主要职责是及时编制项目的财务报表和预算。
资格和任命#
财务主管职位对 sktime 项目的核心开发者开放。
非核心开发者必须先被确认为核心开发者，然后才能被考虑担任财务主管的角色。
CC 通过多数票从适合该职位的候选人中任命财务主管。
当需要填补职位时，CC 应在透明的沟通渠道中向社区征集提名。
任期与罢免#
财务主管的任期为一年，并有连任的可能。
如果财务主管未能按要求编制预算或财务报表，不活跃可能导致移除。
与财务透明度相关的操守违规行为需要进行操守调查。
决策#
本节旨在规范化 sktime 项目使用的决策过程。我们明确：
我们决定做出哪些类型的更改，
决策是如何制定的，以及
谁参与决策。
sktime 的决策过程旨在考虑所有社区成员的反馈，并努力达成共识，同时在无法达成共识时避免僵局。
所有讨论和投票都在项目的 issue tracker、pull requests 或 步骤 上进行。一些敏感的讨论和任命投票在私人聊天中进行。
CC 保留推翻决定的权力。
我们区分以下几种类型的提议变更。相应的决策过程将在下面更详细地描述。
变更类型 |
决策过程 |
|---|---|
代码添加，例如新算法 |
懒惰共识，由 算法包含指南 支持 |
小的文档改动，例如拼写修正，或句子的新增/更正 |
懒惰共识 |
代码更改和主要文档更改 |
懒惰共识 |
API设计的变更、硬依赖项或支持的版本 |
懒惰共识，需要一个 步骤 |
对 sktime 治理的更改（本文档和行为准则） |
懒惰共识，需要一个 步骤 |
任命 |
直接开始投票（第二阶段） |
阶段 1: 带有否决权的懒惰共识#
sktime 使用一种“寻求共识”的决策过程。社区试图找到一个核心开发者中没有公开反对意见的解决方案。
提议的更改应以 GitHub 拉取请求 (PR) 的形式提交。某些更改还需要详细说明 步骤 。这取决于更改的类型，请参阅上面的 决策制定过程 。
对于一个提议的变更要通过懒惰共识获得批准，它需要至少一个核心开发者的批准（懒惰共识），并且没有核心开发者的反对（否决权）。此条件所需的批准必须由与提议者不同的核心开发者做出。
对于一个提议的变更，如果通过懒惰共识被拒绝，它需要至少收到一个核心开发者的拒绝，并且没有收到任何核心开发者的接受。
批准必须以GitHub PR批准相关PR的形式进行。拒绝可以通过-1评论或任何包含“我正式拒绝”的书面评论在PR中表达，以此为参考。
提案者应给予合理的时间进行考虑，即核心开发者审查并给出对PR意见的时间和机会。不包括周末的十个工作日构成上述意义上的“合理时间”。每次对PR进行新的更改时，该期限都会重置。只有在所有GitHub检查通过后，期限才开始。
在此期间，如果PR获得批准且没有拒绝，则可以合并，但如果收到额外拒绝，则应回滚。
如果“合理时间”期限过去后，PR 仍未得到批准或拒绝，该 PR 将被安排在下次开发者会议议程的首位。在会议上，将指定一名核心开发者审查该 PR，并在会议后的五天内（不包括周末）批准或拒绝。
在上述意义上，懒惰共识的失败只有在以下条件下才会发生：PR中至少有一个批准和至少一个拒绝。
当无法达成共识时，决策将升级到 阶段-2。
阶段 2: 投票#
投票进行方式：
当在上述阶段1中找不到惰性共识时
预约
在阶段1之后，投票期的开始时刻是懒惰共识失败的时刻。
投票的开始和结束时间必须在核心开发者频道中宣布，并且在PR（如果在PR上）上宣布。
投票将在投票呼吁发出后的5个工作日内结束，不包括周末。
投票是自愿的。允许弃权。核心开发者可以通过不投票来弃权。
所有投票都是二元投票：支持或反对接受提案。
投票以评论形式进行：+1（赞成）或 -1（反对）。
对于所有类型的变更，除了任命，投票在相关的公共问题或拉取请求上进行。获胜条件是核心开发者（包括CC成员）对该提案投出的2/3多数票。如果该提案未能获得核心开发者投出的2/3多数票，决策将升级到 阶段 3：冲突解决。
对于任命，投票在私人通信渠道中进行，并且是匿名的。获胜条件根据上述 角色 中描述的角色而有所不同。任命决定不会升级到CC。如果提名无法获得足够的支持，则提名将被拒绝。
阶段 3：冲突解决#
如果提议的变更无法获得投票数的三分之二多数，CC 将尝试解决僵局。
CC 将使用共识寻求。
如果在第一阶段“考虑的合理时间”开始后的二十个工作日（不包括周末）内无法达成共识，则通过CC成员之间的简单多数投票（包括平局打破）做出决定。
任何达到阶段 3 的提案必须得到一个 步骤 的支持，该步骤至少在投票前 5 天（不包括周末）公开。
sktime 增强提案#
sktime 增强提案 (STEPs) 是必需的：
某些类型的提议变更，默认情况下，请参见 决策过程
对于所有第三阶段的决策
如果一个 STEP 需要通过投票决定，它必须在投票前至少 5 个工作日（不包括周末）公开。
STEP 是一个综合文档，包含简洁的问题陈述、对提议解决方案的清晰描述以及与替代解决方案的比较，如我们的 模板 中所述。
一个完整的 STEP 必须始终至少包含所提议更改的高级设计，而不仅仅是一个功能清单。
通常，我们会在 sktime 的 增强提案仓库 中收集和讨论提案。
对于较小的更改，例如对API或治理文档的点对点更改，STEP也可以作为问题或拉取请求的一部分。
算法包含指南#
策展是关于我们如何选择贡献，我们使用哪些标准来决定包括哪些贡献，以及在哪些情况下我们弃用和移除贡献。
我们有以下指南：
sktime旨在提供一个算法库，以增强可重复研究，不对引用次数、算法性能或使用频率设置下限。要包含在内，必须有一个科学参考文献，并链接到python估计器。科学参考文献是对算法的正式描述，满足基本的科学要求，例如，形式正确、完整，并遵守数据科学领域的常见展示惯例。
科学参考资料必须避免无根据的科学主张、伪科学、商业营销或其他不适用于科学参考的内容。科学参考资料必须遵守适当的科学引用标准，即引用原始来源，给予适当的认可。科学参考资料的形式可以是类文档字符串中的描述，或链接到科学文档，例如arXiv上的文档。此类科学文档不必经过同行评审或期刊发表，但必须符合科学标准。
我们努力整合现有功能，如果这有助于提高项目的可用性和可维护性。例如，当有多种技术用于相同目的时，我们可能会选择将一种变体作为“主要默认”呈现，而将较少见的变体作为不太容易访问或找到的替代方案。“主要默认”的选择可能会随着用户社区中的使用和相关性而改变。我们意识到“主要默认”的选择可能会增加或减少可见性，并旨在为可用性和选择的质量做出选择。
我们很高兴接受感兴趣的历史算法，作为再现研究中的参考，包括存在错误实现的历史版本。历史上有趣的算法将被明确标记为历史算法，其收录主要由相关性指导，例如，作为重要研究中的参考，在科学讨论中的相关性，或作为重要的算法基线。
从符合上述标准的算法或技术中，只有那些能很好地融入sktime当前框架的才会被接受。对于那些不能很好地融入当前API定义的算法，必须首先扩展API。关于扩展当前API，请参阅 决策制定过程 以了解重大变更。
请注意，一个算法不需要在 sktime 中才能完全兼容 sktime 接口。你可以在第三方代码库（开源或闭源）中以 sktime 兼容的方式实现你喜欢的算法，只需遵循实现兼容估计器的指南（参见 developer_guide_add_estimators:）。
我们很高兴在 相关软件 下列出任何兼容的开源项目。我们也欢迎对 GitHub 上的 我们的附属仓库 中的任何一个进行贡献。
依赖关系是在估计器的层面上管理的，因此完全有可能主要在一个第三方或第二方包中维护一个算法，并添加一个薄的接口到sktime本身，该接口将该包作为依赖项。
致谢贡献#
sktime 是由其多样化的开发者、用户、教育者和其他利益相关者共同开发的。我们重视各种贡献，并致力于公平地认可每一份贡献。
我们遵循 all-contributors 规范来认可所有贡献者，包括那些不贡献代码的贡献者。请参阅 我们的所有贡献者列表。
如果你认为我们遗漏了什么，请告诉我们或提交一个包含适当更改的PR到 sktime/.all-contributorsrc。
请注意，贡献者不拥有他们的贡献。sktime 是一个开源项目，所有代码都在 我们的开源许可证 下贡献。所有贡献者都承认他们拥有所有权利，可以将他们贡献的代码在此许可证下提供。
该项目属于 sktime 社区，其所有部分始终被视为“进行中的工作”，以便随着新贡献的加入而随时间演进。
Outlook#
我们欢迎对我们的治理模型提出改进建议。一旦社区进一步发展，sktime 的代码库变得更加稳固，我们将考虑以下变更：
允许更多时间讨论变更，并在无法达成共识时给予更多时间进行投票。
在寻求共识阶段，要求更多的正面投票（减少懒惰共识）以接受变更，
减少维护者回复问题的时间
此外，我们计划为管理/协调特定项目添加更多角色：
社区经理（指导、外联、社交媒体等）
项目特定技术领导的分委员会（例如，用于文档、学习任务、持续集成）
参考文献#
我们的治理模式受到各种现有治理结构的影响。特别是，我们要感谢：
scikit-learn 的 治理模型
社区的艺术 作者：Jono Bacon
astropy 项目
nipy 项目
scikit-hep 项目