Re: Starting a Quality Assurance Meeting/Team/Sociocracy circle

["Ludovic Courtès" <ludo@gnu.org>]

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’.