Mods are occasionally locking bug reports before engineers review them

Forum Help Forum Features
1

As a bug reporter, I’ve observed many reports being locked that are still marked as “Open” and haven’t received proper review from engineers (e.g., 1, 2*). I believe a possible cause of this is another upsurge in minimodding of bug reports. As I stated in a previous feature request, it can cause more problems, but I digress.

While users who minimod are correct more often than not, I still feel that they do more harm than good. A single user shouldn’t be allowed to determine if a report is valid or not. Sometimes they can cause legitimate reports to be locked. This can impede an investigation by making it more difficult for engineers to reply to a report. This is why I believe it’s important to leave these decisions to the relevant team and/or bug reporting staff. Please see previous statements by staff that relate to this situation below:

I understand some of these users are just trying to help and have good intentions. However, this behavior can discourage users who are learning to file bug reports from filing again in the future. Ideally, I feel that staff should correct users for their mistakes rather than normal users doing so.

A report for the Koala face is a recent example of mods incorrectly locking a report as a duplicate. It’s marked as “Open”, and the previous report was closed. Luckily, I was able to notify mods about it and got this action reversed. The lock messages were also deleted. However, I feel like this shouldn’t have been necessary.

If Roblox is able to address this issue, it would improve reporting bugs by making the handling of bug reports more reliable. I also think better communication between the DevForum Moderation Team, bug reporting staff, and engineers could resolve this situation.

*To elaborate upon the previous situation with the PCWHP report, it was locked without receiving a response from the team around March 21st when it was getting a lot of replies (as indicated by the 6 day gap near the last few replies). I think the lock messages were deleted to improve its flow.

Please note: I have more examples of reports that experienced similar situations in the past, but I felt that a list was unnecessary. I chose to include these 2 reports because I had to make an effort to get them unlocked. Staff also have an understanding of their context. I feel that the examples I’ve provided gets my point across.

4 Likes
2

I feel like the post you linked here is an example of a very niche edge case rather than a widespread issue. Mods are only human, and this specific situation seems to stem from an engineer response in the original report being incomplete or misinformed, which then caused later duplicate reports to be treated incorrectly.

That said, the report you linked still was a duplicate of an existing report; the issue was really that the original report’s resolution/comment didn’t fully address the problem being discussed.

In the overwhelming majority of cases, if a report duplicates one that already has an engineer response or resolution and is Closed, it makes sense for moderators to lock the duplicate accordingly to keep the bug report category manageable.

I’m also not entirely convinced this is primarily a “mini-modding” issue. The fact there’s only one clear example here seems to suggest this is a relatively uncommon moderation mistake rather than a systemic problem with users pointing out duplicates. The one post you provide as an example is already unlocked, so I’m a little confused as to what resolution you want here.

2 Likes
3

This shouldn’t matter as it affected the OP. I favor transparency in bug reports, and locking one without additional info isn’t helpful IMO. The process should be consistent.

IIRC it’s ok to file another report if there’s still a problem, and the original is marked as “Closed”. This is the reason why the example report was unlocked.

The problem with duplicate/dupe relies is by posting one, a user assumes they immediately know everything regarding the issue (which nobody does without further investigation). Take this report for instance. While it was pointed out that it looks very similar to another, it ended up being incorrect to jump to a conclusion on the root cause based on the info provided in the first report. Info in the subsequent report was helpful in determining the root cause for both.

In another case, an engineer might be interested in digging deeper even though the issue might appear to be the same on the surface. Communication with the OP is vital here. It might be ideal to do this publicly, so that other users who are experiencing a similar issue can chime in.

I think sometimes users miss the bigger picture when it comes to bug reports. The goal is to solve the problem. If the main focus is the problem rather than external factors (such as duplicates), resolving issues becomes more efficient. Immediately disregarding a report as a dupe and closing it out might not be productive because the info it provides could still be helpful, the relevant team might want to investigate further, or the root cause could be different.

I had to make an effort to get it unlocked when it shouldn’t have been locked in the first place. Please see:

2 Likes