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

[Ricardo Wurmus <rekado@elephly.net>]

Liliana Marie Prikler <liliana.prikler@gmail.com> writes:

>> one fundamental issue with the email based workflow is that its
>> underlying data model simply does not formally encode enough
>> information to be able to implement a slick workflow and frontend.
>> e.g. with a PR based model the obsolete versions of a PR is hidden
>> until needed (rarely). the email based model is just a flat list of
>> messages that includes all the past mistakes, and the by now
>> irrelevant versions.
> What the?  If anything, emails are like a tree and discussions in most
> forges are a single long list that's rarely well organized.  Virtually
> every mail client supports threads, whereas a certain one of the more
> popular forges still refuses to do so.  Hiding obsolete versions of a
> pull request is in practice implemented either by pushing more commits
> on top of the existing one, often with dubious commit messages or by
> force-pushing a branch, neither of which is an acceptable solution for
> Guix.

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?)

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.

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.  It happens to be the one I’m used
to, but let’s please not pretend that it’s inherently *better* than the
other.

-- 
Ricardo


FWIW: Mumi is the worst of both worlds as it flattens the email tree
while not providing any of the review features that popular forges
have.  So the problem of outdated and repeated mistakes in a flat list
becomes more pronounced there.