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.
sentry-docs repos have multiple teams working in them, and we route using
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. For the
sentry repo, the Customer Support team is responsible for routing. For the
sentry-docs repos, the Docs team is responsible for routing.
Some of our code is covered by a
CODEOWNERS file; most is not. GitHub auto-assigns PRs that touch code covered by
CODEOWNERS. 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.