Guidelines for responding to new forum users

As mentioned here, we have a new program for new members. New members have limited posting privileges within Development Support and Inception so that they can learn the ropes of the forum. As these users are still learning, their posts may not be up to par with what you expect.

Choosing to respond to the user:

We understand some of you may dislike these posts made by new members (or low-quality posts made by full members). In this case, please do not respond do the thread with “Umm…?”, heckle the user, or similar. Instead, point a Community Sage to the thread. Our job is to teach these users how to properly use the forum, so save yourself a headache and let us do the heavy lifting.

Responding to the user:

If you choose to help the user, please be patient with them. If someone asked how to give users 10 Robux when they touch a button and posted in the wrong category, you should reply something along the lines of:

It is not possible to give users Robux through Lua scripts. Economies rely on there being a limited quantity of currency, so allowing developers to give out an unlimited amount of Robux would destabilize the economy.

Your reply should answer their question, or bring the thread closer to answering their question (e.g. asking for clarification). When you ultimately do answer their question, you should explain your answer. These users are learning, and it is important that they understand the why of an answer, or they will never improve. Please ensure you are not repeating what has already been posted on the thread as well, as this can be extremely frustrating to the user.

You will also notice the response neglected to inform the developer they posted in the wrong category. When a user makes a mistake on the forum, please ping a Community Sage so that we can PM the user. We want to avoid 10 people overwhelming the user by PMing the same feedback, and users derailing the thread with forum tips. By letting Top Contributors teach proper forum usage, we can avoid duplicate PMs and derailing the thread. The one exception is duplicate threads, where it is fine to link duplicate threads and ask the user to use the search in the future. Derailing the thread is not a concern in this case, because discussion should not continue on duplicate threads.

Pointing Community Sages / Forum Mods to the thread:

If a user needs feedback on how to use the forum, you can either PM the @Community_Sage group on the devforums or DM them through Discord.

If a post is completely inappropriate and should be deleted, please flag the post and the forum mods will handle the post.


Did you change the name from basic users to trial users?

They’re synonymous. Basic user is the cryptic name of the trust level, similarly to the old name of the visitor trust level (new user), which caused confusion about who was a member of the forum and who wasn’t. Trial user is more explicit than the ambiguous “Basic User” which is open to interpretation.


Is the basic user name because of the discourse default user levels?

Yes. The default Discourse trust levels are:

  1. New User
  2. Basic User
  3. Member
  4. Regular
  5. Leader

So far we’ve only changed the name of “New User” to visitor since it was confusing whether a new user was actually a forum member or not based on the naming. We may end up changing the name of “Basic User” for similar reasons, and likewise for “Regular” if we ever use it.


Right, I saw some post on here mentioning those roles.

I agree with this. The first time I looked at my profile and saw “Basic user” I was confused as to what it meant until I found some sort of definition. Calling it a “trial user” or “trial member” seems more intuitive.


I agree. When I first learned that I finally got into the devforum I was all excited because the name “basic user” implies that you may have more privileges than, say, “trial user” or “trial member”.


Why aren’t trial users able to report bugs and exploits?
I have a few.

  • AllowThirdPartySales seems to be able to be set by scripts, which is bad for inexperienced devs who use free models (e.g. the admin commands script which offers itself to everyone who joins) or games without FilteringEnabled where injected scripts will invoke the following exploit:
  • There is no delay between a purchase item prompt opening and its confirmation button becoming active, which some people exploit by tricking the player into rapidly clicking a button then opening a purchase prompt with the confirm button being where the player is clicking (This is an exploit I heard about, never seen it myself)
  • If an AncestryChanged event is fired for an anchored part being moved to workspace, for an instant Part.Anchored and Part:IsGrounded() will both be false.

These two aren’t so much bugs as questionable programming:

  • SetNetworkOwner() gives an error instead of a warning and thus stops the thread if an issue occurs, which is a bad trait given that the effects of the function are mostly cosmetic and the errors are BasePart-related thus can be caused by external sources. It’s bound to unexpectedly stop threads and perhaps completely break a tool or object in a game, if not the game itself.
  • The chat filter regards characters that look like a certain letter, but aren’t that letter, as a totally different letter. C with a slash through it should be treated as a C for purposes of filtering. I’m not a fan of censoring, but the reason so many irrational things are censored is because huge numbers of new filters are created to try account for every variation of curse words, when what really needs to be done is to make a filter for the filter which undoes those variations (e.g. treats numbers as 1337speak, so it converts 1 into I and 3 into E)

This actually goes back to why the forum is private. On one extreme, we allow public access to the forum, with the result being the Roblox forums. The other extreme is that we restrict the size of the community as much as possible to ensure only the most valuable contributions exist here.

The trial user program was our solution to this, as it enabled us to add a larger volume of users by locking down categories prone to mistakes. Ideally, during this time trial users can learn the ropes of the forum. Feature Requests and Bug Reports are easiest two categories to misuse, which is why they are locked for the duration of the trial program.

There’s not many contributions a trial user can make though; with no ability to report bugs, it’s limited to Development Support, where there is already an abundance of support from people possessing knowledge well beyond most trial users.
Hardly trial users, given that they aren’t trialled in any way.
I think that it would be good if there was somewhere that trial users can report bugs, for example a single thread in each bug-reporting subforum.


You’re correct that trial users are limited in how they can use the forum, but that is by design. By restricting access to categories frequently misused, we can add a larger number of users than we otherwise could.

Trial users’ contributions to the forum are reviewed after their trial period ends to determine whether they will be added as a full member or not.

This doesn’t sound like something we’d ever do. Our goal is to teach users how to post constructive bug reports/feature requests, rather than divide the community with a barrier similar to S&I vs devforum Feature Requests.

It may suck being unable to post feature requests/bug reports, but the same could be said for non-members. You’ll just have to tough it out for the duration of the trial program. Luckily in the meantime, our existing community is pretty good at reporting issues, and there are existing threads for all of the issues you mentioned earlier, where appropriate.


Rewrote & Edited:
Okay so after searching around and reading more stuff that confused me more about this program, I’m beginning to understand but in general I think the concept is a little confusing and should just be called a “trial user” instead of “upcoming developer” as it’s a really broad and hard to understand concept; from what I gather not as good developers get added to the upcoming developer’s rank instead of the members rank. This seems counter productive to me but I understand the concept to an extent.

Sorry for bugging you guys it’s just like trying to wrap a tree around your car, it’s impossible to do but you can wrap your car around the tree.

1 Like