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.
#1: Initial revision
How can we improve community proposals?
Now that we've seen several community proposals, some of which succeeded and some of which have run into hurdles, I want to look at how we're managing and tracking proposals. While there will always be an element of human judgement, I feel like we don't have a good handle on how to decide when to advance a community. I have some thoughts on how to improve what we're doing, and I'm asking for community feedback, especially on the shorter-term items since we have proposals that people are patiently waiting for us to respond to. ## Issues with the current approach - We currently use the "idea" and "proposal" tags as a coarse indication of where a proposal is. The line between them is kind of fuzzy, especially since we (I) added some status tags. - How many supporters are enough? It depends! I think topics of broad interest don't need as many experts to start, and ones of more narrow interest need more of those specialists. But notice I haven't said a number yet, because I really don't know. EE and Judaism, both somewhat specialized, started with a handful of people (<10) and are doing ok. Code Golf, which is newer, also seems to have taken off with a small group of enthusiastic founders. Does that generalize? (Also, is there a better way to track supporters?) - How much scope needs to be agreed on before launch vs after? Do we need sample questions (on/off-topic)? We don't have a good way to manage that now. ## Short term Tags: let's use "needs" tags from the start and separate them from status. A proposal should start with all of them and gradually remove them as they're worked out: - Needs-summary: a paragraph or so describing what this community is for, plus a one-liner summary for the community list. Use one or more answers to work it out so people can vote. When there's consensus, edit into the proposal and drop the tag. - Needs-scope: we want to see the next level down of scope consensus, whether that's lists of on/off-topic items or sample questions or something else. Think of this as fodder for the help topic on what you can ask here. It doesn't have to cover all the edge cases, but it should be a decent start. Again, we want to see some sort of consensus via voting -- do the people who are interested in building the community agree on what they're building (broadly)? - Needs-people: for now we can keep doing what we're doing with collecting them in a post. It would help if we could sort the list by enthusiast vs casual so we can more easily tell, but that requires people to self-identify and they don't always. (I tried to sort one proposal's list this way and gave up because I had to interpret too much.) I don't know if there is still a meaningful distinction between [idea] and [proposal]. Criteria: As I said in "issues", I think some of this is necessarily fuzzy. **As a starting point for discussion**, let's advance a proposal when it meets all of the following: - Has a summary with a score of at least +10/-0. Even people who won't participate actively can and will vote, as part of the broader network community, so it's ok to have a highish bar here. Setting up a new community isn't *hard* but it's not free either, so we should see some consensus from the Meta community that adding this one makes sense. - Has a scope proposal (answer) of at least +5/-0. - Has at least three enthusiasts. - Has other users who've signed up on the proposal, number still TBD. (I'm thinking 5-10?) There are a lot more casual music people in the world than there are casual quantum-computing people, so we're likely to pick up more people "in the wild" on a general topic, which argues for requiring fewer for general and more for specialized. On the other hand, it's harder to find and attract specialists, so if we set the bar higher for a specialized community, it might never get off the ground. So maybe the number doesn't depend on the breadth of the topic, even though that's counter-intuitive to me at least. A factor to consider is that a community needs a decent flow of (quality) *questions* to entice people to stick around. I'm not sure how we assess that in advance. Here's how some of our proposals stack up against these criteria: - Music: would advance - Physics: would probably advance (looks like enough people, scope needs more support) - Linux: needs scope, looks like enough people including enthusiasts - History: needs consensus on scope, and enthusiasts (proposal is popular voting-wise) - RPG: needs people, particularly enthusiasts - Medical Science: has conflicts (needs to resolve), needs more enthusiasts, needs scope ## Longer term Longer term, we need better tooling for proposals. A post type customized for proposals could make a big difference. I'm imagining something that has a top-level post that describes the proposal, and then some specific responses for summary, scope, etc, and with all of this being more easily edited by community members. Can we add an "I'm interested" button? You would be prompted for level of interest, level of expertise, and a freeform comment. Ideally these would be sorted and displayed together somehow; as an interim solution, they could be added to a (standard) answer that collects these, with consistent formatting and without requiring the edit ability on Meta. Once people can register interest in this way, we could ping supporters when the proposal changes state (status tags, I mean). It's ok if sending that ping is a mod clicking something saying "notify supporters" as opposed to something more automated -- the point is that if supporters "register" somehow, then we know whom to contact and could do it with automation rather than hand-written comment pings. It would be nice to have a way to collect sample questions to feed the scope discussion. These would be individually votable (up/down). But it's ok if the scope discussion takes the form of an answer that anybody can edit, comment on, and vote on. What else? What changes (in code or process) would help people proposing, supporting, and evaluating new communities on our network?