this post was submitted on 17 Jun 2023
16 points (100.0% liked)
Lemmy.World Announcements
29044 readers
3 users here now
This Community is intended for posts about the Lemmy.world server by the admins.
Follow us for server news ๐
Outages ๐ฅ
https://status.lemmy.world
For support with issues at Lemmy.world, go to the Lemmy.world Support community.
Support e-mail
Any support requests are best sent to info@lemmy.world e-mail.
Report contact
- DM https://lemmy.world/u/lwreport
- Email report@lemmy.world (PGP Supported)
Donations ๐
If you would like to make a donation to support the cost of running this platform, please do so at the following donation URLs.
If you can, please use / switch to Ko-Fi, it has the lowest fees for us
Join the team
founded 1 year ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
They're different communities, just like /r/tech and /r/technology, /r/DnD and /r/dndnext, or the million different aita subs that popped up last month.
There is a GitHub issue for the Lemmy equivalent of a multireddit which would allow you to create a compound feed of several communities. Others have gone further and requested some kind of automatic merging, which strikes me as a pretty terrible idea... they're different communities with different rules and different mods and maybe different cultures. Sometimes they exist separately because the mods don't like each other or have very different ideas about what the culture should be. Transparent merging in such cases is awkward and creates confusion.
My advice is to consider the server name as if it were part of the sub/community name so that
[!this@that.com](/c/this@that.com)
is just a different thing from[!this@there.com](/c/this@there.com)
. Dupe subs have always been a thing on Reddit, they're a thing here too. They will get better with time as community discovery improves and people aggregate in the active/well-moderated ones and the abandoned ones die off.This issue on GitHub seems to have an interesting idea.
Instead of automatic grouping, what they're suggesting is a sort of "request" from one community to another to sync their content. So two similar communities that have two very different cultures could decline syncing.
Yeah, I've seen that proposal. It's not all that much more compelling to me. If mods were willing to be grouped together, why would they not also be willing to merge their communities entirely and retire one of them? What compelling capability does three but kind of one communities give you that one community with three mods doesn't?
And more importantly, are those capabilities more valuable than the simplicity of people not having to understand these compound communities. Federated designs are generally significantly more complicated to use than "normal" designs. A sprinkle of federation in a system design is a very powerful hedge against individuals coopting the ecosystem, and that make the extra complexity worthwhile (to me, there are smart folks who say that federation is DOA because it's inherently too complex). But almost all people with experience designing federated systems agree that a heaping shovelful of federated system design makes a system an unusable mess of conceptual complexity that no one will bother to learn. It seems pretty clear to me that compound communities fall into this heaping shovelful category, and do no "pull their weight" in complexity. Reasonable people can disagree, but I both would not use such a feature unless I had to... and I think the lemmyverse would be better off without it.
Instead, it's my belief that devs should focus on improving community discovery so people naturally find the most active communities, low-traffic ones die off, and we eventually reach a mature state where... like reddit... even though community duplication is allowed... no one cares about it because the better run communities naturally grow and are easy to find. Improving community discovery has more powerful beneficial side-effects in other ways as well, and if done properly could reduce complexity rather than increase it as this proposal does. But to each their own, maybe other people see something I don't.