I’ve been working with Drupal for quite a few years now. Drupal is open source, and thanks to that, we (and so many other companies) can build powerful websites that match our client’s expectations. Drupal has a very powerful and capable core which offers CMS functionalities that allow you to build powerful sites by clicking around the Drupal UI.
It also has contributed modules, which aren’t used on every site and you can choose to enable for your new site if you need that functionality. There is also a big pool of base themes that you can build upon that will give your site a great starting point and make it look nice.
We often build on top of existing modules and themes. We enhance them or create our own, sometimes tailor-made to the site’s context, sometimes generic enough so the module or theme can be made available to Drupal and therefore to the whole community.
I’ve always loved this. By sharing it you make the product bigger, more robust, better in general and we don’t need to reinvent the same wheel over and over.
Modules and Patches
However, building a whole new module or theme is usually not a quick task, or even desired in some cases (if something similar is out there already). So we often find ourselves trying to leverage existing modules.
Probably the easiest way to contribute to an already big community and an already big set of modules and themes is to help them improve by either fixing little bugs, or by adding new features to them. This is done usually via what we call “patches” (which under other platforms could be called a “pull request”). A patch is just a file that contains changes to the existing source code that will fix or enhance the given project.
For example: if the webform module lacks a type of field for emails, we could create a patch that adds that capability and submit it for the community to review it, and to the maintainer to merge it into the main project. If all goes well, then the webform module will now support emails as a field type, so everybody will benefit from it when updating the module.
At Amazee Labs, we encourage a workflow that lends itself to both contribution and client projects. I knew I wanted to incorporate contribution into my work on an even more regular basis, so my 2019 resolution was to submit (at least) one patch a month to a Drupal module.
Some months it was easy, especially when opportunities for the contribution came right out of working on a ticket. For others, it wasn’t so easy. When I didn’t see any obvious chances to contribute in my work for the month, I set a practice of searching through the issue queue of any module I was installing and working on one of them. This made me inspect the code, see how it was structured and eventually create a patch for an existing issue.
Working in this manner vastly improved my Drupal knowledge, and cemented my personal resolution to regularly contribute. After each month, I felt like I was helping Drupal (even if it was just a tiny bit) one way or another.
I was really happy that I could complete the challenge. Some team members joined during the year and that made the challenge more fun and encouraged me to carry on. Also, as team lead, I had already agreed with some of my team members to set this challenge for them as well for 2020. We have a Slack channel where we share the patches, ask questions, encourage each other, etc.
So if you’re using Drupal and you’d like to contribute more, maybe this could be a challenge that you could also take for 2020.
In case you were wondering which patches were submitted, here is the full list: