[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Formalizing teams
Re: Formalizing teams
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.
Jack Hill <firstname.lastname@example.org> 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”)
>> 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