Re: Formalizing teams

[indieterminacy@libre.brussels]

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 <jackhill@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