Everyone’s new once, no matter what it is you’re doing - the first steps you take, the first time you cook your own breakfast, the first time you head off to school on your own, the first time you make a contribution to a project. There’s a first contribution for everyone, and hopefully it’s a good enough experience that you continue contributing, or you take that experience to contribute to multiple projects.
The team at Tag1 Consulting has many, many years of experience in Open Source Software (OSS), and in that time, we’ve all had good and bad experiences. While success moves the bar, mistakes are where the truest learning takes place. We’ve all had our share of mistakes, and lessons we’ve learned from those missteps.
In a Tag1 Team Talk, Lucas Hedding, Doug Green, Janez Urevc, and Michael Meyers chat about some of their earliest experiences contributing to Drupal.
Contributing your mistakes
There are a few ways to look at mistakes when you’re trying to contribute to a project. Michael’s experience, where he learned how not to do something, and Lucas’ experience with helping newcomers get into the project but the contribution effort went a little awry show us that we’re all susceptible to these kinds of mistakes.
Anyone who’s ever seen a bug report knows what a set of mistakes looks like, either in the bug itself, or the bug report. In either case, it’s a learning opportunity - either for you in troubleshooting and fixing code, or for the bug reporter in submitting a more complete request.
The team at Srijan wrote a post on how their people were interacting with the Drupal community, what issues some of those interactions caused, and most importantly, what they did to correct it. Commitment to owning your work, and stepping up is one of the biggest ways to gain credibility in OSS communities, especially ones like Drupal.
Communicate
One of the biggest lessons many of us in the industry have learned is that communication throughout the process - every process, can make a huge difference in how well something is accepted and ultimately, accomplished.
In many instances, contributions aren’t accepted the first, second, or more times - sometimes ever! It’s easier to get a contribution out there when you create a new project or module yourself or as part of a team - something that hasn’t been done before and fulfills a need. Projects like Coder, Views, Panels, Display Suite, Date, Media - all started as contributed modules, created by individuals or teams for needs they saw and decided to fulfill. As modules grow in size, use, and popularity, those users report problems or contribute new features and fixes.
This is where communication becomes key. In cases like Lucas’s sprint, where code changes were being made to the Views project, dozens of issues were created, each with a minor change. Ultimately, it turned out ok, but he realized later there were better ways to handle big groups of small issues.
When in the issue queues, sometimes it may turn out that module maintainers or other contributors are already working on a feature or a bug fix, and rather than repeat the work yourself, your best contribution is a code review or test. Take the time to review what’s going on in the queues, or any issues you’re wanting to participate in.
The issue queues can be extremely busy, especially in Core or some of the widely used contributed modules. This is where communication is most critical. Writing a good bug report, or explaining what your intention is - why you need a particular feature when submitting a patch, and engaging in actual, honest discussion and feedback goes a long way over just throwing a patch into the queue.
Submit patches anyway
Just not 50 small ones. Script that stuff so the maintainers don’t cry at all the reviews. Lots of tiny patches mean a billion rebases. Nobody wants to rebase that many times, it sucks.
Know your limits
Big projects mean big responsibility. Some projects get sponsored, either by companies paying an independent person to work on it, or by employing the maintainer and giving them some amount of work time to dedicate to their project.
Many projects, however, are developed in people’s spare time. In many ways, it’s a second job. This has led to many module maintainers burning out and needing to step away from projects temporarily, or sometimes permanently. This also happens as people’s lives, interests, or their jobs change and move away from contributing to their project.
This is where communicating with maintainers is again, key. As we see maintainers struggle, we can offer to help review, maintain, and otherwise help with their projects. Things got a lot easier work-wise in the Miles household when Views went into Drupal core in version 8. As a major, massive module, the queues were completely untenable, even with dedicated resources. It’s not the only module that this happens to, and as a maintainer, you have to know when to step back.
Doing the thing you need isn’t always the right thing for the project
One of the lessons some folks learn early on is that contributing isn’t always easy. It’s really, really hard sometimes. When you’re at a DrupalCon or camp, or doing a sprint, people tend to be very focused on completing a project or set of tasks for that time period, and that makes people ready and willing to discuss the best way to tackle an issue, synchronously.
Most work isn’t like that - many of us are working asynchronously on a multitude of projects and tasks, and it’s hard to remember what any given person is doing. What you need may not be what the project needs, and it can feel personal when a maintainer seems to be ignoring you, or worse, is rude. In some cases, it’s as simple as “this change is an edge case and won’t be added to the project.” In other cases though, people can get rude and say nasty things in the queues.
Don’t be that person. There’s a lot of reusable code out there, but there’s also a lot of custom work on websites we work with. Something you think isn’t necessary, or even silly, today may turn out to be the exact thing your next client needs.
Keep trying
The biggest lesson that comes from all the previous lessons and mistakes is to keep trying. Maybe your first patch, or second, or third doesn’t get in, or maybe your contributed module doesn’t get a lot of use. The feedback you do get can be invaluable in improving your next contribution, or help someone else facing a similar problem.
Mistakes also help new contributors see the ecosystem, and how the members of a project work together to fix problems and add new features. These mistakes and issues are great ways for new contributors to enter our projects! We all make mistakes - let’s learn from them.
Don’t be afraid to branch out. While many of our developers here at Tag1 are focused on Drupal, many of them also contribute to other open source projects. For some of us, that means patching libraries we need, or working with projects like MongoDB to help build integrations, or other projects that are just fun to work with. Take those first steps, and work on building something awesome.
Photo by Michael Dziedzic on Unsplash