Post History

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