Make the DevForum Less Frustrating for New Users

Forum Help
#1

Give more feedback to visitors and new members.

Preface

This post will be a bit ranty, you have my apologies for this in advance.

My experience on the forum thus far has not been that enjoyable. After logging in nearly every day for four months to get promoted to new member, I am now having to deal with a (seemingly) arbitrary post approval system. While I understand the purposes of these mechanisms, I believe that a lot of frustration could have been avoided had I been given better information.

Ranking up

Let’s start at the beginning. It took me four months (120 days) of logging in near daily and reading posts to obtain the new member rank. Considering I have seen accounts achieve this feat in as low as 6 days, clearly I was doing something wrong. After waiting about three months, I contacted Roblox customer support to see whether my account had any moderation violations that were preventing my entrance, which I was told that they could not provide me with that information. Even after obtaining the New Member rank, I have no clue what I did that finally allowed me into the system.

This further taints my experience here as I am now wondering how long I am going to have to wait to obtain the Member rank. On the low side I am seeing people getting it after being logged in for 250ish days. On the high side, I am seeing up to 550ish days. Am I going to have to wait two years or more to be able to unlock the rest of the site? And not knowing the answer, is it even worth participating in the forum knowing that I will have to put up with (as I perceive it) a broken post approval system?

I fully understand that we do not want bots on this site, and that is why information is limited. I do believe however that the following information could be given out without much benefit to a bot (I have it on good authority that the new member requirements are basically known at this point). The purpose of these suggestions are not to make it easier to get the ranks, but rather put a cap on how long it takes to get them.

Account eligibility status: If for some reason past conduct has rendered you ineligible for a promotion, it would be nice to know that.

Estimated time to get the next rank(measured in weeks and updated daily): A measurement of how long the system thinks it will take you to get the next rank based on your current usage habits. While not particularly useful to the user, it at least allows them to see that they are making progress and gives them some idea as to how much effort it will take them to obtain the rank so they can make informed decisions whether their time is worth it.

Recommended activity (updated daily): The forum arbitrary picks one of the activities necessary you need to do the most of and displays it to you (say read more posts or read more topics). This will allow users who want to participate in the dev forum the ability to make more informed decisions as to how they use their time on the forum, and also means that a user will not be missing out on doing a necessary activity for months at a time.

Post Approval

This is not intended as a criticism of the Post approval (PA) team, they are volunteers who are likely doing their best with the information and guidelines they have been given.

The first main issue is that new members are held to a different standard than full members. Inother words, as a new member the post approval team can refuse to publish a form when a full member can post an identical article without any issues. As an example of this I have had a bug report that referred to an issue with user permissions during the discobot tutorial squashed on the grounds roblox does not control discobot, when there is already an existing post dealing with a separate instance where the user does not have sufficient privileges to complete the tutorial.

The second main issue I have is there is no standard to hold against. I have one post that has been reviewed by three different users and each have squashed it for a different reason. There is also a good deal of subjectivity involved, I have had a post where the PAs requested edits and after giving them an explanation as to why their edits would not work, published the work as it was. I also have a post where I am expected to rewrite a decent chunk of it, despite following the “Guidelines”. The problems the PA take with it is I use a example to illustrate my problem instead of outright saying it (which is difficult as it is a nuanced problem), and I use a detailed API spec to explain the feature as I have deemed it the most conceive way of conveying the necessary information instead of writing out a massive post detailing every feature that I would like to see implemented.

Both of these issues make making posts incredibly frustrating. I spend a decent amount of time writing my posts but I have no real way of knowing if the post will actually be approved or not. Im not sure what the role of the post approval team is intended to be, but I am guessing they are intended as guides. With this in mind, here are my ideas to help alleviate these issues.

Clearly outline the role of PA: Its my presumption that there goal is to teach new users how to make better and higher quality posts, as well as remove posts that clearly break the rules, but I can’t find anywhere what PAs are supposed to do, nor the scope of there operations. Rules are there to limit bad behavior, but they are also there to give clear limits to the power of enforcers.

Add a style guide: The PA team often gets rather hung up on formatting. A style guide both gives new post writes a clear understanding as to what is expected and, removes a lot of the subjectivity from PAs, as well as giving them a resource to point at.

Write better guidelines: While were they just guidelines I would say that they are enough. However, if they are going to be the stick that your post is measured again, they should be made clearer. Of note, suggestions are rather limited by the fact that you are supposed to post a “problem”. To use already implemented features to illustrate this, I can’t really see a way that you can write a request for dynamic lights or for unions phrased as a problem. You run into a similar issue with quality of life updates. While members will often ignore this requirement, the PA team may not.

Anonymize the post approval process: When dealing with moderation, its best to eliminate as much bias as possible. I do not see any benefit for the PA team to see who is making the post, nor for the poster to see who is reviewing it.

Post status: Sometimes written instructions can be unclear. As such, it would be nice to have a post status to see what is going on. These may include;

Post Denied: when a post is too inappropriate for the devforum.

Waiting for Post Approval: much as it sounds

Post Seen: When Post approval has seen the post but have yet to respond

Requires Reformatting: When you are expected to reformat your post

Requires Clarification: When a PA member requires additional information from you

Post Approved: When the post is finally approved.

52 Likes
#2

I don’t think this is the way to go – ranking up should just be more natural. It’s not the idea to have people do busywork just so they can get a higher forum rank. That means the criteria are failing.

(FYI: Higher forum ranks just mean you get to post more stuff on your own – it doesn’t actually let you do anything new that you can’t already do via post approval. The reason why you see existing Members being “held to different standards” is because most of these people never actually were a New Member and so not all of them have a good understanding of how to write bug reports / feature requests. If you actually look at how many of these bad bug reports / feature requests get addressed compared to ones that went through post approval, you’d notice the better written ones (through PA) will be more likely to get staff responses. I think that’s generally a good thing that we all want to achieve. PA is there to help your topic get addressed first and foremost.)

The difficult thing about managing gatekeeping on this forum is that we do not (and cannot) have a way to differentiate between maturity levels of users, so we have to design processes that somehow account for a huge range of different users, from 13-year-old Timmy that only plays Roblox games to 21+ professional game developers. Making good criteria that don’t feel like a waste of time for those older users is very difficult, but we are definitely aware and looking into this (as best as we can without messing up the forum by having players/kids/teenagers posting bad quality topics all over the place).

9 Likes
#3

It varies for every individual.

These suggestions would make it much easier to cheat the system.

Post Approval will refuse a post if they feel it doesn’t meet forum rules.
If you believe a full member’s post breaks forum rules- please flag it.

Discourse limitations do not allow this to an extent.
It supports anonymous posting (and you can limit it to a certain trust level- eg TL3 aka Post Approval) but from what I’ve heard, it’s quite clunky.

4 Likes
#4

This answer does not help the OP at all, what thing which is supposedly variedly for every individual is key for entrance to the forum?

10 Likes
#5

This idea is effective in my eyes. I doubt that bias is present, but precaution is encouraged.

This sounds effective as well, but nothing more. As previously stated, a smooth and natural promotion system would encourage admired activity. I wouldn’t implement a way to view promotion progress, I feel a lot of content would be forced and potentially malicious. Additionally, if the requirements for promotion were disclosed, I feel like the majority of content would include non-constructive insight. However, this idea isn’t too bad on its own.

6 Likes
#6

Developer Relations are very hush hush on details of how the promotion system works.
Every detail released is a new tactic that can be used to exploit and game the system.

The DevForum is considered privileged and sensitive-- imagine if a bad actor obtains full member status.

9 Likes
#7

I seriously doubt it would take long for the team in charge for removing said bad actor to remove said actor.

I don’t think hindering a bad actor to become a full member and gain all the privileges should hinder & bully away other legitemate users from earning full membership.

9 Likes
#8

By cheating, I presume you mean bots. If you do any testing with bots, you probably already have a good grasp as to the requirements to get new member and having this data is likely of limited value. New Member rank is sufficiently useless that any bad actor is of minimal threat, and I am guessing that obtaining member rank actually requires making good posts, something you cant exactly automate. I’m not suggesting lowering the bar to entry, with how long it takes to get a full member rank (best guess is 8-10 months) its only going to be useful to the most determined of trolls.

As for PA blocking things, they defiantly block (require rewrites) of things that do not break rules. There is no rule that requires a tutorial must include headers, there is no rule stating that you cannot post about bugs with discobot as it pertains to the function of the dev forum.

10 Likes
#9

I have primarily suggested these features to cap how long it takes for users to get ranks. It took me four months to get new member. Here are my stats from when I was finally accepted

image
image1663×177 14.5 KB

The only reason I really care about the member rank is because PA often gets hung up on stupid things. I really don’t want to have to have a argument whether or not my post needs headers to be able to post a tutorial. I welcome critique, but what PAs offer are demands that I need to fulfill if I am allowed to post.

14 Likes
#10

By cheating the system is by farming the requirements to be promoted to the next rank. For example, if you had to create a certain amount of posts to be promoted people will deliberately make low quality posts just so they can be promoted. Then if you had to get a certain amount of likes people will deliberately give each other likes and ask each other for likes.

I was in the first wave of users to be promoted to the full member rank through the new automated system. I was also accepted through the new member process as well. From the day I was promoted to new member to the day I was promoted to the full member rank it took me exactly 5 months 3 weeks to be promoted.

If you make consistent good contributions to the forum and follow the rules I am sure you could be promoted even faster than I did. Also if you make good use of the post approval procedure then that could increase your chances because you are proving you can be trusted to post in areas of the forum that you don’t have access to.

This idea is interesting because I can see why it isn’t a good idea to see who is posting to avoid any sort of bias as you said. However I don’t think something like this is possible or it will take too much time to implement. I will need some sort of confirmation on this though.

However there is a few benefits with seeing who is reviewing and posting through the post approval process. Lets say in the very unlikely event that a member of the post approval team is being bias or acting out of order you can then directly report that person to the Developer Engagement team or the community sages I believe. Then if a person posting through the process and deliberately annoy the team with spam posts then actions can be taken directly against that users.

34 Likes
#11

With plugins, it’s theoretically possible, but it’s impractical to write. Ignoring the fact that writing non-trivial Discourse plugins is challenging to begin with, you then need to consider these problems (and probably more that I am forgetting):

  • How do we preserve the author? We have to in order to move it.
    • Anonymize client side? This could lead to cases where the author is shown, but then anonymized once the plugin loads. Worse, grudgeful post approval members (if there are any) could just bypass the checks.
    • Anonymize server side? Now we need to make sure that it actually de-anonymizes no matter how we move it.
  • How do we show the author if they are making a problematic post?
    • Only anonymize to post approval members (and below)? Sages do post approval work often.
    • Only anonymize to non-admins? This makes it harder for us to track problem users effectively if we need to go through an admin to see if it’s a repeat offender.
  • How much do we have to anonymize?
    • Private messages, topic, replies. All these have different backends, meaning the code for the plugin gets very large, and more likely to break. Client side code cannot be easily tested on Discourse.
15 Likes
#12

IDK anything about how this is hosted or how the PA system works, but if it works the way I am guessing its a rather trivial issue to solve (and there is zero reason to deal with plugins).

The most hacky solution is to forward the page to a separate page that swaps any HTML that refers to a specific user for generic data (PA or poster based on what a query to the database returns) before sending it to the client. Certainly not elegant, but it should work, and there should be minimal issues setting it up. For a less hacky solution, presumably the PHP that is responsible for forming the page in the first place could be modified to do the same.

Now for moderation, I presume that PAs already have to flag a post and that goes though a entirely different system. Bit odd for a community sage to flag a post so they can moderate it, but I think that is a rather mild inconvenience.

Im not sure why you need to anonymize any of that to remove bias from the PA system. Its my understanding that all the PA system is is a special type of post where only the OP and the PA team have access to.

5 Likes
#13

Feel free to make a head start on this if you think this is useful for the forum. Discourse is open source so making plugins is straight-forward, you can find the guide here:
https://meta.discourse.org/t/beginners-guide-to-creating-discourse-plugins-part-1/30515

(Discourse source code itself is at: https://github.com/discourse/discourse)

If you have a plugin that you want to be taken into consideration (i.e. your own) feel free to forward the Github repo to Community_Sage in a private message once you’re done implementing and testing it.

10 Likes
#14

The Post Approval system is just a regular group DM, which in Discourse is really just a public topic that only select users can see. If you would like me to explain more about how Discourse works with regards to permissions, feel free to DM me :slight_smile:

8 Likes
#15

I would say that is a flaw with the promoting system then. On the flip side, I basically only make posts to respond to people who comment on my topics. It would be rather annoying if I have to wait much longer then your average joe to get promoted because I don’t engage in that activity. Likewise if topics are a requirement, and you as a user don’t make many topics you could be stuck at new member far longer then would be “fair”.

My numbers are based on me visiting profiles of random users and checking how many days they have visited so they are not the most accurate. Still 5 months is a long time for a hostile actor to wait.I have now found a newmember who has been visiting the forum for three years worth of days. The goal of these systems is not to make it easier to get promoted, but rather put a cap on how long it takes to get promoted. Heck, these system could even be made available to you as a user only after you have spent X amount of time on the fourm (say a month for visitors and a year for new members)

5 Likes
#16

A brief google seems to show that plugins are JS based, which makes them entirely unsuited for this kind of application. You would need to make a source code edit.

Specific modifications are also a lot easier then scale deployment. This effect could be achived with around 20 lines of code appended to the bottom of whatever page is responsible for serving back these kinds of posts. (granted if you don’t have a way to lock certain parts of the forum from updates or a way to inject the php into the page you will have to paste it back in every time you update discourse. (or as mentioned before you could have your webserver redirect this post to a html stripper before serving it)

To make this suitable for generic deployment, your going to need to need to do a lot more work. You would need to be able to assign levels of anonymity for each page for each rank as well as have all this sync up to some form of central control menu.

4 Likes
#17

Nope, can also make adjustments on the server side through plugin.rb and related files.

As mentioned before feel free to make this a plugin and send it our way!

4 Likes
#18

Im apparently wrong about discorce using PHP, its apparently built using ruby on rails which is a language I do not know. However, my statements from before are likely still true. Its alot easier for roblox to add a if statement that checks if the user data is being sent to something that should be made anonymous, and replacing the users information.
Some pseudo code as a example of what a roblox engineer might have to implement if they do a inline mod where they would replace the relevant return HTML lines with this.

if(topic is of type "Post Aproval"){
     if(logged in users rank >=PA && poseters rank >= PA){
          post posters information as normal
     }
     else if(poseters rank >= PA){
          post posters information as "Post Approval"
     }
     else(){
          post posters information as "Original Poster"
     }
}
else{
     post posters information as normal
}

Even if it were built in PHP, I would have no interest learning an entire framework to make a plugin that would have to work with any possible configuration of discourse just so roblox might adopt a feature I have requested.

7 Likes