[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Formalizing teams

From: Jack Hill
Subject: Re: Formalizing teams
Date: Wed, 22 Dec 2021 11:04:44 -0500 (EST)
User-agent: Alpine 2.21 (DEB 202 2017-01-01)

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:
   (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:

Guix is nowhere near the size of the Rust community (yet!), but I can
already picture teams and members:

 co-maintainers (“core team”)
 security response
 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.


+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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]