Five Years as a Drupal Core Subsystem Maintainer, a Retrospective.

Drupal is written by volunteers and by employees of companies who sponsor them. Writing code is usually the main way to contribute to open source, but reviewing others’ code is important as well.

I’m one of the ones who reviews others’ code, after five years of doing this I would like to reflect on the exercise of being a maintainer.

How it started

I started working with Drupal around June of 2007. After ten years of learning and contributing to random projects and modules, I decided to try something new. So I searched for some projects in the MAINTAINERS.txt file without anyone in charge, and started doing issue triage.

I picked dblog at first, a simple module easy to understand. Nobody was actively maintaining it after the Drupal 8 development started.

As a software developer, one big lesson open source gives you is, complex software needs managers. So that was what I did, I left my programmer hat aside and started doing triage of existing issues.

• Issues with patches state Active, change status to Need Review.

• Issues marked as Needs Review that require changes, mentioned by someone from the community, set as Needs Work.

• Nothing else required, patch looks good? Try the patch locally and if it works, move it to Reviewed and Tested by the Community.

• If an issue is already reported somewhere else, close it as a Duplicate.

• At the same time, since I had some experience working with views in the past, I contributed to using a view to list log entries.

Eventually, after six months of doing this I applied to be a formal maintainer of the dblog module. The community agreed, and I became a formal subsystem maintainer.

What I do

Managing a core module requires keeping an eye on the issue queue. I have some specific advanced search filters that I check at least two times per week.

My main goal is not to have Ready For Review issues waiting for more than one week. I also try to give assistance on new Feature Requests, but deliberately try not to code them so I can review it later.

Since I check the code of dblog quite often, I also create Novice bug reports that new developers can use to start their contribution journey.

In my opinion, one of the most interesting parts of this role is doing some code archaeology. Take for example this issue

The original solution proposed to solve this bug was to prefix the classes of the watchdog views table because they are colliding with other classes of themes. I saw the bug report, it made sense at first glance, and indeed was something inconsistent with the non views UI of the dblog module. But then I started digging why this class was there in the first place.

After some git work, switching branches way back to D7, then D8, I concluded those classes were not used for 9 years! Hence we can remove them.

So, I rewrote the issue summary so others know what to do, and moved the issue to Needs Work.

As Drupal evolves, sometimes it is not easy to just remove code, you need to update the current configuration of existing sites. And you need tests. No issue should be fixed without touching or adding new tests.

Once some other contributors fixed the issue, I did a final review and left the ticket ready to be committed by the core maintainers.

Benefits

Now you have a better idea of what I do, let me reflect on the benefits of doing this.

• You learn a lot. I don’t have all the knowledge in my head, and reading others’ points of view always helps to understand the problem and existing APIs.

• You have the chance to interact with other members of the community. Take the issue mentioned above. Devs from Russia, Canada, New Zealand, Italy, United Kingdom and Argentina collaborated to fix a small bug.

• You keep up to date with what is going on in the rest of the Drupal ecosystem. Sometimes running git log --oneline core/modules/dblog/ gives me an idea of what’s going on elsewhere in core.

• You get a great user profile. I remember my first interview with Amitai saying, “look Mariano, I know you know Drupal, so we will not speak about that”.

Pain points

Not all is beautiful in this role. Sometimes you have more issues than you can handle. Sometimes nobody contributes to fix bugs and they sit there forever. Sometimes you think you did everything ok, but then someone else, usually someone smarter than me, marks a trivial error in your review that requires more work from the original contributor. This often frustrates me because I could have done a better job to reduce the friction and keep devs motivated to fix the problem. But at the same time, I learn a lot.

Also, sometimes nobody reviews your code. Because you are the one who should review it. Take for example the effort to convert db logs entries into entities. This would fix so many long open issues, but it has been there for two months and no real reviews. As a maintainer you must learn to live with that and understand that your issue is one of the 23K currently open issues. Patience is the key.

The bus factor in my case is not ideal either, there is nobody else to discuss architectural decisions specifically for the modules I maintain. Of course there are a ton of capable devs that contribute to core, but there are also a lot of issues out there. This is not the case in other modules like Jsonapi, Layout Builder, or Migrate where you see a team maintaining the subsystem.

Looking back

In retrospect, the last five years have been a great way to learn for me. I had some big milestones during this time, like having cleaned at least for some months all the issues of the syslog module issue queue, which I also maintain.

I have the luck of being supported by Gizra to do this. But I have contributed a lot of my free time as well to this task.

If you are in the same situation as me, or simply think you are a good fit for this task, go ahead and search for orphan modules in core. You know what it takes, the pains but also the benefits. Good luck!