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

[Liliana Marie Prikler]

Hi kiasoc5, hi Attila

Am Samstag, dem 26.08.2023 um 19:42 +0200 schrieb kiasoc5@disroot.org:
> On 2023-08-25 11:31, Attila Lendvai wrote:
> > > I feel like the advantages of a email-based workflow nowadays is
> > > more on the maintainer side of things (as managing large projects
> > > is easier
> > 
> > 
> > another thing worth pointing out here is that the harder it is to
> > test a submitted patchset locally, the fewer non-committer reviews
> > will happen.
> > 
> > and if all the review work rests on the shoulders of the
> > committers, then there'll be long response times on submissions, or
> > straight out forgotten/ignored submissions (khm). especially if
> > it's about some hw or some sw that none of the committers care
> > about, or could test locally (e.g. Trezor support:
> > https://issues.guix.gnu.org/65037 that 
> > doesn't even build in master).
Do you mean that Trezor doesn't currently build on master or that this
series doesn't build relative to master any longer?  It'd be quite
weird if it was the latter, but oh well.  I'll review the series
afterwards.

> I would like to hear from committers if non-committer reviews are 
> helpful, because I don't really know how or what I can comment on for
> incoming patches on packages I'm not really familiar with.
If you're not familiar with the package, on which grounds would you
review the patch?  This holds for committers and non-committers all the
same; it's a main reason as to why I don't review many Emacs packages
despite being in the Emacs team.  My init.el is on the smaller side and
only exercises a small portion of the emacs-xyz module.

On the other hand, if you do have relevant information to add, please
do so.  For instance, if you know about the hardware or the software or
even if you've only heard about some anti-feature such as telemetry,
such information is valuable.  If you want to nerd about the way we
write ChangeLogs, that's also fine, and might save someone else the
need to do so (or encourage them to do so as well, you win some, you
lose some).

> Also do "this builds and works locally" comments help?
"Builds locally" not so much, unless it's a package that CI doesn't
handle usually.  "Works locally" should be qualified to distinguish it
from simply "builds locally", but if you say something along the lines
of "I've tested and ran the program; it works as I'd expect", you might
be saving a committer some time and allow them to focus on other
things.  If there are no cosmetic flaws and the committers are aware
that the package works fine for more than just a single person, they
can fast track it more easily.  OTOH, if you write "works locally" and
no committer reads it – for any reason, really – the result will be the
same as if you never wrote it.

TL;DR: "Builds locally" helps maybe, but probably not.
"Works locally" probably helps, but sometimes not.

For cases in which "works locally" doesn't seem to help, you sadly have
to check the CCs and add a committer who might look like they'd be
interested in upstreaming the series :(

Cheers