Our site incubator concept needs a re-think

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.

posted 3 months ago

CC BY-SA 4.0

3mo ago

trichoplax‭

225 75 718 300

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).

posted 3 months ago

CC BY-SA 4.0

Monica Cellio‭ staff

64 377 2269 838

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...

posted 3 months ago

CC BY-SA 4.0

John C‭

0 3 2 0

Here is a mechanism that addresses some of the problems:

1. Each proposed new site is a full site in the structural sense. It has all the proposed categories, including meta.
2. 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.
3. 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.

4. 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.

posted 3 months ago

CC BY-SA 4.0

3mo ago

Olin Lathrop‭

46 122 342 122