GNU bug report logs - #76503
[GCD] Migrating repositories, issues, and patches to Codeberg

Previous Next

Full log

Message #281 received at 76503 <at> debbugs.gnu.org (full text, mbox):

From: Konrad Hinsen <konrad.hinsen <at> fastmail.net>
To: 76503 <at> debbugs.gnu.org
Subject: [GCD] Migrating repositories, issues, and patches to Codeberg
Date: Sun, 09 Mar 2025 09:44:55 +0100

Hi everyone,

A few high-level comments, to prevent us from getting lost in technical
details.

Quoting the summary of the GCD:

   The contribution workflow in Guix has been facing several challenges:
   difficult onboarding, lack of legibility, complex, unreliable, and
   labor-intensive infrastructure, and lack of automation.  All these lead
   to an experience that contributors often find frustrating and hinders
   quality assurance efforts.

Onboarding: this means new community members, and it suggests, though
not explicitly saying it, growth. Is growth what we want? Or merely
replacement of people leaving or reducing their efforts? If we want
growth, how quickly and up to where? Do we want to operate like the
Linux kernel (recently cited here), in that most contributors are
employees of tech companies? If not, what is the profile of contributors
that we wish to attract? Which others are we willing to give up on in
exchange? (I am thinking of those who are not willing to create a
Codeberg account, for example.)

Is onboarding only about recruiting new community members, or also about
mentoring newcomers on their path from users to contributors to
reviewers and maintainers? I suppose it is. Then which step is the
bottleneck? My impression from this discussion: from contributor to
reviewer. Which is why I personally favor this proposal, because I see
the current workflow as most cumbersome for code reviewing.

Lack of legibility, complex, unreliable, and labor-intensive
infrastructure: these are more technical motivations. It's the current
maintainers that are most exposed to these issues. Not me, so I won't
comment, other than highlighting that we should listen to the current
and past maintainers.

Lack of automation: I haven't seen much discussion about this aspect so
far. Automating what, for who? Who needs to be able to control and
fine-tune automation? Who needs to understand what's happening?
At what stages in onboarding does this matter?

Cheers,
  Konrad.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.