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