this post was submitted on 22 Jan 2026
201 points (99.0% liked)

196

5292 readers
1370 users here now

Community Rules

You must post before you leave

Be nice. Assume others have good intent (within reason).

Block or ignore posts, comments, and users that irritate you in some way rather than engaging. Report if they are actually breaking community rules.

Use content warnings and/or mark as NSFW when appropriate. Most posts with content warnings likely need to be marked NSFW.

Most 196 posts are memes, shitposts, cute images, or even just recent things that happened, etc. There is no real theme, but try to avoid posts that are very inflammatory, offensive, very low quality, or very "off topic".

Bigotry is not allowed, this includes (but is not limited to): Homophobia, Transphobia, Racism, Sexism, Abelism, Classism, or discrimination based on things like Ethnicity, Nationality, Language, or Religion.

Avoid shilling for corporations, posting advertisements, or promoting exploitation of workers.

Proselytization, support, or defense of authoritarianism is not welcome. This includes but is not limited to: imperialism, nationalism, genocide denial, ethnic or racial supremacy, fascism, Nazism, Marxism-Leninism, Maoism, etc.

Avoid AI generated content.

Avoid misinformation.

Avoid incomprehensible posts.

No threats or personal attacks.

No spam.

Moderator Guidelines

Moderator Guidelines

  • Don’t be mean to users. Be gentle or neutral.
  • Most moderator actions which have a modlog message should include your username.
  • When in doubt about whether or not a user is problematic, send them a DM.
  • Don’t waste time debating/arguing with problematic users.
  • Assume the best, but don’t tolerate sealioning/just asking questions/concern trolling.
  • Ask another mod to take over cases you struggle with, if you get tired, or when things get personal.
  • Ask the other mods for advice when things get complicated.
  • Share everything you do in the mod matrix, both so several mods aren't unknowingly handling the same issues, but also so you can receive feedback on what you intend to do.
  • Don't rush mod actions. If a case doesn't need to be handled right away, consider taking a short break before getting to it. This is to say, cool down and make room for feedback.
  • Don’t perform too much moderation in the comments, except if you want a verdict to be public or to ask people to dial a convo down/stop. Single comment warnings are okay.
  • Send users concise DMs about verdicts about them, such as bans etc, except in cases where it is clear we don’t want them at all, such as obvious transphobes. No need to notify someone they haven’t been banned of course.
  • Explain to a user why their behavior is problematic and how it is distressing others rather than engage with whatever they are saying. Ask them to avoid this in the future and send them packing if they do not comply.
  • First warn users, then temp ban them, then finally perma ban them when they break the rules or act inappropriately. Skip steps if necessary.
  • Use neutral statements like “this statement can be considered transphobic” rather than “you are being transphobic”.
  • No large decisions or actions without community input (polls or meta posts f.ex.).
  • Large internal decisions (such as ousting a mod) might require a vote, needing more than 50% of the votes to pass. Also consider asking the community for feedback.
  • Remember you are a voluntary moderator. You don’t get paid. Take a break when you need one. Perhaps ask another moderator to step in if necessary.

founded 1 year ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] Pika@sh.itjust.works 16 points 1 day ago* (last edited 1 day ago) (1 children)

I don't contribute to projects most of the time strictly due to the hurdles in place for contributions. if I see an issue with something, I would like to be able to properly fix it, not have to follow a multi month process to actually get it in

The last project I wanted to contribute to had the following system:

  1. make an account (makes sense, its a self hosted tracker)
  2. verify my identity and specify what I wanted to do in a whole different project in order to get validated to be able to open issues in the tracker
  3. open an issue stating that I found a problem
  4. state in the issue that I was willing to fix said problem
  5. agree to sign the code away if done
  6. wait for response confirming that it was ok
  7. fork the project
  8. fix the issue on your fork
  9. create test units for the project
  10. submit a merge on the main project
  11. wait weeks to months for the actual maintainer teams to review the fix and make suggestions/alterations
  12. fix any merge conflicts that was created during the time that it took to review
  13. rinse and repeat the last 2 steps until it's finally merged

Luckily I had noticed that the timeframe of existing requests prior to doing it, and decided to pass on it.

Don't get me wrong, a lot of those steps are necessary for proper development cycles but, it's the extra steps that are annoying. I'm looking to quickly contribute and move on. Too many steps or if the process seems like it will be a major pain in the butt = You can find and fix it yourself.

Most projects if they have that I will at least open an issue for it so it's known as a problem... but some projects don't seem to want them reported, let alone fixed.

[–] Ephera@lemmy.ml 3 points 1 day ago* (last edited 1 day ago) (1 children)

I 100% understand the frustration. It can easily feel like you're doing the maintainers a favor and they're making this harder than it needs to be.
The thing is, though, from the maintainer side, it very often feels like you're asked to do those contributors favors. You may not care for whatever feature they want to contribute, but then are supposed to put in work reviewing their contributions and possibly having to patch up their work, if it doesn't meet quality standards.

And then, yeah, you start requiring quality gates to ensure you don't have to put in extra work for something you don't care about. But then may also end up putting hurdles in place, so that effectively fewer contributions show up asking for reviews. It's an ugly solution, but frankly, it's better than having contributors put in actual work creating a pull request and then you not having time to review it.

[–] Pika@sh.itjust.works 5 points 1 day ago* (last edited 1 day ago)

Yeah, I understand that point of view as well, especially for feature expansions. I don't agree with that point of view at all for bug reports /fixes though. It's not like I'm asking for an additional feature on top of the devs' already existing code. I'm fixing a mistake that the dev added to their code that they haven't had time to fix, I don't see the need of multi week or month review processes for those.

But at the end of the day I tell myself that if the dev wanted help with the project they would have made the system easier and I just move on with my life. Or usually if it's a small change just fork the code myself if allowed fix it and then never bother with the hassle of submitting it upstream.