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.
Our site incubator concept needs a re-think
Background
Starting new sites here at Codidact has evolved over time, mostly as we got experience and realized we needed to do something different.
Originally, new sites would be proposed here on meta, kicked around, then fully created if it felt right. That sortof worked when Codidact was new, but we found some sites were being launched without sufficient commitment and interest from users. These sites are still here, but have very low activity.
The current incubator system was developed in response to that. A site was created just for starting new sites.
The current system
If you have an idea for a new site, you write it up in the Descriptions category.
Users can indicate their interest and expected level of commitment to the proposed site by selecting one of several "reactions". Currently, the choices are Casual browser, Active user, or Subject matter expert. The users that "signed up" with each reaction are shown at the top of the site proposal so that everyone can see the level of interest.
To define the site better, questions are asked in the Incubator Q&A category. Each question is tagged with the special tag unique to each proposed site. Voting is largely used to get people's opinions of whether the question is a good fit for the proposed site. Reasons why and arguments for or against fit are in comments. Answers are written as if the question were on the real site.
Hashing out the site definition is done in the meta category. People can argue for or against changes to the existing proposal, with voting used to get a sense of how the community feels about each issue. Proposals can then be edited accordingly.
Existing problems
Let's understand that the design of the current system was well-meaning, and in response to experience with the previous system. However, now that we've had some experience with this system, several problems have become apparent:
- Who/when edits the proposal? There have been good discussions in meta about details of various proposals. However, what constitutes a consensus such that the site proposal should be changed? What does it mean when a change gets 2 upvotes and 2 downvotes? Keep in mind that the original proposer presumably agrees with the proposal, so 2-2 vote tally is really 3-2 users for/against. What threshold is sufficient? Who gets to decide that? Anyone can edit the proposal, but when should they?
-
Huge barrier to "outside" people. There are a lot of mechanics around trying to "use" any of the proposed sites. Those already here at Codidact for other reasons can generally figure it out. However, consider the experience of someone outside being told of a new site with a topic that interests them. This person may not be used to computer forums or Q&A sites, or particularly tech-savy. I'll use someone who is interested in invasive species as an example, since there is a meta discussion about that:
- OK, I've read the site proposal and the rules make sense. What's this "proposal" thing? I thought I was going to an invasive species forum.
- Huh? I can't just ask a question here? I have to go to this other "category" thing?
- There is nothing about invasive species here! I don't care about how to make kelp grow less tall, fixing corrupt data in some game, resurrecting long-dead people. What the ...? I must be in the wrong place.
- OK, I have to post my question here, but it has to be "tagged". What's a tag? What tag am I supposed to use? How was I supposed to know this before getting a nasty-gram message in a comment?
- It's a day later. Where did my question go? All I see is babble about psychic powers to move stuff around, some philosophy BS about Kant (who the heck is that?), people underground not knowing a war is over, blah, blah, blah.
- Olin told me this place was for discussing invasive species. I'll never believe anything that guy says again. I'm outta here!
Actually, I can't envision anyone making it to step 6. Most will be lost by step 3.
- Substantially new topics have no chance. Since only existing Codidact users are going to have meaningful impact on proposed sites, the only possible new sites are somewhat close to other topics users are already here for. For example, Worldbuilding might work because enough people here for Scientific Speculation could be interested. It's no surprise that Worldbuilding has gotten way more action than Invasive Species, for example.
-
Nobody outside will ever find a proposed site. Even ignoring the large barrier to participation of outside people, how are they ever going to discover a possible new site? There is little focused on the specific topic for search engines to guide you too. There isn't a whole site proclaiming to be about "Invasive Species", for example, just a site proposal.
A search engine might point you to a specific question in the Incubator Q&A category, but then what? Answering the question may not be so bad, but what if you want to ask a different question? Now there are a lot of things you need to know you really have no way to know you don't know, and it looks like you ended up in a pile of drivel.
The question
Let's hear some ideas for a better way to start new sites.
I agree we want to make it easier for those being recruited for a specific proposal to be able to focus on that proposal …
1mo ago
I think that a lot of the current approach mostly works. Once you've gotten here, if you have an interest in other topi …
1mo ago
Here is a mechanism that addresses some of the problems: Each proposed new site is a full site in the structural sens …
1mo ago
I don't know whether I like the following idea better or worse than the current approach with a tag for each proposed co …
1mo ago
4 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
I don't know whether I like the following idea better or worse than the current approach with a tag for each proposed community, but I agree we could benefit from discussion of new ideas, so here's an idea to discuss. Maybe discussion will lead to something better than either.
Category per proposed community
Process
- If I have an idea for a new community, I add a description to the Descriptions category (as currently).
- A moderator sees the new description and responds by creating a new category with that name, with the first paragraph of the description as the category description at the top of the page.
- A link can now be added from the post in the Descriptions category to its new dedicated category.
- Anyone can now add example questions to this category, and answer them and vote and comment on them.
Less Codidact experience needed
This means that the category only contains questions for this specific proposed community, and there is a community-specific description at the top of the category page, so people unfamiliar with Codidact can be given a link directly to the category and not have to find their way from the Descriptions category.
Meta
Should Meta questions be asked
- In the existing Meta category
- In the relevant proposed community category with the tag "meta"?
- In an individual community-name-meta category per proposed community?
I'd lean towards one of the first two, to keep the number of categories down.
Tags
Currently all questions are in one category, so a tag name that happens to apply to two or more proposed communities will either have a description that only applies to one of them (whoever edited first), or have sections for different communities, making it confusing for people not experienced with how Proposals works.
With a category per community, there could also be a tag set per category (the software already supports this - it's an option an admin can select). This way, a tag in the Invasive Species category has a description unique to that category, even if a tag with the same name also exists in Board Games or Politics.
1 comment thread
I agree we want to make it easier for those being recruited for a specific proposal to be able to focus on that proposal and not all the others. You can see all the posts for a proposal by starting from the tag page, but that loses the nicer presentation of the category view. You can add a filter to the Incubator category, but right now we can't bake that in easily, so that's asking people who don't yet know Codidact to work through the filters UI. What we need is a sharable URL for the proposal that sets everything up to focus on that proposal. Another answer proposes just (proto-)launching the communities -- focused URL solved. I have a different idea that I think would be easier to administer.
The following ideas would require code changes, so I want to float the ideas first.
Part 1: Make filters more granular
There are some built-in filters, which are configurable at the network level. (It's a YAML file, not baked into the code, so it can be changed locally.) These filters are global to the network, so adding a bunch of proposal-specific filters would be confusing for people on, say, Electrical Engineering. We could do better if configurable filters could be restricted to a specific community. This would also give us an opportunity to improve user-created filters, which are global when defined but only make sense on some communities. (Until writing this paragraph I thought user-defined filters were community/category-specific, but I just checked mine and they're not.)
If proposal tag filters could be defined globally for the Proposals site only, this would reduce the problem from "write a filter" to "choose this filter from a list".
Part 2: Skip the filters UI
The filters UI was created for people who are browsing or building their own things. But if you already know what you want, maybe we can do better. That UI where you can choose an existing filter calls into something in the back end to do it. Let's give people another way to do that part. Easiest from the user perspective (I don't know about implementation) would be to embed it in the URL, so (for example) https://proposals.codidact.com/[categories/67]?useFilter=Proposal-InvasiveSpecies would apply that proposal's filter and make it sticky, so as you move about the site and click on category headings you'd still be using the filter. People who become more fluent in the Codidact system or curious about other proposals will find their way to the filters UI and can make changes there. People who really only care about that one proposal don't have to interact with filters at all.
Ideally, we'd be able to omit the category from the URL and useFilter would apply to any category on the site without causing trouble for other pages (individual posts, user profile, etc). If we can't do that, then the downside is seeing descriptions and meta conversations about other proposals (or bugs or feature requests, in the case of Meta) while having a filtered Incubator Q&A view. That doesn't seem terrible to me.
Complication: posting
We want people to post questions (and articles if applicable) in their experimental community without having to think too much about it. But if the proposal tag doesn't get onto new posts, what people will see is that they posted something successfully (according to the submission) but it didn't show up in the list (because of the filter).
Currently, we would have to place prominent reminders to add the proposal tag. Some people will miss them anyway, and it's user burden. I don't know how practical this is, but if you are in this filtered view, it would be great if we could automatically apply the tag for you. So in addition to the more general useFilter API, maybe we want useTagFilter, and in addition to assigning the filter that code would also assign a default tag for all of your posts When you create a post while a tag filter is set, the filtered-on tag would automatically be added to your post. I don't know how hard this is.
A mechanism like this could be useful on other communities later as they grow. One of the arguments we heard against creating a broad Software Development community was that eventually it would be harder for people with more specific interests to focus on them. (The counter-proposal was to create a bunch of different communities.) If, in the future, the python sub-community of Software Development wants that focus, they could use this approach instead of completely breaking off. Implication: a filtered tag should include its children too. (I haven't tested that.)
Part 3: Entry points
If we did all that, then we could set up a page that lists all of the experimental communities, analogous to the list of launched communities at codidact.com. Each entry could include the community name, a summary from the proposal description, and the proposal-specific filter URL. This page would also include general language about the nature of experimental communities -- whatever we want people to know before diving in.
Experimental communities, not being fully launched, would not show up in the switcher in the header, the dashboard, or the list of communities in the footer. This prevents a partly-formed idea of a community from giving people who come across it in a community list incorrect ideas about that community or the network.
That sounds like a lot of work. Why not just launch experimental communities instead?
Administration, mainly. While participants in a single proposal only care about that one proposed community, people who are looking at the whole network, particularly administrators but also other curators, would need to visit each individual community to check in on it. We'd need another dashboard view, for just the experimental communities, to stand any chance of staying on top of flags and meta or seeing new activity in general. Even so, we'd miss some activity that we'd otherwise want to pay attention to, like comments that require responses. Issues that affect more than one proposal would be harder to communicate about. RSS feeds would be more challenging (for example, one feed into Discord would be replaced by about 40, unless someone knows how to aggregate them).
Here is a mechanism that addresses some of the problems:
- Each proposed new site is a full site in the structural sense. It has all the proposed categories, including meta.
- These sites would be in a single container that is at the same level as the full sites. This container would be called Experimental sites.
- Experimental sites are run a bit differently than full sites. They don't yet have much of a user base, and there will be more diverging opinions on the direction the site should take.
The proposers would be the moderators. Users don't earn abilities. They can only be granted them by the moderators, including the moderator ability.
I know this goes against the user-driven philosophy, but it is worth it to have a coherent vision of what the site should be. Design by committee doesn't really work. If someone or a group comes here with a vision for a new site, we should give them a chance to prove themselves before assuming certain things don't work or should be different. We don't want the original proposers getting disillusioned and leave.
Of course there would still be meta discussions about how the site should be formed, but it is up to the original proposers what suggestions to accept or not.
- Anyone can propose a new competing site with a somewhat different focus than another experimental site. This is how we get around problems of point 3, above. If someone proposes something really crazy and won't listen to advice, then those who feel strongly about it can and should propose a different version. Let the marketplace decides which wins. Perhaps in some cases the sites diverge so far that they become viable as distinct full sites.
The point is to give each idea a chance instead of trying to mold them, then let the different ideas compete to decide which to finally promote, if any.
A big advantage of this scheme is that an experimental site looks and feels like a full site from within, especially to users unfamiliar with Codidact. It's a level down in the tree structure, but you don't care or even know if you're just given a URL to check out. Eventually some of those "outside" users might pop up a level and explore, becoming more active Codidact-wide users. By that time, they'd understand about full and experimental sites.
Response to comments
wondering if this new community would have links to the existing communities in the drop down at the top right of the page
I hadn't thought about that. My first reaction is that from an experimental site, you'd see the other experimental sites, with a single entry to go to the full sites. From a full site, it's the other way around.
Does the "level" at which these communities sit make any difference? Is this suggestion practically equivalent to letting anyone make a new community, but with the founder able to hand out abilities?
I think it's important to segregate the experimental sites from the full sites. The experimental sites are by definition half-baked. They could easily appear as noise to many users, reflecting badly on all of Codidact. It should take deliberate action to see the "mess".
Segregating the experimental sites also makes it easier to understand that rules might be different, and that some proposals might turn out to be silly ideas in the long run. After all, they are experiments.
I envision the main page that lists the experimental sites having a disclaimer at the top, pointing to help files that explain the situation in more detail. The main page for each category in the experimental sites should also have an obvious warning or disclaimer that you're in a experimental zone.
The current Proposals community was intended to avoid creating new communities before they are ready, which end up with almost zero activity. Does putting new communities in a container at a different level from existing communities change this?
The new communities are created either way. In the current system they are less obvious and harder to find, but they are still essentially there. They are also in a single container when viewing the list of full sites.
By putting experimental communities in their own area, it makes it clear they are different from the full communities. One of those differences is that we expect the volumes to be low.
Having an experimental site mostly look and feel like the final site will be important to pointing potential users to them. Because of that, I expect these experimental sites to grow faster than our current proposed sites. None of those have more than a small handful of posts, and most of those are from users already at Codidact for other reasons. That's a recipe for failure.
3 comment threads
I think that a lot of the current approach mostly works. Once you've gotten here, if you have an interest in other topics, then you'll find the incubator. If you haven't gotten here or don't have any interest in the topics beyond your own, then...tough?
That said, a couple of ideas come to mind that might improve things.
First, maybe set a (soft) expiration date on proposals. If the person making the proposal can't drum up a certain amount of activity - already here or by recruiting people from their own audiences - within a certain amount of time, then that site won't work here for now. At that point, it doesn't make much sense to let people hope that their day will come, though maybe someone can come along later and try again.
This, I think, solves the "people here don't get your good idea" problem, by making it clear that nobody here has responsibility for making their site idea succeed. And "retiring" the sites that don't pass muster at least touches on the problem of having an entire site that doesn't work.
Then, incubator questions (in my opinion) need a tighter link to the proposal. Clicking on a proposal, I should see the list of all questions destined for that proposed site. And if I click on a question (assuming that a proposal doesn't become some lightweight version of a site), I should see something about the proposal and how to get there. Often, questions seem to come out of nowhere, even after having kept up to date with the proposals.
Related to that link, maybe that linkage could also replace the voting. If nobody asks or answers a question in the topic, then it doesn't really matter that a hundred people said that they'd focus their time there. If hundreds of people ask and answer questions, then it also doesn't matter how they voted.
And sort of combining those, a proposal should come with at least a few questions to "seed" the topic. One question could hypothetically flop because the author didn't make it clear, because it feels like the author's personal playground, because nobody has any interest. When you get to a dozen or so questions by different writers, that would provide a better test. And requiring a dozen questions off the bat would force a certain commitment and provide a test of the topic's breadth.
I don't know if any of that solves the problem, but I hope that something in there works as salvage...
0 comment threads
0 comment threads