I do agree with this. Having it make a bug report is quite extreme for some simple feedback. It’s feedback, which if anything would be a feature/improvement request, not a bug report.
Just to set expectations, we do not care about a rigorous description for these “bug reports”. Simple feedback is fine and it’s not problematic that this is turned into forum threads for us internally. It seems like there is some friction where the community has a high standard for these kind of threads, but for us internally we really appreciate the feedback either way.
I’ll follow up internally on the threads you mention to understand if we can just keep these open or move them for the user, or combine the forum categories.
My expectation is that over time the community will realize that putting shorter form content in this category is fine and this quality / quantity concern should mostly vanish.
We have a couple things in flight:
- We’re adding a checkbox soon so you can optionally send to forum to get status updates, not required.
- We might combine some forum categories together. It doesn’t really make sense for documentation content to split between “bug” and “feature request” because that’s not necessarily how our technical writers are addressing these.
2 Likes
Erm… No one is saying this? Not even what I am saying is about creating descriptions for bug reports. 
The ideal and what I am saying is just to transfer to a category that fits properly to it, #feature-requests:documentation-features because it does not make sense to be a feedback but to be in a report category. It is like making creation feedback, but instead of being on #help-and-feedback:creations-feedback, you put in #development-discussion. It won’t make sense. 
Would it be possible for you to explain it better about these two things? I got confused…
I don’t think the distinction between bug reports and feature requests makes sense for documentation requests. There’s just issues with the documentation and they are generally addressed by the same set of people. (our technical writing team)
For other categories (engine, studio) there is a clearly different set of people addressing those (product manager vs engineer), and generally there is a vastly different time investment for missing features vs. bugs, so there it does make sense to have some indication of a split so we can handle those types of requests differently.
Hence talking about combining the two categories (#bug-reports:documentation-issues and #feature-requests:documentation-features) above.
The docs site integration now has a checkbox that you can use to optionally send to the forum, not as a requirement:
Thanks for your feedback.
3 Likes
For problem area, there is no option to select “Website / Ads Manager”
Hello @Hooksmith! How are you doing?
I understand that distinguishing between bug reports and feature requests can be challenging as different people handle requests from forum users, such as product managers or engineers. However, it would confuse a Roblox employee if a user reported a bug as a feature request.
I am unsure if there are any possibilities for other employees to sort this out with the technical writing team. For example, technical writers could have control over #feature-requests:documentation-features. If it is possible to combine the two categories, will there be a new category? I am curious to know more about this brainstorming idea! 
Thank you! 
1 Like
To @Hooksmith / @Kairomatic:
Ever since the issues regarding the interactivity or other parts within using the Roblox website, it has now been merged into a new category by the name of “Roblox Application and Website”. The same idea also relies on this new category when it comes to cross-platform issues (i.e. Mobile/Tablet and Xbox).
With this, I always wondered, what is the future for #bug-reports:mobile-bugs, #bug-reports:website-bugs and #bug-reports:xbox-bugs? Will they be locked and “deleted” (not visible to anyone except for those a part of the Creator Services Team and/or Technical Writing Team)?
Furthermore, since Roblox is now expanding to new platforms such as PlayStation and Meta Quest, if a developer were to report an issue they encountered using these devices, will they need to #bug-reports:roblox-application-and-website-bugs as well? I know it may sound a bit silly to ask, but I believe it would be great for confirmation since I have been seeing a developer reporting bugs using a console from PlayStation (as a sample), but it always ends up being within the #bug-reports:other-bugs category.
Thank you!
1 Like
Quick question, is there a option for the OP to change the bug report status located at the top of the topic? Sometimes the bug is resolved and the topic gets closed, and the bug report status never gets updated to reflect the bugs status
Yes we will improve the category layout over time, it’s in an in-between state at the moment.
Regarding the documentation issues/requests category I am not sure I understand your concern. Ultimately it’s up to the technical writing team what works for them in terms of where the feedback is submitted. No they are not confused by the current setup.
1 Like
Hiya, @Hooksmith
It is the same concern as I have been stating… Again, if the idea of merging the categories, as you mentioned:
Can be good for both parties, then it can improve the relationship between #bug-reports:documentation-issues from #feature-requests:documentation-features as they are controlled by different groups! 
Does that make sense now? Let me know! 
1 Like
Previewing Posts is a bit more nerfed that the regular way on how you create Forum Posts.
Edit:
Did a magician just fix that, it’s better now.
Maybe it was fixed already before I posted this.
1 Like
It is currently impossible to create posts using the Wizard in #bug-reports:mobile-bugs.
I had a recent bug report:
And the closest category I could select is #bug-reports:roblox-application-and-website-bugs .
I believe we should have the ability to put it in #bug-reports:mobile-bugs.
This was explained in the OP.
See:
Whoops, I just saw this as a feedback thread in the wizard.
Thanks for informing me.