治理
治理
本文档描述了项目的规则和治理。项目的所有开发者和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 (Grafana Labs)
- 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(Pull Request)提出,并通过惰性共识接受。
其他事项
任何需要决议的事项,包括但不限于财务事项,如果任何成员认为有必要,都可以提请投票。对于财务、私密或人事事项,讨论和投票在团队邮件列表上进行;否则,在开发者邮件列表上进行。
投票
Prometheus项目通常通过非正式共识运作,但在某些情况下必须作出正式决定。
根据主题事项,如上文所述,使用不同的投票方法。
所有投票必须开放至少一周。投票截止日期应在投票通知中明确说明。如果已收到足够多的一方票数,且后续投票无法改变最终决定,则可以提前发起和结束投票。
在所有情况下,所有且仅有团队成员有资格投票,唯一的例外是强制移除团队成员,在这种情况下,该成员无权投票。
人事事项(包括但不限于团队成员资格和维护者身份)的讨论和投票在团队邮件列表上私下进行。所有其他讨论和投票都在开发者邮件列表上公开进行。
对于公开讨论,鼓励任何感兴趣的人参与。正式的反对或投票权力仅限于团队成员。
共识
Prometheus项目的默认决策机制是惰性共识。这意味着只要没有人反对,任何关于技术问题的决定都被视为得到团队支持。
对任何共识决定的沉默即为默示同意,等同于明确同意。可以随意明确表示同意。决定可以(但不必须)随时由任何人提出并在开发者邮件列表上进行决策。
共识决定绝不能凌驾于或违背早期明确投票的精神。
如果任何团队成员提出异议,团队成员将共同努力寻找一个所有相关方都能接受的解决方案。该解决方案仍需通过惰性共识。
如果无法达成共识,但必须作出决定,任何团队成员都可以发起正式的多数票投票。
多数票
多数票投票必须在相应的邮件列表上以单独的帖子明确发起。主题必须以 [VOTE]
为前缀。正文中,投票通知必须说明正在投票的提案。它应该引用此前导致此投票的任何讨论。
投票可以采取单一提案的形式,可选择赞成或反对,也可以是多个备选方案的形式。
单一提案的投票,如果赞成票多于反对票,则视为成功。
如果有多个备选方案,成员可以投票支持一个或多个备选方案,或者投“反对”票以反对所有备选方案。不能投“弃权”票。如果某个备选方案获得最多的赞成票,并且得到超过半数投票者的支持,则认为该多选投票已决定支持该备选方案。如果所有备选方案都未达到此法定人数,则可以单独发起一次针对较少选项的投票。
超级多数票
超级多数票投票必须在相应的邮件列表上以单独的帖子明确发起。主题必须以 [VOTE]
为前缀。正文中,投票通知必须说明正在投票的提案。它应该引用此前导致此投票的任何讨论。
投票可以采取单一提案的形式,可选择赞成或反对,也可以是多个备选方案的形式。
单一提案的投票,如果至少三分之二的合格投票者投赞成票,则视为成功。
如果有多个备选方案,成员可以投票支持一个或多个备选方案,或者投“反对”票以反对所有备选方案。如果某个备选方案获得最多的赞成票,并且得到至少三分之二合格投票者的支持,则认为该多选投票已决定支持该备选方案。如果所有备选方案都未达到此法定人数,则可以单独发起一次针对较少选项的投票。
入职/离职流程
入职/离职流程部分是信息性的,可以通过惰性共识进行修改,除非受到质疑。如果无法达成共识,则可以通过多数票解决。
入职
新成员将:
- 被添加到团队成员列表中。理想情况下,通过自行发送PR(Pull Request)完成,至少需要批准该PR。
- 由现有团队成员在开发者邮件列表上公布。理想情况下,新成员会在此帖子中回复,确认其团队成员身份。
- 被添加为 GitHub 组织的“所有者”(Owner)。
- 可选择性地添加到社区、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 组织。
如何移除不活跃的维护者?
维护者可以通过通知团队邮件列表来辞职。一年内没有项目活动的维护者将被视为已辞职。如果急需替换维护者,请在团队邮件列表上讨论此事。
如何移除团队成员?
团队成员可以通过通知团队邮件列表来辞职。如果您认为应违背团队成员的意愿将其移除,请向团队邮件列表提出此项提议。讨论将在此处私下进行。