治理
本文档描述了项目的规则和治理方式。项目的所有开发者和 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)
- Calle Pettersson (Instabee Group)
- 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 (Inuits)
- 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
- 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 组织。
- 可选择性地添加到社区、junkyard 以及相关组织和仓库中。
- 添加到团队邮件列表。
- 添加到 prometheus.io GSuite 账户,使用新成员选择的用户名。(最重要的是,这将获得一个
<chosen-username>@prometheus.io
电子邮件地址,并提供对团队 GDrive 和日历的访问权限。新成员应将后者添加到自己的日历列表中。) - 向 CNCF 宣布。
- 被授予共享密码存储的访问权限。
退出流程
前成员将:
- 从团队成员列表中移除。理想情况下,由他们自己发送一个 PR,至少要批准该 PR。在强制移除的情况下,不需要批准。
- 从 GitHub 组织及相关组织和仓库中移除。如果团队同意,他们可以选择性地保留一个或多个仓库的维护者身份。
- 从团队邮件列表中移除,并降级为其他邮件列表的普通成员,例如 开发者、用户和公告。
- 向 CNCF 宣布移除。我们将明确请求 CNCF 再次确认移除操作。
- 从共享密码存储中移除。所有密码、API 令牌等都将适时更换(例如,在非自愿离职的情况下会立即更换,否则可以与其他离职或例行更换一起适当批量处理)。
- 在适用的情况下,从群组账户中移除。拥有某种群组账户的服务包括但不限于 Digital Ocean、DockerHub、GSuite、Netlify、Twitter (通过 Tweetdeck)、Youtube。
- 不再被允许自称为活跃团队成员,也不允许暗示自己是活跃团队成员。
- 如果他们愿意,可以被添加到一个前成员名单中。
如有需要,我们保留公开宣布移除的权利。
常见问题解答
常见问题解答部分是信息性的,可以通过惰性共识进行更改,除非受到质疑。如果无法达成共识,则该问题可以通过多数票解决。
我如何提出一项决策?
发送一封包含您动议的电子邮件到开发者邮件列表。如果在合理时间内没有反对意见,则认为该决策已做出。如果存在反对意见且无法达成共识,团队成员可以发起投票。
我如何成为团队成员?
要成为正式团队成员,您应该持续为一个或多个项目做出贡献至少三个月。届时,团队成员(通常是项目的维护者)可能会提名您成为成员。相关讨论将私下进行,做出决定后您将收到私下通知。一个可能但非必需的晋升路径是先成为维护者。
如果决定通过,您的新成员身份也将在开发者邮件列表上公布。
我如何添加一个项目?
作为团队成员,在开发者邮件列表上提议新项目。如果没有人反对,就在 GitHub 组织中创建该项目。至少添加一个解释项目目标的 README.md
文件,以及一个包含项目维护者的 MAINTAINERS.md
文件(此时,这可能意味着就是您自己)。
我如何归档或移除一个项目?
发送一封电子邮件到开发者邮件列表,提议停用一个项目。如果没有人反对,就将其移动到 prometheus-junkyard GitHub 组织。
我如何移除不活跃的维护者?
维护者可以通过通知团队邮件列表来辞职。一年内没有任何项目活动的维护者将被视为已经辞职。如果迫切需要更换维护者,请在团队邮件列表上讨论此事。
我如何移除团队成员?
团队成员可以通过通知团队邮件列表来辞职。如果您认为某个团队成员应在非自愿的情况下被移除,请向团队邮件列表提出。讨论将在那里私下进行。