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

[Liliana Marie Prikler <liliana.prikler@gmail.com>]

Hi,

Am Freitag, dem 08.09.2023 um 16:44 +0200 schrieb Ricardo Wurmus:
> I often have to review Github Pull Requests, and I don’t go commit by
> commit by go through the diff and annotate the changes.  I *read* the
> commits to get a sense for how the feature evolved and why changes
> were made, but the fact that new commits are pushed on top of the
> branch is not an obstacle in practice, because the commits don’t
> matter.
> 
> (I know, it hurts me too, but I don’t make the rules, okay?)
Well, thanks to Guix inventing the time machine, individual commits do
matter to us.

> And in these review interfaces we can mark individual comments as
> resolved.  So the flat list of changes with annotations *does* in
> fact provide a clearer organization than a tree of emails.
> 
> Note also that we don’t usually review commits by starting one new
> thread for each issue we address, so we don’t benefit from automatic
> branching of sub-discussions.
To be fair, the summarizing of changes followed by comments to
individual bits are a point that the forges at least get right. 
However, unless you rework a single line multiple times – which
admittedly happens more often in the "push the change on top" model of
the forges than in the "condense your changes to logical units" model
we use – a branching discussion per commit still comes quite close in
practice.  Also, when there are multiple reviewers notice different
things, you also get the branching tree.

> On Github, Pull Request branches are like our WIP branches.  They are
> how we arrive at acceptable changes.  Picky people like me would then
> go back and write new atomic commits for the effective diff, but in
> my role as a reviewer I usually rebase, squash, and merge.
> 
> This workflow is more familiar to some and alienating to others, but
> both of these workflows would work fine for Guix.  But today our
> tools can only accommodate *one* workflow.  
I'd imagine that rebase, squash and merge would exacerbate the workload
on the committer side and I think that most popular projects on those
forges already experience similar effects to us despite folks just
merging the requests as-is and in part even getting paid by big tech
for doing so.  (Perhaps I exaggerate at getting paid for processing
merge requests, I haven't worked for any of these companies, but
especially at the ones more oriented towards doing business, I'd
imagine that you can at least buy yourself a sandwich from the work you
do from time to time.)

> It happens to be the one I’m used to, but let’s please not pretend
> that it’s inherently *better* than the other.
I mean, when we say better, we would have to refer to some metric of
goodness.  And the metric I personally choose is somewhere in the
intersection of accessibility and interoperability, because that is
what matters to me.  With Github, Gitlab and whatever other forges you
have, you are more or less bound to their web interface.  If that works
for you, it works.  If it doesn't, it doesn't.  With the email-based
workflow, I can use whichever tools I am comfortable with, as long as
they work for sending mail (as a contributor) or eventually invoke `git
push' on a bunch of signed-off commits (as a committer).  This both
increases the chances of things working and gives me the tools to build
things that work for myself (and potentially others as well).

Cheers