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
I feel like : i dont know how guix project is organised, but are the goals of any roadmap fit with the goals or the needs of the users ?

There was recently a good article from ''Rust Library Team Chief'' on Framablog about this problem.

@lhp22 I found the article you mention: blog.m-ou.se/rust-is-not-a-com

Insightful! I like how it shows that formalizing teams can help guide contributors to the right group, “make space” for them.

It’s something that’s definitely missing in and that we could set up.

@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 That sounds like something which could work for many.

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

@be @emacsen @civodul Having a goal what to actually do can help with that.

@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!