diff --git a/README.md b/README.md index ca9ce4e7..2e9a4d50 100644 --- a/README.md +++ b/README.md @@ -36,3 +36,4 @@ This repository contains RFCs and DACIs. Lost? - [0071-continue-trace-over-process-boundaries](text/0071-continue-trace-over-process-boundaries.md): Continue trace over process boundaries - [0072-kafka-schema-registry](text/0072-kafka-schema-registry.md): Kafka Schema Registry - [0078-escalating-issues](text/0078-escalating-issues.md): Escalating Issues +- [0080-issue-states](text/0080-issue-states.md): Issue States diff --git a/text/0080-images/States_and_Properties-Current.jpg b/text/0080-images/States_and_Properties-Current.jpg new file mode 100644 index 00000000..04238354 Binary files /dev/null and b/text/0080-images/States_and_Properties-Current.jpg differ diff --git a/text/0080-images/issue_state_diagram.png b/text/0080-images/issue_state_diagram.png new file mode 100644 index 00000000..60fe7c82 Binary files /dev/null and b/text/0080-images/issue_state_diagram.png differ diff --git a/text/0080-issue-states.md b/text/0080-issue-states.md new file mode 100644 index 00000000..ace330cc --- /dev/null +++ b/text/0080-issue-states.md @@ -0,0 +1,88 @@ +# Issue States RFC + +- Start Date: 2023-03-16 +- RFC Type: informational +- RFC PR: https://github.com/getsentry/rfcs/pull/80 +- RFC Status: draft + +## Summary + +🎯 Simplify the triage process by allowing users to easily find relevant Issues in their Issue list + +## Motivation + +Our current set of issue states and how their flow works make it hard to triage. + +![States and Properties-Current.jpg](0080-images/States_and_Properties-Current.jpg) + +There are various problems with the issue life-cycle today: + +1. Customers struggle to find new and regressed issues that they care about + 1. Customers keep seeing old, ongoing issues + 2. The Issue Stream demands a significant amount of manual work to get to an actionable list +2. Customers have to do a lot of mental math to understand if an issue just got worse + 1. 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 + +## What we are planning to change + +We're going to add the Ongoing substate and add some automation to move issues between states. + +The issue properties will transition as follow: + +![issue state diagram.png](0080-images/issue_state_diagram.png) + +Here's an overview of the work: + +### New substates to be added & transitions + +- Notes: + - Check out the [issue transitions table](https://www.notion.so/Improve-Issue-States-and-Filters-1c58cf36ea38459fbc2db26ca0b03675) 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 to `Ongoing` + - Eventually, this task will also be used as part of Escalating V2 in order to transition from `Ongoing` to `Archived-until-escalating` + +### Issue Stream changes + +- `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](https://sentry.sentry.io/api/0/organizations/sentry/issues/?collapse=stats&expand=owners&expand=inbox&limit=25&project=1&query=is%3Aunresolved&shortIdLookup=1&sort=freq&statsPeriod=14d)). + - Change [OrganizationGroupIndexEndpoint](https://github.com/getsentry/sentry/blob/master/src/sentry/api/endpoints/organization_group_index.py) to support new `is:` values + +- 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](https://github.com/search?q=repo%3Agetsentry%2Fsentry%20Mark%20Reviewed&type=code). + +### Finer grain ignore options analytics + +- We currently track how often [the Ignore button is pressed](https://analytics.amplitude.com/sentry/chart/new/xfw2nkw) 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 + +## Drawbacks + +- We may envision a specific approach to triaging and may not work the *many* ways customers may do triaging +- Educational aspect to new workflows + +## Unresolved questions + +- 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?