Hi Ludo! and thanks for the clarifying remarks!
On Wed, Feb 04, 2026 at 04:41:34PM +0100, Ludovic Courtès wrote: > The “maintainers” role was defined back in the day: > > https://guix.gnu.org/en/blog/2019/gnu-guix-maintainer-collective-expands/ > > (In practice it’s probably too broad now that the project has grown and > could be usefully split into several: moderation team, event and > promotion, facilitation, etc. But that’s probably a topic for another > time!) I don't think the definition per se is too broad, especially since 3. should now be obsolete (with the GCD process in place). But if you (maintainers) suffer under too heavy work load then we definitively should split some of the work to new teams. > The primary responsibility of committers is to “enact technical > decisions”: > > https://guix.gnu.org/manual/devel/en/html_node/Commit-Access.html I think much of the wording in that section is somewhat unfortunate and not especially enabling growth of the project. Especially now where team-members and other users are encouraged to review, but committers are still supposed to double check approved changes, plus signing and pushing them. Maybe we need to somewhat formalize how teams tend their own branches and only signal to committers when a merge is due? Shifting the responsibility more into the teams and leaving committers with the power to merge, push and fix-on-master type changes? > The primary responsibility of teams (and thus team members) is peer > review: > > https://guix.gnu.org/manual/devel/en/html_node/Teams.html I think this is where we should make the most drastic change in role definition. From the project's perspective, I'd suggest that we define TEAMS to be where interested people and experts work specific issues of our project. Not just hacking, packaging, PRs and committing, but (not limited to) web/infra admin, security, propaganda (public relations), fund raising, future outlook, newbie onboarding, organisation of social events, abuse prevention and other things necessary...? Maybe we could generalize the phrasing first, to specify it later: > In the Guix Project, Teams are groups of people interested in specific > aspects of the project. Since Guix is a software project, many teams > are dedicated to areas of the source code (especially packaging), but > that is not all that is necessary for a big and continuously growing > endeavor like GNU Guix. Then, we specify what we as Guix Project expect from teams: > Teams are reachable from within and outside of the Guix Project, are > considered the experts in their areas and are to be contacted for > changes relating to their fields. WDYallT?
