Let me catch up on the few days of posts I’ve missed:
@5g3-steven-7tv you’re right of course that this many-headed beast requires many heads in many team(s), and it is being addressed for the various different specific projects that Canonical touches, but I for one would love to see a proposal for how we might tackle the less but still many heads of the community side of documentation? (see last quesiton in this silly-ly long post)
I love the quick call up for a new job , this might be of interest to you if you are looking: https://canonical.com/careers/2288147/technical-writer-remote
But until Canonical gets a stronger hold on its documentation there’s unlikely to be hires to help community documentation, 3-5 full time certainly not. But stranger things have happened, we’re hoping to hire soon for people to join the community team and that could be a significant function. Once that becomes a think I expect it’ll be shared here.
@ian-weisser all great questions that need answers. We don’t have a way to identify issues besides them cropping up on discourse, the best thing would be a centralised place where these kinds of issues can be logged, maybe that’s reviving (if it’s dead? I don’t know): https://launchpad.net/~ubuntu-doc-contributors
and make it very clear how to log them (that’s a guide I could start but would need experienced help to perfect) I’m thinking a simple guide linked to in allt he right places that goes thorugh the proper process. And then a team of volunteers to connect them to and nurture when things happen, which could be in Launchpad too, but Launchpad is not so conducive to conversation so maybe that’s a community docs category here in discourse.
I don’t think this is too broad yet, I agree with @5g3-steven-7tv here. I like that you want to break it down into manageable chunks, and that will 1000% need to be done, but we need to land on a higher-level process that we can agree on and plan to be sustainable before we start trying to carve off in different directions. Which is then what you seem to go and do @5g3?
We’re talking about 3 problems at once and I’m getting them jumbled in my head, so, from top down its:
How we manage community documentation
Then where should that documentation live and how the pieces in that breakdown are maintained
Then the individual pieces of rot. Because the ‘pervasive rot issue’ you flagged there would be solved by the higher level process and wouldn’t be a rot issue as much as an issue filed to the team to be put up for contribution.
Thus, woof, sorry for the extra long post, thus, I would love to see any ideas anyone has for the kind of strucutre/processs/methods of management for communtiy documentation here in this thread, then I can happily turn them into a proper plan/proposal, we can get a group together, I can even poke that Launchpad group, have a meet (or two) and maybe get some stuff going again…?