Wouldn’t this potentially expose normal users to gore or NSFW who are just trying to make a topic? I’m not sure if I support having to be a “moderator” in order to post.
8 Likes
I personally agree with this idea. I am a member and it is very frustrating not being able to express daily bugs I experience nor being able to request features to improve my development. In fact, I feel a little left out since roblox deleted the opportunity for members to attempt to speak their minds. A solution like this would help me and many other developers.
As for this solution, I think it could use some polishing before being implemented to the forum. To restrict users from mass approving posts, they should be limited to approving 1 topic per day. If any of these topics stay inactive for roughly a week, they should be instantly deleted (unless they gather up the minimum amount of approvals).
2 Likes
Oooooo this system actually seems kinda cool
2 Likes
Everyone here (should) be 13+. I’ve seen inappropriate content posted online many times before and I’m just 15. Not too bad (or then it’s just me who doesn’t get disturbed by bad content). Not our responsibility if someone is a little kid and uses an alt to come here and sees inappropriate content. NSFW is also rare here, I’ve not seen it on DevForum.
2 Likes
So in short: basically the original Post Approval program but with more steps and potentially exposing many users to inappropriate content from malicious posters. No support from me.
This still suffers from the same subjectivity that single-person Post Approval did but opens it on a broader scale with enables further problems like malicious behaviour when reviewing topics and system gaming. I would trust single-person PA more because their members are carefully selected from a pool of active contributors with good standing.
Additionally, you should focus on problems rather than solutions. It seems tempting to post a proposed way to fix a problem but the solution to a problem is ultimately up to Roblox’s teams. Your only role is to raise a problem you’re having as a developer or user of the service.
I think I should mention that post approval was never a form of community moderation, only discussion control. Sages and Post Approval were still required to flag problem threads for real moderators to deal with. No community member has moderation capabilities.
I cannot, in good faith, support something that creates more problems than it resolves. The counters to the documented cons aren’t very convincing either.
6 Likes
I mean, this is definitely better than nothing. Of course, the launch will be painful because it will take time for users to discover the feature and learn the rules, but later on when people learn the rules the system will be stable and will work as intended.
But unfortunately, I highly doubt that this will be implemented like 70% of other requests and will probably be ignored like 100% of our cries about the absence of PA replacement.
1 Like
Not sure why being 13 makes it okay to show them 18+ content before the mods can even stop it. There’s a reason it’s called 18+, not 13+. Thirteen year olds are still kids.
This would essentially place every kind of burden that moderators are paid to face onto literal children. Most of the forum is 13-17! I thought it sounded kind of neat at first glance, but no support.
4 Likes
I mean I’ve moderated a Discord server before. I literally had to ban people for 18+ content and I’m just 15 right now. I’ve not been disturbed by those 18+ images ever. So if you’re just moderating, it’s not that bad. Just moderate the poster and forget about it.
1 Like
Currently, users can be exposed to offensive content anywhere on the forum, particularly in development discussion with the rise of trolling attacks. This isolates the exposure and creates barriers to spamming and a clear path to sending the post to DevRel without it ever being sent to the wider community.
Hopefully, having this system in place would end up decreasing the incidence of NSFW content posted on the forum by trolls, because by limiting the audience to 5* reviewers, their goal of getting attention would be almost impossible to achieve.
Yep, the goal of this system is to create a sustainable method of ensuring quality content while still giving everyone the opportunity to post.
This phenomenon is already regulated by a few things:
- Limit of 5* credits maximum in any user’s account.
- DevForum topic posting limits (already in place)
- Shared moderation action for false approvers and bad posters.
Limiting the number of posts that could be approved to 1 post/day would mean that everyone would only be able to post every five days.
While it definitely is not a requirement, implementing a self-moderating system can make the public categories more polished and organized for a <13 kid visiting the forums to learn to develop (as a not logged-in visitor, which is possible).
I wasn’t too familiar with the later post approval system (the one with the fancy plugin and badge), but I can definitely agree that there is some fundamental overlap. However, there are also a few very important differences that make this system more effective than the last:
- Sustainable: in order for a member to submit a post a topic, they have to review a small portion of the queue.
- Self-regulating: this time, (almost) the whole community is involved, rather than a small group of forum veterans.
- Efficient: As more people want to post topics, more topics get reviewed, which ensures the topics are reviewed swiftly.
As said earlier, the DevForum already has inappropriate troll posts popping up. But with this system, the audience would be much smaller (5*), which decreases the potential attention for trolls, while also situating that audience next to a report button. I’ll update the original post to clarify that there would be a well-situated reporting system for offensive content.
The subjectivity is an aspect of all moderation. This, in its very simplest form, is a preemptive flagging system. Rather than allowing low-quality content to get posted, only to be flagged and removed hours later, it makes sure that low-quality content is never posted to begin with.
If the content is deemed malicious, obscene, or otherwise offensive, the post will be sent to DevRel.
If the content is simply low-quality or inappropriately categorized, the OP will receive feedback in order to make changes to their topic as needed.
Malicious behavior with regard to failing topics is countered with a traditional admin-based moderation, through an appeal from the poster. Similar to the false-approval punishment discussed earlier, if an appeal is successful, the users who maliciously failed a topic will be punished. I’ll update the original topic to better explain this (I only included it in one of the design mock-ups).
System gaming has already been extensively discussed. Could you be more specific about how you think the system could be abused beyond alt/friend approval?
Also, after seeing this feedback, I’ve decided to remove the skip button from the design mock-up. Now, rather than being able to skip to your topic, you will be forced to review whatever is at the top of the queue. Although you could spend 30-50 minutes refreshing 5 alts, by the time your post reaches the top of the queue, it will likely already be reviewed by someone else.
(Note that it could be 2-3 hours before I have time to update the image)
Just like how it is necessary to identify issues with Roblox’s team, it’s also important to identify potential changes. That’s why programs like the community sage group existed and why Roblox implemented a community feedback program. Not just to see what’s wrong, but how the community believes that it should be fixed. Please see this topic for more info:
Good to know! I haven’t been in post approval before, so I wasn’t sure where exactly the line is drawn between feedback from post approval and DevRel’s moderation capabilities. This new system should function in a similar way, where malicious topics are handled by DevRel while low quality topics receive feedback from the community.
The goal of this proposition is quite the opposite. By building a system of self-moderation, the community can have the benefits of the old post approval system without the unsclalablility of the legacy system.
I’ll elaborate on those more. As more feedback comes in, I’ll try to update the original topic to reflect the pros and cons that have been raised.
That’s the goal! Even though it doesn’t necessarily resolve all of the issues, it would represent an improvement for both sides. Both those requesting greater accessibility and those seeking higher quality would get what they want (rather than the current situation, where categories are still locked down and the forum is filled with low quality threads).
This is one of the biggest improvements promised by the system. Right now, users learn the rules by posting bad content and getting feedback. This clutters the forum and leads to low-quality content proliferating as a linearly growing moderation team tries to control an exponentially growing forum. With the new system, bad topics would never be posted to begin with, which stops low-quality content before it can start.
A recent post has received a reply from Roblox staff that DevRel is currently researching a major project to overhaul content discovery on the DevForum. This shows that they are open to starting major efforts to improve the Developer Forum. By creating this feature request and describing it in detail, there is hope that progress can be made.
Under the current system, mods can’t do anything to stop offensive content before it is posted anyways (outside of a few measures like word filters). This already occurs in places like #development-discussion where trolls will spam offensive content. Right now, the community is limited to flagging the post (which still requires viewing the offensive content) and hoping it is swiftly removed before others find it. In contrast, this new system would limit the incentive for trolls by decreasing the size of the audience (and thus the attention) and give an option for community reviewers to flag the post immediately before it is broadcasted to the wider community.
Moderators are paid to review hundreds, if not thousands of posts per day, and on this forum particular, few of the posts flagged are actually 18+/NSFW (in my experience). For me, the top things I flag are:
- Off-topic
- Specific rule violations (e.g. no posting on behalf of others).
- Unsubstantive/spam
- Insults/ad hominem attacks
I’ve only had to flag maybe 3-4 posts for offensive content out of the 11.3k topics and 115k replies that I have read (but this could be different for other users).
While a few 13-14 year olds may not be mature enough to understand and take appropriate action against 18+ content, it isn’t possible to create a sustainable cycle of post approval unless everyone is required to moderate to post.
Thank you for your feedback everyone! Later today I’ll try to update the original post to clarify some of the concerns you brought up and add in the pros and cons that have been discussed.
2 Likes
All forms of post approval were the exact same. The plugin and badge were only meant to automate certain tasks rather than do them by hand as well as allow Post Approval members to directly accept a thread into a category.
In regards to your differences points, no those don’t make it better. Sustainable goes against DevRel’s principle of accessibility, self-regulating isn’t convincing given the current nature of the forum and it’s not efficient either because I’m sure a lot of people share the sentiment of not wanting to review topics just to get an answer to a brief or important question in addition to the fact that this also tickles on the negative side of accessibility to the forum.
The point here is that you should be focusing on the problem not the solution. This is applicable for regular feature requests as much as it is for forum feature requests. Roblox will resolve the problem in the way they best see fit. I’m not saying don’t propose a potential solution but your post’s focus should be clearly describing the problem not the solution.
Not agreeing with any community-driven “moderation” solutions. Developers should be focused on developing, moderation should be left to moderation.
2 Likes
The system proposed with credits and forced community moderation is just not fair for the community. I see in a reply that you stated people should just “forget” about inappropriate content. You have to keep in mind that some people are more disturbed about certain topics than you might be. The point of the DevForum is to discuss development related topics, not moderate a forum about development. DevRel has already removed the more community moderation systems due to it being unrealistic for an ever-growing community.
Buildthomas has already created a post elaborating on a more proactive method of moderation that is better suited for the growth of the platform and for future scalability. While I do not agree with everything in it, I totally recommend giving it a quick read as it presents great information on how prevention can be better than moderation.
4 Likes
Sorry for the late response everyone! I wanted to take the time to make sure that I could provide a comprehensive and complete response to your points.
So do CAPTCHAs (fun CAPTCHAs in particular), but both systems are necessary to prevent the spread of low-quality content on the site. No forum for discussion can be high-quality and completely open. While I agree that it is important to make sure that the DevForum is easy to use, unfortunately not everyone is willing to use it correctly. For trolls, new users, and people who post just to post, it’s necessary to add some safeguards, just like how CAPTCHAs are added to group walls on Roblox to safeguard against botting. The comparison is similar in the task itself as well. Completing a CAPTCHA is a small hassle and it only takes a few minutes.
Also, don’t forget that this system is meant to be graduated from. Once members successfully get through the system enough times (TBD by DevRel), they would be promoted to regular and have free posting capabilities. However, until they can prove themselves, this system acts as a set of training wheels for those who might not fully grasp the rules.
Therefore, by implementing the new PA system, the DevForum could be more accessible than ever, with regard to who is allowed in. Although members would have to wait 20-30 more minutes before their topic is sent to the wider Roblox community, the PA process would ensure that everyone who wants to post on the DevForum can submit their topic. In addition, by ensuring that incoming topics are of substance and quality, the signal-to-noise ratio would considerably increase, expediting the speed for support, help, and feedback (which would make up at least some of the lost time). Barriers to membership would not need to be as high because there would already be checks in place to make sure that content is good and rule-abiding.
I do agree that there would definitely be a need for DevRel to intervene at times. The most obvious cause would be when prospective topics are flagged for moderator attention. In addition, the system is meant to be dynamic and flexible in the sense that DevRel could adjust the system as needed. If there are too few credits going around, they could increase the reward ratio from reviewing posts (i.e. instead of 1 → 5 * 1/5, it could be increased to 1 → 5 * 2/5). If the number of posts in the queue is too high, then DevRel could temporarily lower the number of reviewers to speed up the process (i.e. 4 → 5).
However, with regard to the system by itself, I was referring to self-regulating in the sense that volume on both sides would conform itself to supply and demand. So, for example, if a lot of people want to post on Saturdays, those people who want to post would have to review, which makes it were more topics can be posted.
I do think that it could be more self-regulating if whatever plugin administrates the system is built with an algorithm that automatically adjusts stats like the number of reviewers and review reward, but that seemed like it might not be feasible, at least initially, because no one knows how exactly the system would function in the wild.
I already addressed some of this in the sustainability/accessibility section above. To avoid repeating myself, here are a few supplementary points:
- While regulars who can post in all categories may not want to review topics, members who make up “a lot of people” on this forum likely are.
- The good news for regulars is that they won’t have to review topics (regulars keep free posting permissions).
- Members can become regulars through this system.
- The good news for regulars is that they won’t have to review topics (regulars keep free posting permissions).
- Members have been locked out of #bug-reports and #feature-requests for a while now, and constantly are blamed for quality problems in #development-discussion.
- Any access would be an improvement, even if it meant creating a minor barrier to low-quality content.
- Much more efficient than sending a message to DevRel and receiving no response or going to Customer Support and hoping they will do something about it.
- Oftentimes “brief” questions often don’t have enough substance to spark a meaningful discussion or have already been answered.
- Currently very common in #help-and-feedback (e.g. “What is pcall”)
- Also prevalent in #development-discussion (e.g. “Are rank purchase places allowed?”)
- Questions of importance will still be able to pass post approval
- This system is intended to increase the prevalence of high-quality, significant, and important topics.
- May result in better responses to significant questions, because of an increase in signal to noise ratio as fewer spam/repeat/off-topic topics are posted.
While I understand the point you’re trying to make, identifying issues still isn’t the intended use of feature request categories. However, I will try to clarify the Background section to make it clearer what issues I believe this plan will solve. If you truly believe that this topic is still inappropriate for #forum-feedback:forum-features, feel free to flag it.
You’re right: developers should be focused on development. Not sifting, flagging, searching, waiting, sorting, and all of the other menial tasks required to use the forum in its current state. Like you said earlier with regard to post approval, normal users are the ones who forward the threads to moderation. This update would move flagging to the front of the posting queue, which allows users to flag proactively as opposed to the current reactive system (note that the current flagging system would still be around for topics that receive low-quality replies or edit the topic to include bad content). Community moderation has always been a part of this forum, but by introducing this system, it can be utilized more effectively to prevent bad content from emerging.
The current system isn’t very fair for the community either! Members are currently restricted from directly shaping the platform’s future and are facing closures of other categories as well. While I would love for this system to be voluntary, unfortunately, no one would participate if it wasn’t required for something else, which would lead to a repeat of the original PA system. The next best thing is tying the review system to posting topics, which creates a closed system in the sense that you only need to review if you want to post, and by posting, you provide something for others to review so they can post, thus making it cyclic in nature. Also, don’t forget that this new method of post approval is only required for posting topics. Reading is still completely free.
I reread all of my replies and it doesn’t look like I ever suggested that users should ignore/forget/disregard offensive content. However, it appears that another user may have implied that. To be clear, I do not agree that repression is an appropriate solution.
I completely agree that some people may be more sensitive to certain topics and content. Unfortunately, there are no effective ways to reliably analyze content without human intervention. Here are the two main points that at least partially, if not almost fully counter the NSFW content argument:
- Offensive and inappropriate content is already present, in small quantities, on the DevForum, but is only removed after flagging, which allows it to linger for longer. This increases the range and visibility of the content, while with proactive community moderation, only 5 people could encounter it and it would be sent directly to DevRel. Just to reemphasize, community review includes incoming topics from members, NOT flagged topics.
- Reviewing topics is not required for membership in the forum, nor posting replies. Only creating topics. If you don’t feel comfortable reviewing topics, you can still join the discussion and reply or only read. Another possible solution to this issue would be to provide activity-based credit systems, where every month* you get a free posting credit (which as an added effect would also help counter the loss of credits as people become inactive).
As mentioned above, discussing topics in replies is still freely allowed for all users, not just regulars. It would be impractical to regulate replies because these posts are often in quick response to one another. In addition, with regard to your argument about moderation, the official purpose statement of the DevForum is:
A place where Roblox’s developer community can share their thoughts about creating games and get updates from staff members.
Right now, the DevForum is doing a great job with regard to the second part: staff members are able to effectively use #updates to announce important new changes and features. However, the problem facing the forum is that a fair number of users are forgetting about (or in some cases, ignoring) the first, bolded section: their topics are not about creating games. Rather, the problems topics often include
- Posting for the sake of posting/attention (common)
- Posting non-development related topics in development categories (common)
- Posting low-effort content (common)
- Posting inappropriate content for trolling/spamming/raiding/etc (much rarer, but still important to mention)
Thus, it is necessary to create a system that makes it possible to discuss development and not all of the other things that are ruining #development-discussion and other categories.
If you’re referring to the Community Sage and (Old) Post Approval programs, those were hardly “community” moderation systems. Approximately 0.006% percent of the users on the DevForum were asked the voluntarily review the other 99.994%, which definitely does not involve the whole community.
That post is actually part of the inspiration for this post! More specifically, the staff response resolved one of the biggest issues with my plan: the effort required for implementation.
These solutions are good, but as the current member promotion system shows, all stat-based systems can be gamed. In addition, the suggested system is overly simplistic: users are either admitted or not. In comparison, this post-approval system gives more users the opportunity to create topics while still ensuring that low-quality posts are kept out. In short, the main difference is that that system moderates people, while this system moderates content.
I disagree. Limiting access to the forum is not sustainable and is guaranteed to be ineffective at coping with forum growth. As mentioned above, that system is focused on unscalably banning people instead of regulating content. The old community sage/regular/top contributor promotion system was similar in that it relied on a set of statistics to determine if a user was fit for promotion. It required human review over the list of prospective applicants, which didn’t make it scalable as more and more users reached the thresholds. In contrast, this feature request would scale itself to control the flow of topics as the platform and the community grow.
Prevention is ideal. That is the very reason for this feature request. As I mentioned above, this is not intended for use of moderating flagged topics, but rather reviewing incoming, soon-to-be-posted topics.
This system is more efficient and fair because it focuses on eliminating low-quality content rather than the users who could post it. We could ban everyone who hasn’t used DevEx under that assumption that they aren’t developers and might post bad content, and this would result in:
- People who have used DevEx but don’t want to contribute to the discussion making low-quality posts
- People who have used DevEx creating good content on the DevForum
- People who have not used DevEx and who might’ve created a few off-topic posts being banned.
- Non-DevEx trolls being banned
- Many legitimate contributors who would be able to make quality additions to the DevForum being barred from access.
Such arbitrary measures would still allow a little bad content in and keep a lot of good content out.
I do however agree with the second goal from that post, with regard to refocusing the DevForum on development rather than being a general communication platform for Roblox. This is important to prevent the DevForum from decaying into the old on-site forums.
Thank you everyone for your feedback! I’ll update the main post soon with regard to the responses in the reply. Your analysis and constructive criticism is really helpful for refining my feature request!
4 Likes
CAPTCHAs are a lot different from blocking the ability to post if you don’t review other people’s posts on many levels. This is a non-comparison and it’s irrelevant to bring up as well because this thread isn’t about CAPTCHAs or bots. Reintroducing PA but making everyone do it instead of a small group still doesn’t change the fact that this kind of system goes against accessibility.
From the start even when/before post approval was around, Regular wasn’t necessarily a goal. It simply opened up a few more categories for users to post in, one of which shouldn’t even exist. If you don’t actively use the forum then you never needed TL2. I trust Developer Relations to, with community input, come up with a solution to the bug report posting dilemma. There’s no need to overcomplicate the situation over lack of access to posting into a single category, so no, I still disagree regardless.
I’m pretty anchored on my hill when I offered my opinion: I think it’s a terrible system and don’t stand behind it. Members should not be restricted from posting simply because they don’t review topics, they should be able to post questions and get answers like any other platform’s help forum.
Common misconception here: feature request categories have always been about identifying problems, not proposing solutions (though examples can help as additional parts of your post). Roblox has access to data users do not in order to research and create a solution that best resolves the problem. It’s in bold as its own section in How to post a feature request. The same thread is applicable for Forum Features, the only difference is the target.
I don’t need to and won’t flag the thread because you’re misinterpreting that as me finding the thread inappropriate, which I’m not. I’m saying that your proposal is bad and you should focus on the actual problem rather than your proposed solution. I’m not finding anything productive coming from this back-and-forth about something that’s unlikely to happen in itself.
3 Likes
This is not a bad idea, and I think it’s really getting nessesary to do something
Development discussion was already being blown with off topic posts.
Take a look at any time in the day and you will see them. We already knew this lol
But now #resources is also getting off topic too 
The devforum has capitulated into a mess of spam and makes the experience of any “actual” developer worse.
1 Like
Your examples are nothing compared to what I saw last night.
https://devforum.roblox.com/t/how-to-reply-to-a-devforum-topic/1209813
https://devforum.roblox.com/t/how-to-disable-the-selectionbox-the-cube-at-right-above-the-screen-in-studio/1209520
I even made a topic about cleaning up the #resources category about a month ago, and it’s really disappointing that people still make these kind of topics. The selection box topic is still up as of now.
2 Likes
ehhhh, i just felt that other people couldn’t found out where the button is…
1 Like
Community Tutorials are supposed to be much more advanced than learning how to click a button on Studio. When you make a tutorial, it should be something like:
Many beginner developers often look for useful tutorials in this category, and many people already know how to do extremely basic things such as disabling the selection box.
The next time you create a community tutorial, you should focus on something useful like an OOP tutorial or an animation tutorial that most developers could really benefit from. Your tutorial will also be more noticed and it will be bumped towards the top of the category.
I think the most that should happen is a batch of TL2 users being promoted to TL3, some categories that are a little less active but significant enough to warrant their existence (e.g international categories), yet there isn’t much moderation going on, likely because of language barrier. In the spanish category you literally have people posting help requests in the community resources category there, but if there were TL3 users there it would be as simple as them changing the category, and because of the lax nature of the international categories in general flagging can seem like too much.
4 Likes
Hey folks, appreciate the passion for this topic here and the detailed explanations. We recognize the underlying issues and we’re looking into solving those in some different ways. Rest assured I’ve consumed all the content here and whatever we are building out will take the issues mentioned here into consideration.
We’re looking into improving our creator feedback workflows so that everyone without restriction can post feedback about issues with our products in the future and still be able to receive meaningful feedback from our staff.
For now, I’ll be closing out this topic since we won’t be implementing the particular proposed solution mentioned in this topic. I encourage you to use our feature request template in the future to focus your post around issues rather than solutions: How to post a Feature Request
Many thanks for all the discussion here and thinking along as we figure this out!
4 Likes