The Hidden Cost of Volunteering: Reflections on Contributing to Drupal Core
I have worked with Drupal for many years and have contributed to several projects, including Drupal Console and Drush. Recently, I decided to spend some of my free time contributing small improvements to Drupal core.
My intention was deliberately modest. I was not proposing a new subsystem, a major architectural change, or an ambitious refactoring. I selected narrowly scoped issues: the kind of tasks commonly described as “low-hanging fruit”.
The experience has made me reflect on what “small” really means in a mature open-source project.
The patch may be small, but the contribution is not
A one-line documentation correction may require only a few minutes of actual implementation. However, the complete contribution can involve considerably more work:
- Understanding the history and precise scope of the issue.
- Finding the correct files and current development branch.
- Creating and publishing a working branch.
- Preparing a merge request using the expected format.
- Updating both the Drupal.org issue and the GitLab merge request.
- Understanding issue statuses, assignments and contribution credits.
- Monitoring pipelines and distinguishing relevant failures from unrelated ones.
- Responding to feedback and updating the implementation.
- Watching the branch become progressively older while waiting for review.
- Rebasing and repeating automated checks if enough time passes.
None of these requirements is unreasonable in isolation. Drupal core needs strong quality controls, and reviewers need submissions that are clear, tested and maintainable. The difficulty lies in their cumulative effect.
For a volunteer, a technically trivial contribution can acquire a surprisingly large administrative and cognitive cost.
Review availability is the real bottleneck
Drupal’s documentation encourages new contributors to start with small issues. This is sensible advice, but it leaves out an important consideration: the size of a patch does not necessarily correlate with the time needed to complete its lifecycle.
One of my recent contributions, issue #3628393, changes a single PHPDoc comment. The corresponding merge request was ready to merge and had no conflicts, but remained without human review.
This creates an uncomfortable form of uncertainty. The code may be correct and the merge request may be green, but the contributor does not know whether it will be reviewed tomorrow, next month or at all.
Meanwhile, the target branch continues to move. Eventually, an otherwise valid contribution may require a rebase and another pipeline. If that pipeline encounters unrelated or intermittent failures, the contributor must investigate them before knowing whether any further action is genuinely required.
A green pipeline does not become red merely because time passes. Nevertheless, the longer an unreviewed contribution remains open, the greater the probability that maintaining it will require additional work.
Drupal already recognises this problem through the Needs Review Queue Initiative. The existence of that initiative is itself evidence that producing patches is not always the main constraint. Review capacity and committer attention are scarce resources.
Automated testing does not always provide a clear answer
Continuous integration is essential, particularly in a project as large and widely deployed as Drupal. However, its value to contributors depends on whether failures can be interpreted reliably.
A very small documentation-only change may encounter a pipeline containing numerous failures from large test suites. Some may be recurring failures unrelated to the merge request. From the contributor’s perspective, the result is still red, and determining whether the submission is responsible can require more time than producing the change itself.
It would be helpful if the interface distinguished more clearly between:
- Failures introduced by the current merge request.
- Failures already present on the target branch.
- Known intermittent failures.
- Infrastructure failures.
- A genuinely outdated or conflicting branch.
Experienced core contributors may understand these distinctions immediately. Occasional contributors often do not, and uncertainty creates additional work for both contributors and maintainers.
Drupal.org and GitLab form a fragmented workflow
Contributing to Drupal core requires navigating two connected but distinct systems.
Drupal.org contains the issue, its status, assignment, credits and main discussion. GitLab contains the branch, commits, merge request, diff and pipeline. Changes made in one system do not always make it obvious what must be updated in the other.
Even small questions can interrupt the work:
- Should I assign the issue to myself while working on it?
- Should I leave it assigned after moving it to “Needs review”?
- Does editing a file in GitLab’s web editor save it automatically?
- Should separate file edits become separate commits?
- Does the merge request description also need updating?
- Is being several commits behind the target branch a problem?
- Should I rebase now or wait until somebody requests it?
- Should I post a reminder, or would that be considered noise?
Each question has an answer, but finding it requires knowledge that is not directly related to fixing Drupal.
Feedback is valuable, but timing matters
In another recent contribution, issue #3629274, a reviewer identified that a dedicated key/value collection should be used instead of the general state collection.
This was useful technical feedback. I updated the implementation, adjusted the tests and obtained a successful pipeline.
However, this illustrates why early review is important. A short architectural observation made near the beginning can prevent unnecessary implementation and testing. When feedback arrives late, even a small correction can require reopening the development environment, reconstructing the context, modifying several files and restarting the validation cycle.
The burden is not only measured in minutes. Context switching has a real cost, particularly for volunteers contributing outside their normal working hours.
AI transparency introduces another area of uncertainty
English is not my native language, and Drupal core issues can contain long and technically subtle discussions. I sometimes use AI as a supporting tool to verify that I have understood a problem correctly and to help express my reasoning clearly in English.
I do not use it as a substitute for technical judgement. I review the changes, follow the discussion, respond to reviewers and accept responsibility for everything I submit.
Drupal’s AI policy reasonably requires contributors to understand, verify and take responsibility for AI-assisted work. It also requires disclosure when AI generates a significant amount of submitted code or text.
However, transparent disclosure can itself lead to uncertainty if it is immediately treated as a possible policy violation without identifying the specific concern. A contributor attempting to comply with the policy may feel that disclosure has created suspicion rather than trust.
This is particularly relevant to contributors whose first language is not English. There is an important distinction between:
- Automatically generating unreviewed technical contributions.
- Using a tool to avoid linguistic misunderstandings.
- Asking a tool to challenge or corroborate one’s interpretation.
- Using grammar or translation assistance.
- Generating substantial code without understanding it.
Clearer guidance on these distinctions would encourage responsible transparency without discouraging contributors who use language assistance.
Possible improvements
I do not think the solution is to weaken Drupal’s review standards. Those standards are one of the reasons Drupal core is trusted. The objective should be to reduce avoidable uncertainty and make the existing process more proportionate.
Some possible improvements would be:
- Provide an explicit fast-review queue for documentation changes and other very small, low-risk patches.
- Offer early triage that confirms whether the proposed approach is acceptable before substantial work begins.
- Make the relationship between Drupal.org issue states and GitLab merge-request states easier to understand.
- Explain directly in the interface when contributors should assign or unassign themselves.
- Distinguish unrelated, intermittent and infrastructure test failures more clearly from failures introduced by a merge request.
- Provide automatic assistance for keeping otherwise valid merge requests current.
- Clarify how the AI policy applies to translation, grammar correction and linguistic assistance for non-native English speakers.
- Treat transparent AI disclosure as the beginning of a factual assessment, not as evidence that a contribution is inherently unreliable.
- Make it easier to request an appropriate reviewer without needing personal connections within the project.
None of these ideas eliminates the need for human reviewers. They might, however, reduce the amount of reviewer attention spent explaining procedural details and investigating avoidable uncertainty.
Is volunteering still the logical choice?
Open source depends on people deciding that contributing their time is worthwhile. That decision is influenced not only by ideals, technical interest or recognition, but also by whether contributors can see a reasonable path from effort to completion.
A contribution does not need to be merged immediately. Maintainers are volunteers too, and nobody is entitled to another person’s time. Nevertheless, a process can unintentionally discourage participation when a five-minute correction creates weeks of uncertainty and an indefinite maintenance obligation.
The real comparison is not between contributing and doing nothing. It is between contributing and every other meaningful or enjoyable use of limited free time.
After preparing a branch, updating two platforms, monitoring pipelines, interpreting policies, waiting for review and wondering whether the branch will need another rebase, a perfectly rational question eventually arises:
Would Drupal benefit more from a simpler contribution process—or would I be making a more logical use of my evening by lying on the sofa and watching another episode of a series?
At the moment, the sofa presents a remarkably efficient workflow.
AI disclosure: I used ChatGPT to help organise and draft this article in English. The experiences, arguments and opinions are my own.
Login
![[link]](https://i.redd.it/8zhymm27t4uh1.jpeg){kind=link}
![[link]](https://i.redd.it/hnya6fbhomth1.jpeg){kind=link}