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

[Andreas Enge <andreas@enge.fr>]

Hello Katherine,

thanks for your summary, which contains many points I would agree with and
actionable items (disclaimer: I do not promise to act on them).

Am Wed, Aug 30, 2023 at 10:11:02AM -0600 schrieb Katherine Cox-Buday:
> Here's my understanding of the process to contribute a patch:

My process is actually a bit easier...

>   5. Create a git worktree for your patch
>   6. Run `./bootstrap`, then `./configure --localstatedir=/var
> --sysconfdir=/etc`

You can drop 6 assuming you do not create a new .scm file.
Instead of 5, I usually just branch off from master, or simply work on
master itself (for instance, for a simple package update). In the latter
case, after creating and sending the patches, a
"git reset --hard origin/master" drops all my work.

>   8. Make your changes
>   9. Build to ensure your changes are workable.
>   10. Try and determine how your changes should be factored into individual
>       commits (sometimes it's not always so clear when changing two things
> might
>       need to be done atomically).
>   11. Try and get each commit message close to correct and commit.

Usually I start with 10, and then make the changes incrementally.
For instance, today I wanted to update a package and change an input.
I simply changed the input first, built and made a commit.
And then I updated the package, built and invoked ./etc/committer.scm.

Admittedly, I also do not do all the checks you mention, like closure
sizes or reproducibility of the builds.

Andreas