Its certainly worth developing more formal clusters. It would be wise to try and make concerns and research interconnected - lest we create silos that communicate with other groups less.
Jonathan McHugh Jack Hill <jackh...@jackhill.us> writes: > On Wed, 22 Dec 2021, Ludovic Courtès wrote: > >> 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’. > > +1 from me. I think that it is natural that as we grow (yay!) we'll > need a little bit more structure. It would be wise to not overdo it > and create too many teams to start with, but I have nevertheless > brainstormed some additional teams: > > * Documentation/Communication/Cookbook Recipes > * Desktop Environments > > Best, > Jack