There’s been an ongoing debate about whether communities should combine or stay separate. Both have significant disadvantages and advantages:
Combine:
- Network effects. Smaller communities become viable if they pool together their userbase. Communities with more people (up to a point!) are generally more useful and fun.
- Discoverability. Right now, I might stumble on a 50 subscriber community and not realize everyone has abandoned it for the lively 500 subscriber community somewhere else, maybe with a totally different name.
Separate:
- Redundancy. If a community goes down, or an instance is taken down, people can easily move over.
- Diffusion of political power. Users can choose a different community or instance if the current one doesn’t suit them. Mods are less likely to get drunk on power if they have real competition.
This isn’t an exhaustive list, but I just want to show that each side has significant advantages over the other.
Sibling communities:
To have some of the advantages of both approaches, how about we have official “sibling communities”? For example, sign up for [email protected] and, along the top, it lists [email protected] as a sibling community.
- When you post, you have an easily accessible option to cross-post automatically to all sibling communities. You can also set it so that only the main post allows comments, to aggregate all comments to just one post, if that’s desirable.
- The UI could detect sibling cross-posts and suppress multiple mentions of the same post if you’re subscribed to multiple sibling communities, maybe with a “cross-sibling post” designation. That way it only shows up once in your feed.
- Both mod teams must agree to become siblings, so it can’t be forced on any community.
- Mods of either community can also decide to suppress the cross post if they feel it’s too spammy or not suitable for cross discussion.
- This allows you to easily learn about all related communities without abandoning your current one. This increases the network effects without needing to combine or destroy communities.
Of course, this could be more informal with just a norm to sticky a post at the top of every community to link to related communities. At least that way I know of the existence of other communities. I personally prefer the official designation so that various technologies can be implemented in the ways I mentioned.
The moderators on communities that have decided to approach this in this way will discuss it amongst themselves and begin a thread requesting a new feature on the github. In the meantime, the moderators can work together to sketch out a plan of how to connect their communities in a loosely organized manner, where each community links to one another, and cross-posts will be recognized, while not explicitly favoring one community over another. Basically, just moderators working with other moderators and communicating and making a plan that works for those communities, and will likely be different for each set of communities.
If the feature fails to gain traction because there aren’t enough interested parties, then oh well. Maybe one of the interested parties knows a little Rust and will write in the feature themselves and ask for their work to be added to the mainline project. Anyway, these things take time, and running around howling about how it won’t work before people have even really had formative discussions about it isn’t helpful. Yeah, it’s decentralized, which means some people will take longer to find out that the option exists, because they’re on a site that isn’t federated with somesuch other site, and the meandering path of news of “tools to organize multiple communities as a larger whole,” might take longer to get to them. That’s… not the end of the world, you know? That’s the nature of decentralization, initially, the conversation won’t involve everybody. Over time, maybe it will, but likely some areas of the fediverse will wall themselves off and not be interested in connecting their communities to others and that’s fine. That’s literally the point of the federated decentralization, so people can be allowed to make their own decisions on how to interact, everything from not interacting at all, up to and including making “webrings” of related Lemmy communities. I’m not sure why you need a whole gameplan laid out for you, but it feels like maybe you haven’t been part of a lot of self-organizing communities in your life. These things grow organically. Yes, that includes competing standards growing at the same time, much like there being a bunch of different Lemmy apps existing at the same time.
Seems like a great approach
I proposed a features a while back to both lemmy and kbin that never really got any traction. Unfortunately, on the lemmy issue, people kept discussing similar but unrelated ideas and the discussion got pretty muddled until a mod closed it for being a duplicate of an unrelated issue.
https://github.com/LemmyNet/lemmy/issues/3071
https://codeberg.org/Kbin/kbin-core/issues/149
That was a rhetorical question.
Ah well… I didn’t have much hope that it’d work.
This is not quite accurate, and it neatly illustrates the problem.
“Allowed,” in this context, is incoherent. There can be no “allowed” unless there’s some authority empowered to, and mechanisms by which to, allow this or disallow that.
The literal point of decentralization is to move entirely away from institutionalized, hierarchical authority by arranging things so that it can neither be claimed nor exercised in the first place.
And one problem is that people tend to drag their authoritarian habits of thought along with them.
If you think organizing in groups at all is authoritarian, that’s on you dude. Take your pedantry to someone who cares.