菜单
文档面包屑箭头 Grafana Loki面包屑箭头 社区面包屑箭头 治理
开源

治理

本文档描述了项目的规则和治理。项目的所有开发者和 Loki 社区都应遵守这些规则。本文档中使用的常见术语列举如下：

  • 团队成员: 私有团队邮件列表的任何成员。

  • 维护者: 维护者负责领导单个项目或其中的一部分 (MAINTAINERS.md)。

  • 项目: 以下列出的 Grafana GitHub 组织中的单个仓库被称为一个项目

    • loki
    • puppet-promtail

  • Loki 项目: 本治理文档下进行的所有与一个或多个仓库或社区相关的活动的总体。

  • Loki SIG (特别兴趣小组) Operator: 本治理文档下进行的所有与仓库子文件夹 operator 或其特定社区相关的活动的总体。

价值观

Loki 开发者和社区成员应遵循行为准则中定义的价值观。此外，Loki 社区努力做到友善、有效提供反馈并营造受欢迎的环境。Loki 开发者通常通过共识进行决策，只有在无法达成共识时，才会诉诸多数投票解决冲突。

项目

每个项目必须有一个MAINTAINERS.md 文件，其中至少包含一位维护者。对于有发布流程的项目，应提供必要的访问权限和文档，以便多人能够执行发布。发布应在发布和用户邮件列表上宣布。任何新项目都应首先按照下述投票程序在团队邮件列表上提出。

决策制定

团队成员

持续为 Loki 项目贡献至少 3 个月的人员可能会被授予团队成员身份。这通常以代码改进和/或在文档方面做出显著工作为形式，但组织活动或提供用户支持也可被考虑在内。

任何现有成员都可以通过电子邮件向团队邮件列表提议新成员。强烈建议对是否接受新成员达成共识。然而，提案最终将通过正式的绝对多数投票进行表决。

如果新成员提案被接受，应通过电子邮件私下联系被提议的团队成员，以确认或拒绝其接受团队成员身份。此电子邮件也将抄送至团队邮件列表，以便记录存档。

如果他们选择接受，则遵循入职程序。

团队成员可以随时通过电子邮件告知团队来退出。

团队成员可以通过绝对多数投票在团队邮件列表上被移除。在此投票中，涉及的成员没有投票资格，也不计入法定人数。任何移除投票只能针对一个人。

成员去世后，将自动退出团队。

如果成员离开，则执行离职程序。

当前团队成员有：

当前的 Loki SIG Operator 团队成员有：

维护者

维护者负责领导一个或多个项目或其中的一部分，并在项目贡献者之间解决冲突。理想情况下，维护者也是团队成员，但对于由于某种原因尚未成为团队成员的合适维护者，也可以有例外。

维护者变更必须在开发者邮件列表上宣布。这些变更通过大致共识决定，并通过修改相应仓库的MAINTAINERS.md 文件来正式确定。

维护者被授予对本治理文档涵盖的所有项目进行提交的权限。

维护者或提交者可以通过通知团队邮件列表来辞职。一年内没有项目活动的维护者被视为已辞职。希望辞职的维护者被鼓励推荐另一位团队成员来接管该项目。

一个项目可以有多位维护者，只要他们之间明确约定职责。这包括协调谁处理哪些 issue 和 pull request。

技术决策

仅影响单个项目的技术决策由该项目的维护者非正式地做出，并假定已达成大致共识。涉及项目多个部分的技术决策应在开发者邮件列表上讨论并做出。

决策通常通过大致共识做出。如果无法达成共识，可以通过多数投票解决问题。

治理变更

本文档的变更由 Grafana Labs 负责。

其他事项

任何需要决策的事项，如果任何成员认为有必要，都可以发起投票。对于私有或人事相关事项，讨论和投票在团队邮件列表上进行；否则，在开发者邮件列表上进行。

投票

Loki 项目通常通过非正式共识运作，但有时必须做出正式决策。

根据上述主题，采用不同的投票方法。

所有投票必须开放至少一周。投票截止日期应在投票号召中明确说明。如果某个方向的票数已足够，使得进一步的投票无法改变最终决定，则可以提前发起并结束投票。

在所有情况下，只有且所有团队成员有资格投票，唯一的例外是强制移除团队成员的情况，在这种情况下，该成员没有投票资格。

人事相关事项（包括但不限于团队成员资格和维护者身份）的讨论和投票在团队邮件列表上私下进行。所有其他讨论和投票在开发者邮件列表上公开进行。

对于公开讨论，鼓励任何感兴趣的人参与。正式的反对或投票权仅限于团队成员。

共识

Loki 项目默认的决策机制是大致共识。这意味着只要没有人反对，或者反对意见已被考虑但不必被采纳，任何技术问题上的决策都被视为得到了团队的支持。

对任何共识决策保持沉默即表示默示同意，等同于明确同意。可以随时明确表示同意。决策可以（但并非必须）在任何时间由任何人提出，并在开发者邮件列表上进行决策。

共识决策永远不能凌驾于或违背早期明确投票的精神。

如果任何团队成员提出反对意见，团队成员会共同努力达成所有参与者都能接受的解决方案。该解决方案再次受大致共识的约束。

如果无法达成共识，但又必须做出某种决定，任何团队成员都可以发起正式的多数投票。

多数投票

多数投票必须在相应的邮件列表上另起主题明确提出。主题必须带有前缀 [VOTE]。在正文中，投票号召必须说明正在投票的提案。它应引用之前的所有相关讨论。

投票可以采用单个提案，选项为是或否；也可以采用多个备选方案的形式。

如果赞成票多于反对票，则单个提案的投票被视为成功。

如果存在多个备选方案，成员可以投票支持一个或多个备选方案，或者投“否”以反对所有备选方案。不允许投“弃权”票。对多个备选方案的投票，如果某个备选方案获得的赞成票最多，且赞成票来自半数以上的投票者，则该备选方案被视为最终决定。如果没有备选方案达到此法定人数，可以另行发起一次关于减少选项数量的投票。

绝对多数投票

绝对多数投票必须在相应的邮件列表上另起主题明确提出。主题必须带有前缀 [VOTE]。在正文中，投票号召必须说明正在投票的提案。它应引用之前的所有相关讨论。

投票可以采用单个提案，选项为是或否；也可以采用多个备选方案的形式。

如果至少三分之二符合投票资格的人投赞成票，则单个提案的投票被视为成功。

如果存在多个备选方案，成员可以投票支持一个或多个备选方案，或者投“否”以反对所有备选方案。对多个备选方案的投票，如果某个备选方案获得的赞成票最多，且赞成票来自至少三分之二符合投票资格的人，则该备选方案被视为最终决定。如果没有备选方案达到此法定人数，可以另行发起一次关于减少选项数量的投票。

入职 / 离职

入职

新成员会被：

  • 添加到团队成员列表。理想情况下是发送他们自己的 PR，至少也要批准相关 PR。
  • 由现有团队成员在开发者邮件列表上宣布。理想情况下，新成员会在该主题下回复，确认其团队成员身份。
  • 添加到拥有提交权限的项目中。
  • 添加到团队邮件列表中。

离职

前成员会被：

  • 从团队成员列表中移除。理想情况下是发送他们自己的 PR，至少也要批准相关 PR。如果是强制移除，则无需批准。
  • 从项目中移除。如果团队同意，他们可以选择保留一个或多个仓库的维护者身份。
  • 从团队邮件列表中移除，并在其他邮件列表中降级为普通成员。
  • 不再允许自称为活跃团队成员，也不允许暗示是这种情况。
  • 如果他们选择，则会被添加到前成员列表中。

如有必要，我们保留公开宣布移除的权利。