Me: weird bug, better report it
Devforum: Please take 10 minutes and completely shift your focus so you can fill out this overly-verbose, colossal, and largely unnecessary form.
Me: I will not report this bug
I am not the only one. The fact that I have to even go to this website and make a forum post is dissuasive enough. Stop making this harder than it has to be. I am no longer making any bug reports until this is fixed.
It’s verbose specifically so the dev team can get as much information as they can to try and replicate and fix the bug. It wastes everyones time and patience if they just get inundated with “Hey, Roblox is broken” and no log files or steps to reproduce.
Historically bug reports posted by many users prior to the wizard were extremely sparse for details, did not include the correct details, or were ambiguous requiring extra discussion. The wizard is meant to avoid this problem by forcing you to think in a certain way when writing your report so that you are more likely to include important information.
It takes some getting used to but after filing a few reports with this form I am no slower at it than I was previously. You should give it a chance before outright refusing to use it.
Further, if you want your issues fixed, you’re going to have to report them.
My bug reports do not fall under this category. I should not be forced to use the wizard.
If you were not forced to use the wizard, other users who are too lazy to describe their problems would not be forced either. There is no scalable way to audit users who do not need to use the wizard (there is already a problem with auditing users who should be able to report bugs at all), and using the wizard standardizes reports and simplifies processing them on the engineer side.
Highly unlikely to change, sorry. You should give it a chance.
All three of those text blocks are redundant.
Reproduction steps: You didn’t even put any steps, you just described your platform and gave a redundant timestamp.
Expected behavior: Completely redundant, you are spelling out the obvious intended behavior
Actual behavior: You have restated the redundant thing you put in expected behavior, then gone on to elaborate on how much the thing doesn’t work. None of this is important to the report.
Let’s talk about the rest, too.
Issue area: This is obvious because you posted it in Studio Bugs
Issue Type: Totally useless non-information
Impact: If it’s not critical, this is non-information
Frequency: This isn’t relevant to something that simply doesn’t work
Date First Experienced: This is ok
Date Last Experienced: Why would you even be reporting this if it wasn’t ongoing? If you really want to report a bug that was already fixed, that should just be written in the description.
Instead of filling out all that information, you could have just written “Play solo button does nothing. Windows 8.1. Started 2 weeks ago.”
Hey,
Thanks for giving us your thoughts, really appreciate it!
Just to provide some context; the form exists to help push everyone to report bugs that are more immediately actionable by our teams, rather than starting a time-consuming back and forth. This is important because we need to be able to handle bugs internally super efficiently to be able to scale the number of bugs we receive (and ergo, the number of people who can report bugs).
As you pointed out, you already gave sufficient information on your bug reports - great! One of the other perks of this form for receiving more verbose bug reports from yourself, is that because the fields are standard, we can automate the reading, calculate initial priority, and even start to do a first pass automatic-triage of the bug. This makes our internal processes even more efficient, which is critical as the number of engineers and the number of Creators reporting bugs scale.
What I’d be interested in learning is what particular fields or sections you view as high friction points? We will want to continue to iterate on the form questions so that it provides us with enough information to automate and be generally efficient, whilst also not asking too much of the Creators reporting bugs.
Thanks!
Hey @Sharksie I’d still be really curious about what fields give you the biggest headaches so we can look into improving that.
For context, we recently started shifting more focus on creator feedback workflows like this. In the future I hope that we don’t need this bug report wizard anymore and we’ll just automatically find relevant context for the bug report and pre-fill that automatically (e.g. Studio version, OS info, time things occurred and such) to save you time and frustration. But also curious if there is any short-term relief we can do here that you think might help.
@Sharksie I never got your response to the above, but we just shipped a simplification to the form. There are now much fewer pages (only 2) and much fewer required fields (only 1 dropdown on the first page, and 1 title box and 1 “describe the issue” box on the second page), as well as reduced minimum limit for text fields (300 => 30).
We also reduced the visual clutter on the page.
Let me know if this makes it less tedious the next time you make a bug report. Happy to take feedback to make it easier.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
