本文档提供了PlatON开源项目运作所依据的治理指南。它定义了角色和职责、谁可以投票、投票如何进行、如何解决冲突等。PlatON由LatticeX基金会支持和推动项目，并遵循现有LatticeX基金会相关章程约束（具体查看LatticeX基金会网站），本指南作为 LatticeX基金会章程的补充，将使所有人能够清晰的了解PlatON项目的运作方式。
PlatON社区化开发治理指南（初稿）
概述
我们的目标是让PlatON成为社区化驱动、开放性开发、可持续发展的开源项目。
PlatON将基于共识的精英制治理模式进行管理，任何对项目感兴趣的人都可以加入社区，为项目发展做出贡献并参与决策过程。本文档描述了PlatON项目中参与者的角色职责，参与方式，决策过程，以及如何在项目社区内获得成就。
角色和责任
用户
用户是那些对项目有需求的社区成员。他们是社区中最重要的成员，任何人都可以成为用户，没有特殊要求。
我们期望用户能够尽可能地参与到项目和社区中来，为项目提供持续改进建议和需求。常见的用户贡献包括（但不限于）：
- 对项目进行宣传（例如，给网站增加项目链接和口碑宣传）
- 积极参与项目讨论、问题反馈和功能建议
- 从新用户的角度告知开发者项目的优势和劣势
- 提供精神上的鼓励和支持（一句 "谢谢"会有很大的帮助）
贡献者
贡献者是以具体方式为项目做出贡献的社区成员。任何人都可以成为贡献者，没有具体的贡献预期，没有具体的技能要求，也没有筛选过程。贡献者可以采用多种形式参与贡献，详见How to Contribute to Open Source。
除了作为 “用户” 的行动外，贡献者还可以做以下一项或多项工作：
- 社区支持（例如，解答新用户问题）
- 反馈bug（在GitHub上提交issue）
- 修复bug
- 审核他人提交的代码
- 识别需求
- 提供图形和网页设计
- 编写代码
- 协助建设项目基础设施（例如，改进工具和测试）
- 编写文档（例如，撰写教程、解决方案、技术科普稿、以及改进项目文档）
- 新增特性
- 内容翻译和信息整理
- 组织活动（例如，组织研讨会、线上线下分享等）
贡献者通过Issue跟踪器和公开的邮件列表(dev)，或通过编写或编辑文档参与项目。并通过补丁向项目提交修改，由提交者合并入项目。
在开始参与第一个贡献时，您可以使用开发者“dev”邮件列表寻找帮助。
随着贡献者获得经验和对项目的熟悉，他们在社区中的形象和对社区的贡献也会增加。在某个阶段，他们可能会发现自己被提名为提交者。
提交者（维护者）
提交者是项目开发管理的社区成员，被授予对PlatON相关项目的写入权限。提交者身份可以使其更加轻松地进行与项目相关的活动，比如，直接对项目内容进行修改而不需要通过补丁提交修改。
但是，这并不意味着提交者可以自由地做他们想做的事。提交者的改动在被正式发布前仍需经由社区的审查。提交者和贡献者之间的关键区别在于何时向社区寻求批准。其中贡献者是在做出贡献之后而不是之前寻求批准。
任何人都可以成为提交者；除了表现出有意愿和能力参与项目之外，没有其他任何特殊要求。一般来说，潜在的提交者需要表明他们对项目、目标和战略有一定的了解。
每个项目的提交者都是单独选举的，新的提交者可以由任何现有的项目提交者来邀请，一旦他们被提名，项目管理委员会（PMC，见下文）将进行投票。提交者投票将通过项目的私人邮件列表(pmc)进行，这是为了让PMC成员能够自由地表达他们对被提名人的意见，而不会造成尴尬。一旦投票结束，汇总的投票结果将公布在公共邮件列表(dev)中。无论投票结果如何，被提名人都有权要求对任何反对他们的 "反对 "票做出解释。这种解释将由PMC主席（见下文）基于匿名提供。
被提名人可以拒绝接受成为提交者的任命。然而，我们不鼓励这样做，因为该项目并不期望其有任何具体的时间或资源贡献。提交者角色背后的意图是让人们更容易为项目做出贡献，而不是以任何正式的方式将他们与项目绑在一起。
提交者如果对项目的贡献超过平均水平，特别是在项目的战略方向和长期发展方面，可以被提名成为PMC成员。
项目管理委员会（PMC）
项目管理委员会由各开发站点被确定为“项目所有者”的个体组成，即各项目及子项目的提交者及核心贡献者组成。PMC除包含提交者的责任之外还有其他责任，大致包含审查代码贡献，参与战略规划，批准治理模式的变化等。这些责任确保了项目的顺利运行。
PMC成员相对社区的其他成员并没有很大的权力，PMC主要拥有对新提交者和PMC成员的投票权。当社区无法达成共识时，拥有最终决定权。以及项目的私人邮件列表（pmc）和档案的访问权。注意这个私人邮件（pmc）列表仅用于处理敏感问题，例如对新提交者的投票和不能公开讨论的法律问题。
项目管理委员会每两周召开一次线上会议，您可以在“项目管理委员会议”仓库中提出您需要进行的讨论议题。
PMC成员是由现有的PMC成员邀请的。提名后需经过现有PMC成员的讨论，然后进行投票，经PMC成员的批准后方可成为PMC成员。
PMC的主要职责包括：
- 监督提交日志消息并确保代码库没有版权和许可问题，确保项目正朝着预期的方向发展。
- 保持对邮件列表和社区的监督，以确保维护开放性开发的理念。
- 解决与项目产品有关的纠纷。
- 决定项目的产品发布。所有的发布必须由PMC批准。
- 指导项目方向。
- 建设并维护和谐的开发者社区。
- 提名新的PMC成员和提交者。
- 维护项目的共享资源，包括代码库、邮件列表、网站。
- 代表项目发言。
- 维护项目治理及其他指南。
PMC成员可申请转换为“名誉成员”，通过发邮件至PMC私人邮件列表(pmc)，我们将跟进并调整名单。同时“名誉成员”可以向PMC 请求恢复到PMC成员。此类复职须经 PMC 成员一致批准。另外在 PMC 成员（相关成员除外）一致同意下，可以撤销相关PMC成员资格。
关于提交者和 PMC成员的选举，当发现拥有奉献精神且始终如一的新人时，PMC将会逐一评估讨论，并在私人 PMC 邮件列表上进行投票选举，以便能够进行坦诚的讨论，这样我们就不会对人进行公开讨论。
PMC主席
PMC的主席由PMC成员投票选出。一旦有人被任命为主席，他们将一直担任这一职务，直到他们选择退休，或者PMC投出三分之二的多数票将其撤换。
项目管理委员会主席对项目管理委员会的其他成员没有额外的权力：其角色是协调者和促进者。主要职责包含：
-
确保所有的管理程序得到遵守。
-
在项目未能达成共识时拥有决定性投票权。
-
每季度向LatticeX基金会提交开源社区运营报告（包含开源社区的状况，以及技术进展）。
社区支持
我们鼓励社区中的所有参与者为项目的新用户提供支持。这种支持是作为发展社区的一种方式提供的。那些寻求支持的人员应认识到项目内的所有支持活动都是自愿的，因此应在时间允许的情况下提供。
目前提供的支持渠道有
- 公开邮件列表（dev），通过发送邮件寻求支持（推荐）
- GitHub，通过在对应项目的issue上寻求支持（推荐）
- LatticeX论坛，通过在对应项目板块下发布帖子寻求支持
- Discord，通过在对应频道上发布消息寻求支持
决策过程
项目的决策是通过与社区的所有成员讨论作出的，从最新的用户到最有经验的PMC成员。
所有非敏感的项目管理讨论都将在公开场合进行，并提供公开记录，以此鼓励开放，并刺激更广泛的社区参与。
偶尔，敏感的讨论会发生在一个私人邮件列表（pmc）中。私人邮件列表通常仅用于与个人有关的事务（例如对新提交者进行投票）以及需要保密的法律事务。未避免敏感信息泄露，造成不必要的混乱和不明智的讨论，未经明确许可，您不得公开披露此类列表中的信息。
为了确保项目不被无休止的讨论和不断的投票所拖累，项目主要采用了懒惰的共识政策，因此大多数日常操作并不需要明确的投票。
懒惰共识
决策通常包含以下步骤：
- 提议
- 讨论
- 投票（如果没有通过讨论达成共识时，将进入投票表决）
任何成员都可以对项目提出建议想法供社区讨论，为了发起对一个新想法的讨论，发起者可以在GitHub对应项目issue跟踪器上提交想法、或者通过版本控制系统（Pull request）提交实现该想法的补丁，以及给项目公开邮件列表（dev）发送邮件，这将促使社区对这个想法进行讨论和审查。这种审查和讨论的目的是为了获得对该贡献的批准。
一般来说，只要没有人明确反对这个建议或补丁，它就被认为得到了社区的支持。这就是所谓的懒惰共识–也就是说，那些没有明确表示意见的人已经隐含地同意了该提案的实施。
为了使懒惰共识有效，有必要对在假设提案没有反对意见之前，留出至少72小时（3天）。这一要求确保每个人都有足够的时间来阅读、消化和回应提案。选择这个时间段是为了尽可能地包容所有的参与者，无论他们处于哪个位置和时间。
投票
并非所有的决策都可以采用懒惰共识的方式作出，例如影响项目战略方向的问题就必须以投票的形式获得明确的批准。
PMC成员（包含项目提交人）拥有正式的具有约束力的投票权。但总体而言，我们鼓励社区的每个成员在所有的讨论和投票中表达你们的意见。
项目的某些行动和决定将通过项目公开邮件列表的投票做出。必要时（例如，讨论和投票成为新提交者的特定人员）可在私人邮件列表（pmc）上进行。
投票需清楚地以【VOTE】开头的邮件主题标识，讨论和提案应该在投票之前进行。投票是通过回复投票邮件进行，投票使用以下符号表示：
| +1 | “是”、“同意”或“应该执行该操作”。总的来说，这张票表明了投票者愿意协助“实现它”。 |
|---|---|
| +0 | 这张票表示愿意继续进行所考虑的行动。然而，投票者将无法提供帮助。 |
| -0 | 这张票表明，投票者总体上不同意所提议的行动，但也没有达到阻止行动的进行。 |
| -1 | 这次投票算作否决权。所有否决权都必须包含对否决权适当的解释。没有解释的否决本次投票无效，也可以适当地包含一个备选的行动方案。 |
| 弃权 | 可以投弃权票。他们可以保持沉默或表达自己的理由。 |
我们鼓励项目的所有参与者通过投票表明他们对某一行动的偏好。当投票被统计时，只有PMC成员的投票具有约束力。不具约束力的投票仍然是有用的，可以使大家了解更广泛的社区对一项行动的看法。
投票共识也可以应用于对项目代码库的修改。通常采取否决的形式（-1），作为对提交补丁是否认可合并的回复。
批准类型
不同的行动需要不同类型的批准：
| 类型 | 描述 |
|---|---|
| 共识批准 | 共识批准需要 3 个及以上有约束力的 +1 票，且没有有约束力的否决票。 |
| 懒惰的多数（多数共识） | 懒惰多数投票需要3张有约束力的+1票，并且有约束力的+1票多于-1票。 |
| 懒惰的批准 | 除非收到 -1 投票，否则隐式允许使用惰性批准的操作，此时，根据操作的类型，必须获得惰性多数或共识批准。 |
| 2/3 多数 | 有些行动需要2/3 PMC 成员的批准。此类操作通常会影响项目的基础。较高的门槛是为了确保这种变化得到强有力的支持。要通过这种投票，需要至少有2/3的投票为+1。 |
| 一致共识 | 投出的所有选票都为 +1，并且不能有具有约束力的否决权 (-1)。 |
否决权
有效的否决权不能被推翻，只能由其发出者撤回。任何否决权都必须附有理由并准备为其辩护。
否决权的有效性，如果受到质疑，可以由任何有约束力的投票者确认。这过程并不一定意味着同意该否决权–而仅仅意味着该否决权是有效的。如果对否决权是否有效存在争议，则 PMC 主席的意见为最终意见。
如果您不同意该有效的否决权，那么您必须与投否决权的人进行进一步讨论。因此否决者有义务提前投票，然后与社区合作解决问题。
如果最终不撤回该有效的否决权，被否决的行动必须及时撤回。
行动
本节描述了在项目中采取的各种行动、该行动所需的相应批准以及对行动具有约束力的投票者。
| 行动 | 描述 | 赞同 | 约束性投票 |
|---|---|---|---|
| 代码更改 | 提交者对项目代码库所做的更改。这包括源代码、文档、网站内容等。 | 懒惰的批准 | PMC成员 |
| 发布计划 | 定义发布的时间表和操作。发布计划不能被否决（因此是懒惰的多数）。 | 懒惰的多数 | PMC成员 |
| 产品发布 | 当项目产品的发布准备就绪时，需要投票以接受该发布作为项目的正式发布。 | 懒惰的多数 | PMC成员 |
| 采用新的代码库 | 当现有的已发布产品的代码库将被替换为替代代码库时。如果这样的投票未能获得批准，现有的代码库将继续。这个将包括在项目内创建新的子项目。 | 2/3 多数 | PMC成员 |
| 新提交者 | 当为项目提议新的提交者时。 | 共识批准 | PMC成员 |
| 新 PMC 成员 | 当为 PMC 提议新成员时。 | 共识批准 | PMC成员 |
| 恢复名誉成员 | 当为名誉成员恢复PMC成员时。 | 共识批准 | PMC 成员（不包括相关成员） |
| 提交者移除 | 当寻求解除某提交者的提交特权时。 | 一致共识 | PMC 成员（如果是 PMC 成员，则不包括相关提交者） |
| PMC 成员移除 | 当寻求删除PMC成员时。 | 一致共识 | PMC 成员（不包括相关成员） |
投票时间
投票通常开放一周，以便让所有活跃的投票者有时间考虑投票事宜。如果投票未达到法定人数（PMC主席决定是否有足够的人投票），则可以再延长一周。如果仍然没有达到法定人数，则投票失败，并需要在以后时间点再次提出。与代码更改相关的投票不受严格时间表的限制，应尽可能及时进行。
投票时请注意各地区的节假日。由于我们无法完全了解世界各地的习俗，所以如果有人知道投票时间有问题，请及时反馈出来。
最终决定
对于崩溃故障和需要一致同意的情况，如果不能在延长的时间内达成一致意见，则LatticeX基金会与PMC主席将基于项目战略目标和方向并做出最终决定。
沟通渠道
沟通主要通过项目公开邮件列表（dev）方式进行，任何时区的任何人都可以参与。
所有的决定都在 "dev "邮件列表中做出。用户支持的主要渠道是 "users"邮件列表。
偶尔我们会使用其他通信渠道，如Discord。这些渠道只用于特定的目的，并不是永久可用的。
最后需要说明的是，我们不鼓励任何私人讨论。
贡献和认可
对与开源项目，任何人无论技术如何都可以找个参与贡献的方法，从项目的设计讨论，监督，测试，文档、错误等方面都可以进行支持。
开放性开发的原则是确保每个贡献者都得到认可并感受到自己是社区中富有成效的一部分。
由于贡献的多元化，贡献的认可主要体现在：
- 鼓励贡献者加入邮件列表，相互尊重，并公开合作。
- 鼓励贡献者通过issue提交问题和修复补丁，以清晰的记录贡献者
- 提交者及时响应贡献者的补丁合并请求
- 提交者在项目更改文档中为每个重要贡献添加一个条目，链接到相关贡献并显示贡献者信息。
- 现有的PMC将邀请新的贡献者成为新的提交者/ PMC成员。
- 列出提交者/PMC成员名单
如上所述，没有具体的文件来列出每个贡献者和他们的贡献内容。对于那些感兴趣的人，可以通过相关机制进行确认：如使用互联网搜索服务；使用提交者ID和贡献者姓名搜索邮件列表；浏览项目更改记录页面等。