Bug reports need more transparency on their progress

As a bug reporter, it is currently too hard to know when a bug report is actively being addressed. Currently, a bug report’s progress can be tracked by viewing a filing confirmation, replies by engineer(s), and its status (Open, Need Information, Fixed, or Closed). However, from my experience, engineers mostly reply if an issue has a major impact or when an issue is resolved; Sometimes an engineer doesn’t reply to a report at all. Additionally, most bug reports are marked as “Open” which conveys little of their progress.

Either an “In Progress” status needs to be added or communication on progress for bug reports needs to be greatly improved. Here are 2 good examples of reports whose progress has lacked transparency:

  1. “Default” button on Profile Picture editor resets full body shot thumbnail incorrectly
  2. SteamVR once again automatically opens whenever starting roblox

If Roblox is able to address this issue, it would improve my experience reporting bugs by (1) knowing if an issue is actively being addressed, (2) not having to bump a report for an update as much, and (3) not having to periodically try to reproduce an issue to check if it has been resolved.

Cc: @Kairomatic and @Hooksmith

20 Likes

Thanks for the feedback! We’ll look into how we can do better here.

FYI, both tickets have recent activity internally in the last month (mostly, trying to figure out the right engineer to own the issue and look into it).

It’s not always possible to 1:1 map everything that happens internally to external world since we can’t account for every single kind of human operation on a task but we’ll see what can be improved.

Yes “in progress” state is an interesting idea we’re thinking about, just need to make sure it doesn’t give false promises to show this to users since different engineering teams have different workflows internally.

12 Likes

I’m sorry to bump, but I just thought of another idea: Would it be possible to have an “In queue: #” for bug reports? Once a report reaches the front of the queue, then its status could be changed to “In Progress”. Of course, the queue # for a report could change as new reports are filed that have a higher impact, but it would still provide a rough estimated wait time for a report to be addressed. Maybe there’s already a similar system for tickets in the internal database.

5 Likes

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:

  1. ProcessReceipt does not fire with TeamTest (In team create)
  2. Tool.Deactivated does not fire if the mouse button is released while cursor is on top of a ProximityPrompt
  3. 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

5 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.

10 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?

1 Like

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.

4 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.