开源数据治理_什么是开源项目治理？

开源数据治理

在关于开源项目和社区治理的许多讨论中，人们倾向于关注活动或资源，例如“为项目发言”或“网络域所有权”。 尽管记录这些事情很有用，但它们并不是真正的治理问题。 另外，其他人则专门关注技术问题，例如选举规则，行为守则和发布程序。 尽管这些可能是治理的工具，但它们本身并不是治理。

那么开源项目治理到底是什么？

简而言之，治理是项目的规则或习惯，由它决定谁去做或应该去做，应该如何去做以及何时去做。

治理的这种定义可以为寻求发展其治理模型的开源社区提出重要问题。 让我们探讨一下。

定义治理

但是，上面对治理的定义仍然有些笼统，因此让我们更加具体。 在定义项目的治理时，需要确定以下五件事：

1. 贡献者可以在项目中扮演什么角色？
2. 每个角色与哪些资格，职责，特权和权限相关联？
3. 人们如何被分配到角色（或从角色中删除）？
4. 如何更改角色定义？
5. 项目收集了哪些政策和程序？

例如，“领导代码维护者”，“新贡献者”或“会议组织者”都是角色。 虽然这些角色没有被写下来，但它们隐含在人们已经从事的活动中（并可能成为争论的来源）。 因此，为项目定义治理的过程主要是记录角色的过程，既包括现有角色，也包括项目应/将要创建的角色。

了解你的角色

例如，一个治理文档可以定义“文档维护者”的角色，通常可以这样描述：

• 任职资格：几年来为文档做贡献
• 职责：编写文档并查看其他人的文档
• 特权：代表文档团队，参加开发会议
• 权限：决定文档内容，生产工具链和策略
• 变更程序：所有现有的文档维护者都对角色变更进行投票

实际上，书面角色描述要比这更为详细和明确（某些项目的正式角色描述可以运行十几页甚至更多页）。

此外，某些角色是集体角色，而不是个人，更多的是团体角色，某些政策和程序可能适用于这些集体角色。 例如，可能存在定义职责和特权的“指导委员会选举程序”。 而且，当然，行为准则通常适用于项目中的所有角色。

这是政策和程序变得重要的地方。 有据可查，他们解释了角色组应该如何执行特定的活动。 但是他们并不独立。 他们需要角色描述才能有意义。 例如，假设您想编写指导委员会的选举程序。 在此之前，您需要定义谁是项目的投票成员以及指导委员会的成员。

大型开源项目可以具有数十个或数百个可能定义的角色，尤其是因为每个角色也经常具有子角色。 例如，在Kubernetes中，代码贡献者的角色按特殊兴趣小组（SIG）和贡献者级别（成员，审阅者，批准者和所有者）细分。 因此，某人的实际角色将是“ SIG网络批准人”，而不仅仅是代码贡献者。 另一方面，规模较小的项目应定义较少的角色，并使其描述更为笼统。

入门

如果您的开源项目或社区的治理模型正在发展，或者您是第一次对其进行文档化或形式化，则社区应该问自己以下问题，以进行富有成效的讨论：

• 项目贡献者在这个社区中扮演什么角色？
• 是否明确定义或描述了这些角色？
• 这些角色定义或描述是否可供项目中的每个人访问？
• 这些角色描述是否也解释了贡献者如何担任或离开角色？

这些问题看似直截了当，但您将收到的答案可能比您预期的要复杂。

本文改编自 The Open Source Way项目 。

翻译自: https://opensource.com/article/20/5/open-source-governance

开源数据治理