Sorry but this does not correspond with how people internally work on bugs. At Roblox each engineering team decides its own workflow for handling issues and there is no feasible way to assert this kind of time estimation mechanism across all teams. It’s not feasible to predict when an issue might exactly be worked on, it depends on what else is on that team’s plate and how they prioritize your bug.
7 Likes
I don’t know if this belongs here but it does relate to bug reports and their status.
Sometimes bug reports seem to just get lost, even after months or years of them existing and some being bumped, there is no indication that any ticket has been filed, or that any work is going to be done on them. Is this something that could be brought up alongside bug report status/progress?
Some that I’ve encountered personally:
- ProcessReceipt does not fire with TeamTest (In team create)
- Tool.Deactivated does not fire if the mouse button is released while cursor is on top of a ProximityPrompt
- RichText strokes don't fade out with TextTransparency
If it’s easier to track if I make a separate thread, or if this qualifies as a bug let me know and I’ll file a separate report, I just felt like this sorta belonged here
6 Likes
The first issue is too old to be in our new system. We’re going to do a historical triage of issues older than 2020 at some point. Sorry for the inconvenience.
Some issues from before 2020 were ingested based on popularity and recent activity. This one did not make the cut at that time.
For the other two issues unfortunately there is no more information on the internal tickets than is on the threads, so they are as transparent as they can be based on info in internal system. I’ll ask to have them looked at by the assigned engineers.
4 Likes
I see. Is the historical triage going to be relatively soon or would it be more worthwhile to just refile it?
And the second part, that sounds good, thank you
3 Likes
If this is actively blocking you from doing something right now you could re-file it, but I can’t guarantee it will be looked at faster via that route.
4 Likes
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