Since I’m not very deep into Docs yet, I’ll hold back on comments. But a few remarks:
I am not 100% sure if I got your point (FESCO in terms of being on par in the organization level, or in terms of the number of people? Or just having a more formally organized structure?). If it is the first, is this really necessary (in terms of fostering the goals of Docs) and does it really solve/reduce the issues we have now? If it’s the second, I think this is not realistic to achieve, is it?
If it is the third, I would agree that creating more formal (and documented) structures could help in many respects. The entry barrier to the team is very high as everyone has to come to the team actively and ask what they would be up against if the join, they don’t know in advance what this is about. However, if they connect to get that information, it feels bad to then say “sorry, that’s too much for me” or “sorry, I’m not qualified for that”. People don’t want to be in such a situation. This is a psychological thing that maybe should be avoided if possible, and maybe one of the reasons for the personnel issue.
The git introduction of Ben and the draft for the meetings are already a good start. I would also add the Group fedora-docs - Pagure.io page to the git intro (it offered me the overview I was seeking), so that people have an overview of what Docs includes/is about (and maybe what else is included). Also, an introduction to the workflow and “how to do what” (including responsibilities, decision-making, and so on) makes sense (as soon as it is determined). This implies just an abstract overview, no dedicated Doc or such
That was my goal with the GitLab dashboard Although the dashboard is intended for managing the “day to day” work of Docs (in short, managing the work related to the content and its development; this includes discussing pull requests which are related to the content (the issue ticket) and not to the date as the meeting), but not to manage Docs as “Fedora entity” itself (organizational architecture issues, long term issues/development, necessary adjustments, strategic issues). The latter needs a different structure (Discourse & the meetings are appropriate for this) with different “primary keys” to discuss, sort and find (or simply, organize) things that are not reappearing in the same manner and not standardized like content management So my approach does not exclude Ben’s argument:
In short, I wanted to say that GitLab dash is for managing the product of Docs (the processes), Discourse/meetings to manage Docs (the projects)
Are we talking here primarily about employee retention? Indeed something that is worth to be discussed in terms of how to achieve that, if there is an issue with keeping contributors on the longer term (is this the case?).
Concerning the issue of employee retention (if this is an issue), I disagree a bit with that. Clear affiliation is a thing that gives the people something back. A type of recognition for their work. If I understand you correctly, your point would make it not worth much to be a contributor here. However, this is a very shaky point. What do you think? Maybe it is worth to think how to independently from each other facilitate infrequent contributors but also the “proven contributors/responsible team” PBoy was talking about? I don’t know how much difference this makes in managing content. But keeping the team self-sustaining would indeed make it necessary to have a reliable “core” team.