Community on Grafana Labs

Contacting the Loki Team

Thu, 09 Apr 2026 02:28:18 +0000

Contacting the Loki Team

For questions regarding Loki:

Ask a question in the #loki channel of our Slack community
Open source Loki users are welcome to post technical questions on the Grafana Labs Community Forums under the Grafana Loki category at community.grafana.com. Please be mindful that this is a community-driven support channel moderated by Grafana Labs staff where Loki maintainers and community members answer questions when bandwidth allows. Be sure to review the Community Guidelines before posting.
Users using Loki via Grafana Cloud can submit support tickets via the Grafana.com Account Portal.
For questions regarding Enterprise support for Loki, you can get in touch with the Grafana Labs team here.

Your feedback is always welcome! To submit feedback or a report a potential bug:

File a GitHub issue for bugs, issues and feature suggestions. Grafana UI issues for the Loki data source plugin should be posted directly to the Grafana repository, not the Loki repository.
Send an email to lokiproject@googlegroups.com, or visit the google groups page.
Join us for our monthly Loki Community Call on first Thursday of every month alternating between EU (12:00 UTC) and US (17:00 UTC) timezones. Subscribe to the calendar in the doc for being up to date.

Contributing to Loki

Thu, 09 Apr 2026 02:28:18 +0000

Contributing to Loki

Loki uses GitHub to manage reviews of pull requests:

If you have a trivial fix or improvement, go ahead and create a pull request.
If you plan to do something more involved, discuss your ideas on the relevant GitHub issue (creating one if it doesn’t exist).

Steps to contribute

To contribute to Loki, you must clone it into your $GOPATH and add your fork as a remote.

$ git clone https://github.com/grafana/loki.git $GOPATH/src/github.com/grafana/loki
$ cd $GOPATH/src/github.com/grafana/loki
$ git remote add fork <FORK_URL>

Make your changes, add your changes to a commit, and open a pull request (PR).

$ git add .
$ git commit -m "docs: fix spelling error"
$ git push -u fork HEAD

Note
If you downloaded Loki using go get, the message package github.com/grafana/loki: no Go files in /go/src/github.com/grafana/loki is normal and requires no actions to resolve.

Building

While go install ./cmd/loki works, the preferred way to build is by using make:

make loki: builds Loki and outputs the binary to ./cmd/loki/loki
make logcli: builds LogCLI and outputs the binary to ./cmd/logcli/logcli
make loki-canary: builds Loki Canary and outputs the binary to ./cmd/loki-canary/loki-canary
make docker-driver: builds the Loki Docker Driver and installs it into Docker.
make images: builds all Docker images (optionally suffix the previous binary commands with -image, e.g., make loki-image).

These commands can be chained together to build multiple binaries in one go. The following example builds binaries for Loki and LogCLI.

$ make loki logcli

Contribute to the Helm Chart

The official Loki helm charts can be found in the Grafana Helm Charts Repo.

Governance

Thu, 09 Apr 2026 02:28:18 +0000

Governance

This document describes the rules and governance of the project. It is meant to be followed by all the developers of the project and the Loki community. Common terminology used in this governance document are listed below:

Team members: Any members of the private team mailing list.
Maintainers: Maintainers lead an individual project or parts thereof (MAINTAINERS.md).
Projects: A single repository in the Grafana GitHub organization and listed below is referred to as a project:
- loki
- puppet-promtail
The Loki project: The sum of all activities performed under this governance, concerning one or more repositories or the community.
The Loki SIG (Special Interest Group) Operator: The sum of all activities performed under this governance, concerning the repository subfolder operator or its specific community.

Values

The Loki developers and community are expected to follow the values defined in the Code of Conduct. Furthermore, the Loki community strives for kindness, giving feedback effectively, and building a welcoming environment. The Loki developers generally decide by consensus and only resort to conflict resolution by a majority vote if consensus cannot be reached.

Projects

Each project must have a MAINTAINERS.md file with at least one maintainer. Where a project has a release process, access and documentation should be such that more than one person can perform a release. Releases should be announced on the announcement and users mailing lists. Any new projects should be first proposed on the team mailing list following the voting procedures listed below.

Decision making

Team members

Team member status may be given to those who have made ongoing contributions to the Loki project for at least 3 months. This is usually in the form of code improvements and/or notable work on documentation, but organizing events or user support could also be taken into account.

New members may be proposed by any existing member by email to the team mailing list. It is highly desirable to reach consensus about acceptance of a new member. However, the proposal is ultimately voted on by a formal supermajority vote.

If the new member proposal is accepted, the proposed team member should be contacted privately via email to confirm or deny their acceptance of team membership. This email will also be CC’d to the team mailing list for record-keeping purposes.

If they choose to accept, the onboarding procedure is followed.

Team members may retire at any time by emailing the team.

Team members can be removed by supermajority vote on the team mailing list. For this vote, the member in question is not eligible to vote and does not count towards the quorum. Any removal vote can cover only one single person.

Upon death of a member, they leave the team automatically.

In case a member leaves, the offboarding procedure is applied.

The current team members are:

Aditya C S - adityacs
Ashwanth Goli - ashwanthgoli (Grafana Labs)
Cyril Tovena - cyriltovena (Grafana Labs)
Danny Kopping - dannykopping (Grafana Labs)
David Kaltschmidt - davkal (Grafana Labs)
Dylan Guedes - dylanguedes (Grafana Labs)
Edward Welch - slim-bean (Grafana Labs)
Goutham Veeramachaneni - gouthamve (Grafana Labs)
Joe Elliott - joe-elliott (Grafana Labs)
Karsten Jeschkies - jeschkies (Grafana Labs)
Kaviraj Kanagaraj - kavirajk (Grafana Labs)
Li Guozhong - liguozhong (Alibaba Cloud)
Michel Hollands - michelhollands (Grafana Labs)
Owen Diehl - owen-d (Grafana Labs)
Periklis Tsirakidis - periklis (Red Hat)
Salva Corts - salvacorts (Grafana Labs)
Sandeep Sukhani - sandeepsukhani (Grafana Labs)
Susana Ferreira - ssncferreira
Tom Braack - sh0rez (Grafana Labs)
Tom Wilkie - tomwilkie (Grafana Labs)

The current Loki SIG Operator team members are:

Brett Jones - blockloop (InVision)
Cyril Tovena - cyriltovena (Grafana Labs)
Gerard Vanloo - Red-GV (IBM)
Periklis Tsirakidis - periklis (Red Hat)
Sashank Agrawal - sasagarw (Red Hat)

Maintainers

Maintainers lead one or more project(s) or parts thereof and serve as a point of conflict resolution amongst the contributors to this project. Ideally, maintainers are also team members, but exceptions are possible for suitable maintainers that, for whatever reason, are not yet team members.

Changes in maintainership have to be announced on the developers mailing list. They are decided by rough consensus and formalized by changing the MAINTAINERS.md file of the respective repository.

Maintainers are granted commit rights to all projects covered by this governance.

A maintainer or committer may resign by notifying the team mailing list. A maintainer with no project activity for a year is considered to have resigned. Maintainers that wish to resign are encouraged to propose another team member to take over the project.

A project may have multiple maintainers, as long as the responsibilities are clearly agreed upon between them. This includes coordinating who handles which issues and pull requests.

Technical decisions

Technical decisions that only affect a single project are made informally by the maintainer of this project, and rough consensus is assumed. Technical decisions that span multiple parts of the project should be discussed and made on the developer mailing list.

Decisions are usually made by rough consensus. If no consensus can be reached, the matter may be resolved by majority vote.

Governance changes

Changes to this document are made by Grafana Labs.

Other matters

Any matter that needs a decision may be called to a vote by any member if they deem it necessary. For private or personnel matters, discussion and voting takes place on the team mailing list, otherwise on the developer mailing list.

Voting

The Loki project usually runs by informal consensus, however sometimes a formal decision must be made.

Depending on the subject matter, as laid out above, different methods of voting are used.

For all votes, voting must be open for at least one week. The end date should be clearly stated in the call to vote. A vote may be called and closed early if enough votes have come in one way so that further votes cannot change the final decision.

In all cases, all and only team members are eligible to vote, with the sole exception of the forced removal of a team member, in which said member is not eligible to vote.

Discussion and votes on personnel matters (including but not limited to team membership and maintainership) are held in private on the team mailing list. All other discussion and votes are held in public on the developer mailing list.

For public discussions, anyone interested is encouraged to participate. Formal power to object or vote is limited to team members.

Consensus

The default decision making mechanism for the Loki project is rough consensus. This means that any decision on technical issues is considered supported by the team as long as nobody objects or the objection has been considered but not necessarily accommodated.

Silence on any consensus decision is implicit agreement and equivalent to explicit agreement. Explicit agreement may be stated at will. Decisions may, but do not need to be called out and put up for decision on the developers mailing list at any time and by anyone.

Consensus decisions can never override or go against the spirit of an earlier explicit vote.

If any team member raises objections, the team members work together towards a solution that all involved can accept. This solution is again subject to rough consensus.

In case no consensus can be found, but a decision one way or the other must be made, any team member may call a formal majority vote.

Majority vote

Majority votes must be called explicitly in a separate thread on the appropriate mailing list. The subject must be prefixed with [VOTE]. In the body, the call to vote must state the proposal being voted on. It should reference any discussion leading up to this point.

Votes may take the form of a single proposal, with the option to vote yes or no, or the form of multiple alternatives.

A vote on a single proposal is considered successful if more vote in favor than against.

If there are multiple alternatives, members may vote for one or more alternatives, or vote “no” to object to all alternatives. It is not possible to cast an “abstain” vote. A vote on multiple alternatives is considered decided in favor of one alternative if it has received the most votes in favor, and a vote from more than half of those voting. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.

Supermajority vote

Supermajority votes must be called explicitly in a separate thread on the appropriate mailing list. The subject must be prefixed with [VOTE]. In the body, the call to vote must state the proposal being voted on. It should reference any discussion leading up to this point.

Votes may take the form of a single proposal, with the option to vote yes or no, or the form of multiple alternatives.

A vote on a single proposal is considered successful if at least two thirds of those eligible to vote vote in favor.

If there are multiple alternatives, members may vote for one or more alternatives, or vote “no” to object to all alternatives. A vote on multiple alternatives is considered decided in favor of one alternative if it has received the most votes in favor, and a vote from at least two thirds of those eligible to vote. Should no alternative reach this quorum, another vote on a reduced number of options may be called separately.

On- / Offboarding

Onboarding

The new member is

added to the list of team members. Ideally by sending a PR of their own, at least approving said PR.
announced on the developers mailing list by an existing team member. Ideally, the new member replies in this thread, acknowledging team membership.
added to the projects with commit rights.
added to the team mailing list.

Offboarding

The ex-member is

removed from the list of team members. Ideally by sending a PR of their own, at least approving said PR. In case of forced removal, no approval is needed.
removed from the projects. Optionally, they can retain maintainership of one or more repositories if the team agrees.
removed from the team mailing list and demoted to a normal member of the other mailing lists.
not allowed to call themselves an active team member any more, nor allowed to imply this to be the case.
added to a list of previous members if they so choose.

If needed, we reserve the right to publicly announce removal.

Maintaining

Thu, 09 Apr 2026 02:28:18 +0000

Maintaining

This section details information for maintainers of Grafana Loki.

Loki Improvement Documents (LIDs)

Thu, 09 Apr 2026 02:28:18 +0000

Loki Improvement Documents (LIDs)

Purpose

Loki Improvement Documents (LIDs) are proposals for modifying Grafana Loki’s feature-set and/or processes. These documents serve to promote engagement between the community and maintainers before making large changes to Grafana Loki. This ensures that we will only work on features that the maintainers and the community actually want, implemented in line with Loki’s engineering and scalability considerations.

LIDs are not required for:

bugfixes
minor features
minor process changes

Creating a LID

Start by opening a PR against this repository, using this template.

All LIDs require a “sponsor”. A sponsor is a Grafana Loki maintainer who is willing to shepherd the improvement proposal throughout its development process from draft through to completion. A sponsor can be found by starting a thread in our mailing list, which one or more maintainers will respond to and volunteer. If a LID is generated internally by a Grafana Labs employee who is also a maintainer, the sponsor will be the author. Thread topics should be prefixed with “LID: “.

LIDs should contain a high-level overview of the problem, the proposed solution, and other details specified in the template. LIDs can optionally have a rough prototype implementation PR associated with it, but it is advised to not spend too much time on it because the proposal may be rejected.

LIDs will be viewable in perpetuity, and serve to document our decisions plus all the inputs and reasoning that went into those decisions.

Process

Once a PR is submitted, it will be reviewed by the sponsor, as well as interested community members and maintainers. LIDs require approval from the sponsor and one additional maintainer to be accepted. Once accepted, work can commence on the improvement and the nominated sponsor(s) will review all further related contributions.

Notes

LIDs will be assigned a number once accepted.
LIDs must be kept up-to-date by the sponsor and/or author after the initial PR (which adds the LID) is merged, to reflect its current state.
A LID is considered completed once it is either rejected or the improvement has been included in a release.
CHANGELOG entries should reference LIDs where applicable.
Significant changes to the LID process should be proposed with a LID.
LIDs should be shared with the community on the #loki channel on Slack for comment, and the sponsor should wait at least 2 weeks before accepting a proposal.

Design documents

Thu, 09 Apr 2026 02:28:18 +0000