One of the things that was confusing to me and felt weirdly undocumented in the Nix project was “how to become an official maintainer” (of a package, module, or whatever). I remember digging through various github comments, then discourse topics where people asked this, and then finding that the answer was “you send a PR adding your name to a file”. (The further mechanics around it require reading source code and understanding github mechanics apparently? I was very confused and basically bounced off that entire process.)
I’d love for aux to have really good and up-to-date documentation for how to become a contributor: what the expectations and responsibilities are, as well as how to become one and how to stop being one; what being in the github org means, what commit bits mean and how to get them (do we expect to use some CODEOWNERS-like mechanism?), etc etc.
So - what roles do we expect contributors to have in the Aux projects? How should those roles be assigned (mechanically and trust-wise)?
The Steering Committe will probably have more concrete (and potentially more accurate) things to say on the matter, but here’s the overall summary as I understand it:
There’s two main types of governing body (at the moment) - Committees and Special Interest Groups (SIGs).
Committees are the overall drivers, working on plans and guiding direction for different parts of the project. For example, we have the Steering Committee in charge of guiding overall project direction and purpose, the Security Committee focusing on strategies for keeping the project up to date with vulnerabilities and security disclosures, and the Infrastructure Committee designing and operating the various supporting services to run the project. At the moment, the Committee members are made up of mostly whoever volunteers to be a part of them, however this could change in future.
Special Interest Groups (SIGs) are more akin to code maintainers - these are the groups that own and maintain particular parts of code, documentation, or other various deliverables. Examples include the Javascript SIG owning the maintenance of the Javascript support, the Core SIG working on the base infrastructure, libraries and packages that make up our Nixpkgs equivalent, and the Documentation SIG that write the docs to support the overall project (note that there is some discussion at the moment around this one potentially becoming a committee). Where Committees plan and decide direction, SIGs execute on them. Like Committees, they are composed of volunteers right now, but that may also change.
There is a third type of body that we are yet to see but will probably start to crop up once we become more established - the Working Group. As I understand it, the intention of these is to be cross-SIG groups that temporarily form to tackle a project that crosses the boundaries of multiple SIGs. For example, let’s say a theoretical “Home Manager SIG” and the GNOME SIG wanted to work together to create some tooling in a Home Manager-like system to assist in some elements on GNOME support - a Working Group would form from members of both SIGs to work on that project, and then dissolve once their goals are achieved.
Much of this is inspired by the Kubernetes community structure, and their documentation is a good reference for understanding the general ideas that will guide governance here. The Steering Committee is open to making alterations to make it more suitable to our project, but as I understand it, Kubernetes is effectively the “template” guiding the base of our structures.
In terms of joining one of these groups, most of them (besides the Steering Committee) are basically just accepting whoever wants to volunteer for them, so we can bootstrap ourselves without getting bogged down in slow, procedural decisions. Once we get more established, I believe the idea is to make a more democratic nomination/voting process for joining and leading SIGs and Committees, but those are details that we’re largely yet to hash out - it’s still early days, and we aren’t seeing a pressing need to get that sorted out yet.
I definitely agree that this should be all be documented somewhere, and that’s probably something for the Documentation SIG/Committee to think about (cc @minion, @coded). For now, this is probably about as good as an overview as I can give, as someone not on the Steering Committee (my work at the moment is focused on the Javascript and Core SIGs) - @jakehamilton and @isabel may have better insights to give.
@srxl did a really good summary but just to add a little about how we are keeping track of our maintainers and such. At the current moment we have GitHub - auxolotl/community. But the plans for go a lot bigger hopefully to also contain a lot of meta information about our community.
This is a really good answer, and it clears up a lot about the current state of the world for me. Thank you!
I’m hopeful that the project will keep its structure accessible to people and that it’ll remain easy to become an effective contributor at whatever level one can sustain!