-
-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Track follow ups #89
Comments
Something to consider here: in #86 we're realizing that GTM folks should be classed as "community" (basically) even though they're on staff. |
From @HazAT:
|
Weekly Update May 8 |
Weekly Update May 22 |
Weekly Update May 30
|
Weekly Update June 20
|
Weekly Update June 26 |
Weekly Update Jul 10 |
We're ready to close this out, yes? |
Tasks are done, just looking to write a shipped post before closing |
Weekly Update Jul 24 |
shipped post out! closing this, other items will be bonus |
Are customers happy with our response times?
Well, yes and no. In Q4 2022, we've introduced slack notifications for routing/triage. We've seen how effective this can be, as our routing and triage numbers have gone up. These are our recent numbers
We've reached all time highs for quarterly numbers, with routing at 97.8% and triaging at 87.8%.
However, here at the OSPO we've noticed two main issues:
How are we analyzing the problem?
Currently, we have two goals: drive up customer engagement numbers and provide a standard way to handle responses between GitHub users and Sentry product owners. Routing and triaging as it currently exists can be a bit confusing.
sentry
andsentry-docs
, while triaging is done in every repo owned by Sentry. Issues that are cross repos are hard to track for teams.Status: Untriaged
andStatus: Unrouted
labels.How can we fix this?
In Q1 2023, our team has implemented a new process for maintaining EPD team changes and product mappings. Most importantly, each issue that comes in corresponds to a product area (Replays, Crons, Issues, etc). A product owner is then responsible for issues that fall under the product area that they own. The initial automations to replace team labels with product owners have been completed. We want to expand on this automation to allow for product owners to easily determine which issues need actionable items.
Right now, we have two Status labels that are primarily used for notifications
Status: Unrouted
andStatus: Untriaged
. Many of the otherStatus: *
labels are unused, and are not used by automation for any purposes. What we really care about is whether or not someone at Sentry should respond to an issue, or if an issue is waiting for a response from the community. We can consolidate theseStatus: *
labels into something simpler and more useful for automation purposes.These are the new status labels:
Waiting for: Support = Support team at Sentry
Waiting for: Community = everyone else
Waiting for: Product Owner = Sentry members who own parts of the product
Waiting for: Support
This status is applied to all issues that are new or need to be rerouted. It will also be applied to issues that Support should be responsible for. Support serves as a overseer for which product areas an issue belongs to. The due date column will be occupied for a route by date. For automation purposes, there are two cases to handle
Waiting for: Support
status to an issueWaiting for: Community
This status will be applied to issues that have been responded to by product owners. Product owners will manually add the
Waiting for: Community
label once they deem that they need more information from the creator of the issue. We will only apply stalebot to issues that are waiting for community.Waiting for: Product Owner
This status will be applied to issues that have last been interacted with by a community member. If a community member comments to an issue, the status of the issue will become this.
We want to use these statuses instead of labels as a source of truth to send slack notifications. Furthermore, instead of tracking the success of two different processes (routing and triage), we can instead track the success of overall response time.
Rough Task List
Waiting for: *
labels #95Waiting for: *
label changes #134Waiting for: *
label logic #98Waiting for: *
labels for Looker Dashboards #133Status: *
labels once they are unused #135Waiting for: Product Owner
across all issues where a community member comments eng-pipes#527Bonus
Won't do
The text was updated successfully, but these errors were encountered: