501
Lemmy
12524 readers
1 users here now
Everything about Lemmy; bugs, gripes, praises, and advocacy.
For discussion about the lemmy.ml instance, go to !meta@lemmy.ml.
founded 5 years ago
MODERATORS
502
If you want, please add your tips to the comments.
Here are mine - just a bunch of opinions/suggestions from someone who used to be a forum mod, then a subreddit mod.
As this is a rather big wall of text, I'll split it into sections, contained within spoiler tags.
Mindset and duty.
A happy mod is a good mod. Take care of your personal life first.
Your comm[unity] is not your personal possession or project, it's a collective effort. You're just its representative - be humble but proud about it.
Use your comm as any other user would. Be active in it, interact with other users, discuss, learn, have fun.
If you don't enjoy your comm any more, for whatever reason, pass the torch to newer mods.
Check your comm at least a few times per day. A quick peek is fine for slower comms.
It's useful to follow the RSS feed of the comms that you moderate, as it'll be quicker to spot rule-breaking posts. You can do it here:
In days that your comm is too slow, specially at the beginning, it's your job to provide content for your comm.
Recruitment
Avoid recruiting mods who:
- never post/comment in your comm, or only did it after you announced "we want new mods"
- asked over and over to be a mod
- already mod lots of other comms
- claim to have a "vision" about your comm, and propose 9001 drastic changes for it*.
- rush towards certainty on things that they cannot reliably know (intrinsically unfair)
- cannot reasonably infer things from context (ditto)
*Major exception: if your comm got some biiiig problem, and nobody seems to be able to solve it.
If you get multiple people willing to mod, you can be a bit pickier. Use open-ended questions to trial them. Ideally new mods should:
- be active members of the comm
- work well alongside the rest of the mod team. (are they strict rule enforcers, or more on the "let users have fun" side?)
- active in different hours than the rest of the mod team. (e.g. night owls, different longitudes, etc.)
A lazy mod is less worse than a well-intentioned but dumb mod.
Rules and their enforcement
You do not know the users' intentions, thoughts or beliefs. However, you do know how they behave and what they say. Use the later, not the former, in your rules.
If a rule cannot be enforced, it is not a rule. It's at most a request.
Enforce rules by spirit, but the letter should follow fashion. There's some room to be sloppy with this with smaller comms, but not the bigger ones.
Do not enforce "hidden rules". If there's some shitty behaviour that needs to be addressed, do it in the open.
Do not enforce new rules retro-actively. You're just creating more work for yourself and pissing off users, for no good reason.
Be succinct when phrasing the rules. If necessary/desired, write down two versions of it:
- short version - addressing what users can/can't/need do in broad strokes, without "why". Keep it in the side panel, visible at all times.
- long version - addressing specificities of each rule, as well as reasoning. Keep it in a post or similar.
Synchronise changes in all versions of your rules. Few things confuse users the most than rule disparity.
If your comm got more than seven rules, it's probably already too much. Consider merging them.
It's fine to use imperative in the rules ("do this", "don't do that"), as it's succinct and you're in a position to do so.
Every rule has a grey area, of things that are only arguably rule-breaking content. Try to minimise the grey area when possible, but keep in mind that you'll never get rid of it.
Beware the fluff principle: voting alone will allow only the lowest common denominator content to the top, and shove down well thought content that is hard to judge. Take that into account when creating rules.
Handling other users
Ask community input periodically. Don't use votes for this, let other users speak their mind.
Input from rule-lawyers is surprisingly useful to find issues in your rules. And a few people will be abler to phrase your own rules better than you do.
Even then, asking community input is not an excuse to relay responsibility. You're still the mod.
It's useful to keep notes of a few users from your comm:
- notes about good, specially engaged and helpful users might be useful later on, as you're recruiting newer mods
- notes about bad users are useful for rule enforcement. Certain types of bad behaviour are only revealed in long-term tendencies.
Activity of your comm's users outside your own comm should be only taken into account as much as it might predict their future activity in your comm. There are a few corner cases to do so, but by default you're better off not doing this.
Don't feel afraid to upstream reports of specially problematic users to the admins of your instance. Specially if they're more on the stricter side.
This is debatable, but I personally believe that a few types of users, regardless of their intentions, should be handled as you would handle trolls and shitposters. They are:
- witch hunters: users who point fingers at other specific users without rational grounds to do so
- entitled, bossy or whiny users: users who are eager to tell other users what to do, for their own sake
- obtuse users: users who "conveniently" pretend to not read or understand counter-arguments of other users in discussions
- assumers: users who are prone to say things that they cannot reliably know, specially about other users. (A superset for witch hunters.)
This sort of user is prone to piss off other users, specially the most contributive ones.
When there's a fight between users, typically, at least one of them is stupid. Make sure to know which one (or if both) before intervening.
503
504
506
507
508
509
34
I made a VERY BUGGY tool to check both "blocked by" and "blocked" of a Lemmy instance
(federation-checker.vercel.app)
How to use:
The url must be the hostname only, NO SLASHES, like this: lemmy.dbzer0.com, don't use https://, don't append a slash afterwards (lemmy.dbzer0.com/), only the hostname including the subdomain if it has it (in this case, lemmy).
If the instance has blocked the IP address from the server, or it is stuck and its API is not working correctly, it returns "Not a Lemmy instance" (I am too busy to fix this right now).
If the url is not formatted in a way it can process it, it will say Invalid URL. Better processing can come in the future. I won't be updating it now.
- URL: https://federation-checker.vercel.app/
- Source code: https://github.com/lemmygod/federation-checker
In the backend, it just scrapes https://fba.ryona.agency/?domain={url} and uses the api https://{instance}/api/v3/federated_instances
PRs welcome.
Honestly it works better when deployed locally in a development environment. I think Vercel's IP address is just blocked by cloudflare and other blacklists that stop automated stuff? Idk. Can check back in a few days.
510
511
512
513
514
515
516
517
518
519
40
More anti-Lemmy brigading with massive upvotes on Reddit as the 3rd party app apocalypse looms
(lemmy.world)
cross-posted from: https://lemmy.world/post/715287
Guess where? Unironically r/Save3rdPartyApps
The Reddit search for Lemmy also gives these privacy copy-pasta as top results when searching for Lemmy. I'm still betting that Reddit employees are involved in boosting these posts.
520
it's not just Lemmy users and instances graphs that are going FULL STONKS 📈 , it's people starring repo as well:
521
522
523
524
525