From: "Ludovic Courtès" <ludo@gnu.org>
To: Christopher Baines <mail@cbaines.net>
Cc: guix-devel@gnu.org
Subject: Re: Starting a Quality Assurance Meeting/Team/Sociocracy circle
Date: Thu, 27 Jun 2024 15:03:16 +0200 [thread overview]
Message-ID: <87cyo27d2j.fsf@gnu.org> (raw)
In-Reply-To: <87bk3x3qe5.fsf@cbaines.net> (Christopher Baines's message of "Wed, 19 Jun 2024 16:26:26 +0100")
Hi Christopher,
Christopher Baines <mail@cbaines.net> skribis:
> Following on from the governance discussion at the Guix Days earlier
> this year, I'm not sure what progress has been made.
None, I’m afraid, so what you propose is a great step in that direction.
OTOH, teams are picking up steam, and AIUI, the missing steps to turn
teams into circles (in the Sociocracy sense) are well identified:
• recognizing their autonomy and agency when it comes to making
decisions in their area;
• having a “hierarchy” of teams/circles (where hierarchy refers to the
scope of each circle and not to the authority of one circle over
another one) with representative of each circle in the “higher”
circle;
• where appropriate, nominating people within circles to specific
roles and responsibilities.
I really discovered Sociocracy when we discussed it at the Guix Days so
I’m totally a newbie, but that seems to match what
<https://en.wikipedia.org/wiki/Sociocracy#Essential_principles> says.
From our discussions, I believe Sociocracy is designed primarily for
in-person interaction, where people can actually sit in circle and
ensure, with a baton, that everyone in the circle gets to express their
view. We’ll have to emulate that in an asynchronous and on-line space.
> I'd still like to get the QA stuff in to a more sustainable state,
> whether that means shutting things down or moving the services to be run
> by the project/Guix Foundation and getting more people involved.
+1
> I know nothing about Sociocracy, but I did like what I heard about it at
> the Guix Days, so I want to at least work out what a minimally viable
> circle around this would look like, and whether there's support for
> setting one up.
>
> I think the domain of responsibility would include:
>
> - Making changes to Guix
> - Patches and patch review
> - Merging branches
> - "Supported" architectures
> - Processes, services and tooling related to patches and branches
> - qa.guix.gnu.org
> - data.qa.guix.gnu.org
> - The bit of bordeaux.guix.gnu.org that builds patches and branches
> - The bit of ci.guix.gnu.org that's used for branches
> - The "Managing Patches and Branches" docs
> - https://guix.gnu.org/manual/devel/en/html_node/Managing-Patches-and-Branches.html
> - Tracking bugs/issues
> - issues.guix.gnu.org
> - debbugs.guix.gnu.org
> - Guix System tests
Verbs are missing to some of the above: “Defining” supported
architectures? “Defining” processes, “maintaining” services and tooling?
“Monitoring” system tests?
It seems quite broad to me at first sight, but probably that’s just a
matter of clarifying what goes into each bullet point. Overall that
looks great to me.
It’s much needed if we are to strengthen our QA infra and processes.
> Given there aren't any other explicit circles, I'm not quite sure what
> to do here. I think it would be good if one of the maintainers
> volunteered to be a member, and I think it would also be good to have a
> member from the Guix Foundation SAC (which I am). I'm also not sure what
> the ideal size is, but it's probably not two people so I think there's a
> need for at least one or two additional people to volunteer to be
> initial members.
I would expect maintainers to be the “top circle”, in that it oversees
the entire project, so with one representative of each circle in the
other one (“double linking”).
> The final thing is to have some regular meeting, ideally a less than 30
> minute voice or video call every month, which would be about discussing
> and making decisions on things in this area. If no one else wants to
> organise this bit, I can commit to organising the meetings initially.
That would probably be very helpful.
Personally I prefer not to commit for the moment (I feel overwhelmed and
am trying to figure out where I can be useful and where I’m not needed),
but I might join eventually.
Thanks for this initiative!
Ludo’.
prev parent reply other threads:[~2024-06-27 13:04 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 15:26 Starting a Quality Assurance Meeting/Team/Sociocracy circle Christopher Baines
2024-06-20 20:35 ` Andreas Enge
2024-06-21 5:01 ` Felix Lechner via Development of GNU Guix and the GNU System distribution.
2024-06-27 13:03 ` Ludovic Courtès [this message]
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=87cyo27d2j.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=mail@cbaines.net \
/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).