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

[Liliana Marie Prikler]

Am Freitag, dem 08.09.2023 um 22:24 +0200 schrieb Ricardo Wurmus:
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> writes:
> 
> > > 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.
> 
> Look, I’m relating merely my work experience here as someone who
> regularly reviews pull requests on Github.  Github has buttons for
> “Rebase and merge”, “Squash and merge”, and “Create a merge commit”,
> so that part is automated.
> 
> I’m not saying that this is the workflow we should adopt.  I’m saying
> that these platforms — for better or worse — encourage *different*
> workflows, and for some this is what they are most comfortable with.
How many different workflows are those?  In my opinion, the one that
folks typically refer to when mentioning comfort is
1. git branch
2. git push elsewhere
[ long conversation using the forge's blessed UI ]
?. git merge
Fair enough, as a committer you get the option of cherry-picking,
rebasing, or whatever else instead of a merge, but the UI support for
those alternatives ranges from "okay, I guess" to "you know how to do
this by command line, don't you?" and "this change will be marked as
rejected even though you actually merged it".  Whenever you're using
these platforms, you are being nudged into its happy path, just as the
contribution via email model really makes it hard to just type "git
merge" and expect success – you do need git am at some point.

> Must we force a single workflow on everyone, even if our track record
> in reviewing and merging doesn’t clearly show that our way is
> superior?
Again, define superior.

> Recall that the reason for my response at this point in the thread is
> your statement:
> 
> > 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’m trying to convey that this workflow is similar to how we would
> push to wip-* branches and informally discuss open issues out of
> band.  (And even in that scenario, we are rather limited by the way
> our shared repository with all-or-nothing permission management
> works.)
I think this is a bit of an apples to oranges comparison.  Even for our
wip branches, we mostly adhere to the guidelines that govern master,
it's mostly the rule regarding breaking changes that is relaxed.  We
wouldn't have well-functioning wip branches if those forewent *all*
communication efforts.  The only common ground I can see is that all
feature branches – or at least those that don't die – get merged to the
main branch in either workflow.

Cheers