Proposal: Improving Governance and Responsiveness for Grafana Helm Charts

[jkroepke]

Core Problem: Missing Ownership

The main problem with the Grafana Helm Charts repository is the lack of defined ownership.
No clear structure exists for who maintains, governs, or makes decisions about the repository.

This leads to slow reviews, blocked pull requests, and no path for improvement.
For community maintainers, it is often unclear who to contact, who has authority, and how to drive changes.

Consequences

1. Bottleneck in PR Reviews

The repository currently requires two approvals per PR, but there are only few active maintainers.
This creates a bottleneck, especially for small or low-risk changes.
Even simple updates can take weeks to merge. (#3918)

2. Security Restrictions Without Context

Since the repository lives under the official Grafana organization, it inherits security rules and pipelines designed for internal Grafana projects.
These restrictions can block PRs and make community contribution unnecessarily complicated.

3. No Room for Improvement

Without ownership, no improvements or automation can be introduced.
In the Prometheus Community Helm Charts, a Renovate-based auto-update and auto-merge process was implemented successfully. (see prometheus-community/helm-charts#6239 in action)
A similar setup is not possible here because no one has authority to approve structural changes.

Proposal

Grafana should define what kind of repository this should be and establish a clear ownership model.
This doesn’t require a full team, but it needs defined roles and communication channels.

Option 1: Grafana-owned repository (shared ownership)

If Helm charts are considered part of Grafana’s ecosystem, then ownership should follow this structure:

Chart Contributors

• Community members and Grafana Labs employees
• Submit and review pull requests
• Maintain charts and documentation

Community Admins (including Repo Admins)

• From community and/or Grafana Labs
• Have full control over repository settings and workflows
• Can invite new contributors and manage permissions
• Responsible for evolving processes and automation

Overall Ownership (Grafana Labs)

• Provides strategic direction
• Acts as escalation point for major issues or decisions
• Ensures alignment with Grafana’s ecosystem security and standards

This shared model keeps Grafana in control of strategic and security aspects, while empowering the community to maintain and improve the repository efficiently.

A closer communication channel between Grafana Labs and community admins would also help — for example, a private Slack or GitHub team discussion space for coordination on urgent issues and strategy.

Option 2: Community-owned repository

If Grafana prefers to treat Helm charts as a purely community project,
consider moving it to a new organization such as grafana-community.
This would allow trusted community maintainers to define rules, manage automation, and evolve the repository independently.

Similar to https://github.com/prometheus-community/helm-charts/blob/main/PROCESSES.md

Summary

The lack of ownership is the root cause of all other problems.
By defining a clear ownership structure — with Grafana Labs as strategic owner and empowered community admins handling daily operations — we can make the Grafana Helm Charts repository productive again.

As a maintainer of Grafana Helm Charts and admin of Prometheus Helm Charts, I’ve seen that this hybrid model works well in practice.
It builds trust, speeds up processes, and creates space for evolution.

[jkroepke]

/cc @ewamag @QuentinBisson @zalegrala @Sheikh-Abubaker I would appreciate some comments from your point of view as well.

[QuentinBisson]

I could not agree more. Thank you for the nice proposal

[makkes]

I believe the first question should be in the direction of Grafana Labs: Is Grafana interested in governing this repository going forward or would they prefer to move it outside of the official Grafana org structure?

[moxious]

I don't speak for all Grafana but I do work at Grafana on many related issues. First I want to say thank you. It's really useful to put an issue together and outline in an engineering oriented way what the issue is and outline a set of possible solutions. Second, you've definitely got my attention. Some internal Grafana folks already have scheduled to discuss this issue at an offsite we're having coming up soon (1st week of November). I'll be sharing this thread around to others inside of Grafana to gather perspectives, that we can have this discussion and do our best to find a solution. If I don't say much in the next few days or weeks don't take that as a sign it's ignored.

[isweluiz]

There are hundreds PR's waiting for review with clear and defined improvements stuck. The proposal of changes makes total sense; instead of continuing to do what is not working properly, try a different method of work on the repo.

[KyriosGN0]

I totally agree, i think that helm charts are important part of the way in which community interacts with the (amazing) LGTM stack, i see and feel the difference between mimir and loki to tempo for example, I hope that this thread kicks off a good discussion for the future of these helm charts

[Sheikh-Abubaker]

Being a Maintainer of Grafana Helm Charts, I could affirm the pain points here, we used to have an active Maintainer @zanhsieh who took care of the PRs, preventing them from piling up, since he's no longer here, the process has become tidious. We (@jkroepke , @zalegrala and myself) are trying our best to merge PRs, however the 2 approvals requirement is one of the major bottlenecks here, even if the PR has 1 approval, the other approval takes weeks or more than that in some scenarios, which ultimately leads to slow reviews, confusion and frustration among the contributors.

[zalegrala]

Please see my comment here.

[DrFaust92]

As a fellow maintainer for https://github.com/prometheus-community/helm-charts and working on other repos with @jkroepke I 100% agree and support keeping this shared effort with Grafana instead of forking, especially around automation like version bumps with combination of some basic CI.

FWIW, im happy to volunteer and help push any effort