Processing Issues & PRs

This document describes Sentry's process for handling issues and PRs—let's use "tickets" to refer to both together, if that's okay—that are created by external contributors in our public GitHub repos.

1. Validate

Target: 1 hour

The Open Source Team maintains a bot that validates incoming tickets. Invalid tickets are closed; valid tickets are given the label Status: Unrouted. The bot is installed on three repos: sentry, sentry-docs, and onpremise.

2. Route

Target: 72 hours

Each ticket is routed to a single Engineering team based on our internal Product and Service Registry:

  1. Most repos are owned by a single Engineering team, so tickets opened in those repos are already routed.
  2. For the sentry repo, the Open Source Team is responsible for routing.
  3. For the sentry-docs repos, the Documentation Team is responsible for routing.

Routing in the sentry and sentry-docs repos is done with Team: Foo labels and a comment mentioning @getsentry/team, with the "Team" field in the Registry being the source of truth for who owns what.

Some of our code is covered by a CODEOWNERS file; most is not. For the code that is in CODEOWNERS, GitHub will auto-assign a GitHub Team to review the PR. All tickets should get a Team label and a mention, regardless of whether they are also assigned directly. If and when GitHub allows for assigning issues to teams, we can revisit the use of labels/mentions vs. direct assignments.

3. Triage

Target: 1 week

Each Engineering team is responsible for monitoring issues assigned to their team (whether in repos they own, via @mentions, or via their Team label), and triaging each ticket within one week by removing Status: Untriaged, and either closing the ticket or applying exactly one of these three labels (likely with a comment in either case explaining the decision):

  1. Status: Needs More Information — The ticket is not actionable.
  2. Status: Backlog — The ticket is actionable, but is not actively being worked.
  3. Status: In Progress — The ticket is actionable, and is actively being worked.

External core contributors may participate in triage (this is common in SDK repos, for example), but the internal Sentry Engineering team that owns the repo is responsible for the time target and for the final triage decision if there are disagreements.

The Open Source Team maintains a bot (installed on the same repos as the validation bot) that closes tickets (with a warning) after four weeks of inactivity unless they have the Status: Backlog or Status: In Progress label.

4. Resolve

Target: none

Once a ticket is triaged it is up to each team to decide if and when it will be worked on, manage the work using their tools of choice (GitHub, Jira, Asana, clay tablets, ...), and communicate with customers via the GitHub ticket and whatever other channels pertain.

GitHub is the source of truth for the customer.

You can edit this page on GitHub.