One thing that needs to be considered within our trust level system is, how new/young communities start out. Often there isn’t enough content to make the achievement of some trust levels possible. This creates a moderation hole.
I propose the following:
A community is in “young community mode” for at least twenty days. This phase is extended, if there are less than fifty users with at least one upvoted, open, undeleted post.
During that phase, the following exceptions apply:
This mode is intended for starting a community. We don’t need any verification system for that. Most, if not all, users will be trustworthy. Those who aren’t can be dealt with by platform admins/flagging.
This isn’t viable for communities running our system who aren’t coming from SE.
There aren’t community mods. Therefore manual bumping is either not possible or a task for the platform admins. This creates more workload when launching communities, because they need to keep in strong contact with the community to see who is trustworthy.
If you want to change the “trigger”, I’d be fine with it. But not applying it to some/most isn’t viable IMHO.
A similar system works fine for the forum software Discourse. This forum is live and linked for some month or so. There has been no single spam attempt AFAIK, and I try to read every single post for now.
Tangential, but: I think it’s reasonable for our instance to expect a community to come in with at least two designated moderators from day 1. Either it’s an SE community already or it’s a self-organized group of people who are already doing something together (at least shopping for a platform ). This isn’t like old-style Area 51 where the initial community is more like a collection of people who followed an ad link out of curiosity.
Yeah, my comment on that (2.) was more related to instances not hosted by us due to the open-source nature of our project.
I still don’t think (3.) that mods should handle promotion/demotion, except for edge cases. And, technically, trust level change is an platform admin tool (TL6)
I expected that when a community is starting out that there should be designated initial moderators (as @cellio noted). At the beginning there won’t be a lot of moderation needed - for exactly the same reason that it won’t be easy for users to get to higher Trust Levels based on activity. So having those moderators during the initial stages of a community handle bumping Trust Levels makes sense. But it could be Platform Admins too - absolutely they should have that power. But giving it to the very same Moderators who are helping launch a new community makes sense in terms of sharing the workload and as they will have a better sense of the issues involved for their community.
But “automatic for anyone who signs up”? No. Someone already noted a problem with an SE site where on launch it immediately had to deal with troublemakers. That may never happen here - but we shouldn’t make it too easy for that to happen.
And if “has to be site admins” is just a technicality because of how we’ve assigned privs (i.e. only level 6 can change lower trust levels), then we can still give the decision in the early days to the new site’s moderators. This isn’t a tool mods on a mature site will need anyway; it’s purely a bootstrapping concern.
Except nobody will raise a flag. In the proposal, users of a young community have TL2 plus vote to close and edit (which are ordinarily TL3). This means that nobody will suggest edits or raise flags because they can just VTC or edit a post directly. It also means that once young community status ends, nobody except moderators hand-picked by platform admins will have TL3 because nobody will have raised any flags nor suggested any edits. Should we add “not enough active users have been given TL3 by a platform admin” to the criteria to hold a community in young community state past 20 days?
And yes, @manassehkatz, there will be a lot of moderation needed on day one, even if only to create tags so that users can ask questions in the first place. In manassehkatz’s reply to “MVP Proposal: User Trust and Reward System”, it was suggested to make tag creation a TL3 privilege. But again, a young community will have zero TL3 users except those promoted by a platform admin. A site not seeded with an SE import will begin with zero tags, and zero tags mean zero questions.
I would expect that part of the procedure for a new community (whether based on SE import or not) would be to set up tags. For an SE-import site that is easy - just take the top ‘n’ tags from SE (or any with > ‘x’ questions, etc.). For a totally new community, I am sure the founders/initial moderators can come up with a basic set of tags.
When SE started new sites, all users had (almost?) all privileges for the duration of the private beta, and then privilege levels changed when the public beta started. Maybe we’ll need to do something similar, and as a defense against spammers and vandals, maybe we do it only for users who have associated an SE account that has some minimum rep level.
I’d be fine with resetting the trust level for everyone, once the “young community” period is over. Anyone with reasonable interest in the site should have enough activity by then to gain TL2 normally.
I’d also agree to resetting the trust level to 0 for everyone, whose post was deleted for being flagged as spam/offensive often enough.
This should give us enough tools for handling this, without having to resort to manual selection (which I strongly oppose). That could still work for few, extraordinary cases, but it should not happen as the “normal” thing.
Maybe we shouldn’t think of these things as special cases in the first place. All the various thresholds should adjust based on the size or activity of the site. For a site with activity and number of users like SO, the various thresholds would be higher than, for example, than the almost dead Engineering.SE.
Instead of requiring a fixed 50 blurps, for example, to get a certain privilege, you have to do as many blurps as the top 2% of users average in 3 months. That 2% can itself scale based on the number of active users. It could might be 50% for 10 or less users, then decreasing to 2% and clipping there at 300 users. If all these threshold automatically scale based on the existing site experience, little else needs to be done for the startup special case.
There need to be some lower limits, and checks for exceptionally small numbers of users or low activity. This is akin to protecting against dividing by 0, and defaults back to some minimum values when there is not enough data to determine reasonable values from site metrics. This solves the startup site problem, but not as a separate deliberate “startup mode”.
Limiting the extra privileges during the young community period to users who can bring an association bonus from a competing service would encourage visitors to view Codidact as an offshoot of its competitor, whether true or not. It would also exclude people who don’t have an account on SE for any of several reasons:
People who disagree with some of the more contentious provisions of its code of conduct.
People who want to discuss a topic for which SE has no site yet and don’t already have enough experience on other SE sites to make a successful Area 51 proposal.
People joining a Codidact instance that isn’t connected to SE, such as if Stack Apps starts rejecting the applications of Codidact instance administrators for API keys for the purpose of linking accounts.
People who cannot get past SE’s automated IPv4 address throttles because of NAT, such as college students living on campus and residents of some late-to-develop countries such as Myanmar.
People who cannot complete reCAPTCHA because they live in a country that requires ISPs on its soil to block access to services provided by Google LLC, such as China.
When SE opened Super User, Server Fault, NPR (now Software Engineering), and the variety of Area 51 sites, private beta was open to those who could bring association bonus from Stack Overflow or other SE sites that existed at the time. This leaves the question of how to handle privileges on a QA network’s first community. I’ve read a claim that the private beta for Stack Overflow itself was among people who had transcribed Jeff and Joel’s podcasts, which left the Deaf community underrepresented among the early users who established SO’s initial tags.
I’m liking @Olin’s principle of having the thresholds dynamically scale between “young community” and “established community” water marks based on activity level. But in practice, finding the right scaling factors would need a lot of iteration. Could activity statistics from SE sites in private beta, public beta, and awaiting design phases help? SE has tended to end sites’ public beta at 10 questions a day or seven years without being overrun by low-quality posts, whichever comes first, so that could be the high water mark.
These are good points. I was looking for a way to give migrating users a helping hand, but don’t want to create barriers by doing so. I retract the suggestion.
@pinobatch I meant that to be a reply to you but seem to have misclicked, sorry.
It’s not only about the hand up from TL0 to TL1, which would be possible by answering another TL0 user’s question and receiving an upvote. It’s also about an opportunity to participate in defining a young community’s scope through its tags.
Hmmm… Could someone earn a “suggest new tags” privilege outside of the tiered trust level progression by suggesting edits to other questions’ tag fields in order to show knowledge of the tag system? Then a moderator could review added tags and approve them (or approve the whole question if it uses only new tags). This privilege to suggest a tag would also be available to everyone during young community phase, much as tag creation is free in SE private beta.
Personally, I’d like to make a clean break from SE. I’m looking forward to bootstrapping up an electrical engineering site here, but really rather start completely from scratch. We won’t be seen as having our own value if we just copy SE, even if that’s only how we start. I’d like to see if we can create our own value. If we import stuff from SE, then it will never be clear how much of our value was just copied from SE, and how much was natively grown.
There are also some sticky issues with copying from SE, like the images on imgur.
That said, if it’s reasonably technically feasible and folks that want to start a particular site here really want to copy from an existing SE site, I’m not trying to tell them they shouldn’t. Personally, I’d like to give it a go at least without copying.
Sure, whether and what to import from SE is a decision each community should get to make. Some might import everything, some might cherry-pick, and some might start fresh. All are valid approaches.
IANAL, but I already looked into that a little bit. Basically, the standard imgur policy is really problematic. But the SE agreement with imgur puts the images in basically the same license as the Q&A posts (text) themselves.
). This isn’t like old-style Area 51 where the initial community is more like a collection of people who followed an ad link out of curiosity.