Triage Party: turning GitHub issue triage into a multiplayer board

The problem it comes from

Triage Party is described as a stateless web app to optimize issue and PR triage for large open-source projects using the GitHub API, and it carries a note that it is not an officially supported Google product.

The origin story is specific and worth knowing, because it explains the design. It was built from the Google Container DevEx team's experience contributing to popular open-source projects, and three of those are named: minikube, Skaffold and Kaniko. A team that files and triages issues on its own repositories, and on Kubernetes-adjacent ones with a large contributor base, has a very particular pain.

The stated focus is reducing response latency for incoming issues and pull requests and ensuring that conversations are not lost in the ether. That second half is the more interesting one. The failure mode in a large project is not only that nobody answers, it is that a thread of discussion fragments across the issue, a linked PR and a comment somewhere else, and the context that would let the next maintainer act is scattered.

That context explains why this is a view over GitHub rather than a tracker with its own database. The readme lists the requirements as one item, a GitHub API token with public_repo permissions, read-only. The token is read-only precisely because the tool is about presenting and organising what is already there.

The tool is configured via YAML and designed for projects to self-host on anything from a Raspberry Pi to Google Cloud Run to Kubernetes. So the deployment footprint is deliberately small.

Rules and pages, and the filters GitHub does not have

Triage Party's model is that you define pages, and each page is a set of rules that select issues and pull requests into that page. The YAML configuration covers all pages, rules and filters, and the readme says it can be configured to accept any triage workflow you can imagine.

The filters are where the novelty lies. The readme lists filters that are not possible on GitHub itself: follow-up latency by project members, written as responded: +15d, reactions as reactions: >=5, and comment popularity as comments-per-month: >0.9.

Each of those encodes a triage policy that GitHub's own search cannot express. Follow-up latency finds issues that someone already answered but that came back, which is the population that gets lost. Reactions and comments-per-month are proxies for attention rather than for correctness, and they are the sort of signal that a human reviewer applies by feel and cannot write down in GitHub's query syntax.

The rest of the feature list covers the surrounding mechanics. Query across GitHub projects or repositories, duplicate issue detection, conversation direction tracking and filtering, code review state-tracking from v1.2.0, the Kanban dashboard also from v1.2.0, and opening groups of issues into browser tabs, which is the feature that makes a triage meeting fast.

The usage tips explain how the pieces are meant to work together, and they are prescriptive in a useful way. Rules work best when there is a documented resolution to remove the item from the list. Pages work best if the process is defined so that the page is empty when triage is complete. And if a non-actionable issue shows up in a daily or weekly triage, the advice is to step back and tune the rules or define an appropriate resolution rather than to work around it in the meeting.

Multi-player mode, and why statelessness is the point

The multi-player mode is the feature that gives the project its name, and it works because the application holds no state.

Use the drop-down labelled Solo on the top-right of any page to enable it. The number of issues is split among the number of players configured, and since Triage Party is stateless, players are assigned via the remainder of the issue or PR divided by the total number of players. The URL carries the player count and the player number, so sharing that URL is all it takes to put everyone in the same session.

The readme describes a workflow it has seen work well. Wait for attendees to arrive. The host selects the number of players and shares the resulting URL. If someone is late, leave a slot open and re-shard later. The host assigns each attendee a player number. Players work through the list section by section, using the open-items-in-new-tabs feature to move quickly. When a player lacks the context to resolve an item, they present their screen and discuss it. When a player leaves, the host re-shards and everyone selects the updated player count.

The statelessness is what makes the re-sharding possible. There is no server-side session to migrate, because the only state is the issue state on GitHub and the shard parameters in the URL.

The limit is stated too: up to 20 simultaneous players, and multi-player works best if the Resolution field of each rule has a clear action to resolve the item and remove it from the list. Without a resolution, an item stays on the page after it has been dealt with, and the board stops being a queue.

The Kanban mode, new in v1.2.0, offers a different shape for the same meeting. Columns are based on the rule the issue was found in and rows are swim lanes based on the assignee. The design guidance is that rules should be ordered to represent progress, from Not started through Started and Under Review to Completed, that rules work best when they are mutually exclusive so no issue matches several, and that a collection which should display in Kanban form by default specifies display: kanban in its configuration.

Running it locally

The setup path is short. Store the token on disk:

echo YOUR_GENERATED_TOKEN > $HOME/.github-token

and then run the server directly with Go:

go run cmd/server/main.go \
  --github-token-file=$HOME/.github-token \
  --config config/examples/kubernetes.yaml \
  --repos kubernetes/sig-release

The flags are the whole configuration surface for the basics: a token file, a config file, and the repositories to pull. The example config used here is the Kubernetes one that ships in config/examples.

If Go is not installed, the Docker path is equivalent:

export GITHUB_TOKEN="$(cat $HOME/.github-token)"
docker build --tag=tp .
docker run \
  --rm \
  -e GITHUB_TOKEN \
  -v "$PWD/config/examples/kubernetes.yaml:/app/config/config.yaml" \
  -p 8080:8080 tp

The volume mount is what makes the Docker path useful, because the configuration file is baked into the image built by the Dockerfile, and mounting over it lets you point at a different config without rebuilding. The readme notes that the published triageparty/triage-party image on Docker Hub is the one to use if you would rather pass configuration in through a ConfigMap or environment variable instead.

There is also a third option using the GitHub CLI's stored credentials, which avoids creating a token at all:

export GITHUB_TOKEN=$(grep oauth_token ~/.config/gh/hosts.yml| cut -d ":" -f 2 | sed "s/ //g")
docker build --tag=tp .

One operational detail is worth planning around. The first time a repository is used it takes some time, about 45 seconds in the readme's example, to download the necessary data before the pages will render, and the site blocks page loads until that content has arrived. After the first run, pages render from memory within about 5ms. So the first start is slow and everything after it is fast, which is the opposite of what a stateless label suggests.

Where Triage Party is the wrong choice

The first limitation is the setup cost relative to the problem. The tool needs a GitHub token, a YAML configuration describing pages, rules and filters, and a deployment, whether that is a laptop, a Raspberry Pi or a Kubernetes cluster. For a project with twenty open issues, that is more work than opening them one by one. The point at which the tool starts paying for itself is a backlog big enough that the queue itself is the problem.

The second is the statelessness, which cuts both ways. It makes multi-player mode and re-sharding work without a database, and it means there is nowhere to store anything that is not already on GitHub. There is no record of who triaged what, no saved view, no personal assignment state and no per-user notification. Everything the tool knows, it re-derives from GitHub on each request, which is why it can be handed to twenty people at once and why it cannot remember anything between meetings.

The third is the read-only token constraint. Triage Party observes; it does not act. It cannot label, assign, comment or close anything, so every resolution still involves a person going to GitHub and doing the thing. For a workflow that is fine, and it is arguably a feature that a triage tool cannot accidentally mass-close issues. For a team wanting the tool to also file the summary comment afterwards, that step is manual.

The fourth is the release cadence. The newest published release is v1.6.0 from 2024-03-27, before v1.5.0 in September 2023 and v1.4.0 in May 2021, and the last push to the repository was on 2026-07-08. The repository carries a CHANGELOG.md, so history is available, but the gap between the last tag and the current tree is large enough that a self-hosted deployment is effectively running master.

The fifth is that it is aimed at open source issue trackers, not at private repository triage or at customer support queues. The GitHub Enterprise support is via a --github-api-url command line flag, so self-hosted GitHub is covered, but the workflows it encodes, labelled as applicable and unlabelled, and the Resolution-per-rule model, are shaped around public project triage where anyone can file an issue.

Editorial conclusion

Triage Party fits a maintainer team that triages a large backlog together in a call, since the multi-player mode splits the issue list among the attendees, each player works through the list section by section with a documented resolution per rule, and the state stays on the GitHub side rather than in a database. It is the wrong choice for a project with a handful of open issues, since the setup cost is a YAML configuration and a deployed instance, and it is the wrong choice if your workflow needs per-user state, because the application is stateless by design. Before adopting it, read the rules you define and check that each has a documented resolution, note that the requirement is a read-only GitHub token with public_repo permissions, and consider that the last push was on 2026-07-08 with the newest published release still v1.6.0 from 2024-03-27.

Frequently asked questions

Official sources

1. google/triage-party on GitHub
2. Issues
3. License: Apache-2.0
4. README
5. Releases