Hello Guix!
I’ve been looking at our guix-patches backlog, at the great
contributions we get but that stick there for too long, certainly
discouraging people, and also at non-code initiatives (meetups, Guix
Days, Outreachy, documentation, etc.) that we as a project could often
support and encourage better, wondering how we could improve.
I’ve been inspired by how the Rust folks approach these issues, in
particular as described here:
https://blog.m-ou.se/rust-is-not-a-company/
https://www.youtube.com/watch?v=T1t4zGJYUuY
(RacketCon 2019 talk by Aaron Turon)
One idea that I like is to bring structure to the group, or rather to
make structure visible, so that newcomers know who they can talk to to
get started on a topic, know who to ping for reviews, and so that each
one of us can see where they fit. Rust has well-defined teams:
https://www.rust-lang.org/governance
Guix is nowhere near the size of the Rust community (yet!), but I can
already picture teams and members:
co-maintainers (“core team”)
community
infrastructure
internationalization
security response
release
Rust packaging
R packaging
Java packaging
In Rust, teams are responsible for overseeing discussions and changes in
their area, but also ultimately for making decisions. I think that’s
pretty much the case with the informal teams that exist today in Guix,
but that responsibility could be made more explicit here. They
distinguish teams from “working groups”, where working groups work on
actually implementing what the team decided.
How about starting with a web page listing these teams, their work,
their members, and ways to contact them? Teams would be the primary
contact point and for things that fall into their area and would be
responsible for channeling proposals and advancing issues in their area.
What do people think?
Aaron Turon nicely explains that at first sight it has a bureaucratic
feel to it, but that in practice it does help a lot in many ways, from
onboarding to channeling change without losing consistency.
Ludo’.