Hello, I understand, but can a staff member send a little message just to confirm if a staff member has seen it? I’m ready to wait for the bug to be fixed, but it would be nice to at least get a message like ‘we’ve seen the bug, we’ll fix it soon’.
2 Likes
The issue is assigned to someone but the team assigned to the ticket did not leave a public response.
In the near future we’re going to add an “Acknowledged” state to let you know it has been assigned to someone. We currently don’t mandate that an acknowledged issue is responded to by the team that owns the issue since acknowledged just means we have found an owner for the issue, it does not indicate when/if they have time to work on it soon yet.
11 Likes
@Hooksmith I’ve noticed that sometimes a bug report’s status is changed without an explanation being provided. Could it be made a common practice to provide an explanation when a report’s status is changed?
2 Likes
Currently the process only mandates closure messages to be submitted by a human or if more information is needed. We’re going to show automated status change messages in the near future for the rest of the transitions.
3 Likes
@Hooksmith With all due respect, I feel that anyone who files a bug report should expect it to be resolved within a reasonable timeframe regardless of its impact. Possibly, this could be achieved with realistic deadlines. When you said this, I thought of the backlog of reports. I understand that things are going on behind the scenes and sometimes other issues take precedent, but I think this should be considered being improved upon if possible. Hopefully, you can ease my mind on this.
1 Like
There’s a lot of variance in how much effort a bug might take to address. A typo in a webpage can be fixed in 5 minutes, a bug in the rendering system might take weeks if not months to resolve or needs significant overhauls.
There’s no way to put a deadline on bugs being addressed like you suggest. What we can do is clearly communicate on the status of it, so that’s what we’re focusing on.
Also, not all bugs are necessarily worth addressing. Sometimes work is in progress that might make a bug obsolete, or sometimes fixing a bug simply has no impact. It’s hard to make general assumptions because each bug is different.
5 Likes
I would appreciate more transparency and regular follow-ups for Bug Reports, whether automated or manual.
A great example is ClickUp. When I filed a bug report with them, they responded within one day.
Once my ticket was assigned to the correct team, I was supported by an engineer who was incredibly kind, patient, and helpful. He guided me through each step to address my bug report.
The fix was completed in just three days, and the engineer was very understanding of any challenges I encountered during the process.
Here’s how their process worked:
- Automated reminders kept me informed that my ticket was under review (before an engineer was assigned).
- I received notification of the engineer assigned to my case, named (Name here).
- The engineer collaborated closely with me to troubleshoot the issue.
- I was provided with a workaround and informed that the fix was underway.
Implementing a similar approach at Roblox could address several issues:
- Eliminating the frustration of hearing the crickets when topics or DMs are not replied to promptly.
- Reducing the need to constantly request follow-ups or “bump” topics.
- Improving communication and reducing the feeling of being ignored by engineering teams.
- Making better relationships between users and engineers.
False hopes aren’t the primary concern users are facing. Currently, the issue lies in not knowing the status of our bug reports or whether they’re being handled by an engineer, making it difficult to anticipate any pending fixes.
An “in progress” state would provide reassurance that my bug report has a fix pending, confirming that an engineer is actively working on it behind the scenes. This transparency would greatly improve user confidence and clarity in the process.
I agree with this suggestion. Receiving a message assuring us that a fix is on the way (‘we’ve seen the bug, we’ll fix it soon’) would save the hassle of wondering if my bug report is being addressed by an engineer behind the scenes.
Thank you for this update. Adding an “Acknowledged” state would be beneficial for bug reports, letting me know that my report has been assigned to someone.
3 Likes
@Hooksmith Could you please give me an update on this feature request? Mainly, will an “Acknowledged” status be implemented and communication be significantly improved soon? Personally, I have filed 17 bug reports that are still unresolved, and I’m not too happy about that. I feel that actively working on improving communication with bug reports will make the process more efficient.
Don’t have a timeline for you at the moment but it’s still on our list of things to do!
1 Like
I understand, but could it be prioritized soon at least? Bug reporting is such an important process for the platform. It’s been almost 4 months since this request was filed, and pretty much nothing has been done. I find this inaction a little disappointing and disheartening. I hope bug reporting is still strongly cared for and taken seriously.
2 Likes
We have a ton of different responsibilities to different groups of users, be mindful you’re not the only type of customer that my team has. All I can tell you on the above atm is that it is still definitely on our near-term roadmap to do.
5 Likes
In the meantime, maybe something similar to this could be posted publicly (on the “About the Bug Reports category”) if it’s still applicable to the handling of bug reports today. It would help garner more sympathy for engineers when they’re unable to provide extensive communication by explaining their perspective. This was quite an eye-opener. I can file another feature request for this if it’s necessary.
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?
3 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
Why are filing confirmations still being posted on some reports if a ticket is automatically filed to the database? I feel like these generic statements provide minimal transparency that is already conveyed by the “Open” status. Also, I think they are pretty misleading: I’ve seen many instances where the reporter replies to the message, believing that the poster is responsible for addressing the issue and/or interpreting it as the issue is currently being worked on. Wouldn’t the time copying and pasting be better spent providing transparency specific to a report (e.g., perceived impact, connecting the assigned engineer[s] to the reporter, estimated time to fix)?
I understand that revamping the bug reporting process will take time and effort, so I apologize for being antsy in my previous replies. I hope you don’t mind if I continue to provide more feedback on the current process and ask questions about it from time to time.
On an unrelated note, I really appreciated your statement on the report for the workclock headphones this morning; That was peak transparency. You’re the GOAT!
1 Like
We still haven’t been able to prioritize “Acknowledged” status label and automatic update messages for statuses, so these notices will keep being posted until we are able to change that.
2 Likes