Follow

Submissions to guix-patches keep increasing, but the rate at which they’re closed doesn’t quite keep up:
debbugs.gnu.org/rrd/guix-patch (see “All bugs ever opened”)

How do projects encourage committers to review? Any insight to share?

thread: lists.gnu.org/archive/html/gui

(HT to zimoun)

@civodul I have no magic solutions, just saying the problem is hard. It's especially hard when people explicitly refuse to agree to a roadmap.

@civodul The only direct help I know is to delegate to the CI as much as possible.

Having some feeling of friendship or kinship helps. It’s not just a common goal, it’s a group of people who like each other and feel that the review helps the others, too.

Other than that, and rather experimental: Aligning messaging to the core drivers of as many people as possible: 1w6.org/english/tables#org4edf

If you feel that reviewing supports something that gives you strength, that helps to become stronger.

@ArneBab @civodul

I know the guix community is small, but what about an event, like a "Bug-A-Thon" where you all collectively get together and squash bugs, and maybe use that time to help do some bug motioning and other changes that would help the situation longer term.

@emacsen @civodul (even when many are 5 — that’s already a lot of potential to get moving).

@ArneBab @civodul

In OSM-world we used to have OSM meetups in London. I went to London a few times and hacked on various things. It was fun and we got a lot done.

I did the same once in that town in Germany named after the map projection... ;)

@civodul One thing I also see is that it helps to have a web-based tool to flag something as ready to merge. That’s what I actually use on GitHub when I have a few minutes to review something: Read the diff, add tag ReadyForMerge.

@civodul That can especially help for small patches like this openjdk patch: issues.guix.gnu.org/51443 / debbugs.gnu.org/cgi/bugreport.

What I’m missing here:
- CI information (do all packages still build? Is the coding style OK? — that could already be automatic feedback by email)
- if with patch: latest diff
- link to the issues-link in the acknowledgement email (the one to debbugs is in there) to make it easier to ask a friend for review
- button to mark a patch as ready for merge (with login).

@civodul
Would be interesting to know why people are not reviewing. Anyhow, asking those who are not here is an issue :-/

Speaking for myself: I unsubcribed guix-pathes long ago, since there have been to many pathes and discussions - and in the mail-based workflow issues keep open/unread (in my inbox) even if done. Using debuts in emacs I never got familiar with.

Maybe(!) mail-based workflow is what hinders people. Welcome to the old discussion about tooling. Not even sure, tooling will help.

@kirschwipfel @civodul I think tooling is major, I think providing tools to reviewers to quickly address reviews at a glance (UI/UX!!) certainly motivates reviews. You feel discouraged when you know something could be automated and you do it lots of time everyday. When I was still contributing to the project I tried raising that argument of tooling to motivate reviews, I think everyone is kind of burnt out so it's easy to raise that point but difficult to solve

@kirschwipfel I think it’s a problem for a committer to not be on guix-patches since that leaves the reviewing burden on others.

I understand that email-based workflows is a hindrance to some, just like web-based workflows are a hindrance to others.

In terms of tooling, issues.guix.gnu.org was developed to help those who prefer a web interface. Perhaps a starting point?

Sign in to participate in the conversation
Mastodon (Aquilepouet)

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!