治理
本文档描述了项目的规则和治理。所有项目开发人员和 Prometheus 社区都应遵守这些规则。本治理文档中使用的常见术语如下：
-
团队成员：私有 prometheus-team Google 群组的任何成员。
-
维护者：维护者领导一个或部分项目（
MAINTAINERS.md）。 -
项目：Prometheus GitHub 组织 中的单个存储库被称为一个项目。
-
Prometheus 项目：本治理下，所有关于一个或多个存储库或社区的活动的总和。
价值观
Prometheus 开发人员和社区应遵循 CNCF 章程 中定义的价值观，包括 CNCF 行为准则 。此外，Prometheus 社区致力于友善、有效反馈和营造一个受欢迎的环境。Prometheus 开发人员通常通过共识做出决定，只有在无法达成共识时，才会通过多数投票解决冲突。
项目
每个项目都必须有一个 `MAINTAINERS.md` 文件，其中至少有一名维护者。如果项目有发布流程，则访问权限和文档应确保多于一个人可以执行发布。发布应在 prometheus-users 邮件列表 上宣布。任何新项目都应首先在 开发者邮件列表 上按照以下投票程序提出。当一个项目不再相关时，应将其移至 prometheus-junkyard GitHub 组织。
决策制定
团队成员
对于持续为 Prometheus 项目贡献至少 3 个月的人员，可以授予团队成员身份。这通常以代码改进和/或文档显著工作形式出现，但组织活动或用户支持也可以考虑在内。
任何现有成员都可以通过电子邮件向 prometheus-team 提议新成员。非常希望就接受新成员达成共识。但是，提案最终由正式的绝对多数投票决定。
如果新成员提案被接受，应通过电子邮件私下联系被提议的团队成员，以确认或拒绝其接受团队成员身份。此电子邮件也将抄送至 prometheus-team 以作记录。
如果他们选择接受，将遵循入职程序。
团队成员可以随时通过电子邮件通知团队 退出。
团队成员可通过绝对多数投票在团队邮件列表 上被移除。在此投票中，当事成员没有投票资格，也不计入法定人数。任何移除投票只能涉及一个人。
成员死亡后，其将自动退出团队。
如果成员离开，则适用离职程序。
目前的团队成员包括：
- Alex Greenbank（独立）
- Arianna Vespri（独立）
- Arthur Sens（Grafana Labs ）
- Arve Knudsen（Grafana Labs ）
- Augustin Husson（Amadeus ）
- Ayoub Mrini（Red Hat ）
- Bartłomiej Płotka（Google ）
- Ben Kochie（Reddit ）
- Ben Reedy（Indue Ltd ）
- Björn Rabenstein（Grafana Labs ）
- Bryan Boreham（Grafana Labs ）
- Callum Styan（独立）
- Carrie Edwards（Grafana Labs ）
- Chris Marchbanks（Grafana Labs ）
- Chris Sinjakli（PlanetScale ）
- Conrad Hoffmann（独立）
- Cristian Greco（Grafana Labs ）
- Daniel Magliola（IndeedFlex ）
- Daniel Swarbrick（独立）
- David Ashpole（Google ）
- David Leadbeater（G-Research ）
- Doug Hoard（Confluent ）
- Fabian Stäber（Grafana Labs ）
- Fiona Liao（Grafana Labs ）
- Frederic Branczyk（Polar Signals ）
- Ganesh Vernekar（Reddit ）
- George Robinson（Grafana Labs ）
- Goutham Veeramachaneni（Grafana Labs ）
- Gregor Zeitlinger（Grafana Labs ）
- György Krajcsovits（Grafana Labs ）
- Jan Fajerski（Red Hat ）
- Jan-Otto Kröpke（独立）
- Jesús Vázquez（Grafana Labs ）
- Joe Adams（WebstaurantStore ）
- Johannes Ziemke（5π Consulting ）
- Josh Abreu（Grafana Labs ）
- Julius Volz（PromLabs ）
- Julien Pivotto（Grafana Labs ）
- Kemal Akkoyun（独立）
- Matthias Loibl（Polar Signals ）
- Matthias Rampke（Chronosphere ）
- Max Inden（Protocol Labs ）
- Owen Williams（Grafana Labs ）
- Pedro Tanaka（Shopify ）
- Richard Hartmann（Grafana Labs ）
- Saswata Mukherjee（Red Hat ）
- Sebastian Schubert（Grafana Labs ）
- Simon Pasquier（Red Hat ）
- Suraj Nath（Grafana Labs ）
- Thomas Peitz（独立）
- Tobias Schmidt（独立）
- Tom Wilkie（Grafana Labs ）
前成员
- Brian Brazil
- Calle Pettersson
- Conor Broderick
- Fabian Reinartz
- Jessica Grebenschikov
- Krasi Georgiev
- Matt Layher
- Steve Durrheimer
- Stuart Nelson
请注意，在本治理文档和正式团队成员资格创建之前，Prometheus 已收到许多未列出个人的重大贡献。
维护者
维护者领导一个或多个项目或其部分，并作为该项目贡献者之间冲突解决的联络点。理想情况下，维护者也是团队成员，但对于那些因某种原因尚未成为团队成员的合适维护者，也有可能例外。
维护者变更必须在 开发者邮件列表 上宣布。它们通过惰性共识决定，并通过更改相应存储库的 `MAINTAINERS.md` 文件正式化。
维护者被授予对 GitHub 组织 中所有项目的提交权限。
维护者或提交者可以通过通知团队邮件列表 辞职。一年内没有项目活动的维护者被视为已辞职。鼓励希望辞职的维护者提名另一名团队成员接管项目。
一个项目可以有多个维护者，只要他们在职责上明确达成一致。这包括协调谁处理哪些问题和拉取请求。
技术决策
仅影响单个项目的技术决策由该项目的维护者非正式地做出，并假定采用惰性共识。涉及 Prometheus 项目多个部分的技术决策应在 Prometheus 开发者邮件列表 上讨论并做出。
决策通常通过惰性共识做出。如果无法达成共识，则可以通过多数投票解决。
治理变更
本文档的重大更改将在 开发者邮件列表 上公开讨论。任何更改都需要绝对多数赞成。编辑性更改可以通过惰性共识进行，除非受到质疑。
编辑性更改
编辑性更改是指修正拼写或语法错误、更新工作隶属关系等类似修改；它们修改样式或反映外部和显而易见的事实。它们不会改变本文档中任何内容的意图或含义。它们必须通过 PR 进行，并通过惰性共识接受。
其他事项
任何需要决定的事项，包括但不限于财务事项，任何成员如果认为有必要，都可以提请投票。对于财务、私人或人事事项，讨论和投票在 团队邮件列表 上进行，否则在 开发者邮件列表 上进行。
投票
Prometheus 项目通常通过非正式共识运作，但有时必须做出正式决定。
根据主题事项，如上文所述，使用不同的投票方法。
所有投票必须至少开放一周。截止日期应在投票通知中明确说明。如果投票结果已足够明确，以至于进一步的投票无法改变最终决定，则投票可以提前发起和结束。
在所有情况下，所有且仅有团队成员有资格投票，唯一的例外是强制移除团队成员，在这种情况下，该成员没有投票资格。
人事事项（包括但不限于团队成员资格和维护者身份）的讨论和投票在 团队邮件列表 上私下进行。所有其他讨论和投票在 开发者邮件列表 上公开进行。
对于公开讨论，鼓励所有感兴趣的人参与。反对或投票的正式权力仅限于团队成员。
共识
Prometheus 项目的默认决策机制是惰性共识 。这意味着只要没有人反对，任何技术问题决策都将被视为获得团队 的支持。
对任何共识决策的沉默即为默示同意，等同于明确同意。明确同意可随时提出。决策可以（但不是必须）在 开发者邮件列表 上随时由任何人提出并提交决策。
共识决策绝不能凌驾或违背先前明确投票的精神。
如果任何团队成员提出异议，团队成员将共同努力寻找所有相关方都能接受的解决方案。此解决方案仍需遵循惰性共识。
如果无法达成共识，但必须做出某个决定，则任何团队成员均可提请正式的多数票。
多数票
多数投票必须在相应的邮件列表上以单独的线程明确提出。主题必须以 `[VOTE]` 为前缀。正文中，投票请求必须说明正在投票的提案。它应引用在此之前的所有讨论。
投票可以采取单一提案的形式，可以选择赞成或反对，也可以采取多重替代方案的形式。
如果赞成票多于反对票，则单一提案的投票被视为成功。
如果存在多个备选方案，成员可以投票支持一个或多个备选方案，或者投票“反对”以拒绝所有备选方案。不允许投“弃权”票。如果一个备选方案获得了最多的赞成票，并且获得了一半以上投票者的投票，则该备选方案的投票被视为已决定。如果没有任何备选方案达到该法定人数，则可以单独召集对减少数量选项的另一次投票。
绝对多数投票
绝对多数投票必须在相应的邮件列表上以单独的线程明确提出。主题必须以 `[VOTE]` 为前缀。正文中，投票请求必须说明正在投票的提案。它应引用在此之前的所有讨论。
投票可以采取单一提案的形式，可以选择赞成或反对，也可以采取多重替代方案的形式。
如果至少有三分之二的合格投票者投赞成票，则单一提案的投票被视为成功。
如果存在多个备选方案，成员可以投票支持一个或多个备选方案，或者投票“反对”以拒绝所有备选方案。如果一个备选方案获得了最多的赞成票，并且获得了至少三分之二的合格投票者的投票，则该备选方案的投票被视为已决定。如果没有任何备选方案达到该法定人数，则可以单独召集对减少数量选项的另一次投票。
入职/离职
入职/离职部分是信息性的，除非受到质疑，否则可以通过惰性共识进行更改。如果无法达成共识，则可以通过多数投票解决。
入职
新成员：
- 添加到团队成员列表。最好由他们自己发送 PR，至少要批准该 PR。
- 由现有团队成员在 开发者邮件列表 上宣布。理想情况下，新成员在此线程中回复，确认团队成员身份。
- 作为所有者添加到GitHub 组织 中。
- 可选地添加到社区、废弃项目和相关组织和存储库。
- 添加到 团队邮件列表 。
- 加入到prometheus.io GSuite账户，用户名为新成员选择的名称。（最重要的是，这会有一个
<chosen-username>@prometheus.io的电子邮件地址，并提供对团队的Gdrive和日历的访问权限。新成员应将后者添加到自己的日历列表中。） - 通知CNCF。
- 获得共享密码存储的访问权限。
离职
前成员：
- 从团队成员列表中移除。理想情况下，由他们自己发送PR，至少批准该PR。如果是强制移除，则不需要批准。
- 从GitHub组织 及相关组织和仓库中移除。如果团队同意，他们可以选择保留一个或多个仓库的维护权。
- 从团队邮件列表 中移除，并降级为其他邮件列表（例如开发者 、用户 和公告 ）的普通成员。
- 通知CNCF已移除。我们将明确要求CNCF重新确认移除。
- 从共享密码存储中移除。所有密码、API令牌等将适时循环（即，非自愿离开时立即循环，但可以与其他的离开或例行循环适当批量处理）。
- 在适用的情况下，从群组账户中移除。具有某种群组账户的服务包括但不限于Digital Ocean、DockerHub、GSuite、Netlify、Twitter（通过Tweetdeck）、Youtube。
- 不再被允许自称为活跃团队成员，也不允许暗示是这种情况。
- 如果他们愿意，可添加到前成员列表。
如有必要，我们保留公开宣布移除的权利。
常见问题
FAQ部分是信息性的，除非受到挑战，否则可以通过非强制共识进行更改。如果无法达成共识，则可以通过多数投票解决。
我如何提议一项决定？
向开发者邮件列表 发送一封电子邮件，提出您的动议。如果在合理时间内没有异议，则认为该决定已做出。如果存在异议且无法达成共识，团队成员可以要求投票。
我如何成为团队成员？
要成为正式的团队成员，您应该持续为一项或多项项目做出贡献至少三个月。届时，一名团队成员（通常是该项目的维护者）可能会提议您加入。关于此事的讨论将私下进行，并在做出决定后私下通知您。一种可能但非必需的晋升路径是首先成为维护者。
如果决定有利，您的新成员身份也将公布在开发者邮件列表 上。
我如何添加项目？
作为团队成员，在开发者邮件列表 上提出新项目。如果没有人反对，则在GitHub组织中创建该项目。至少添加一个解释项目目标的README.md，以及一个包含项目维护者的MAINTAINERS.md（此时，这可能意味着您自己）。
我如何归档或移除项目？
向开发者邮件列表 发送一封电子邮件，提议淘汰某个项目。如果没有人反对，将其移动到prometheus-junkyard GitHub组织。
我如何移除不活跃的维护者？
维护者可以通过通知团队邮件列表 来辞职。一年内没有项目活动的维护者将被视为已辞职。如果急需更换维护者，请在团队邮件列表 上讨论。
我如何移除团队成员？
团队成员可以通过通知团队邮件列表 来辞职。如果您认为应违背团队成员的意愿将其移除，请向团队邮件列表 提出此建议。讨论将私下进行。