Every Contribution Matters

GNOME is lucky to have a healthy mix of paid and volunteer contributors. Today’s post looks at how we can keep it that way.

I had some time free last summer and worked on something that crossed a number of project boundries. It was a fun experience. I also experienced how it feels to volunteer time on a merge request which gets ignored. That’s not a fun experience, it’s rather demotivating, and it got me thinking: how many people have had the same experience, and not come back?

I wrote a script with the Gitlab API to find open merge requests with no feedback, and I found a lot of them. I started to think we might have a problem.

GANGSTER CAT - Do we have a problem?

Code Reviews are Whose Job?

I’ve never seen a clear breakdown within GNOME of who is responsible for what. That’s understandable: we’re an open, community-powered project and things change fast. Even so, we have too much tribal knowledge and newcomers may arrive with expectations that don’t match reality.

Each component of GNOME lists one or more maintainers, In principle the maintainers review new contributions. Many GNOME maintainers volunteer their time, though. If they aren’t keeping up with review, nobody can force them to abandon their lives and spend more time reviewing patches, nor should they; so the solution to this problem can’t be “force maintainers to do X”.

Can we crowdsource a solution instead? Back in 2020 I proposed posting a weekly list of merge requests that need attention. There was a lot of positive feedback so I’ve continued doing this, and now mostly automated the process.

So far a handful of MRs have been merged as a result. The list is limited to MRs marked as “first contribution”, which happens when the submitter doesn’t have anything merged in the relevant project yet. So each success may have a high impact, and hopefully sends a signal that GNOME values your contributions!

Who can merge things, though?

Back to tribal knowledge, because now we have a new problem. If I’m not the maintainer of package X, can I review and merge patches? Should I?

If you are granted a GNOME account, you get ‘developer’ permission to the gitlab.gnome.org/GNOME group. This means you can commit and merge in every component, and this is deliberate:

The reason why we have a shared GNOME group, with the ability to review/merge changes in every GNOME project, is to encourage drive by reviews and contributions. It allows projects to continue improving without blocking on a single person.

— Emmanuele Bassi on GNOME Discourse

Those listed as module maintainers have extra permissions (you can see a comparison between Gitlab’s ‘developer’ and ‘maintainer’ roles here).

On many active projects the culture is that only a few people, usually the maintainers, actually review and merge changes. There are very good reasons for this. Those who regularly dedicate time to keeping the project going should have the final say on how it works, or their role becomes impossible.

Is this documented anywhere? It depends on the project. GTK is a good example, with a clear CONTRIBUTING.md file and list of CODEOWNERS too. GTK isn’t my focus here, though: it does have a (small) team of active maintainers, and patches from newcomers do get reviewed.

I’m more interested in smaller projects which may not have an active maintainer, nor a documented procedure for contributors. How do we stop patches being lost? How do you become a maintainer of an inactive project? More tribal knowledge, unfortunately.

Where do we go from here?

To recap, my goal is that new contributors feel welcome to GNOME, by having a timely response to their contributions. This may be as simple as a comment on the merge request saying “Thanks, I don’t quite know what to do with this.” It’s not ideal, but it’s a big step forwards for the newcomer who was, up til now, being ignored completely. In some cases, the request isn’t even in the right place — translation fixes go to a separate Gitlab project, for example — it’s easy to help in these cases. That’s more or less where we’re at with the weekly review-request posts.

We still need to figure out what to do with merge requests we get which look correct, but it’s not immediately obvious if they can be merged.

As a first step, I’ve created a table of project maintainers. The idea is to make it a little easier to find who to ask about a project:

Searchable table of project maintainers, at https://gnome-metrics.afuera.me.uk/maintainers.html

I have some more ideas for this initiative:

  • Require each project to add a CONTRIBUTING.md.
  • Agree a GNOME-wide process for when a project is considered “abandoned” — without alienating our many part-time, volunteer maintainers.
  • Show the world that it’s easy and fun to join the global diaspora of GNOME maintainers.

Can you think of anything else we could do to make sure that every contribution matters?

11 thoughts on “Every Contribution Matters

  1. Great post (as always)!

    Do you think it would be possible to add a “last non trivial commit” (it needs a better name) to your maintainers table? There are some applications where the “last commit code” is really recent but when you take a look at the history, it’s “only” (not that it does not matters), translation or small build fix commits. The last “real code change” commit is sometimes one or two years old. In other words, no one is really working on this project.

      1. Trivial is really not a good naming. It’s not the size of the commit that matters.
        I’m not able to find the link at the moment but I remember a discussion from aMR last year on a somewhat inactive project:
        the contributor of the MR basically said “I don’t understand why there is no review. The last commit was one week ago”.
        At some point, someone answered something like that: “it’s commits from the translation team. The last real commit is from two years ago. No one is really working on this project. So don’t be surprised if there is no review or no one willing to merge your change”.

        My point is that the “last commit date” is an interesting metric but it’s unfortunately not enough. Maybe, exclude the translation commits ? I’m not sure because translations are important and real work but they are usually not done by the maintainers or the main contributors of a project.
        Or add the day of the last release ? Even this is not a really good metric because a mature project does not necessarily need regular releases.

      2. Trivial is really not a good work.

        I remember a MR from last year (cannot find the link at the moment) without a review.
        The contributor said something like: “I don’t understand why no one is reviewing it. The last commit is from last week”.
        At some point someone replied: “It’s translation commits. The last ‘real’ commit is from two years ago. No one is really working on this project. So, don’t be surprised if no one is willing to review and merge your change.”

        My point is that unfortunately the “last commit date” is not a good enough date. Some ideas:
        – ignore all the translation commits to compute it?” I’m not even sure because translation commits are important work and it would seem like we discard the work of the translators
        – add a “last release” metric? I’m not even sure because mature project don’t necessarily need to make regular releases.

  2. Hmm, yeah maybe removing the ‘Last commit’ from the list would make sense. And last release date can also be a good metric, although sometimes the release team step in to release things that are otherwise unmaintained.

  3. Thanks for this initiative.

    As a seasonal contributor, it pains me how often I arrive too late to review a 1st contribution. And then if I get no response to the review (not rare at all) I wonder if the late review is at fault.

    One idea I’d like to put forward is something I’ve been doing already: encouraging new contributors to review MRs. Often after about 2 successful MRs, the new contributor already knows about some things to watch out for. A maintainer is still responsible for final review/approval.

  4. Maybe consider to automate annoying people sufficiently. For example a gitlab bot which repeatedly pings one of the correct people according to the required CODEOWNERS and someone less specific if that wasn’t successful.

  5. Several years ago I created “/Unmaintained” wiki pages under “Apps” and “Projects” on the GNOME wiki, it has now been moved here:
    https://wiki.gnome.org/Apps#Maintainers_needed

    I got inspiration from the GNU project (in a certain way GNOME still is/was a GNU project, so everything that applies to GNU can be applied, to a certain extent, to GNOME). If you look at:
    https://www.gnu.org/
    you can see the section “Can you help maintain a GNU package?”, which links to:
    https://www.gnu.org/server/takeaction.html#unmaint

    For GNOME, in any case, it’s better to ask previous maintainers of the specific module whether it’s OK to take over an unmaintained module. Sometimes a fork would be necessary, because the author of the code (1) doesn’t have the time or energy to still be the maintainer for that module (right now), and (2) may still be interested to maintain the code in the future (without the need to fork his/her own project!), and (3) the module works fine as it is for the author’s needs, and (4) it was maybe not the intention of the author to “donate” his/her project to GNOME, with anybody being able to take over the project when someone feels that it is abandoned.

    Also, sometimes it’s the seemingly “abandoned” projects that work the best, see:
    https://drewdevault.com/2021/01/04/A-culture-of-stability-and-reliability.html

    Of course, many of the high-level modules in GNOME rely on GTK, so there is an endless “need” for code maintenance/rewriting, to port to GTK 4, GTK 5, … like a Sisyphus’s job.

    1. Really useful link about the “apps in search of a maintainer”, thanks!

      I was actually tempted to link to Drew Devault’s post as a kind of opposite opinion. However, I realised the same that it applies more to CLI apps, than GUI apps. On the desktop, designs and user expectations and even hardware are still evolving fairly quickly, and so apps that aren’t actively maintained end up missing critical new features (UI scaling for hi-dpi monitors being a current example)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.