Idea: weekly review of unloved merge requests

sthursfield · September 18, 2020, 4:35pm

I volunteer time to GNOME because I like the community. Sometimes I open an MR and it gets no response for a while, or never, and it makes contributing a bit less fun. I thought – are we losing contributors this way? Can we do something about it?

The root cause is – maintainers have limited time, GNOME has limited maintainers, etc. We can’t immediately buy more maintainers.

One idea I had is a weekly roundup of MRs that have been open a week or more, and haven’t had a friendly “Thanks for the patch, I’ll look at it when I have some time”. Wondering what this would look like in practice, I made a simple script. The output is below.

Let me know what you think of the idea! It wouldn’t be hard to turn this into a regular Friday forum post.

Further thoughts:

What should we do with these MRs? My idea would be – if it seems appropriate, sanity check the patch and say something like ‘Thanks for the contribution, I don’t maintain this module but it looks good to me.’ The goal is not to speed up review, nor put pressure on the module maintainer(s), but to make the contributor feel welcome rather than ignored.
GitLab has a ‘first_contribution’ flag for MR’s – perhaps we could prioritise these over MRs by established contributors. I didn’t do this yet.
The script lists any MR which has only 1 participant. GitLab somehow doesn’t consider reviewers to be participants in an MR – so fontchooser: add language filtering (!2551) · Merge requests · GNOME / gtk · GitLab should not be in this list, but is. I’m not sure if it’s a GitLab bug or feature.

Here’s the automatically generated list of merge requests! Let’s not comment on them yet, better to see what everyone thinks of this idea first.

Recent merge requests in need of attention

This list shows 10 merge requests which were opened a week or more ago but have not yet received feedback.

evince - Stop trusting phsyical dimensions from monitors (Alternative Fix for #1403)

Opened: Sep 10
Author: @MikeVastola
URL: Stop trusting phsyical dimensions from monitors (Alternative Fix for #1403) (!279) · Merge requests · GNOME / evince · GitLab

ebassi · September 18, 2020, 5:29pm

This would be great!

It would be worth looking into this, because many merge requests only have a single reviewer, especially for small projects.

crvi · September 18, 2020, 8:23pm

My suggestion would be to start with:

once in 2 weeks ( ~ twice a month ), rather than weekly.

serghei · September 19, 2020, 9:07am

Can we a have a special tag for such regular posts?

serghei · September 19, 2020, 9:13am

I’d like to see also in such posts:

Top 10 oldest MRs
Project with the highest number of total MRs
Project with the highest number of opened MRs at this week (two week)
Most discussed (comments) MRs of this week (two week)
Top 5 contributors this week (two week)

vanadiae · September 19, 2020, 12:06pm

I think it is totally out of scope for this idea. It isn’t about giving metrics on the MRs/issues/etc, but about giving new contributors the feel their MRs are not ignored.

crvi · September 19, 2020, 12:42pm

Sure. We can have both with 2 separate tags.

Thanks!

serghei · September 19, 2020, 12:44pm

IMO, if a maintainer for some reason doesn’t react on a merge request, it is unlikely that he will reply to it simply by seeing yet another reminder on the forum. Or do you think the maintainer is avoiding Gitlab but is visiting the forum? The target audience for such digests is people who don’t have rights to merge proposed patches. Otherwise, it is not entirely clear to me why this issue cannot be resolved through the appropriate setting of notifications.

sthursfield · September 19, 2020, 2:35pm

The goal is not to put extra pressure on already overworked maintainers. Quite the opposite.

GNOME has a responsibility to make volunteer contributors feel that their contributions are welcome – otherwise they will take their energy somewhere else. Maintainers already get notifications of new MRs, but maintainers can’t be continuously responsive and some GNOME projects lack fulltime maintainers altogether.

This is a good opportunity for everyone who is not a maintainer to volunteer a little time to review an MR and provide some feedback, even though they won’t be able to actually approve it.

sthursfield · September 19, 2020, 2:36pm

What would be the benefit of a 2-weekly review vs weekly?

crvi · September 19, 2020, 2:54pm

We want to balance information with the time resource every has. Having weekly e-mails / topics will have more chances of people ignoring them, as they can’t take information at that frequency. Everyone who is capable of providing any meaningful feedback for an MR probably is already busy.

So, a 2-weekly review would be a healthy balance of information vs attention one can actually pay to that information.

Thanks!

julian · September 22, 2020, 10:47am

You might want to filter WIP: and Draft: MRs.
I’d say it’s fine to ignore them until the tag is removed.

sthursfield · September 22, 2020, 2:39pm

I’s a good point, we can certainly prioritise them lower than other MRs in the list.

I think if someone opens a WIP merge request, it’s good to comment on it – sometimes I open a WIP MR to say “This isn’t ready, but I would like feedback to see if it’s going the right direction”.

julian · September 22, 2020, 3:02pm

Haven’t thought about this. Good point!

Anyways, this is a great initiative and I will definitely keep an eye on it

sthursfield · September 25, 2020, 12:01pm

I’ve gone with a weekly review for now as it’s easier for me to keep track. If it’s too much then I’ll think about how to schedule it every 2 weeks.

system · October 9, 2020, 12:16pm

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.

Idea: weekly review of unloved merge requests

Recent merge requests in need of attention

evince - Stop trusting phsyical dimensions from monitors (Alternative Fix for #1403)

rhythmbox - Remember column resizes

cheese - WIP: Detect x-h264 cameras

CITemplates - Do not remove build output before test build step

File Roller - Add info to appdata

gtk - fontchooser: add language filtering

gnome-mines - Use GAction more.

gnome-software - Resolve “Fails to finish pending install after going online”

gnome-software - Resolve “Codec install - oddities in “unable to find” message”

gnome-software - Resolve “InstallPackageNames exits immediately”