One board, four teams, many perspectives

Grafana Labs keeps its engineering work in the open: the GitHub organization hosts nearly 1,000 repositories, eight of which have crossed 2,000 stars. Beyond open source, engineers also handle Grafana Cloud and customer escalations. For Armand Grillet, Senior Engineering Manager for the Grafana Alerting and SLO backend teams, that meant one project board had to serve teammates, other employees, and the open source community. The team's GitHub Project is public, and anyone can copy it for their own use.

Grafana Alerting spans backend, front-end, UX, and docs contributors. Each group gets its own view in the project, but all views share the same columns:

  • Inbox—not reviewed yet
  • Waiting for input—open source issues needing more details
  • Backlog—reviewed, priority depending on milestone
  • In progress
  • In review
  • Done

The columns are intentionally generic so they work for both community-written and internal issues. Project filters based on labels such as area/frontend route issues to the right view automatically once they land in the project.

Tasklists split big work, labels point to owners

For larger issues, the team relies on the GitHub tasklist feature to decompose work. Labels determine which tasks appear in which team's view, and the result carries two distinct signals. For the docs team, for example:

  • Smaller issues with only the type/docs label are items docs owns outright.
  • Larger issues whose tasklists carry type/docs alongside other area labels (say area/frontend) are items with a docs dependency but not docs ownership. When such an issue reaches "in progress," docs should start looking at how to help.

That workflow keeps views accurate without relying on attendance at status meetings: engineers update issue status, and the Docs view reflects reality. Four team views plus an "Epics" view—which lists the quarter's big issues—give everyone a read on Grafana Alerting progress. Grafana Labs members see all issues; external community members see public ones. Since most issues live in the Grafana public repository, transparency is the default.

Operational work lives in a private repository, but the same labels are used across all alerting-related repos to keep project filters straightforward. That commonality creates an incentive to adopt the same labels elsewhere, making cross-repo searches easier—a boon for product managers.

Custom fields per view

GitHub Projects allows different custom fields per view, which mattered because the team handles more than iterative tickets. Escalations move faster than regular issues, and quarterly goals span multiple work items. Three custom fields cover those cases:

  • Status: the default for all issues except escalations.
  • Quarter: applied to bigger issues containing tasklists.
  • Escalation: tracks granular status per escalation.

Those fields power two extra views: an epic view for a birds-eye look at quarterly goals, and an escalations view to track engineering work in flight. The result is a single source of truth covering standard issues, epics, and escalations.

Automation keeps engineers on code

Escalations are urgent, so the team pairs GitHub Projects with GitHub Actions to push Slack notifications, or route to Grafana OnCall for high-priority cases. Combining Projects and Actions opens up a lot of options. Actions like github/issue-labeler label issues automatically based on keywords, which in turn triggers other actions to route issues into the correct view or fire external notifications. New, relevant issues land in the project pre-triaged—"feels like magic," Grillet says.

Escalations often trace back to customer feature requests. Linking an escalation to an open source issue lets engineers and product managers prioritize on one platform while keeping the escalation's contents confidential from outside GitHub users.

The impact on workload was measurable. Grafana Alerting gets roughly five support escalations per week. In Q4 2022, the team averaged only four open escalations at any time, versus an average of 20 before adopting GitHub Projects and Actions. The automation itself drives prioritization: seeing escalations surface visibly motivates engineers to act.

Scaling the pattern to a new team

GitHub Projects scaled along with the org. When the SLO team formed—initially small, with no escalations—Grillet copied the Alerting project and adjusted filters for the new team's repositories. The open question was whether a workflow built for a large team would burden a smaller one. It was: too many views created unnecessary overhead. But trimming them was straightforward, and starting from an existing project let the SLO team get up and running quickly.

After a year of use, Grillet's team sees GitHub Projects as flexible enough for its mix of issue types and teams. Engineers stay focused on code, contributors face a low burden, and managers still get the views needed to plan and track effort. For Grafana Alerting, GitHub Projects is the only planning tool required.