本文档描述了项目的规则和治理。它旨在被项目的所有开发者和 Prometheus 社区遵守。以下列出了本治理文档中使用的常用术语：
团队成员：私有 prometheus-team Google 群组的任何成员。
维护者：维护者领导单个项目或其部分内容 (MAINTAINERS.md)。
项目：Prometheus GitHub 组织中的单个仓库被称为一个项目。
Prometheus 项目：在本治理下执行的所有活动的总和，涉及一个或多个仓库或社区。
Prometheus 开发者和社区应遵循 CNCF 章程 中定义的价值观，包括 CNCF 行为准则。此外，Prometheus 社区努力做到友善、有效地给予反馈，并建立一个欢迎的环境。Prometheus 开发者通常通过共识进行决策，只有在无法达成共识时才通过多数票进行冲突解决。
每个项目都必须有一个 MAINTAINERS.md 文件，其中至少有一名维护者。如果项目有发布流程，则访问权限和文档应确保有多人可以执行发布。发布应在 prometheus-users 邮件列表上宣布。任何新项目都应首先在 developers 邮件列表上按照下面列出的投票程序进行提议。当一个项目不再相关时，应将其移至 prometheus-junkyard GitHub 组织。
团队成员资格可以授予那些为 Prometheus 项目持续贡献至少 3 个月的人。这通常以代码改进和/或文档方面的显著工作形式出现，但也可能考虑组织活动或用户支持。
新成员可以由任何现有成员通过电子邮件向 prometheus-team 提出。非常希望就接受新成员达成共识。但是，该提案最终由正式的绝对多数票表决。
如果新成员提案被接受，应通过电子邮件私下联系被提议的团队成员，以确认或拒绝他们接受团队成员资格。此电子邮件也将抄送至 prometheus-team 以进行记录。
如果他们选择接受，则遵循入职程序。
团队成员可以随时通过电子邮件发送至 团队 退休。
团队成员可以通过 绝对多数票 在 团队邮件列表 中移除。在此投票中，有问题的成员没有投票资格，也不计入法定人数。任何移除投票只能针对一个人。
成员去世后，他们将自动离开团队。
如果成员离开，则应用离职程序。
当前的团队成员有
之前的成员
请注意，在本文档以及正式团队成员制度创建之前，Prometheus 已经收到了许多未列出的个人的重大贡献。
维护者领导一个或多个项目或其部分内容，并充当该项目贡献者之间冲突解决的联络点。理想情况下，维护者也是团队成员，但对于合适的维护者，由于任何原因尚未成为团队成员的情况，也可能存在例外。
维护者变更必须在 developers 邮件列表上宣布。它们通过惰性共识决定，并通过更改相应仓库的 MAINTAINERS.md 文件来正式确定。
维护者被授予对 GitHub 组织中所有项目的提交权限。
维护者或提交者可以通过通知 团队邮件列表 来辞职。一年内没有项目活动的维护者将被视为已辞职。希望辞职的维护者应建议另一位团队成员接管该项目。
一个项目可以有多名维护者，只要他们之间明确约定了责任即可。这包括协调谁处理哪些问题和拉取请求。
仅影响单个项目的技术决策由该项目的维护者非正式地做出，并假定为惰性共识。影响 Prometheus 项目多个部分的技术决策应在 Prometheus 开发者邮件列表上讨论和做出。
决策通常通过惰性共识做出。如果无法达成共识，则可以通过多数票解决问题。
对本文档的实质性更改将在 开发者邮件列表 上公开讨论。任何更改都需要绝对多数赞成。编辑性更改可以通过惰性共识进行，除非受到质疑。
编辑性更改是指修复拼写或语法、更新工作单位或类似情况的更改；它们更新样式或反映外部和显而易见的事实。它们不会更改本文档中任何内容的意图或含义。它们必须通过 PR 进行，并通过惰性共识接受。
任何需要决策的事项，包括但不限于财务事项，如果任何成员认为有必要，都可以发起投票。对于财务、隐私或人事事项，讨论和投票在 团队邮件列表 上进行，否则在 开发者邮件列表 上进行。
Prometheus 项目通常通过非正式共识运行，但有时必须做出正式决定。
根据以上列出的主题，使用不同的投票方法。
对于所有投票，投票必须开放至少一周。结束日期应在投票通知中明确说明。如果已获得足够的单方面票数，以至于进一步的投票无法改变最终决定，则可以提前发起和结束投票。
在所有情况下，所有且仅限团队成员有资格投票，唯一的例外是强制移除团队成员的情况，在这种情况下，该成员没有资格投票。
关于人事事项（包括但不限于团队成员资格和维护者资格）的讨论和投票在 团队邮件列表 上私下进行。所有其他讨论和投票都在 开发者邮件列表 上公开进行。
对于公开讨论，鼓励任何感兴趣的人参与。反对或投票的正式权力仅限于团队成员。
Prometheus 项目的默认决策机制是 惰性共识。这意味着，只要没有人反对，关于技术问题的任何决定都被认为得到了团队的支持。
对任何共识决定的沉默都表示默示同意，等同于明确同意。可以随意声明明确同意。可以随时由任何人发起和提出决策，但不需要在 开发者邮件列表 上公开征求决策。
共识决定永远不能推翻或违背先前明确投票的精神。
如果任何团队成员提出异议，团队成员将共同努力寻找所有相关人员都可以接受的解决方案。此解决方案再次受惰性共识约束。
如果找不到共识，但必须做出决定，任何团队成员都可以发起正式的多数票。
多数票必须在适当的邮件列表上的单独线程中明确发起。主题必须以 [VOTE] 为前缀。在正文中，投票通知必须说明正在投票的提案。它应参考导致此点的任何讨论。
投票可以采用单一提案的形式，可以选择赞成或反对，也可以采用多种替代方案的形式。
如果赞成票多于反对票，则对单一提案的投票被认为是成功的。
如果有多个替代方案，成员可以投票支持一个或多个替代方案，或投“反对”票以反对所有替代方案。不可能投“弃权”票。如果某个替代方案获得最多的赞成票，并且获得超过一半投票者的投票，则对多个替代方案的投票被认为是赞成该替代方案。如果没有任何替代方案达到法定人数，可以单独发起对减少数量的选项的另一次投票。
绝对多数票必须在适当的邮件列表上的单独线程中明确发起。主题必须以 [VOTE] 为前缀。在正文中，投票通知必须说明正在投票的提案。它应参考导致此点的任何讨论。
投票可以采用单一提案的形式，可以选择赞成或反对，也可以采用多种替代方案的形式。
如果至少有三分之二的有资格投票的人投赞成票，则对单一提案的投票被认为是成功的。
如果有多个替代方案，成员可以投票支持一个或多个替代方案，或投“反对”票以反对所有替代方案。如果某个替代方案获得最多的赞成票，并且获得至少三分之二的有资格投票的人的投票，则对多个替代方案的投票被认为是赞成该替代方案。如果没有任何替代方案达到法定人数，可以单独发起对减少数量的选项的另一次投票。
入职/离职部分是信息性的，可以通过惰性共识更改，除非受到质疑。如果无法达成共识，则可以通过多数票解决问题。
新成员是
<chosen-username>@prometheus.io 电子邮件地址，并提供对团队 GDrive 和日历的访问权限。新成员应将后者添加到他们自己的日历列表中。）前成员是
如果需要，我们保留公开宣布移除的权利。
常见问题解答部分是信息性的，可以通过惰性共识更改，除非受到质疑。如果无法达成共识，则可以通过多数票解决问题。
向 开发者邮件列表 发送一封电子邮件，其中包含您的动议。如果在合理的时间内没有异议，则认为已做出决定。如果有异议且无法达成共识，则团队成员可以发起投票。
要成为正式团队成员，您应该为一个或多个项目持续贡献至少三个月。届时，团队成员（通常是项目的维护者）可以提名您成为成员。关于此事的讨论将私下进行，并在做出决定后私下通知您。一个可能的但非必需的晋升途径是先成为维护者。
如果决定对您有利，您成为新成员的消息也将在 开发者邮件列表 上宣布。
作为团队成员，在 开发者邮件列表 上提议新项目。如果没有人反对，请在 GitHub 组织中创建项目。至少添加一个 README.md 解释项目的目标，以及一个 MAINTAINERS.md 文件，其中包含项目的维护者（此时，这可能意味着您）。
发送一封电子邮件到 开发者邮件列表，提议停用某个项目。如果没有人反对，请将其移至 prometheus-junkyard GitHub 组织。
维护者可以通过通知 团队邮件列表 来辞职。一年内没有项目活动的维护者将被视为已辞职。如果迫切需要更换维护者，请在 团队邮件列表 上讨论此事。
团队成员可以通过通知 团队邮件列表 来辞职。如果您认为应该违背团队成员的意愿将其移除，请向 团队邮件列表 提出此事。讨论将在那里私下进行。