Drupal is a free, open-source content management system (CMS) with a large, supportive community. As a specialized Drupal developer, I’ve contributed greatly to this community with more than 200 Drupal Issue credits – and a goal of adding an additional 200 issue queue credits by the end of this year. What are Drupal Issue Credits? I’m glad you asked.
What are Drupal Issue Credits?
When contributing open source code, back to the Drupal community, through drupal.org, there are a couple types of credit.
1. Issue Credits: When individual bug reports/task/feature requests are marked as finished credit is given to the developer who helped with the issue. Anyone who posts a patch or commits a patch will gain credits. Most often maintainers will credit anyone who gave a helpful review or a high-quality report/discussion. Many issues, when resolved, warrant credit to the multiple individuals who helped with resolving the issue. In turn, these credits are then reported on the users’ profile pages. You can see mine here.
2. Commit Credits: As with many open-source projects, Drupal uses Git for code version control, (and we do at Taoti Creative as well). Every set of changes is a ‘commit’, and each commit has an author – usually, the last patch maker or the maintainer. Drupal.org adds these Commit Credits to the users’ profile page.
Neither type of credit is perfect in that, they can’t discriminate between a complicated new feature that took a week of work and a 1-line bug fix that took 2 minutes – or for that matter, a 1-line bug fix that took 6 hours and half of your hair.
It’s important to note that not all contributions are code, and that’s one of the reasons for the Issue Credits. An issue credit could be for code or code-like work such as reviewing or testing, but Issue Credits can be used for almost anything, including a discussion about how a feature could be improved to work better for users with disabilities, or for documentation.
Why do I contribute?
Primarily because I use the software – daily and in depth. When you’re involved with hundreds of websites it is hard not to find bugs or desire features that don’t exist. There are very rare instances where – due to contractual requirements bugs – can’t be resolved publicly.
With new features, it is often hard to choose whether or not to contribute – and where to contribute to. Before deciding, I ask myself these questions:
· Is it helpful beyond my limited use case?
· What stakeholders need to sign off on this – depending on the contract, this could be no one or multiple people.
· Is this clearly part of a module or Drupal core? If not, it would have to be a new module.
Secondarily, I contribute because it feels great knowing my work is being used to help and support hundreds, in some cases thousands, of sites. At Taoti, a significant amount of the work we do for clients comes in the form of ongoing maintenance, updates and patches of websites. Since a lot of maintenance work is not readily visible as to what you’ve done code-wise, contributing provides a nice resume addition as well.
Tertiarily, doing contribution work is an amazing way to learn. You’re not interacting with a few people on your team, you’re seeing the work of hundreds of other people with varied backgrounds reviewing your work. A solid code review – whether one you’re doing or one you’re receiving – can be a great learning experience.
Another bonus is the community. I enjoy low-pressure discussions with people who share the same interest but often have vastly different life experiences and viewpoints. Beyond code, I’ve learned about the differences in holidays, the school system in South Africa, problems in tech that I never have to face, comparative religions, and politics. It is quite amazing to go to a conference hundreds of miles away and meet folks that you’ve been talking to for years.
What about barriers to contribution?
For many people – especially in underrepresented groups in tech – money and time is a major barrier; contributing takes time, and time is money. In ideal situations, employers and clients will see the value and support it, but it is not a guarantee by any means. Even when they do, often it will be partial; for example, you can end up writing the tests for a feature on your own time if your company doesn’t do testing (which, unlike Taoti, is sadly too many). I’ve been lucky and found support over the years with most of my freelance contracts and all of my employers. However, I’ve also invested a significant amount of my personal time, which has been worthwhile to me as a way of building my career and improving my skills.
What have I contributed?
I have contributed a lot of small stuff, and some stuff at the beginning that I’m embarrassed to see with my name on it. My skills are vastly better now than they were when I started with Drupal in various ways. I initially wasn’t accustomed to writing tests, and now I’m eager to apply automated testing to almost every code.
With a thousand commit credits, it is hard to choose one thing that I’m most proud of, but I think it would have to be my work bringing the 8.x branch of Drupal/Color_field from an unstable dream to a stable solidly tested release. Are there improvements to be made? I’m sure. Are there more features that I’d love to have? Yes. But those are things for the future. There are other modules that I’ve spent more time on and more commits, but that is one of the ones that I’ve contributed to significantly.
What’s next?
The vast majority of my contributions have been in the contrib environment – both maintaining modules of my own and contributing to many others. In this year, I want to dramatically increase my degree of contribution to core.
The quality gates between contrib and core contribution are vastly different – almost anyone can start a module. If you’re unfamiliar with the term contrib, in Drupal, it is basically all the code that isn’t in the core download. Maintainers with contrib have varying goals and experience levels and if something goes wrong with a module it will affect a lot of users.
Core quality gates are harder, and the tickets take more work – and requires more of a discussion, but the impacts are greater.
Final Thoughts …
Helping users become contributors is very rewarding. Through maintaining my own modules and community presence, I’ve had the pleasure of mentoring users through contributing. I was recently presented an opportunity to help mentor a co-worker in Drupal contributions. Mentoring is a two-way street – discussing how to do things and seeing their work allows me to learn as well. At this point, with my knowledge base, I feel that mentoring is a responsibility as well as a privilege and an honor.
