Process

This document describes Sentry’s process for handling issues that are created by external contributors in our public GitHub repos.

1. Validate

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.

2. Route

Target: 1 business day

Each ticket is routed to a group of product owners based on the product area (the left nav, mostly). Issues opened in SDK repos are already routed since they are in separate repos.

The sentry and sentry-docs repos cover multiple product areas, and we route using Product Area: Foo labels. A routing bot watches for these labels, ensures that only one product area is assigned, and @mentions the relevant GitHub 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.

3. Product Owner Response

Target: 2 business days

Each set of product owners is responsible for monitoring issues assigned to them (whether in repos they own, via @mentions, by polling a GitHub search, or via Slack pings), and responding to each ticket within two business days in the following ways:

1. Closing the ticket
2. Removing the Waiting for: Product Owner label (likely with a comment explaining the decision)
3. Adding the Waiting for: Community label if more information needed

Additionally, follow ups to issues are also tracked. Whenever a community members comments on a ticket, it will automatically have the Waiting for: Product Owner label applied.

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

A stale bot closes tickets (with a warning) after four weeks of inactivity that are Waiting for: Community.

4. Resolve

Target: none

Once a ticket has sufficient information it is up to each set of product owners to decide if and when it will be worked on, manage the work using their tools of choice (GitHub or Jira), and communicate with customers via the GitHub ticket and whatever other channels pertain.

GitHub is the source of truth for the customer.