Grafana Loki 开源项目治理机制详解角色体系、决策流程与投票规则【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiGrafana LokiLike Prometheus, but for logs.是一个由社区共同维护的日志聚合开源项目。本文基于仓库中的官方治理文档 docs/sources/community/governance.md系统讲解 Loki 项目的治理架构团队成员与维护者的角色定位、基于粗略共识的决策机制、多数票与超级多数票的正式投票规则以及成员入职/离职Onboarding/Offboarding的完整流程。读完本文你将理解一个大型开源日志项目是如何在Grafana Labs 主导 社区自治的框架下保持长期健康运转的也能快速上手参与 Loki 社区治理相关的贡献与讨论。一、治理文档的定位与适用范围治理文档Governance规定了 Loki 项目由谁治理、如何决策、如何投票、成员如何进出是全体开发者和 Loki 社区都必须遵守的规则。文档首先定义了四个核心术语作为后续所有规则的基础术语定义仓库对应物Team members团队成员私有 team 邮件列表的成员治理文档中的团队成员名单Maintainers维护者领导单个项目或其部分模块的人MAINTAINERS.mdProjects项目Grafana GitHub 组织下、受本治理约束的单个仓库loki、puppet-promtailThe Loki projectLoki 项目本治理框架下关于一个或多个仓库或社区的所有活动总和本仓库loki特别地治理文档还单独定义了Loki SIGSpecial Interest Group特别兴趣小组Operator指治理框架下围绕仓库子目录operator或其特定社区展开的所有活动。从仓库结构看operator/ 目录正是 Loki 的 Kubernetes Operator 实现拥有独立的社区与维护团队详见下文团队成员名单一节。二、价值观ValuesLoki 开发者和社区成员被要求遵循 CODE_OF_CONDUCT.mdContributor Covenant 贡献者公约中定义的价值观。该行为准则明确要求无论年龄、残疾、族裔、性别认同与表达、经验水平等参与者都应享有免受骚扰的体验并规定维护者有权移除、编辑、拒绝不符合行为准则的评论、提交、代码、wiki 编辑、issue 及其他贡献或临时/永久封禁违规贡献者。在行为准则之外Loki 社区还追求三点友善kindness有效反馈giving feedback effectively营造欢迎的环境building a welcoming environment在决策风格上Loki 开发者一般通过共识consensus做决定只有在无法达成共识时才诉诸多数投票作为冲突解决手段。三、项目Projects的基本要求治理文档对每个受治理的项目提出硬性要求每个项目必须有一个 MAINTAINERS.md 文件且至少包含一名维护者。如果项目有发布流程其访问权限与文档应保证不止一个人能够执行发布避免单点依赖。发布release必须在 announcement 和 users 两个邮件列表上公告。任何新项目必须先在 team 邮件列表上按照下述投票流程提出。仓库中的 MAINTAINERS.md 恰好印证了这套规则的实际落地——文件声明slim-bean是默认/主要维护者同时为部分代码区域指定了其他维护者如grafana/docs-logs负责文档。此外CODEOWNERS 文件从代码所有权层面进一步细化了治理粒度例如默认所有代码归grafana/loki-team/docs/文档由grafana/docs-logs与grafana/loki-team共同负责/operator/Loki Operator由grafana/loki-team periklis xperimental JoaoBraveCoding负责pkg/logql/syntax/syntax.yLogQL 语法文件由grafana/oss-big-tent与grafana/loki-team共同负责/nix/与flake.nix由trevorwhitney负责CHANGELOG.md被标记为无所有者No owners允许子维护者直接合并更改。这种默认团队兜底 模块级子维护者的 CODEOWNERS 配置正是治理文档中维护者领导项目或其部分模块的落地体现。四、决策机制Decision Making治理文档将决策分为四个层面从日常技术决策到文档修订各有一套规则。4.1 团队成员Team Members获得资格向 Loki 项目持续贡献至少 3 个月的人可以获得团队成员身份贡献形式通常是代码改进和/或显著的文档工作组织活动或用户支持也可作为考量。提名与投票任何现有成员都可以通过向 team 邮件列表发送邮件提名新成员。虽然理想情况下应就新成员达成共识但提名最终要经过正式的**超级多数投票supermajority vote**表决。接受流程提名通过后被提名者会被私下通过邮件联系以确认或拒绝团队成员身份该邮件会抄送CCteam 邮件列表留档。如果接受则走 入职流程。退出与移除成员可随时通过邮件通知 team 而退休retire成员可被 team 邮件列表上的超级多数投票移除被移除者本人无投票权也不计入法定人数quorum任何移除投票只能针对一个人成员去世后自动离开团队成员离开后适用 离职流程。治理文档还列出了当前团队成员名单均为 GitHub 账号多数来自 Grafana Labs也有来自 Red Hat、Alibaba Cloud 等公司的成员以及当前 Loki SIG Operator 团队名单。这些名单属于文档中的历史快照实际以文档最新版本为准。4.2 维护者Maintainers维护者领导一个或多个项目或其部分并充当贡献者之间冲突解决的触点。身份关系理想情况下维护者同时也是团队成员但允许合适但尚未成为团队成员的例外。任免宣布维护者的变动必须在 developers 邮件列表上宣布通过**粗略共识rough consensus**决定并以修改对应仓库的 MAINTAINERS.md 文件为正式化标志。权限维护者被授予本治理覆盖的所有项目的提交commit权限。辞职维护者可通过通知 team 邮件列表辞职一年无项目活动即视为辞职希望辞职的维护者被鼓励提名另一位团队成员接管项目。多维护者一个项目可以有多个维护者只要他们之间明确约定职责包括协调谁处理哪些 issue 和 pull request。4.3 技术决策Technical Decisions单项目内决策只影响单个项目的技术决策由该项目维护者非正式做出并默认视为粗略共识。跨项目决策跨越项目多个部分的决策应在 developers 邮件列表上讨论并做出。兜底规则决策通常通过粗略共识达成若无法达成共识可通过多数投票majority vote解决。4.4 治理变更Governance Changes与其他事项治理变更对本治理文档本身的修改由Grafana Labs做出——这是文档中明确保留的主导权。其他事项任何需要决策的事项任何成员认为必要时都可以发起投票。涉及私人或人事事务的讨论与投票在 team 邮件列表进行其余在 developers 邮件列表进行。五、投票Voting通用规则Loki 项目通常以非正式共识运转但有时必须做出正式决定。根据主题不同见上文决策机制采用不同的投票方法。所有投票必须遵守以下通用规则投票开放期投票必须至少开放一周发起投票时须明确说明结束日期。提前结束如果已有足够票数、后续票数不可能改变最终结果投票可以提前召集并结束。投票资格所有情况中只有且仅有团队成员有资格投票唯一例外是被强制移除的成员本人无投票资格。公开/私密人事事项包括但不限于团队成员资格和维护者资格的讨论与投票在私有 team 邮件列表进行其他所有讨论与投票在公开 developers 邮件列表进行。公开参与公开讨论鼓励任何感兴趣的人参与但正式反对或投票的权力仅限于团队成员。六、三种决策/投票方式详解6.1 粗略共识Rough Consensus默认决策机制其定义借鉴了 IETF RFC 7282On Consensus and Humming in the IETF中rough consensus的理念任何技术议题的决定只要无人反对或反对意见已被考虑但未必被采纳即视为获得团队支持。沉默即同意对任何共识决策的沉默等同于明确同意等同于明确表态任何人都可以随时在 developers 邮件列表上提出决策请求但并非必须。一致性底线共识决策永远不能推翻或违背先前明确投票的精神。异议处理若有团队成员提出反对大家共同协商一个所有相关方都能接受的方案该方案再次接受粗略共识检验。升级路径若找不到共识但必须做出决定任何团队成员都可发起正式的多数投票。6.2 多数投票Majority Vote发起方式必须在相应邮件列表上以独立线程separate thread明确发起主题必须以[VOTE]为前缀正文须写明被表决的提案并应引用此前的相关讨论。投票形式可以是单一提案 赞成/反对的形式也可以是多备选方案multiple alternatives的形式。单一提案赞成票多于反对票即为成功。多备选方案成员可为一个或多个备选方案投票也可以投no反对所有备选方案不能投弃权abstain。某备选方案获得最多赞成票、且赞成票超过投票人数的一半即视为胜出若没有备选方案达到该法定人数可另行对缩减后的选项进行第二轮投票。6.3 超级多数投票Supermajority Vote发起方式与多数投票相同——独立线程、主题以[VOTE]前缀开头、正文写明提案并引用讨论。单一提案至少三分之二2/3有资格投票者投赞成票才算成功。多备选方案某方案须获得最多赞成票且赞成票达到有资格投票者的三分之二才胜出达不到法定人数则对缩减后的选项另行投票。两种正式投票的应用场景可总结如下投票类型适用场景通过门槛多数投票Majority无法达成共识时的常规正式决策单一提案赞成 反对多备选最多赞成 过半投票者超级多数投票Supermajority新成员加入、成员移除等人事决策单一提案≥2/3 有资格者赞成多备选最多赞成 ≥2/3 有资格者七、成员入职/离职流程On- / Offboarding7.1 入职流程Onboarding新成员正式加入时需要完成四步更新名单添加到团队成员名单中理想情况下由新成员自己发送 PR至少批准该 PR。公开宣布由一位现有成员在 developers 邮件列表上宣布理想情况下新成员在该线程中回复确认成员身份。授予权限将新成员加入各项目并授予提交权限。加入邮件列表添加到私有 team 邮件列表。7.2 离职流程Offboarding成员离开时执行以下步骤移除名单从团队成员名单中移除理想情况下由本人发送 PR至少批准强制移除时无需本人批准。移除项目权限从项目中移除如果团队同意可选择性保留一个或多个仓库的维护权。邮件列表降级从 team 邮件列表移除降级为其他邮件列表的普通成员。身份约束不再允许自称或暗示自己是活跃团队成员。历史记录如果本人愿意可加入前任成员previous members名单。公开宣布如有必要保留公开宣布移除的权利。八、与社区实践的结合沟通渠道与维护指南治理文档中的决策与投票都围绕邮件列表展开这与仓库社区文档定义的沟通渠道互相印证。docs/sources/community/getting-in-touch.md 列出了与 Loki 团队联系的具体方式在 Grafana 社区的#lokiSlack 频道提问在 Grafana Labs Community Forums 的 Grafana Loki 分类下发帖社区驱动支持由 Loki 维护者与社区成员在带宽允许时答复通过 GitHub issue 提交 bug、问题与功能建议发送邮件到 lokiprojectgooglegroups.com 或访问对应 Google Groups 页面参与每月的 Loki Community Call每月第一个周四EU/US 时区交替。对于已获资格的维护者仓库还提供了专门的维护指南 docs/sources/community/maintaining/_index.md其中汇集了面向 Grafana Loki 维护者的发布等操作信息与治理文档中发布应保证多人可执行、并在邮件列表公告的要求形成呼应。九、治理机制要点速览权力结构Grafana Labs 主导治理文档修订团队与维护者分层自治CODEOWNERS 实现模块级代码所有权。默认决策粗略共识沉默即同意无法共识时升级为多数投票。人事决策新成员加入与成员移除走超级多数投票2/3 门槛且移除投票一次只针对一人、当事人不参与。流程透明所有正式投票主题以[VOTE]前缀发起开放至少一周人事事项私密、技术事项公开。文件落地维护者名单见 MAINTAINERS.md代码所有权见 CODEOWNERS行为底线见 CODE_OF_CONDUCT.md。这套治理框架的核心在于通过粗略共识 分层投票兼顾了开源社区的低摩擦协作与重大人事决策的审慎性是理解 Loki 社区如何长期稳定运作的关键文档也是新贡献者判断自己如何在其中定位成为团队成员、维护者或仅仅是积极参与者的权威依据。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Grafana Loki 开源项目治理机制详解：角色体系、决策流程与投票规则
Grafana Loki 开源项目治理机制详解角色体系、决策流程与投票规则【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/lokiGrafana LokiLike Prometheus, but for logs.是一个由社区共同维护的日志聚合开源项目。本文基于仓库中的官方治理文档 docs/sources/community/governance.md系统讲解 Loki 项目的治理架构团队成员与维护者的角色定位、基于粗略共识的决策机制、多数票与超级多数票的正式投票规则以及成员入职/离职Onboarding/Offboarding的完整流程。读完本文你将理解一个大型开源日志项目是如何在Grafana Labs 主导 社区自治的框架下保持长期健康运转的也能快速上手参与 Loki 社区治理相关的贡献与讨论。一、治理文档的定位与适用范围治理文档Governance规定了 Loki 项目由谁治理、如何决策、如何投票、成员如何进出是全体开发者和 Loki 社区都必须遵守的规则。文档首先定义了四个核心术语作为后续所有规则的基础术语定义仓库对应物Team members团队成员私有 team 邮件列表的成员治理文档中的团队成员名单Maintainers维护者领导单个项目或其部分模块的人MAINTAINERS.mdProjects项目Grafana GitHub 组织下、受本治理约束的单个仓库loki、puppet-promtailThe Loki projectLoki 项目本治理框架下关于一个或多个仓库或社区的所有活动总和本仓库loki特别地治理文档还单独定义了Loki SIGSpecial Interest Group特别兴趣小组Operator指治理框架下围绕仓库子目录operator或其特定社区展开的所有活动。从仓库结构看operator/ 目录正是 Loki 的 Kubernetes Operator 实现拥有独立的社区与维护团队详见下文团队成员名单一节。二、价值观ValuesLoki 开发者和社区成员被要求遵循 CODE_OF_CONDUCT.mdContributor Covenant 贡献者公约中定义的价值观。该行为准则明确要求无论年龄、残疾、族裔、性别认同与表达、经验水平等参与者都应享有免受骚扰的体验并规定维护者有权移除、编辑、拒绝不符合行为准则的评论、提交、代码、wiki 编辑、issue 及其他贡献或临时/永久封禁违规贡献者。在行为准则之外Loki 社区还追求三点友善kindness有效反馈giving feedback effectively营造欢迎的环境building a welcoming environment在决策风格上Loki 开发者一般通过共识consensus做决定只有在无法达成共识时才诉诸多数投票作为冲突解决手段。三、项目Projects的基本要求治理文档对每个受治理的项目提出硬性要求每个项目必须有一个 MAINTAINERS.md 文件且至少包含一名维护者。如果项目有发布流程其访问权限与文档应保证不止一个人能够执行发布避免单点依赖。发布release必须在 announcement 和 users 两个邮件列表上公告。任何新项目必须先在 team 邮件列表上按照下述投票流程提出。仓库中的 MAINTAINERS.md 恰好印证了这套规则的实际落地——文件声明slim-bean是默认/主要维护者同时为部分代码区域指定了其他维护者如grafana/docs-logs负责文档。此外CODEOWNERS 文件从代码所有权层面进一步细化了治理粒度例如默认所有代码归grafana/loki-team/docs/文档由grafana/docs-logs与grafana/loki-team共同负责/operator/Loki Operator由grafana/loki-team periklis xperimental JoaoBraveCoding负责pkg/logql/syntax/syntax.yLogQL 语法文件由grafana/oss-big-tent与grafana/loki-team共同负责/nix/与flake.nix由trevorwhitney负责CHANGELOG.md被标记为无所有者No owners允许子维护者直接合并更改。这种默认团队兜底 模块级子维护者的 CODEOWNERS 配置正是治理文档中维护者领导项目或其部分模块的落地体现。四、决策机制Decision Making治理文档将决策分为四个层面从日常技术决策到文档修订各有一套规则。4.1 团队成员Team Members获得资格向 Loki 项目持续贡献至少 3 个月的人可以获得团队成员身份贡献形式通常是代码改进和/或显著的文档工作组织活动或用户支持也可作为考量。提名与投票任何现有成员都可以通过向 team 邮件列表发送邮件提名新成员。虽然理想情况下应就新成员达成共识但提名最终要经过正式的**超级多数投票supermajority vote**表决。接受流程提名通过后被提名者会被私下通过邮件联系以确认或拒绝团队成员身份该邮件会抄送CCteam 邮件列表留档。如果接受则走 入职流程。退出与移除成员可随时通过邮件通知 team 而退休retire成员可被 team 邮件列表上的超级多数投票移除被移除者本人无投票权也不计入法定人数quorum任何移除投票只能针对一个人成员去世后自动离开团队成员离开后适用 离职流程。治理文档还列出了当前团队成员名单均为 GitHub 账号多数来自 Grafana Labs也有来自 Red Hat、Alibaba Cloud 等公司的成员以及当前 Loki SIG Operator 团队名单。这些名单属于文档中的历史快照实际以文档最新版本为准。4.2 维护者Maintainers维护者领导一个或多个项目或其部分并充当贡献者之间冲突解决的触点。身份关系理想情况下维护者同时也是团队成员但允许合适但尚未成为团队成员的例外。任免宣布维护者的变动必须在 developers 邮件列表上宣布通过**粗略共识rough consensus**决定并以修改对应仓库的 MAINTAINERS.md 文件为正式化标志。权限维护者被授予本治理覆盖的所有项目的提交commit权限。辞职维护者可通过通知 team 邮件列表辞职一年无项目活动即视为辞职希望辞职的维护者被鼓励提名另一位团队成员接管项目。多维护者一个项目可以有多个维护者只要他们之间明确约定职责包括协调谁处理哪些 issue 和 pull request。4.3 技术决策Technical Decisions单项目内决策只影响单个项目的技术决策由该项目维护者非正式做出并默认视为粗略共识。跨项目决策跨越项目多个部分的决策应在 developers 邮件列表上讨论并做出。兜底规则决策通常通过粗略共识达成若无法达成共识可通过多数投票majority vote解决。4.4 治理变更Governance Changes与其他事项治理变更对本治理文档本身的修改由Grafana Labs做出——这是文档中明确保留的主导权。其他事项任何需要决策的事项任何成员认为必要时都可以发起投票。涉及私人或人事事务的讨论与投票在 team 邮件列表进行其余在 developers 邮件列表进行。五、投票Voting通用规则Loki 项目通常以非正式共识运转但有时必须做出正式决定。根据主题不同见上文决策机制采用不同的投票方法。所有投票必须遵守以下通用规则投票开放期投票必须至少开放一周发起投票时须明确说明结束日期。提前结束如果已有足够票数、后续票数不可能改变最终结果投票可以提前召集并结束。投票资格所有情况中只有且仅有团队成员有资格投票唯一例外是被强制移除的成员本人无投票资格。公开/私密人事事项包括但不限于团队成员资格和维护者资格的讨论与投票在私有 team 邮件列表进行其他所有讨论与投票在公开 developers 邮件列表进行。公开参与公开讨论鼓励任何感兴趣的人参与但正式反对或投票的权力仅限于团队成员。六、三种决策/投票方式详解6.1 粗略共识Rough Consensus默认决策机制其定义借鉴了 IETF RFC 7282On Consensus and Humming in the IETF中rough consensus的理念任何技术议题的决定只要无人反对或反对意见已被考虑但未必被采纳即视为获得团队支持。沉默即同意对任何共识决策的沉默等同于明确同意等同于明确表态任何人都可以随时在 developers 邮件列表上提出决策请求但并非必须。一致性底线共识决策永远不能推翻或违背先前明确投票的精神。异议处理若有团队成员提出反对大家共同协商一个所有相关方都能接受的方案该方案再次接受粗略共识检验。升级路径若找不到共识但必须做出决定任何团队成员都可发起正式的多数投票。6.2 多数投票Majority Vote发起方式必须在相应邮件列表上以独立线程separate thread明确发起主题必须以[VOTE]为前缀正文须写明被表决的提案并应引用此前的相关讨论。投票形式可以是单一提案 赞成/反对的形式也可以是多备选方案multiple alternatives的形式。单一提案赞成票多于反对票即为成功。多备选方案成员可为一个或多个备选方案投票也可以投no反对所有备选方案不能投弃权abstain。某备选方案获得最多赞成票、且赞成票超过投票人数的一半即视为胜出若没有备选方案达到该法定人数可另行对缩减后的选项进行第二轮投票。6.3 超级多数投票Supermajority Vote发起方式与多数投票相同——独立线程、主题以[VOTE]前缀开头、正文写明提案并引用讨论。单一提案至少三分之二2/3有资格投票者投赞成票才算成功。多备选方案某方案须获得最多赞成票且赞成票达到有资格投票者的三分之二才胜出达不到法定人数则对缩减后的选项另行投票。两种正式投票的应用场景可总结如下投票类型适用场景通过门槛多数投票Majority无法达成共识时的常规正式决策单一提案赞成 反对多备选最多赞成 过半投票者超级多数投票Supermajority新成员加入、成员移除等人事决策单一提案≥2/3 有资格者赞成多备选最多赞成 ≥2/3 有资格者七、成员入职/离职流程On- / Offboarding7.1 入职流程Onboarding新成员正式加入时需要完成四步更新名单添加到团队成员名单中理想情况下由新成员自己发送 PR至少批准该 PR。公开宣布由一位现有成员在 developers 邮件列表上宣布理想情况下新成员在该线程中回复确认成员身份。授予权限将新成员加入各项目并授予提交权限。加入邮件列表添加到私有 team 邮件列表。7.2 离职流程Offboarding成员离开时执行以下步骤移除名单从团队成员名单中移除理想情况下由本人发送 PR至少批准强制移除时无需本人批准。移除项目权限从项目中移除如果团队同意可选择性保留一个或多个仓库的维护权。邮件列表降级从 team 邮件列表移除降级为其他邮件列表的普通成员。身份约束不再允许自称或暗示自己是活跃团队成员。历史记录如果本人愿意可加入前任成员previous members名单。公开宣布如有必要保留公开宣布移除的权利。八、与社区实践的结合沟通渠道与维护指南治理文档中的决策与投票都围绕邮件列表展开这与仓库社区文档定义的沟通渠道互相印证。docs/sources/community/getting-in-touch.md 列出了与 Loki 团队联系的具体方式在 Grafana 社区的#lokiSlack 频道提问在 Grafana Labs Community Forums 的 Grafana Loki 分类下发帖社区驱动支持由 Loki 维护者与社区成员在带宽允许时答复通过 GitHub issue 提交 bug、问题与功能建议发送邮件到 lokiprojectgooglegroups.com 或访问对应 Google Groups 页面参与每月的 Loki Community Call每月第一个周四EU/US 时区交替。对于已获资格的维护者仓库还提供了专门的维护指南 docs/sources/community/maintaining/_index.md其中汇集了面向 Grafana Loki 维护者的发布等操作信息与治理文档中发布应保证多人可执行、并在邮件列表公告的要求形成呼应。九、治理机制要点速览权力结构Grafana Labs 主导治理文档修订团队与维护者分层自治CODEOWNERS 实现模块级代码所有权。默认决策粗略共识沉默即同意无法共识时升级为多数投票。人事决策新成员加入与成员移除走超级多数投票2/3 门槛且移除投票一次只针对一人、当事人不参与。流程透明所有正式投票主题以[VOTE]前缀发起开放至少一周人事事项私密、技术事项公开。文件落地维护者名单见 MAINTAINERS.md代码所有权见 CODEOWNERS行为底线见 CODE_OF_CONDUCT.md。这套治理框架的核心在于通过粗略共识 分层投票兼顾了开源社区的低摩擦协作与重大人事决策的审慎性是理解 Loki 社区如何长期稳定运作的关键文档也是新贡献者判断自己如何在其中定位成为团队成员、维护者或仅仅是积极参与者的权威依据。【免费下载链接】lokiLike Prometheus, but for logs.项目地址: https://gitcode.com/GitHub_Trending/lok/loki创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
