Hi Christopher,
Christopher Baines <m...@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’.
