Bug Reporting Updates

I believe that this is a good idea so users can share their feedback and how the articles can look better for the next readers, but there is something wrong when you share the input…

Today, a few minutes ago, I sent a feedback message as a test and it seems that it created publicly a topic at #bug-reports:documentation-issues. This can confuse Roblox forum users and staff thinking it is a bug whether than a suggestion.

It would be nice if we could have a Feedback category containing a subcategory for Creator Documentation.

1 Like

Thanks for the feedback. To clarify, it seems like you didn’t notice this part of the form?

Or is the confusion about the forum category, not about the fact it made a forum post?

1 Like

IMO this form does not adequately communicate that it’s going to create a public post when you submit it. I feel like this action is a bigger deal than the design of this form suggests. A small footnote under the textbox is very easy to be blind to. I think an additional confirmation modal that explicitly tells you what’s going to happen would be more appropriate.

E.g.

Notice: This feedback will be submitted publicly to the Developer Forum.

[Create Thread] [Cancel]

1 Like

Heya @Hooksmith!

Yeah, it is about the forum category because it doesn’t fit properly there when it comes to providing feedback of how articles of Roblox Creator Documentation could be better.

It would be better if creating a new forum category for this particular case! :smiley:

Would it be possible to have an “In Progress” status for when these processes (processing, reviewing, or working on a solution) are occurring? To me, marking a report as “Open” makes it appear that it has enough information to be investigated. I feel that an “In Progress” status would elaborate more upon a report being open and add another layer of transparency.

I realize the “Open” status already indicates these processes and applying an “In Progress” status might not be scalable due to the amount of reports that are open. I just wanted to put this suggestion out there.


I can file a feature request if you need me to.

I didn’t notice that either because of how new it is and how it’s account specific to TL2+; in my opinion it’s not an adequate enough disclaimer. In-fact, I wrote a topic about an embarrassing moment I had because of it…

Just to set expectations right… I had a look at your deleted topic and it was totally valid feedback and not at all inappropriate to report.

Where is this quality standard feeling coming from? Is it our requirements or is just a certain feeling you have about the forum? Engineers / writers would have been happy to take the feedback you wrote as-is.

We considered this, but discovered that the idea of “In Progress” varied so much from feature to feature that it may end up setting unrealistic expectations for when something will be addressed.

We’re getting ready to release an update to our internal tools that we hope will improve the frequency of staff updates along the way. The idea here is that we can pair the high level statuses with more detailed replies.

Curious to hear more though!

What are you usually doing/thinking when you feel like you want to see that an issue is In Progress? What would you do or not do if you saw that? And how would seeing that status on a bug feel if it’d been “In Progress” for x amount of time?

Anyone else, please feel free to tag in if you have feedback to add :slight_smile:

3 Likes

I would try to reproduce the issue to see if it has been reduced.

I feel like less reports would be bumped to request an update.

I would have peace of mind knowing that it’s actively being addressed and will eventually be fixed.

4 Likes

Thanks! 1 year anniversary on that thread is coming up dec 5 :sob:

1 Like

A lot of people would appreciate if this bug was looked into as well.

4 Likes

Just as I speculated and predicted @Hooksmith!

It confused one Roblox employee believing it was a bug, but only feedback. As I have mentioned in another message replying to you, the cases to fix this misunderstanding would be either creating a new forum category or utilizing #feature-requests:documentation-features.


(If anyone is reading this and confused about what I am talking about, below, it will explain better)

Ever since this ability was created, it had good impacts actually! Providing feedback is good and can engage with the people behind the documentation on how they can improve in terms of teaching new products of Roblox. However, when it comes to forum users who are Regulars (as their TL, i.e. Trust Level), their feedback is created on the Developer Forum in a category that does not fit its guidelines whatsoever. This can also easily be flagged and outcasted from recent posts.

Furthermore, the Creator Documentation has a new form to translate their pages based on your device location (which was explained by @YuckyBucket [from the Creator Translator Team] here), and with that being in mind, if someone were to create a feedback message without being in English, it can be hard for readers to get it. (Yes, they, the readers, can translate messages utilizing any software that relies on Machine Learning to provide the text in the language they hope to open their eyes, but let’s not forget that it can be inaccurate.)

Pros:

  • Can be good for ways to understand the perspective of the reader.
  • Better engagement.

Cons:

  • Easy to confuse Roblox employees thinking it is feedback instead of a bug.
  • Easy to be flagged and removed for not following the guidelines of the category.
  • Creates barriers if they are in other languages.

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. :sweat_smile:

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. :dizzy_face:

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:

image

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! :smile:

Thank you! :saluting_face:

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