治理¶
本文档的目的是正式化aeon项目所使用的治理流程，以明确决策是如何做出的以及我们社区各个元素如何互动。我们的目标是确保一个透明、民主和包容的决策过程，使所有社区成员都能为项目做出贡献。
aeon 是一个社区拥有和社区运营的项目。任何对该项目感兴趣的人都可以加入社区，参与项目设计并参与决策过程。
本文档确立了aeon使用的决策结构，旨在从社区中寻求共识，同时避免任何僵局。我们的决策过程涉及不同的角色，每个角色都有特定的职责。
角色¶
贡献者¶
贡献者是那些以具体方式为项目做出贡献的社区成员。任何人都可以成为贡献者，贡献可以采取多种形式——不仅仅是代码——正如贡献指南中详细说明的那样。贡献者通过参与讨论和影响决策过程，在塑造项目中扮演着至关重要的角色。
核心开发者¶
核心开发者是社区成员，他们做出了重大贡献，并被信任继续项目的开发并与社区互动。核心开发者被授予对aeon仓库的写权限，并对所有项目决策拥有投票权。他们被期望审查代码贡献，并参与他们熟悉的话题或代码。
新的核心开发者由现有的核心开发者提名，并需要获得投票核心开发者的三分之二多数票。核心开发者应保持对项目的合理参与度。编写代码、与贡献互动以及参与更广泛的社区活动都是核心开发者的有效贡献。
不再希望或无法参与项目的核心开发者应辞职。核心开发者如果在一年内没有贡献（见上文）并且没有与其他开发者互动，可能会失去其角色。如果这种缺乏互动的情况已经显现，另一位核心开发者可以建议移除并在aeon仓库上创建一个拉取请求。如果这个拉取请求成功合并，移除将完成。
工作组¶
额外的职责被委派给工作组，这些工作组是由核心开发者领导的贡献者群体。工作组负责项目的特定领域，并期望在其责任领域内进行管理和决策。工作组应透明地展示其活动和决策，并尽可能与社区互动。
工作组的成员资格和工作组的领导职位需获得核心开发者的三分之二多数票。无法履行职责的工作组成员应辞去工作组职务。工作组负责人有责任保护相关项目资源和账户的访问权限。
基础设施工作组¶
基础设施工作组负责维护aeon的基础设施，以确保项目的顺利运行。这包括确保网站保持在线，持续集成（CI）保持功能正常以及其他相关任务。
基础设施工作组负责维护aeon GitHub组织和ReadTheDocs账户的所有权。
发布管理工作组¶
发布管理工作组管理aeon的发布。这包括决定发布时间表、管理发布候选版本以及发布版本。
发布管理工作组负责维护aeon PyPi项目和conda feedstock的所有权。
财务工作组¶
财务工作组负责管理项目财务。这包括批准任何项目支出和管理任何与财务相关的账户。
通信工作组¶
通信工作组的作用是通过aeon社交网络账户和讨论论坛与更广泛的社区互动。通信工作组的职责是管理和维护aeon的Twitter、LinkedIn、Slack和其他相关通信账户。
通讯团队负责维护社交网络账户的访问权限，并负责管理aeon电子邮件地址的访问权限。为了帮助管理GitHub讨论，通讯工作组被授予了对aeon GitHub仓库的分类访问权限。
行为准则工作组¶
行为准则工作组（CoCW）由贡献者组成，他们的任务是确保aeon保持一个欢迎和包容的社区。CoCW的职责包括维护aeon的行为准则（CoC）和管理违反CoC的报告。CoCW成员需要审查违反CoC的报告，与相关个人联系和讨论，并提出采取行动的建议。
任何涉及CoC报告的CoCW成员或对报告有利益冲突的CoCW成员都应回避该过程。CoCW被授予对aeon GitHub仓库的分类访问权限，以便在必要时主持讨论。
决策过程¶
关于项目未来的决策会公开宣布，以便与社区所有成员进行讨论。从提案到实施的整个过程都是完全透明的，除了被视为敏感的话题。所有非敏感的项目管理讨论都在项目的Slack和/或问题跟踪器上进行。偶尔，敏感讨论和投票（如任命）会在私密的Slack频道或会议中进行。
对于大多数决策，采用所有感兴趣的贡献者寻求共识的过程。 贡献者试图找到核心开发者中没有公开反对意见的解决方案。 如果自上次对提议的贡献进行更改以来已经过去了合理的时间（对于非微小更改至少为7天）， 并且该提议至少获得了一个核心开发者的批准（+1），且没有核心开发者的拒绝（-1）， 则可以通过懒人共识批准。如果更改被拒绝，预计会提供解释和撤销拒绝的条件（如果有的话）的描述。
在讨论的任何时候，任何支持变更的核心开发者都可以要求进行投票，投票将在要求投票的两周后结束。任何要绕过核心开发者拒绝的投票必须由AEP支持（见下一节）。对于重大贡献（如新模块或主要框架重新设计），可以在没有拒绝或投票的情况下请求AEP。如果要求进行投票，提案必须获得投票核心开发者的三分之二多数才能被批准。
对aeon代码或文档的所有更改都应通过拉取请求进行。默认情况下，所有核心开发人员对main GitHub分支的推送权限都受到限制。在紧急情况下，基础设施工作组可能会暂时撤销分支保护，允许小组成员直接提交，但这只应在紧急情况下发生，即如果不及时采取行动，项目将受到损害。
增强提案¶
对于有争议的决策投票（不包括任命投票），应在投票前公开提案以供讨论。建议将此提案作为一份综合文件，以“aeon增强提案”（AEP）的形式提出。AEP模板可在此处here获取，但使用该模板并非强制要求。如果所有相关方认为足够详细，一个详细的问题或拉取请求可以替代AEP，但任何核心开发者都可以要求更正式的提案。
在拉取请求上遇到拒绝并不需要创建AEP，并且可以继续进行进一步的讨论以达成共识，但在任何投票以绕过拒绝之前必须创建一个AEP。
提交AEP不需要进行投票。如果贡献者希望提出更正式的提案或认为某个变更可能会引起争议，可以将AEP提交给社区进行讨论和评论。
致谢¶
本文档的很大一部分改编自或受到以下项目治理文档的启发：