本文档描述了项目的规则和治理。项目的所有开发人员和 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 用于记录目的。
如果他们选择接受,则将遵循 加入 程序。
团队成员可以通过向 团队 发送电子邮件随时退休。
团队成员可以通过 团队邮件列表 上的 超级多数票 被移除。对于此投票,相关成员无权投票,也不计入法定人数。任何移除投票只能涵盖一个单独的人。
成员去世后,他们将自动离开团队。
如果成员离开,则将应用 退出 程序。
当前团队成员如下
以前的成员
请注意,在创建本治理文档和正式团队成员资格之前,Prometheus 已从许多未列出的个人那里获得了大量贡献。
维护者领导一个或多个项目或其部分,并作为该项目贡献者之间冲突解决的中心。理想情况下,维护者也是团队成员,但对于出于某种原因尚未成为团队成员的合适维护者,也可能存在例外情况。
维护权变更必须在 开发者邮件列表 上公布。它们通过 惰性共识 决定,并通过更改相应存储库的 MAINTAINERS.md
文件来正式化。
维护者被授予对 GitHub 组织 中所有项目的提交权限。
维护者或提交者可以通过通知 团队邮件列表 辞职。一年内没有项目活动的维护者被视为已辞职。希望辞职的维护者应建议其他团队成员接管项目。
一个项目可以有多个维护者,只要他们之间明确达成责任分工。这包括协调谁处理哪些问题和拉取请求。
仅影响单个项目的技术决策由该项目的维护者非正式决定,并假定 惰性共识。跨越 Prometheus 项目多个部分的技术决策应在 Prometheus 开发者邮件列表 上进行讨论和决定。
决策通常通过 惰性共识 进行。如果无法达成共识,可以通过 多数票 解决。
对本文件的重大变更将在 开发者邮件列表 上公开讨论。任何变更都需要 超级多数票 赞成。编辑变更可以通过 惰性共识 进行,除非有异议。
编辑变更包括修复拼写或语法错误、更新工作隶属关系或类似的变更;它们更新样式或反映外部和明显的现实。它们不会改变本文件中任何内容的意图或含义。它们必须通过 PR 进行并通过 惰性共识 接受。
任何需要决策的事项,包括但不限于财务事项,如果任何成员认为有必要,都可以提请投票。对于财务、私人或人事事项,讨论和投票将在 团队邮件列表 上进行,否则将在 开发者邮件列表 上进行。
Prometheus 项目通常通过非正式共识运行,但有时需要做出正式决定。
根据主题的不同,如 上面 所述,将使用不同的投票方法。
对于所有投票,投票必须至少开放一周。投票结束日期应在投票通知中明确说明。如果足够多的投票结果一致,使进一步投票无法改变最终决定,则投票可以提前宣布并结束。
在所有情况下,所有 团队成员 都有资格投票,唯一的例外是强制移除团队成员,在这种情况下,该成员无权投票。
人事事项(包括但不限于团队成员资格和维护权)的讨论和投票将在 团队邮件列表 上私下进行。所有其他讨论和投票将在 开发者邮件列表 上公开进行。
对于公开讨论,鼓励所有感兴趣的人参与。反对或投票的正式权力仅限于 团队成员。
Prometheus 项目的默认决策机制是 惰性共识。这意味着只要没有人反对,任何关于技术问题的决定都视为得到 团队 的支持。
对于任何共识决定,保持沉默意味着默示同意,等同于明示同意。可以随意声明明示同意。决定可以随时由任何人提出,但不必在 开发者邮件列表 上宣布并提请决定。
共识决定永远不能推翻或违背先前明确投票的精神。
如果任何 团队成员 提出异议,团队成员将共同努力寻找所有相关人员都能接受的解决方案。此解决方案再次受惰性共识的约束。
如果无法找到共识,但必须做出一方或另一方的决定,任何 团队成员 都可以发起正式的 多数票。
必须在相应邮件列表上的单独线程中明确发起多数票。主题必须以 [VOTE]
为前缀。在正文中,投票通知必须说明所投票的提案。它应参考导致此投票的任何讨论。
投票可以采取单一提案的形式,可以选择赞成或反对,也可以采取多个备选方案的形式。
如果只有一个提案,则当赞成票数多于反对票数时,该提案就被认为是通过了。
如果有多个备选方案,成员可以投票支持一个或多个备选方案,或者投票“反对”来反对所有备选方案。无法投“弃权”票。如果一个备选方案获得的赞成票数最多,并且超过半数投票者赞成,则该备选方案就被认为是通过了。如果没有任何一个备选方案达到这个法定人数,则可以另行对减少的选项进行投票。
必须在适当的邮件列表上的单独主题中明确提出超级多数投票。主题必须以[VOTE]
为前缀。在正文中,投票请求必须说明要投票的提案。它应该参考导致这一步的任何讨论。
投票可以采取单一提案的形式,可以选择赞成或反对,也可以采取多个备选方案的形式。
如果至少三分之二的投票者赞成,则对单个提案的投票被认为是成功。
如果有多个备选方案,成员可以投票支持一个或多个备选方案,或者投票“反对”来反对所有备选方案。如果一个备选方案获得的赞成票数最多,并且至少三分之二的投票者赞成,则该备选方案就被认为是通过了。如果没有任何一个备选方案达到这个法定人数,则可以另行对减少的选项进行投票。
加入/退出部分为信息性内容,可以通过松散共识进行更改,除非受到挑战。如果无法达成共识,则可以通过多数投票解决。
新成员将
<chosen-username>@prometheus.io
电子邮件地址,并提供对团队的 GDrive 和日历的访问权限。新成员应该将后者添加到他们自己的日历列表中)。前成员将
如有需要,我们保留公开宣布删除的权利。
常见问题解答部分为信息性内容,可以通过松散共识进行更改,除非受到挑战。如果无法达成共识,则可以通过多数投票解决。
向开发者邮件列表发送包含你提议的电子邮件。如果在合理的时间内没有人反对,则认为该决定已做出。如果有反对意见,并且无法达成共识,则团队成员可以发起投票。
要成为正式的团队成员,你应该至少连续三个月为一个或多个项目做出贡献。在那时,团队成员(通常是项目的维护者)可以提议你加入团队。关于此事将进行私下讨论,并在做出决定后私下通知你。一个可能的,但并非必要的,晋升路径是先成为维护者。
如果决定赞成,你的新成员身份也将被宣布在开发者邮件列表上。
作为团队成员,在开发者邮件列表上提出新项目。如果没有人反对,则在 GitHub 组织中创建该项目。至少添加一个README.md
文件来解释项目的目标,以及一个MAINTAINERS.md
文件,其中列出项目的维护者(目前,这可能意味着你)。
向开发者邮件列表发送电子邮件,提议退休一个项目。如果没有人反对,则将其移至 prometheus-junkyard GitHub 组织。
维护者可以通过通知团队邮件列表来辞职。如果一个维护者在一年的时间里没有项目活动,则将其视为已辞职。如果需要紧急替换维护者,请在团队邮件列表中讨论此事。
团队成员可以通过通知团队邮件列表来辞职。如果你认为应该强行删除一名团队成员,请向团队邮件列表提出建议。关于此事将在那里进行私下讨论。