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’.
