在许多关于开源项目和社区治理的讨论中，人们往往专注于“代表项目发言”或“Web 域名的所有权”等活动或资源。 虽然记录这些东西很有用，但它们并不是真正的治理问题。 或者，其他人只专注于技术问题，如选举规则、行为准则和发布程序。 虽然这些可能是治理的工具，但它们本身并不是治理。
那么，究竟什么是开源项目治理？
简而言之，治理是项目决定谁可以做什么或应该做什么、如何做以及何时做的规则或惯例。
对于寻求发展其治理模式的开源社区，治理的这一定义可以引发重要的问题。 让我们探讨一下如何做到这一点。
定义治理
上述治理的定义仍然有点笼统，所以让我们更具体一些。 当您为一个项目定义治理时，您需要确定以下五个事项
- 贡献者可以在项目中扮演哪些角色？
- 每个角色有哪些资格、职责、特权和权力？
- 人们如何被分配到（和从）角色？
- 如何更改角色定义？
- 项目的集体政策和程序是什么？
开源社区中的许多活动都取决于项目角色。 每个社区都有其贡献者扮演的角色，但不幸的是，许多项目没有正式定义这些角色及其职责。 将角色视为每个项目参与者拥有的“工作”。 一个贡献者可以有多个角色，并且许多角色由多个贡献者共享。
例如，“首席代码维护者”是一个角色，“新贡献者”或“聚会组织者”也是一个角色。 虽然这些角色没有写下来，但它们隐含在人们已经参与的活动中（并且可能成为争论的来源）。 因此，为一个项目定义治理的过程主要是记录角色，包括现有角色和项目应该/将要创建的角色。
了解你的角色
例如，治理文档可以定义“文档维护者”的角色，其一般描述如下
- 资格：多年为文档做贡献
- 职责：编写文档并审查其他人的文档
- 特权：代表文档团队发言，参加开发会议
- 权力：决定文档内容、生产工具链和策略
- 更改程序：所有现有文档维护者投票决定角色更改
实际上，书面角色描述比这要详细得多（一些项目的正式角色描述可以运行十几页或更多）。
此外，一些角色是集体的——更多关于群体而不是个人——某些政策和程序可能适用于这些集体角色。 例如，可能有一个“指导委员会选举程序”来定义职责和特权。 当然，行为准则通常适用于项目中的所有角色。
这就是政策和程序变得重要的地方。 如果记录良好，它们会解释特定活动应该如何由角色组执行。 但它们不能独立存在； 它们需要角色描述才能有意义。 例如，假设您想为您的指导委员会编写选举程序。 在此之前，您需要定义谁是项目的投票成员以及指导委员会成员做什么。
大型开源项目可以包含数十个或数百个潜在定义的角色，特别是因为每个角色通常也有子角色。 例如，在 Kubernetes 中，“代码贡献者”的角色按特别兴趣小组 (SIG) 和贡献者级别（成员、审核者、批准者和所有者）进行细分。 因此，某人的实际角色将是“SIG-Network 批准者”，而不仅仅是“代码贡献者”。 另一方面，较小的项目应该定义较少的角色，并使他们的描述更通用。
开始使用
如果您的开源项目或社区的治理模式正在发展——或者如果您是第一次记录或正式化它——社区应该问自己以下问题以产生富有成效的讨论
- 项目贡献者在这个社区中扮演什么角色？
- 这些角色是否已明确定义或描述？
- 这些角色定义或描述是否可供参与项目的所有人访问？
- 这些角色描述是否还解释了贡献者如何承担或离开这些角色？
这些问题看起来很简单——但您收到的答案可能比您预期的要复杂得多。
本文改编自 The Open Source Way 项目。
1 条评论