Re: Formalizing teams

[Jack Hill <jackhill@jackhill.us>]

[-- Attachment #1: Type: text/plain, Size: 2534 bytes --]

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