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.
- 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.
- 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!