Enhancing Issue List Ranking and Interactions - Your Valuable Feedback Requested!

[therealarkin]

Hello Everyone!

I'm Eran, a PM here at Sentry. We're on a mission to keep improving your experience, and one area we are focusing on is our issue list ranking and view.

While we've developed robust search capabilities, our data indicate they are not frequently utilized, and we are working on exposing them better. Interestingly, we've observed that many of you engage with issues that are ranked lower on the list. This tells us there's a significant opportunity to improve and better meet your needs.

We would love to hear about your experiences and preferences. To kick off the discussion, here are some questions:

1. What factors guide your decision to view, assign, fix, or ignore an issue from the list?
2. How are you finding the list view itself? Are the Error type, name details, etc, helpful?
3. Are you using the hover state to guide that decision? How can we make the hover state better?
4. Are there specific elements you would want to be considered in our improved default issue ranking?

Your insights will directly influence the evolution of our issue list and priority sorting. Thank you in advance for taking the time, and we can't wait to hear from you!

[naticaceres]

1. how much users complain about it and how noisy it is (how often it happens).
   Edit: We use the JIRA integration tool and we receive user feedback there. updating the sentry issue status and comments with JIRA interactions and statuses would be incredibly useful.
2. IT is helpful, but our errors sometimes end up with cryptical non descriptive names. We need to go back and make sure our error management internally is helping us.
3. I didn't know about the hover state, I'm looking for it right now!
4. YES, we have multiple projects (backend, front end, readDBreads) and multiple times, an error that is logged by the front end project, can be traced back to equivalent errors in the 2 other projects. I whish we could group them all together or at least link them all to each other in the "all projects" view, bc they all share the same ID tag, but I haven't found a way to do that. is there already a guide? help 🥲

[therealarkin]

Thanks @naticaceres!

1. How do you know "how much users complain about it"? And when you know it what do you do?
   2a "sometimes end up with cryptical nondescriptive names" -> Can you give me examples of names that are helpful vs. names that aren't from the last couple of issues you see?
   2b. "We need to go back and ensure our error management internally " What tools do you use? Do you know that Sentry has many integrations(Jira, Asana, etc)? And if so, do you find them helpful?
2. Thank you!
3. Great feedback - we will look into it!

[naticaceres]

How do you know "how much users complain about it"? And when you know it what do you do?

We get our users and user-facing team reports all in JIRA as comments in JIRA bugs. We also link our sentry issues to Jira. Most of the times, an user complain can be traced back to a sentry issue, so we link them using the Sentry JIRA integration.

2a "sometimes end up with cryptical nondescriptive names" -> Can you give me examples of names that are helpful vs. names that aren't from the last couple of issues you see?

Sure! Error h._ and System.Exception are trademarks lol. Their description is actually helpful, but the title says nothing.

2b. "We need to go back and ensure our error management internally " What tools do you use? Do you know that Sentry has many integrations(Jira, Asana, etc)? And if so, do you find them helpful?

We are using Jira among other internals. I do find it helpful.

I found another user asked on 2019 the same question I am asking today (how can I link or group issues in sentry from different projects?) but I found no answers to it in Github or in forum.sentry. Is this still unanswered? I can use any help or guide to at least understand if this cannot be done today with the tools available.

[tdtm]

+1 on @naticaceres 's no 4, same here. Linking those together would be great.

In our case, when the API encounters an error, it'll include the Sentry ref in the response JSON. The API's Sentry project thus has that exception with the ref, but the error response returned to the app consuming the API will also get the Sentry ref. Depending on the case, the consumer may also have its own, separate exception logged with its own ref.

Best approach I can think of is to have a "previous" property on the Sentry event object that we set through the SDK, which gets a list of other Sentry refs and sends those alongside the event. Then the Sentry UI can link those.

[tdtm]

1. What factors guide your decision to view, assign, fix, or ignore an issue from the list?

From the list...

• View: I don't have enough information to know what to do with it
• Assign: I have enough information from the preview to know who/what team is best suited to address it
• Fix: Most often, it's something that I know is fixed, either because it didn't get auto-resolved (perhaps because we forgot the "fixes project-abcd" commit comment) or because I can tell it's a duplicate that wasn't automatically grouped
• Ignore (archive): Typically it looks minor and hasn't occurred many times, so I'll archive and deal with it once it comes back enough

2. How are you finding the list view itself? Are the Error type, name details, etc, helpful?

Fine. I'd like bigger pages though.

3. Are you using the hover state to guide that decision? How can we make the hover state better?

On occasion. I think I'd rather have a side panel with a summary (kinda like email clients) rather than hover.

4. Are there specific elements you would want to be considered in our improved default issue ranking?

Some sort of learning algorithm that improves over time?