From: indieterminacy@libre.brussels
To: Jack Hill <jackhill@jackhill.us>
Cc: guix-devel@gnu.org
Subject: Re: Formalizing teams
Date: Wed, 22 Dec 2021 17:22:34 +0100 [thread overview]
Message-ID: <87czlor4jb.fsf@qiuy04.i-did-not-set--mail-host-address--so-tickle-me> (raw)
In-Reply-To: <alpine.DEB.2.21.2112221101050.9433@marsh.hcoop.net>
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
next prev parent reply other threads:[~2021-12-22 16:29 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-12-22 15:46 Formalizing teams Ludovic Courtès
2021-12-22 16:04 ` Jack Hill
2021-12-22 16:22 ` indieterminacy [this message]
2021-12-22 19:43 ` Filip Łajszczak
2022-01-03 15:09 ` Ludovic Courtès
2021-12-27 5:17 ` Maxim Cournoyer
2021-12-28 10:52 ` Lars-Dominik Braun
2021-12-28 15:44 ` Kyle Meyer
2021-12-28 18:03 ` Ricardo Wurmus
2021-12-29 21:04 ` Lars-Dominik Braun
2021-12-28 14:44 ` Ricardo Wurmus
2021-12-29 9:05 ` Efraim Flashner
2022-01-03 15:22 ` Ludovic Courtès
2022-01-03 15:57 ` Ricardo Wurmus
2022-01-04 22:35 ` adriano
2022-03-31 21:15 ` david larsson
2022-04-01 9:14 ` Ludovic Courtès
-- strict thread matches above, loose matches on Subject: below --
2021-12-23 15:13 Blake Shaw
2021-12-23 21:51 ` Jonathan McHugh
2021-12-24 12:23 ` Hartmut Goebel
2021-12-24 15:37 ` indieterminacy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87czlor4jb.fsf@qiuy04.i-did-not-set--mail-host-address--so-tickle-me \
--to=indieterminacy@libre.brussels \
--cc=guix-devel@gnu.org \
--cc=jackhill@jackhill.us \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).