Welcome to Codidact Meta!
Codidact Meta is the meta-discussion site for the Codidact community network and the Codidact software. Whether you have bug reports or feature requests, support questions or rule discussions that touch the whole network – this is the site for you.
Comments on How granular should network communities be?
Parent
How granular should network communities be?
What are (y)our principles for deciding how granular Codidact network communities should be? The Other Place seems to lean towards more granular communities—one for software development, one for server administration, one for UI design, one for theoretical computer science. For those with experience moderating those communities, has that worked well? I could easily imagine going the opposite route and lumping those all into ‘computers’, with tags to categorize within that. How do we choose?
I'll enumerate some considerations I've thought of here; feel free to edit and add more.
-
More granular communities generate more busywork in the forms of finding the right community in which to submit a question, evaluating questions to determine whether they are on topic for a community, and resubmitting questions when they are found off-topic. Broader communities don't eliminate this work entirely, but they do reduce it.
-
Narrow communities can deter potential users interested in related subdisciplines if narrow communities for those subdisciplines don't exist yet. Broad coverage increases initial user draw, which might be important for reaching critical mass.
-
Communities have a lot of autonomy in determining what is on topic and how they should be moderated. Larger autonomous units need more infrastructure (procedure and/or tools) to function efficiently than smaller ones.
-
More granular communities let users select for the sorts of posts they're interested in. Can't tags serve this purpose just as easily in broader communities?
-
A question may have multiple answers which would be most at-home in two different narrow communities—a question could get good answers from both a software development and a theoretical computer science perspective. In a model where every question has at most one ‘accepted’ answer, this can be resolved by moving the question to whichever community the best answer belongs in. But in a model with an emphasis on collecting a plurality of answers, that's a tradeoff with no good answer. In the broad community model, this is a non-issue, as long as communities are selected to avoid this sort of conflict. (But maybe this isn't possible? Are there always going to be questions that want answers from, e.g., both cooking and Judaism, where the communities are naturally disjoint for most purposes?)
-
More granular communities enable moderators with narrower areas of expertise to make judgment calls on most questions in the community. Broader communities would likely require more moderators per community to get the same expertise coverage. This might not be more moderators overall though, if there are correspondingly fewer communities? I'm not sure this point matters.
-
Users build reputation independently in different communities. The Other Place tracks tag-specific reputation for some privileges; perhaps Codidact could do the same. Or perhaps this doesn't matter either.
-
Are there technical concerns—is the architecture for the Codidact network opinionated on the ideal size of a community?
-
Is it easier to correct mistakes in one direction or the other—i.e., merge a bunch of communities into one, or split off communities from an existing one?
A community with common interests is a part of it too. At Some Other place somebody wanted to combine all the Abrahamic …
4y ago
If you'll allow me to come up with a made-up dystopia community scenario: Suppose you are a professional carpenter w …
4y ago
The main guiding principle should be what fraction of posts a typical user would find interesting, or at least feel are …
4y ago
Post
A community with common interests is a part of it too. At Some Other place somebody wanted to combine all the Abrahamic religion sites into one, arguing that they share a lot of biblical books and tags could differentiate religious context. I argued against this because the three communities view those topics very differently and there weren't people who wanted to build a community for all three religions, but there were people who wanted to build communities for each of the three separately. In addition to different views of the bible, there are whole additional layers -- extra-biblical sources, customs, etc -- that differ among the three. This community would have been too general; by making everybody wade through a bunch of stuff they didn't care about to find their own subcommunity, that arrangement would have actually driven people away, in addition to not providing any benefit from those subcommunities all being in the same place. (It also likely would have led to tensions among users with very different perspectives.)
But, in an alternate universe, I could imagine a "religious studies" community forming, drawing from academia (some universities have departments for this), where there would probably be more cross-cutting questions, fuzzier lines, and fewer people deeply invested in personal religious values. That community, having basically the same breadth as the one in the previous paragraph, could work just fine -- because the people in that community have that shared interest.
So it's not really about scope. It's about the people. Who are the people coming together to form a community? What do their boundaries look like? What forms their identity? Where do they see themselves going?
Now consider an example from our own network, Software Development. This topic is pretty broad; on Some Other network its scope would cover a dozen or so different sites. Some Other network, as you point out, has tended to carve off smaller scopes for sites -- often, but not entirely. I think that's because of scale; Stack Overflow is so huge that people with a more focused interest like databases or quality assurance or web development can feel lost there. Their questions are on topic on SO, but it's harder for them to find their communities (people). They can do that more easily on focused sites, and so, over the years, SO has spawned a bunch of specialist sites.
On the other hand, there are communities with a very broad scope, like Writing, that haven't spawned children, because even though the scope is huge, the community is still fairly small. Even in the before times, if SE had split Writing up into sites for fiction, technical writing, and other topics, each of those sites would have had too few people to sustain them. (In fact SE tried to create a technical-communications site, over the objections of the Writing community because it was 90% scope overlap, and that community failed.)
In my opinion, we should create a separate community here when either the topic really is specialized (it doesn't make sense for it to be part of something broader) or when there is an active community that wants to focus on that area of scope. Either way, we're looking for enough active people to sustain it. If there's an active community of people, I don't really care whether the scope is narrow or broad -- they're doing stuff that makes sense for that community. So long as we don't create confusion or tension on our network of other communities, I don't see a problem.
We do not have the user base of Some Other network. When we were planning the Software Development community, there were arguments for a general community and arguments for several specialized communities. I don't currently see enough people to support any specialized communities, and as you point out, more related communities creates a little more friction for people coming in. So we created the general community, but with the expectation that as it grows, sub-communities might want to split off. We will support that in a way that minimizes disruption to all involved; I think that just by planning for that kind of growth from the start, we're already ahead of Some Other network where the subcommunity would have to start by proposing a brand-new site and people with questions would still find lots of questions on SO even though there's that other site over there.
(What does our plan look like? I have a ticket to develop this idea and share a draft with the community, which I haven't had time to work on yet, but the broad idea is that we'd spin off a new community but make its content (or some of its content?) available on the parent community too and steer people from the parent to the specialized community when appropriate. If there's a Javascript community but you go to Software Dev and search you would still find hits (that would guide you to the JS community). There would be something TBD in the question-asking flow that would lead you there based on tags. Something like that, but we haven't fleshed it out yet.)
0 comment threads