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.
For some busy repos, like
sentry, we use GitHub Issue Forms to strongly encourage quality reports. For other repos we use old-style Issue Templates, which are easier to get around.
If When people give us garbage issues anyway, we close them.
Target: 1 business day
Each ticket is routed to a single Engineering team.
- Most repos are owned by a single Engineering team, so tickets opened in those repos are already routed.
- For the
sentryrepo, the Open Source Team is responsible for routing.
- For the
sentry-docsrepos, the Docs Team is responsible for routing.
Routing in the
sentry-docs repos is done with
Team: Foo labels. A routing bot watches for these labels, ensures that only one team is assigned, and @mentions the relevant team in a comment.
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, 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.
Target: 2 business days
Each Engineering team is responsible for monitoring issues assigned to their team (whether in repos they own, via
@mentions, by polling a GitHub search, or via Slack pings), and triaging each ticket within one week by either closing the ticket or applying exactly one of these three labels (likely with a comment in either case explaining the decision):
Status: Needs More Information— The ticket is not actionable.
Status: Backlog— The ticket is actionable, but is not actively being worked.
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.
A status bot ensures that we have only one
Status label at a time, and a stale bot closes tickets (with a warning) after four weeks of inactivity unless they have the
Status: Backlog or
Status: In Progress label. Both bots are installed on the same repos as the validation bot.
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.