Submissions to guix-patches keep increasing, but the rate at which they’re closed doesn’t quite keep up:
https://debbugs.gnu.org/rrd/guix-patches.html (see “All bugs ever opened”)
How do #FreeSoftware projects encourage committers to review? Any insight to share?
(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.
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.
Here in french for those who would be interested.
@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: https://www.1w6.org/english/tables#org4edffdc
If you feel that reviewing supports something that gives you strength, that helps to become stronger.
@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: https://issues.guix.gnu.org/51443 / https://debbugs.gnu.org/cgi/bugreport.cgi?bug=51443
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).
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, https://issues.guix.gnu.org was developed to help those who prefer a web interface. Perhaps a starting point?
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!