Re: How can we decrease the cognitive overhead for contributors?

[Felix Lechner]

Hi Katherine,

On Wed, Aug 23, 2023 at 9:27 AM Katherine Cox-Buday
<cox.katherine.e@gmail.com> wrote:
>
> I'm a Mom

Congratulations, and thanks for dedicating your life to someone else!

>      Savannah closed my account one or two days later due to inactivity.

That happened to me too, although it took a couple of weeks.

>      I can't ever seem to get the GNU style commit messages correct.

Neither can I. The style apparently helps with automated maintenance
of the changelog, but I do not understand why a changelog is useful
for a rolling release model.

No one uses Guix releases other than to install. Even then, we
encourage folks to run 'guix pull' at their earliest opportunity.

>      I don't use the email-based patch workflow day-to-day

Yeah, I can deal with small inline patches, but Guix requires changes
to be split into many tiny commits.

Such a series is then submitted with one message per commit. Then
people argue in between and submit multiple versions of the commit
series to the same bug. I think it requires a lot of practice to work
through that.

Some email clients, such as aerc, may help. I don't think people are
opposed to better tooling. We just don't have it yet. Mumi could be
part of the solution.

>      My script runs `guix style`

According to an authoritative source, hitting TAB on a marked region
in Emacs is actually the preferred way to format submissions.

>      "At every step of the contribution process, I must manually check that
>      multiple things are correct. With limited available executive
> functioning,
>      and no automation, this is very difficult to do correctly, and an
> easy place
>      for contributors to stop."

There is an easy medicine: Lose your worries, and don't be afraid!

Just send in what you have. For example, I ask my reviewers to adjust
commit messages to their liking.

> I have given a list of issues to a group of people who are presumably
> analytical, and I think the natural inclination is to go point-by-point
> and make
> arguments for/against. Instead of that[*], I invite you to address the more
> abstract issue: (should/how do) we reduce friction for making contributions?

Your broader perspective will probably generate a lot of discussion in
which people offer many valuable viewpoints, but it will yield no
resolution.

There is no central authority in Guix, yet people are afraid to step
out of line. In the end, everyone just conforms out of habit.

> * Contributing to Guix is not for you

Guix has a steep learning curve that is not necessarily limited to
contributions. The Guile syntax features, which are so popular in
Guix, can be difficult to understand even for people who know Scheme.
The file system layout, which is brilliant, also takes time to
understand.

> * It's OK to make lots of mistakes

That headline should be on all of Guix's web pages. Peopl focuss on
wayy to meny details in al technicl Forums.

> * We could support a managed web-based workflow

Mumi needs more love. Or, maybe we can co-opt Codeberg or Sourcehut.

> * Encourage upstream communities like "Guix 'R Us"

Every contributor should have their own channels for packages [1] and
for Guix. [2] Testing patches before they are submitted would vastly
improve the code quality in Guix.

Just fork my repos on Codeberg and use the 'prebuilt' branches. (Also,
please tell me when to advance them to more recent commits.) Here is
how you use them via Guix Home. [3]

> What do you all think? Does this affect anyone else?

For now, it's just you and I—unless others speak up. Thanks for your
helpful comments!

Kind regards
Felix

[1] https://codeberg.org/lechner/juix
[2] https://codeberg.org/lechner/guix
[3] 
https://codeberg.org/lechner/home-config/src/branch/history/service/channels.scm