- Start Date: 2023-03-16
- RFC Type: informational
- RFC PR: #80
- RFC Status: draft
🎯 Simplify the triage process by allowing users to easily find relevant Issues in their Issue list
Our current set of issue states and how their flow works make it hard to triage.
There are various problems with the issue life-cycle today:
- Customers struggle to find new and regressed issues that they care about
- Customers keep seeing old, ongoing issues
- The Issue Stream demands a significant amount of manual work to get to an actionable list
- Customers have to do a lot of mental math to understand if an issue just got worse
- The Escalating issues project partially solves this problem
We want to create a curated solution that notifies developers about relevant issues in a timely manner. This means building a solution that shows developers new issues and regressions as they occur.
The states and filters we want to improve in this story are meant to be stepping stones that Sentry can use to create a notification and UX experience that provides better signal value.
Additionally automatic state transitions from New to Ongoing issues becomes important for customers that see a lot of new issues everyday
We're going to add the Ongoing substate and add some automation to move issues between states.
The issue properties will transition as follow:
Here's an overview of the work:
- Notes:
- Check out the issue transitions table for all details
- New → Ongoing (After 3 days)
- Regressed → Ongoing (After 7 days)
- Escalating (new substatus) and Archived (new status) will be added as part of the Escalating project
- When substate changes occur, track in GroupHistory and show in the Activities details
- There is no unignored label after these changes, if an ignored issues becomes unresolved again due to spike detection or because the issue hit a user-defined threshold then it gets the escalating property
- Related work:
- Add Ongoing substate to
[GroupInboxReason](https://github.com/getsentry/sentry/blob/661d7234b93f8164cdcf147fd2b31c31039ed34b/src/sentry/models/groupinbox.py#L28-L33)
- Create daily periodic task to update the status of new tasks into ongoing (after 7 days)
- For every every org, query PG for
New
Groups that were created in the last 24 hours and update the substate toOngoing
- Eventually, this task will also be used as part of Escalating V2 in order to transition from
Ongoing
toArchived-until-escalating
- For every every org, query PG for
- Add Ongoing substate to
-
is:
changes- Notes:
- All existing is searched will continue to work
- Remove
ignored
from the list of allowed values- Perhaps support it but do not show it as list of allowed values
- Add the following new values:
new
,regression
,archived
,ongoing
,escalating
(done in Escalating project)
- Related work
- The API we hit for is searches is this (example call).
- Change OrganizationGroupIndexEndpoint to support new
is:
values
- Notes:
-
Remove Mark Reviewed button
- Mark as Reviewed currently removes the New-Regression-Unignored label
- There will be few more places to remove it from but most of them can be seen here.
- We currently track how often the Ignore button is pressed every day without notes as to what specific options.
- We can either extend the Amplitude query or we can create a query to show the count for each (e.g.
select count(*) from sentry_groupsnooze where until is not null;
) - It would be great to see what options people used before and what options they will use once we switch them over
- We may envision a specific approach to triaging and may not work the many ways customers may do triaging
- Educational aspect to new workflows
- What parts of the design do you expect to resolve through this RFC?
- What issues are out of scope for this RFC but are known?