I wonder if it’s time to introduce some new categories here in the Help Center. I rarely feel like I’m putting my topic in the right spot and end up defaulting to ‘Hosting on Micro.blog’ (like this very topic!).
A few that I would suggest:
I think it’d make topics easier to find, as well.
I second this. When reporting a bug today, I didn’t know where to put it. I chose Getting Started, but it’s avoidable friction with clearer categories.
Also, security bugs, where does one send those? A special email address seems more appropriate, so the devs can act quickly, instead of wading through help requests.
I’ve reported a handful of security vulnerabilities by sending emails to help@micro.blog with Security vulnerability as a prefix in the subject line. @manton has responded and patched the vulnerabilities swiftly in all these cases.
But I would love to see a security policy and a dedicated channel as well. Great idea! security.txt and GitHub’s Security Policy feature (one can set up a default one for the entire organization) might be worth looking into.
I do also like this idea, but I think that if I was one of the admins, it might be getting harder and harder to moderate those.
As things get more specific, certain posts need to move to another category (and an explanation should be given since the person who posted might be confused). Some users don’t have as much technical knowledge (raises hand) as others, and perhaps not everyone should have access to everything to keep things more clear. Then there are more urgent things, like security issues, than say photogblogging. Not to mention these topics might need to change with time and fit this very dynamic community.
One of the solutions that comes to mind is to have moderators of course, at least for the big ones. That’s a good next step, but again, this in itself requires time to find the right people and for these folks to get their bearing.
So, yes, definitely! But also, this is not that simple (at least from my own experience). Just my two cents 
We had similar bugs and I put mine under photoblogging since it dealt with image upload.
That goes to show that picking the “wrong” category can be without ill intent, just different interpretations.
Another solution could be to reduce the number of categories, how strange that might seem. Less choice means less confusion among people.
Good points, everyone. I really want to rethink all the categories (and Help Contents sections too, which don’t necessarily need to match the discussion categories). Open to any suggestions… From the above list, “Timeline” and “Themes” seem like good additions to me.
To me, the categories are most useful for newcomers. Personally I read everything here regardless of which category it goes into.
Personally, I like the categories, but if it ultimately doesn’t matter where things end up and you’re looking to simplify, maybe you just want to do the locked Help Contents and then a General Support. Mostly I feel silly because specifying a category is mandatory, and then I can’t find the “right” one.
But if you went down that route, I’d suggest adding optional tags for common types of topics and features, like…
I might actually like that better because I feel like my topics often span multiple of those types, but others may not feel like tagging it at all. I think it’d be more flexible overall, and work well into the way it seems both users and moderators already use the Help Center anyway.
I’d really like to see a top-level category for Creating a Safe and Inclusive Micro.blog Community which would allow discussion of the points @cygnoir raised in her blog post with that title and other ideas for that topic. It would demonstrate the importance of safety and diversity for the community. This would be different from the simple Community topic where people discuss all manner of general things about the community, such as finding people to follow or whether there should be an emoji for some hobby.
Any more consideration on this? I still find it challenging to select the right category for topics, but it’s a required field.