I’ve noticed in the explosion that we are getting duplicate communities in multiple instances. This is ultimately gonna hinder community growth as eventually communities like ‘cats’ will exist in hundreds of places all with their own micro groups, and some users will end up subscribing to duplicates in their list.
A: could we figure out a system to let our communities know about the duplicates as a sticky so that users can better find each other?
B: I think this is the best solution, could a ‘super community’ method be developed under which communities can join or be parented to under that umbrella and allow us to subscribe to the super community under which the smaller ones nest as subs? This would allow the communities to stay somewhat fractured across multiple instances which can in turn protect a community from going dark if a server dies, while still keeping the broader audience together withing a syndicated feed?
I kind of like the idea for B. I’m not sure how to determine who the authoritarian figure would be to decide which ‘cats’ get to be in ‘super cats’. Could some be excluded from the super group if they’re pro-dogs/racist/etc? Is that against the whole idea?
Any update on this?
I couldn’t find any comment from the devs. Was there one?
There is an extra problem, not mentioned here. When there are subs with the same name, it is actually impossible to know of choose which sub I am posting to. Like here.
[This comment has been deleted by an automated system]
I propose two ways to create super communities:
Proposal 1) Tag and tag health)
A) Community tags: Here each community is associated with a set of tags (for example, the community ‘Earth’ can have tags #geology #geography #climate_change). When users post original content to these communities, they will be automatically suggested to add these default tags, but they can remove some tags or add other tags.
B) Tag health: A user Alice who consumes the content can view these posts, upvote some posts, downvote some posts, and can also report an inappropriate tag. Based on these reports, a numeric value can be ascribed to the health of each tag in that community. If the tag #climate_change is reported in a post, then that tag health would reduce.
For example, the community ‘Earth’ can have tags #geology (90% health), #geography (80% health), #climate_change (40% health).
C) Super-Community: A user Bob can create super communities based on community tags and tag health.
He can create a super-community ‘#geology’ which would lookup ‘Earth’ and pull the appropriately tagged posts from there. These tags are considered healthy, but Bob can set his own health threshold (say he sets it at 70% health).
He can also create a super-community ‘#climate_change’. This will not lookup posts from ‘Earth’, not even the appropriately tagged posts, because a lot of these posts were reported to be bad.
D) Tag Algebra: A user Charlie can create a super-community with multiple tags. For example, he can create (#novels OR #light_novels) EXCEPT (#tragedy AND #drama).
E) User Interface: When user David tries to create a super-community, he would simply enter the relevant tag(s). An advanced customization option would be hidden by default, but the user can expand it if he wishes. Upon expanding, he can see the default health threshold, and can modify it if he wishes. He can also see a list of all communities with that tag, along with their tag health, and a toggle button which automatically turns on or off based on the health threshold. The user can also manually override the automation, and specifically set one community to be on or off.
F) Conclusion: Unlike a central repository of super-communities, this approach can dynamically add new good communities. This approach can also remove old communities which have been abandoned by their moderators, when their tag health has deteriorated.
Proposal 2) Machine Learning Classification)
This is an extension of the first proposal of tag and tag health. Here we consider the following problem:
A) Problem) Suppose a community considers itself to be a neutral #news community. However, they have an unknown bias (capitalist, socialist, communist, etc). This bias is not reflected in the community tag or the post tag. However, users of one bias group would be dissatisfied to see posts of a different bias group.
Users outside the community cannot set unofficial tags or unofficial descriptions for the community since that can be abused. Then how would users create super-communities in a satisfactory manner?
B) Solution) Tag subgroup) Communities that share the same tag (say #news) would dedicate some of their server computing power for appropriately grouping themselves.
Suppose there are communities News1, News2, News3. Each community (say News1) would observe whether its own users upvote/downvote content from other communities (News2 and News3). Based on this, it would establish a positive link strength or a negative link strength with other communities.
In addition, moderators can also add a section called suggested similar communities, and dissimilar communities.
Based on these link strengths, all communities with the same tag (or tag algebra) can be grouped into multiple groups. When a super-community is created with this tag (or tag algebra), then the communities are grouped together if they have positive link strength with each other. However, if some child community has high negative link strength with other communities, then they would be classified into two or more groups, such that each group has positively linked child communities.
C) User interface) When user Emily tries to create super-community #news, it will get automatically created if the child communities do not have too much negative link strength with each other. However, if some news communities have a different theme from other news communities (negative link strength), then they would be auto-grouped into two or more groups.
Emily would see an advanced setting which is auto-expanded, and it will show two or more different groups. Each group would have a snippet that shows a couple of highly upvoted posts. Based on these snippets, Emily can choose any one group, or she can also choose any/all combination of these groups.
D) Conclusion) We can avoid the problem of duplicate communities with conflicting themes on multiple server instances.
What about allowing communities to federate with others?
Eg. The mods at [email protected] and [email protected] could decide their communities have the same audience and ideology. They choose to federate with each other so anyone that subscribes to either or both will get posts for both. Mods will then work together to moderate.
Then if 1 set of mods decide to change their policies or go in a different direction they can then de-federate and break the 2 communities apart again.
I don’t think this is an issue tbh.
The full name of a community includes the instance is running on. For this community here the instance is [email protected] . If you are referring to community you should include the instance to avoid confusion.
To the issue of duplicate communities: That issue existed on reddit too. Communities with slight variations in the name always existed. Sometimes the owners of some variation of the community just decided to forward their users to a “main community”. Sometimes multiple communities coexist. I believe that in most cases a certain “main community” will establish itself as the one that the majority just accepts as the “real deal” because it has the most activity and the best moderation policies.
I think you’ve got it. It’s only a problem that exists when communities are first starting. The best version will win out eventually, or a balance will emerge. Sometimes one will end up as a meme- or image-heavy forum, while the other one becomes primarily discussion focused.
