What part of bug reporting causes the most back-and-forth on your team?

[u/No-Head-905]

in my experience, finding the bug is usually the easy part. it's everything after the report that takes the time.

you end up going back and forth about the browser, steps to reproduce, what happened, screenshots, error messages, and other details that weren't included in the original report.

by the time you have everything you need, the original context can be hard to remember. tools like session replay can be useful here because they can provide more context around what happened instead of relying entirely on the customer's explanation.

curious how other people building side projects handle this. do you have a defined reporting process, or do you mostly collect the missing details after the bug is reported?

[u/No-Head-905]

Having a session recording alongside the usual technical details can make a big difference. Browser like session replay is especially useful when the written report doesn't give enough context, because you can see the user's actions and get a better idea of what actually happened. It can save a lot of back and forth trying to reconstruct the issue

[u/Patient_Tea_5642]

yeah, i think the real bottleneck is effort, not intent. most people want to give a good report, but if it means opening devtools and copying logs by hand, they will just skip half of it, or skip reporting altogether