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.
Post History
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 se...
#1: Initial revision
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. 1. 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. 1. 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. 1. 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. 1. 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? 1. 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?) 1. 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. 1. 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. 1. Are there technical concerns—is the architecture for the Codidact network opinionated on the ideal size of a community? 1. 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?