Bug reports need more transparency on their progress

How exactly do teams prioritize reports? I hope that a report’s age is considered with its impact, team’s workload, and other factors. I would like to restate my idea of an “In queue: #”. I think it might be possible to implement by basing it on prioritization, not deadlines. Stuff has to be getting done somehow currently, and the order in which reports are being addressed can’t be random (I hope).

The reason why I ask: A report for the Kitty Ears was recently addressed in the Catalog Asset Bugs category. In terms of prioritization, it doesn’t make sense that it was fixed so quickly because it was a relatively new report and there is still a backlog. Don’t get me wrong, it wasn’t a bad thing that they fixed them; It was the first time that a Roblox accessory has been fixed in a long time. After they fixed them, more users felt confident and started filing reports in the category. This also happened when Tixvalk was fixed awhile back.

Why the lack of a growth mindset here? It is what it is. If a process is inefficient, what’s the harm in making changes? If a change doesn’t lead to improvement, just revert the change. There are currently 8k members in @AllowBugReports, so I think some change(s) was needed for the increased workflow and providing good communication. I understand being unable to do something that isn’t feasible, but at least be more open to change. I hope this isn’t another reason why this request is taking so long to address.

1 Like

It’s primarily based on impact and effort needed to address the bug. I fail to see how age of report correlates to value of fixing the issue. It is either an impactful issue or it is not, an issue does not become more impactful over time just because it hasn’t been solved.

I hear you, but it’s not feasible or productive use of manpower to predict resolution order in the way you’re requesting across dozens/hundreds of independent teams, each with their own way of planning and roadmap for how they address bugs and ship new features. Nor is it possible to predict up-front how easy/hard certain issues are to resolve. I also don’t think this is a meaningful way to communicate with the reporter personally.

We strive to give you transparency through written update on each impactful issue to keep you updated on what we are doing to address each issue.

In the future, we’re also looking into give you a rough indication how impactful we rated an issue to be internally with a label on the thread.

1 Like

This makes me feel less confident in filing reports for low impact issues that should be fixed because it sounds like they’ll just end up in a big backlog where they might not ever be addressed. That is a waste of my time and is disrespectful towards reporters’ time in general. Reports should be partially prioritized by their age because old reports contribute to the backlog. If two reports have relatively the same impact, I would expect the older report to be prioritized. IMO there should be a balance between addressing new and old reports, and reporters should be able to expect their reports to be resolved within a reasonable timeframe (not years) regardless of their impact. If a team considers a report not impactful, then the report should be closed and locked to not provide false hope.

Out of curiosity, what % of total bug reports have been resolved?

2 Likes

Yes, we’re planning to put a sense of impact/priority on issues in the future so you have better insight into what we are prioritizing.

We close out well over 2/3 of all bugs currently. We want to get this higher all the time of course, and the past few quarters we’ve seen a steady increase in the overall percentage, but it’s not really realistic to assume 100% closure or closure within a certain time frame.

Perceived impact of a bug report can change over time as the amount of creator engagement with the thread changes.

4 Likes

I’m presuming this is also the case for feature requests?

2 Likes

As explained in my replies on other threads, the feature requests are used to inform product decisions, but the way they are handled is much less formalized than bug reports, and so you’re not guaranteed to see any response or closure on those threads.

1 Like