Drupal's contribution process is open and straightforward. It's also the fastest route to mastering this CMF.
Drupal is an open-source Content Management Framework (CMF) that allows you to build a Content Management System (CMS) that fits your needs. This article doesn't go into detail about the differences between a CMS and a CMF. The article “Drupal Is Not a CMS” (www.palantir.net/blog/drupal-not-cms) by Larry Garfield of Palantir (known as “crell” on Twitter and IRC) does an excellent job of explaining this distinction. What's important to readers of this article is the basic structure that makes Drupal a framework. There's a core (analogous to the Linux kernel in many ways) that contains the basic Drupal functionality. This is what you get when you download Drupal. The additional functions come from contributed modules, which add capabilities to Drupal's core.
This article focuses on Drupal's core, how you can contribute to the project and why you'd want to. I'll start with the why, and then move on to the various methods of how.
Drupal core is the basic functionality common to any Drupal-based CMS. Like the Linux kernel, it's not Drupal without core. When you download Drupal, you're downloading core. In addition to core, there are several optional pieces of software (called Modules in Drupal-speak) that add useful functions to the core. These range from the nearly critical modules like Views and CCK, used on most Drupal projects, to modules meant for very specific use cases.
If you already know you want to contribute to Drupal core, skip ahead to the “How” section of this article. There are several reasons you would want to contribute to Drupal core, mostly related to how you use Drupal or plan to use it.
As mentioned earlier, Drupal is a CMF, allowing you to build a custom CMS that suits your needs more easily. In some cases, that may mean combining pre-existing contributed modules. If you're someone who's using Drupal to build Web sites or a custom CMS (perhaps an intranet), but you're not planning to make any changes to Drupal (such as adding new code to a module), making contributions to core can give you a better understanding of how the system works under the hood. This, in turn, can help you make more educated decisions about which contributed modules to use as you build your project. As an example, you may have a scenario where site speed is critical. There may be two modules that perform a similar function, but one may have been built with an emphasis on ease of use/configuration (which we all like), while the other may have been built for performance. A better understanding of how Drupal core works can help you decide what's best for your use case and what to do when your needs change—and, you know they'll change.
In some cases, there may be certain, specific functionality you need or want that doesn't already exist in Drupal. In that case, you can add functions to an existing module or create a module of your own. Please, don't hack core. Drupal is written in PHP, and core is designed in a modular fashion to accept these new functions. Contributing to core will give you stronger understanding of the best ways to create your new modules to best work with what core or other existing modules already provide. You may not need to create a complex new module—perhaps all that's needed is a small extra bit of functionality. The more you know about what core provides and how it provides it, the less you'll have to create. Remember, as Eric Raymond says, “No problem should ever have to be solved twice” (www.catb.org/esr/faqs/hacker-howto.html#believe2).
The above examples assume you're someone who's already using Drupal but not making contributions to core. If that's the case, consider this: Drupal is a growing and evolving system. By contributing to core, you're in a great position to learn more about where Drupal is going in the future. As an example, the current version of Drupal is Drupal 7. Drupal 8 is going to be awesome! How do I know that? Making small contributions to core keeps me in the loop about what's happening. But, what about people just starting with Drupal?
Say you're a system/network/database admin who's had Drupal “thrust upon you” by someone higher up. That never happens, right? I had a sysadmin friend recently tell me that someone in her organization was “excited” about using Drupal. What's that going to mean for my friend? You probably don't care, but you do care about what it would mean for you, don't you? Contributing to core can help you get a much better understanding of how a Drupal system may impact the system/network/database resources you administer. This is especially true once you figure out what your organization wants to do with Drupal. I look at specifics regarding that in the “How” section of this article.
What if you're the “Web person” for your organization who's had Drupal “thrust upon you”, but with a mandate to make it usable, “pretty” and accesible or to “look like our company, not every other Drupal site”? First, realize how lucky you are to have higher-ups who are enlightened enough to choose Drupal. They could have thought Flash was “the next big thing”. Second, realize that contributing to core can help you learn the best ways to do that. Again, more details on that in the “How” section.
If you're someone new to Drupal, you'll probably want all the help you can get. The people best positioned to help you use Drupal are the people who built Drupal. How can you meet these people? By contributing to core.
The first thing you have to do to before you can make a contribution to Drupal core is register for an account at drupal.org. This allows you to do all sorts of small things immediately, such as update documentation. You can contribute in several different ways. For the Linux Journal audience, I'll first focus on the “standard” approach, which is more developer-centric and involves using the Drupal Issue Queue. After that, I'll go into some ways even a “non-coder” or “non-technical” person can contribute.
The approach most developers (but not just developers) will be comfortable with can be seen on the Drupal Ladder (drupalladder.org/ladder/ee503327-50be-1904-8d04-9499098cad64). The Drupal Ladder is the result of an effort to get more people involved in contributing to Drupal core. It is made up of “lessons and materials to help people learn about and contribute to Drupal” (drupalladder.org/node/1). It's also worth noting that Drupalize.me, an on-line repository for Drupal training videos created by Lullabot, has a free “Learn the Drupal Ladder” (drupalize.me/series/learn-drupal-ladder) series of videos available for viewing. At the time of this writing (August 2012), four videos are available, going through the “Getting Started in the Issue Queue” rung of the ladder, with at least two more in the works. Those are excellent resources as well. The first two steps are basic setup. If you've already got a local Web development environment and Git setup, feel free to skip ahead to step 3.
This involves setting up a local *AMP stack (with the “P” being PHP) and downloading/installing the latest version of Drupal. For most Linux Journal readers, this shouldn't be a problem, as most Linux distros already include this software. If you're not running Linux, you've got a couple options. You can use WAMP (www.wampserver.com/en) for Windows or MAMP (www.mamp.info/en/index.html) for OS X. Drupalize.me has free videos to help with installing WAMP (drupalize.me/videos/installing-wampserver) or MAMP (drupalize.me/videos/installing-mamp-web-server) for those needing help. A second option, for both platforms, is the Acquia Dev Desktop. This is an *AMP package created by Acquia, a Drupal company started by Drupal project founder and lead, Dries Buytaert. Instructions for installing the Acquia Dev Desktop can be found in the second video in the “Learn Drupal Ladder” series mentioned earlier.
After you've got your *AMP stack going, it's just a matter of downloading the latest version of Drupal. If you're happy with the Linux command line, the “Quick install for developers (command line)” (drupal.org/documentation/install/developers) approach should work just fine, starting with:
wget http://drupal.org/files/projects/drupal-x.x.tar.gz tar -zxvf drupal-x.x.tar.gz
Otherwise, you can go to drupal.org/download for the latest version of Drupal 7 (which is the current version of Drupal as of August 2012), or you can go to the releases page (drupal.org/node/3060/release) to find anything from Drupal 4.7 to the latest update to Drupal 8 (under development now). Refer to Drupal's Installation Guide for further details.
Drupal uses Git for version control, and if you're going to be helping with the Issue Queue, you'll need it installed locally as well. Instructions for installing Git are beyond the scope of this article, but once you've got it installed, there is a set of instructions specific to working with Drupal core (drupal.org/project/drupal/git-instructions) available for those new to Git or Drupal. Don't forget, there's also a lesson at the Drupal Ladder site (drupalladder.org/lesson/027b5839-7a74-af04-6905-fee2d01c7ef4) and a video at Drupalize.me. With the first two setup steps out of the way, you're ready to dive into the Issue Queue and start meeting Drupal Folks.
Now, I'm going to depart a bit from following the Drupal Ladder, by outlining the basic steps for dealing with a bug in Drupal core, which probably are similar across open-source projects. What's important to note is that you're helping by taking part in any of these steps. Please note, this is my “broad strokes” overview of the process. It's not an “official” outline or process document. I'm sure I'm leaving out some details, but this will more than suffice for an introduction:
1. Someone has a problem and adds an issue to the Drupal Core Issue Queue (https://drupal.org/project/issues/drupal?categories=All). When doing this, be as detailed as possible about the conditions that cause the bug to appear. People will need to be able to reproduce it. Screenshots help. You need to have an account on drupal.org to post an issue.
2. Someone working on the issue queue tests an issue to see if they can reproduce it. If they can't reproduce it, they'll post a comment for that issue, probably asking for more information. This will alert the original poster and anyone else who may be “following” that issue. If they can, they'll add a comment noting this and perhaps move on to the next step.
3. Someone sees an issue they know how to fix. They may explain what needs to be done (this is often done by more experienced developers when they encounter “easier” problems) or create the patch they think will fix the issue. When a patch is created, it's submitted by attaching it to a new comment in the issue queue. Drupal's automated testing system (SimpleTest) will do basic testing on the patch.
4. Someone sees a patch that has passed automated testing and will test it manually on their own local Drupal install. They'll include before-and-after screenshots of the behavior that created the bug and how it's been fixed (or not fixed).
5. Someone with commit access (a small group of people, https://drupal.org/node/3060/committers) will commit the successful patch to Drupal core after it's been successfully Reviewed and Tested By the Community (RTBC)
My use of the word “someone” in the steps above was important because you could be the “someone” in each or any of those steps (except the last one) in the process, but for a different issue. It all depends on the issue and your abilities. As an example, if you know how to download a file from the Web, take screenshots of what's on your computer screen and upload a picture to the Web, you can do step 4 above. You just need to learn the first two “rungs” of the Drupal Ladder (install Drupal locally and install Git—remember, there are free videos to show you how), and you're ready to go. If you don't know how to create or apply a patch with Git, the Git instructions for working with Drupal core (drupal.org/project/drupal/git-instructions) tell you how. This step is a critical step, and if that's all you ever do to contribute to Drupal core, you'll be appreciated more than you know. But, it also could be a great entry point to other types of contributions.
Similarly, step 3 above provides an opportunity to focus on your areas of expertise. There's more to Drupal than just PHP. There's a lot of markup (https://drupal.org/project/issues/drupal?categories=bug&component=markup), including HTML5, CSS (https://drupal.org/project/issues/drupal?categories=bug&component=CSS) and JavaScript (https://drupal.org/project/issues/drupal?categories=bug&component=javascript) in Drupal core. Each category has issues. The Drupal community is heavy on “back-end” developers, but if you're good with the “front-end” stuff, you may be able to point out, suggest or create patches to core issues quickly, without ever leaving your comfort zone. Again, once you've climbed those first two rungs of the Drupal Ladder, you can go to town.
One of the best benefits of working with Drupal is the great community. It's honestly one of the biggest reasons I've spent so much time learning more about Drupal. More than just a CMF, Drupal, like Soylent Green, is made of people—great people. You can leverage those great people as you learn to contribute by participating in Core Mentoring Hours (drupal.org/core-office-hours).
Core Mentoring Hours (which you may sometimes hear called “Office Hours”—it was originally called Core Office Hours) got started in August 2011 as an effort to get more of the Drupal community involved in helping with contributions to core. As with many projects, you find a small group of people carrying a lot of the weight. If more people could be recruited to help with some of the tasks (like steps 3 and 4 above), that would create two benefits. First, it would leave the Drupal architects free to focus on higher-level stuff (instead of fixing typos in text strings, an actual issue I've worked on). Second, it would help “build” new Drupal architects by letting members of the community learn more about the inner workings of Drupal. The benefit for new contributors is that there's now an official, well-formed (and constantly evolving) “on-ramp” for new contributors.
Currently, Core Mentoring Hours happen twice each week, Tuesday, 02:00–04:00 UTC, and Wednesday, 16:00–18:00 UTC. Here in Texas, that's 9–11pm Mondays and 11am–1pm Wednesdays. The Core Mentoring page has time-zone converters so you can find your local times. If you can make yourself available during one of those time slots, go into the #drupal IRC channel on freenode.net and announce that you're there for Core Mentoring Hours (drupal.org/irc). You promptly will be put to work and/or assisted with questions you have about how to contribute. I participated in the first COH/CMH last August, and I've learned quite a bit.
Remember those examples I mentioned about the people who had Drupal “thrust upon them”? Remember when I said you'd be able to find ways to contribute that would benefit your specific functions? This is where the various Drupal core subsystems come into play. My sysadmin friend may be more concerned with the cache (https://drupal.org/project/issues/drupal?categories=bug&component=cache+system) or database (https://drupal.org/project/issues/drupal?categories=bug&component=database+system) systems and how they work. Looking at bugs related to those systems can help expand her understanding of how they function. If her organization is using MySQL (https://drupal.org/project/issues/drupal?categories=bug&component=mysql+database) or PostgreSQL (https://drupal.org/project/issues/drupal?categories=bug&component=postgresql+database), she may want to focus more on those. The “Web person” may want to focus more on things like the markup, CSS or JavaScript subsystems I mentioned earlier. Or, if the site has a lot of community activity, maybe looking at the Comment module (https://drupal.org/project/issues/drupal?categories=bug&component=comment.module) would be helpful.
If you know what parts of Drupal you're more interested in, point that out while you're in Core Mentoring Hours, and you can work on those areas. Or, work on it on your own. Another option is to look at the various Drupal 8 Core Initiatives (drupal.org/community-initiatives/drupal-core), which focus almost exclusively on specific areas, such as configuration management, Web services or mobile. Discussion of those topics deserves its own article, but take a look at the Initiatives page and see what looks good.
There are a number of ways non-coders can contribute. Every issue in the core queue should have a clear, concise summary. They don't. The Issue Summary Initiative (groups.drupal.org/node/167534) looks to fix this. If you can read and write English, you can help here. Change notices (drupal.org/node/1314040), although slightly more technical, involve documenting changes that already have been made. So, if there's a patch that changes an API or adds/removes a function, a Change Notice is needed. Here's an example of one I worked on for a new function that themes (styles) date/time information (drupal.org/node/1441334). I didn't write the patch, just the Change Notice. Finally, as a member of drupal.org, you can update most of the documentation on the site, and there is a lot! As an example, while I was writing the paragraph on Core Mentoring Hours, I updated the time-zone conversion link for 02:00 UTC Tuesday. It was going to 02:00 UTC Monday, probably because the Mentoring Hours started on Monday/Wednesday. It was a simple fix, but each bit helps.
I've done all three of the things mentioned above. If you're curious about any of them, you can take a look at the docs I've linked to or ask in Core Mentoring Hours.
Drupal is an excellent CMF that offers a lot of functionality out of the box, as well as for people wanting to build something custom. In a more general sense, Drupal is also an open-source project with a very welcoming and supportive community. In the words of Angela “webchick” Byron, open-source evangelist, a Drupal core co-maintiner and April 2011 Linux Journal cover girl (www.linuxjournal.com/content/interview-angie-byron-drupal), “Drupal is a Do-ocracy”. It's not about who you are; it's about what you do. My own experiences have confirmed this. There's very little cliquishness, and anyone who's willing to learn about the community standards is welcome to contribute. This article exists only because I've come across so many smart and helpful people contributing to the Drupal community. Join us!
