Boris Mann

Open Source. Community. Decentralized Web. Building dev tools at Fission. Cooks & eats.


Being involved in the issue queue as a normal part of development

Patches that we write for modules are submitted to the issue queue, and we refer to the patch’s location on in the make file. This has made us much better contributors to other people projects as it makes being involved in the issue queue a normal part of development, and it encourages us to only patch contrib modules where it’s likely that the patch will be accepted. When a patch gets a review, we make changes, upload a newer version of the patch to, and update our make file.


This is actually a quote from Jeff in the comments on the article Drush Make Files for Production Drupal sites, but I thought it was definitely worth highlighting on its own.

In this particular case, using make files actually codifies the decision to integrate closely with contrib modules and actively improve them / add features as needed for a particular project.

I've followed this practice for years, albeit without make files. Patches go in a "patches" directory in version control, with the patch file named with both the name of the module and the node number of the issue on

An additional process is that if a patch is needed, you run it in the issue queue on, but you also have an internal ticket that links to that issue. You don't close the issue until the patch has been accepted into the mainline of the module. Then you can remove the patch, update the version of the module you're using, and your clients' website is one step closer to easier long term maintenance and updates.

And yes, being involved in the issue queue SHOULD be a normal part of developing Drupal websites.