On lip 23, Tasos Alvas wrote:
As the project is facing the challenge of decentralizing
whole set of guidelines need to be made explicit so they can be discussed
and enforced without necessarily involving Maciej.
It might be tempting to have him document everything every time there's an
issue but there must be a better way!
I agree. I've seen multiple organizational structures in different open source
projects over the years... At various stages of DebOps development I tried to
set up some kind of formal organizational model, but now I think that it might
have been too soon for that - maybe it's best to wait and let the project
evolve organically. What I think is lacking is for me to be more open about
development and do design and conceptualization outside of my own head so that
the various processes are more visible to others. Maybe some writing lessons
are in order.
# Doc team. STYLE FORCE?
I propose a documentation team, as I think it's not only a good
responsibility to decentralize, but also a domain that could benefit from
a perspective that's not the code author's.
In broad strokes, the process I have in mind is like this:
* Doc team gets `/docs` in `CODEOWNERS`, either wholesale or in chunks
* Require a doc team member to close issues that add global functionality
(No need to block the PRs themselves)
* Leave the issue open and tag someone responsible if replies to an issue
should result in documentation
Sounds like an interesting approach. GitHub has a concept of Teams in an
organization, but I don't really want to vendor lock DebOps to GitHub; the
teams should probably be defined in a file somewhere. As I mentioned in the
other reply, most likely defining teams in the comment section of the
CODEOWNERS file and then assigning file paths to each member accordingly
should probably be the most portable way to achieve this.
This doesn't apply equally to roles, since their actual
codeowners will know
the internal workings better, but the doc team will still be in the position
to define and advocate for best practices. Obviously I'm not suggesting we
write people's role doc. :D
So the doc team turns answers into guidelines, helps people adhere to those
guidelines, identifies unclear points and iterates.
It might make sense to generalize the group's function to coding
well, since those issues are likely to benefit from the same process. I'm
not happy about bloating the group's responsibilities, but then it can be
called `STYLE FORCE!`. xD
I think that following such a convention would allow people to contribute to
the project earlier and stay involved until they're ready to handle harder
stuff. Even going from "I fixed some typos" to "I wrote an extra
Sounds good to me. Team description can be included in the CODEOWNERS file.
Anyway, that's my RFC. I'd rather not be the team alone;
I'm not even
remotely financially secure to be able to solo such a commitment. If we're
2 or 3 people I can see it working, though.
It's all voluntary anyway, so don't worry about it too much. When people see
that you are doing good work helping organize documentation and keeping it up
to date, they will either join you or will try to not get in your way. And
don't forget, there has to be at least one person for a party to happen. :-)