Ooh, thanks everybody for the replies! I was also super “impressed” to find them in my e-mail this morning – the integration with e-mail is going to be a huge asset for our community.
I’m not surprised! I tend to over-engineer and over-optimise. I started reading @HAWK ‘s article on tags, which is useful to me.
Fun fact, nearly 20 years ago I was writing this: https://climbtothestars.org/archives/2006/02/11/tags-and-categories-are-not-the-same/ (if anybody remembers, at the time WordPress was treating both as one same thing and I had some beef with it 
) – but the relationship between tags and categories in a publishing context, or community context, is not the same, so it’s very helpful to read about tags on Discourse. Also because they do seem somewhat more “structured/ontological” than the way I tend to see tags in my world.
So, definitely, in the light of this, I think Senvelgo, high doses, different types of equipment, emergencies etc should probably all be tags. My take-away is: use a category if there is an access right issue or a very specific “box” for the use-case/topic covered.
In that light, veterinarians are clearly a category (because it’s private to them). Grief/death also, because we want to “manage” those posts outside the regular stream of posting.
I think that “Beginners/Welcome” needs to be one too (proof: we already split that out on Facebook).
Dosing advice could justify a separate category because we want to control posting rights differently there (on the other hand: will people “workaround” that by trying to sneak their dosing advice posts in other places? sure…)
One thing that’s not clear: can we give “moderation rights” to certain users on certain tags? e.g. if we have “tech support” or “food” as a tag rather than a category, can we have members who have rights to moderate discussion in those topics but not others?
In our case, we do have eight years of active community life to draw from, so we do have a rather good view on what people post about – on facebook. It’s true, though, that being in another environment will change behaviours, so that is an unknown.
We can look up join dates manually, and have no e-mails. However, as we have an “onboarding members” culture, we have manual lists of member cohorts by username. My idea is to ask people for their Facebook name when they sign up, and their join date if they remember. Then we can sort them into user groups according to the year they joined. We’ll see if it’s worth trying to automate that.
yeah, I’m very much aware of this issue! in our case, we need to balance it with the “overwhelm” for our new (non-migrating) members. Members typically join our community when their cat is freshly diagnosed, often in bad shape, and they are freaking out. Seeing the “intensity” of involvement of our active members, everything people are doing in terms of care (that their veterinarian didn’t tell them about), we are in a space that is at very high risk of creating more distress for the people we are trying to support.
This is where the idea of “chopping things up” so people are not faced with everything and the kitchen sink when all they thought they were going to get were some kind words and a tip or two.
This would definitely be open to all. But is there a way to exclude posts from that category from the “everything” feed? or create an ad hoc “everything” feed that is not really everything?
Thanks, I’ll definitely have a look at this.
To give you an idea what we’re dealing with, here’s some insight into our current documentation in Google Docs, which honestly functions pretty well for now. There is an Index Page which is kind of where we assume people will start from, and a Master List for people who are library rats or who are just trying to lay their hands on something specific.
The issues:
- they’re not “on the web” even though they’re public Google docs, and I’d like them to be more findable by the general public => first idea was to convert them to web pages on the WordPress site we have
- people struggle to link to them, and also “remember” what exists => having them integrated in Discourse would be interesting in that respect, as long as it can be done in a way that also satisfies the first point above
What works well:
- we can distribute access rights per document to the handful of people who might contribute on keeping them up-to-date
- they print well, which is important in a world (the veterinary world) where paper still very much has a place
- once added to one’s google drive, they are searcheable
To help people find their way through the documentation, I recently made them accessible via an ai/chatbot interface with NotebookLM, but I’m hoping something similar might be possible inside Discourse.
If I remember correctly when I tested the Docs plugin, it didn’t really work for my use case because it makes the documents too much like topics. But maybe my thinking around this still needs to evolve.
These rules don’t apply to staff, so to test the setup you need a separate test account.
)