[Top][All Lists]

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

Re: Formalizing teams

From: indieterminacy
Subject: Re: Formalizing teams
Date: Wed, 22 Dec 2021 17:22:34 +0100

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

reply via email to

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