# Sanic 社区公约白皮书
2019 年 12 月 第一版
# 目标(Goals)
围绕 Sanic 项目创建一个可持续的、社区驱动的组织，以促进：
（1）增强 Sanic 的稳定性和可预测性。
（2）对 Sanic 进行快速迭代并增强周期支持。
（3）外部贡献者参与其中。
（4）创造一个整体可靠的软件。
（5）为社区成员提供一个安全有益的环境。
# 概览(Overview)
本公约是 Sanic 社区组织（Sanic Community Organization 简称 SCO）的管理概述。SCO 是一个精英主义、以共识为基础的社区组织。负责其下所有的项目。任何对组织下任一项目感兴趣的人都可以加入社区。为社区或项目做贡献，并参与决策过程。本公约用于描述如何参与其中以及如何从中获益。
# 架构(Structure)
SCO 有多个 项目。每一个项目都由单独的 Github 仓库进行存储。这些项目由 用户 使用，由 贡献者 开发， 核心开发者 管理， 发布经理 发布 最终由 指导委员会 监督。这看起来与 Python 项目和 PEP8016 类似， 因为那是有意设计的。
# 角色与责任(Roles and responsibilities)
# 用户(Users)
用户是对项目有需求的社区成员。他们是下载和安装软件包的开发者和使用者。他们是社区中 最重要 的成员，没有他们，项目就没有意义。任何人都可以是用户，项目采用的许可证应该是适当的开源许可证。
SCO 认为 用户应该尽可能多的 参与项目与社区活动
用户贡献使项目团队能够确保他们满足这些用户的需求。常见的用户贡献包括（但不限于）：
- 宣传项目（例如：网站链接或进行宣传）。
- 从新用户的角度告知开发者优势与劣势。
- 提供精神支持（您的一句谢谢会让您受益匪浅）。
- 提供资金支持（该软件开源，但是开发者也需要糊口）。
长期参与 SCO 的项目和社区的用户，随着时间的推移，他们可能会发现自己成为贡献者，就如下一章节所述。
# 贡献者(Contributors)
贡献者是以具体的方式为一个或多个项目做出贡献的社区成员。 任何人都可以成为贡献者，贡献者可以有很多种形式。捐款和需求由每个项目通过捐献政策分别管理。
在贡献过程中，不需要对项目进行负责，也 没有具体技能要求，同样 不需要对人员进行选拔。
除了作为用户的行为之外，贡献者可能还会发现自己在做以下一项或多项事情：
- 为新用户提供技术支持（现有用户通常是为新用户提供技术支持的最佳人选）
- 报告错误
- 提交需求
- 提供图像设计或网站设计
- 编程
- 提供使用示例
- 协助项目进行改进
- 编写文档
- 修复 BUG
- 添加功能
- 提供建设性意见和参与社区讨论
贡献者通过 GitHub 和社区论坛参与项目。他们通过提交请求的方式向项目提交变更，这将被整个社区考虑纳入项目中。当做出第一次贡献时，社区论坛是寻求帮助最合适的地方。
事实上, 贡献者承担最多的任务可能是 参与社区对话。因为大多数关于项目方向的决定都是通过协商做出的。这将在下面详细讨论。但是，一般来说，有助于项目发展的事情，贡献者都可以 畅所欲言 （在行为准则的范围内）并 表达他们的意见和经验 以帮助达大家成共识。
随着贡献者获得开发经验和对项目的熟悉度逐渐提升，他们在社区中的形象和在社区中承担的责任会也会逐步提升。直到某个阶段，他们可能会发现自己已经成为了核心开发者。
# 核心开发者(Core Developer)
SCO 下的每一个项目都有自己的核心开发团队。他们是项目的负责人。
什么是核心开发者？
核心开发者是社区成员，他们通过长期参与社区活动，表明他们致力于项目的持续发展。作为一名核心开发人员，通过让贡献者直接访问项目资源，使得他们可以更好的完成项目相关的内容。他们可以直接对项目库进行更改，不必通过 frok 项目的方式。
这并不意味着核心开发者可以自由地做他们想做的事情。核心开发者并不比普通贡献者拥有更大的权力。他们并不能直接控制项目的最终发布。虽然这一荣誉确实表明他们作为社区中的重要成员对项目做出了具有积极意义的贡献，但他们的工作在正式发布前仍会受到社区的审查。
核心开发者能够在项目中做什么？
每个项目对核心开发者的定义可能略有不同。当然，通常来说，拥有这种称呼的人在社区中已经上升到一个信任的水平，因此他们现在被给予一些权限。这表现为对非受保护分支的推送权限，以及在批准请求时拥有发言权。
如何成为核心开发者？
任何人都可以成为核心开发者。除了表现出作为团队成员积极参与项目的意愿和能力之外，没有其他特殊要求。
通常，一个潜在的核心开发者需要展现出他对项目目标与理念的深度理解。他们还将在一段时间内为该项目做出宝贵贡献。但是，对于资格没有 技术 或 其他技能 的要求
新的核心开发者可以由现有的任何核心开发者 随时 提名。指导委员会每年至少举行两次投票（4 月 和 10 月）。投票应以无记名投票方式进行。该项目的每一个现有的核心开发者都将获得相当于选票上被提名者人数的票数。例如，如果有四个提名者，那么每个现有的核心开发者有四票。核心开发者可以投出他们的选票，但是不能将选票重复投给同一个候选人。被提名的候选人必须获得三分之二的选票数才会被批准。一旦被核心开发团队接受，指导委员会有责任批准并最终确定提名。指导委员会无权决定被提名人是否有足够的资格获得核心开发者称号。当然，在必要的情况下，他们保留否定投票结果的权利。
投票结束后，投票结果将在社区论坛上进行公布。被提名人有权要求对任何针对他们的否决进行解释。未被录取为核心开发者的被提名人，可以在之后的选举中被再次提名。
最重要的是要明白成为核心开发者是一种荣誉，而不是一种权利。只要成为核心开发者就必然获得这种荣誉。当然，指导委员会可以在极端情况下取消核心开发者称号（见下一节）。在正常情况下，只要个人希望继续参与项目和社区，核心开发者的头衔就一直存在。
对项目做出高于平均水平的贡献，特别是在战略方向和长期发展方面的贡献，可以被提名为指导委员会成员或发布经理。
核心开发者的权力和责任是什么？
如前所述，大多数决策都是通过协商并达成共识做出的。在某些情况下，当某个问题变得具有争议，或者需要做出重大决策时，发布经理或指导委员会可能会决定（或被要求）实施 RFC 流程，这将在之后进行详细介绍。
核心开发者在社区治理中同样拥有发言权。所有项目的所有核心开发者都有被提名为指导委员会委员和在选举中投票的权力。
本社区公约只能在三分之二活跃核心开发者的授权下进行更改，除非在采用后的前六个月内，多数核心开发者否定了多数活跃核心开发者的授权。
如果核心开发者变得不活跃怎么办？
虽然我们希望所有核心开发者能够定期参与并保持活跃。但是大家都明白，这种承诺有时并不现实。
因此，指导委员会有责任鼓励参与，并有责任将不再愿意或没有能力参与的核心开发者置于不活跃状态。这样做的主要目的 不是为了惩罚 一个人的行为，而是为了帮助那些确实保持活跃的人继续发展。
一个变得“不活跃”的核心开发者不应该拥有存储库的提交权，也不应该参与任何投票。为了有资格在选举中投票，核心开发人员必须在先前计划的项目发布时处于 活跃状态。
不活跃的成员可以随时要求指导委员会恢复他们的状态，根据这种请求，指导委员会应使核心开发者再次归为活跃状态。
如果个人知道他们将在一段时间内无法保持其活跃状态，则会被要求与指导委员会保持联系，并在必要时宣布自己处于不活跃状态。
“活跃的”核心开发者是指在过去六个月中以有意义的方式参与的核心开发者。最终解释权归指导委员会所有。
# 发布经理(Release Manager)
核心开发者只能在不受保护的分支上进行提交和合并。主分支和其他受保护的分支由该项目的发布管理团队控制。发布经理应由核心开发团队从核心开发团队中选出，并应在整个发布周期为大家服务。
每个核心开发团队可以决定每个发布周期有多少个发布经理。建每一个发布周期至少有两个发布经理，以分担职责。不能让一个人承担所有的压力。但是，也不应该有太多的发布经理，这样项目维护起来会变得十分繁琐。
发布管理团队的主要职责：
- 通过监听和促进技术讨论来推进开发周期
- 制定发布日历并执行发布所需的操作
- 批准对主分支和其他受保护分支的请求
- 将请求合并到主分支和其他受保护的分支
发布经理 无权否决或拒绝 那些 符合贡献标准并已被社区接受 的合并请求。他们无权决定开发什么。他们的责任是执行社区的决定，推进项目的进度。
有时，可能需要做出无法通过协商达成共识的决定。在这种情况下，发布经理有权要求 RFC 流程删除决策。这种情况不应经常发生（除非有以下讨论的要求）。不应该鼓励使用这种方法，而是采用更有利于建立社区共识的方法。
由于并非所有的项目都有相同的要求，所以管理项目发布经理的细节应在本公约的附录或项目贡献指南中规定。
如有必要或出于其他正当理由，指导委员会有权撤换失职的发布经理。
# 指导委员会(Steering Council)
指导委员会是由被确定为 “项目所有人” 并控制 SCO 资源和资产的个人组成的管理组织。他们的最终目标是通过消除障碍，并根据需要帮助成员，以确保项目的顺利进行。预计他们将成为社区的常客。
指导委员会能做什么？
指导委员会的成员 没有 比其他任何核心开发者更多的权力，也没有任何额外的权利对项目进行决策、提交、合并等。
但是，指导委员会具有以下职能：
- 同意、搁置和拒绝所有的 RFC 建议
- 强制执行社区行为准则
- 管理社区资产，如存储库、服务器、论坛、集成服务等（或者将这些权限委托给其他人）
- 在适当的情况下，将核心开发者置于不活跃状态，并采取本政策中规定的任何其他强制措施。包括在极端情况下，移除核心开发者
- 从社区保护伞下采纳或移除项目
我们强烈建议指导委员会尽可能将其权力授予其他有意愿的社区成员。
指导委员会 无权更改 本决策。
指导委员会有多少成员？
4 个。
虽然只拥有 4 票的委员会可能会陷入僵局，无法打破多数票，但指导委员应该尽可能少地投票。相反，它应该努力以协商一致的方式工作。在有必要就一个问题进行表决时，需要三票同意。
指导委员的任期是多久？
单个任期应为两年，从 1 月开始。任期应错开，以便于每年有两名成员从上一年的理事会延续下来。
因此，选举投票将有两个任期为两年的职位，两个任期为一年的职位。
可以任职的任期没有限制，个人有可能连续任职。
指导委员会如何运作？
指导委员会选出后，小组应集体决策由一人担任主席。主席的权力和其他委员完全相同，没有任何额外的权力。
主席的作用仅仅是作为协调者和推动者。主席应确保遵守所有治理规则。该职位更多的是行政和文书工作，预计主席将制定议程并协调小组讨论。
指导委员是如何选出的？
每年一次，所有核心开发者 都有权选举指导委员会委员。
选举提名从 9 月 1 日开始，9 月 30 日截止。投票于 10 月 1 日开始，10 月 31 日结束。每个在 6 月份发布该年度版本时活跃的核心开发者都能够参与选举和投票，每一位核心开发者都能获得相当于空缺的指导委员数量的选票。为了公平起见，核心开发者 不需要 是 Sanic Framework 的核心开发者，而是在各自的项目中处于活跃状态的核心开发者。
获得票数最多的核心开发者将被宣布成为指导委员会委员。如果有任何平票，强烈建议平票的被提名者自己解决争议，然后再随机做出决定。
关于指导委员会的创始投票，得票最多的两位当选者任期两年，之后两位当选者将获得一年的任期。
想要成为指导委员会的合格候选人，该候选人必须在过去的 12 个月中至少是一个项目的活跃核心开发者。
如果空缺怎么办？
如果指导委员会在某个任期内存在空缺，则应提供上一次选举中得票次高的候选人来完成剩余任期。如果找不到合适的人选，指导委员会可以决定最合适的人选（通过任命、投票或其他方式）。
如果指导委员会的一名成员处于不活跃状态，则该成员应立即从指导委员会中除名，该席位将空缺。
在极端情况下，所有的核心开发者团队有权以投票的方式表决罢免指导委员会委员（需要超过三分之二的核心开发者赞同）
指导委员会应如何展开工作？
指导委员会应尽可能公开开展工作和讨论。社区的任何成员都可以和他们进行对话。当然，有时私下讨论可能是必要的或适当的。选择合适的谈话地点是主席管理职责的一部分。
虽然如何操作的细节超出了本公约的范围，但我们鼓励指导委员会尝试每季度至少召开一次“实时”讨论会议。这可以通过视频会议、实时聊天或其他适当的方式来实现。
# 支持(Support)
鼓励社区中的所有参与者在项目管理基础架构中为用户提供技术支持。这种支持是作为社区发展的一种方式提供的。寻求支持的人应该意识到，项目中的所有技术支持都是自愿的，是在时间允许的情况下提供的。因此，要求保证响应时间或结果的用户应该寻求从社区成员处购买支持。当然，对于那些愿意以自己的方式参与项目，并愿意帮助支持其他用户的人来说，社区支持渠道是最理想的。
# 决策过程(Decision making process)
从最新用户到最有经验的成员，通过与社区所有成员的讨论来决定项目的未来。每个人都具有发言权。
所有非敏感项目管理讨论都在社区论坛或其他指定渠道进行。偶尔，敏感的讨论可能会私下进行。
为了确保项目不会因无休止的讨论和持续的投票导致停滞不前，该项目采取了 惰性共识 政策。这使得大多数决策无需正式投票即可做出。对于任何 重大决策 (定义如下)，都有单独的征求意见（RFC）流程。
# 技术决策(Technical decisions)
技术决策通常应分为以下几类：
常规决策：文档修复，用于清理或附加测试代码的更改。功能没有变化。
次要决策：对代码库的修改，修复一个错误或引入一个无关紧要的特性。没有突破性的变化。
重要决策: 对代码库的任何更改都会中断或弃用现有的应用接口，以一种非同寻常的方式改变操作，或者增加一个重要的特性。
发布经理通常有责任确保对存储库的更改在合并之前得到适当的授权。
发布经理有权单独审查和接受符合代码质量标准的常规决策，而无需额外的输入。
# 惰性共识(Lazy consensus)
决策(无论是由社区还是指导委员会)通常包括以下步骤:
- 提议
- 讨论
- 投票(如果讨论未达成共识)
- 决策
任何社区成员都可以提出建议供社区考虑。为了发起关于一个新想法的讨论，他们应该在社区论坛的适当渠道上发布一条消息，或者在 GitHub 上提交一个实现该想法的请求。这将促进对这一想法进行审查，并在必要时进行讨论。
本次评审和讨论的目的是获得对贡献的认可。由于项目社区中的大多数人都有一个共同的愿景，因此通常很少需要讨论来达成共识。
一般来说，只要没有人明确反对一个提案或补丁，它就被认为得到了社区的支持。这叫惰性共识；也就是说，那些没有明确表示意见的人已经含蓄地同意了执行这项建议。
惰性共识是 SCO 内一个非常重要的概念。正是这一过程使一大群人能够有效地达成共识，因为对一项提议没有异议的人不需要花时间阐述他们的立场，其他人也不需要花时间阅读这些信息。
为了使惰性共识有效，有必要在假设没有人反对该提案之前留出适当的时间。这在一定程度上取决于具体情况，但一般认为 72 小时是合理的。这一要求确保每个人都有足够的时间阅读、消化和回应提案。选择该时间段是为了尽可能包容所有参与者，无论他们的位置和时间如何。讨论主持人（无论是主席还是发布经理）应负责确定达成此类共识的适当时间长度。
如上所述，关于所谓的常规决策，发布经理有权在较短的时间内做出决策。在这种情况下，应暗示惰性共识。
# 意见征求(Request for Comment)(RFC)
指导委员会应负责监督意见征求的过程。这将是一个向社区所有成员开放的辩论过程，并应留出充足的时间来审议一项提案，让成员做出回应并参与有意义的讨论。
最终决定权属于指导委员会。但是，强烈建议指导委员会不要通过与社区中可能存在的任何共识相悖的决定。有时可能会发生共识与整体项目和社区目标之间存在冲突的情况。
应该按照指导委员会的规定，以公开的方式向指导委员会提交建议书，从而启动征求建议书。辩论应继续进行，并由指导委员会，特别是主席提供便利。
在指导委员会认为合适的情况下，可以放弃征求建议书程序，达成惰性共识。