C H A P T E R  38

Contributing to the Community

by Benjamin Melançon and Claudina Sarahe

“People come to me and ask how they can contribute. I always tell them to do what they want to do. If I told them what to do, then it wouldn't always be fun and it wouldn't necessarily translate into the passion that I'd like to see happen.”

—Dries Buytaert, Drupal Project Lead

“A contributor is someone who has three qualities: they see something and they say, ‘that's dumb,' then they say ‘hey, I really wanna see that thing fixed,' and they do something about it.”

—Angela Byron, Drupal 7 Maintainer

There is a common misconception that you have to be a programmer in order to contribute to Drupal. This is untrue; even those with little or no prior knowledge of code can contribute to the community in ways that will help make Drupal better. In fact, this is what happens all the time: people support the Drupal community by organizing events, answering questions, and sponsoring development sprints—all examples of vital non-code contributions that the community needs to grow. Non-code contributions, such as mentorship and writing documentation, are ideal ways to develop and grow one's skills in coding and configuring Drupal. Growing the community means, on the one hand, growing the infrastructure and number of people and, on the other, growing the capabilities of people in the community.

With this chapter, we conclude the book with a tour through the wide assortment of ways we can all make Drupal a better place to make web sites, to make a living, to make friends, and, just maybe, to make a better world.

Contributing is about doing something about things that you have an interest in improving. This is the message from Dries and Angie, the two people who performed the final review and committed every improvement made to Drupal 7. Trying to contribute where it doesn't interest you is not likely to be effective. As Drupal continues to grow, so does the need for more contributors and types of contributions. It is the authors' hope that this chapter will help us all find ways we can contribute (if we aren't already), inspire us to want to contribute more, and increase our knowledge about the fuel that powers Drupal's success—the community. This chapter presents reasons to get involved and ways to make your contributions more effective. This chapter is also a way of saying thanks to those that have contributed and continue to contribute to Drupal.

Why Contribute?

There are many reasons to contribute. For the intrinsic joy of making or helping, to aid personal or professional betterment, and out of commitment to community. To the authors, contributing is about making the place where you live better. It's like changing the oil in a car; it may not immediately affect you but it will make a difference down the road not only to you but to others.

Evan Donovan (drupal.org/user/168664), one of the hundreds of contributors to Drupal 7 core, highlighted five reasons to contribute on his blog (donanvan.covblogs.com/archives/040454.html):

• It's fun to learn things.
• It's fun to solve problems.
• It's fun to help people out.
• The work you contribute back to the community can be multiplied many-fold by the others in the community. In turn, their work can provide a base for further progress.
• Sometimes, it can even be beneficial to your job prospects.

Gábor Hojtsy (drupal.org/user/4166), a major contributor to Drupal core as well as the maintainer of Drupal 7's Locale module and the entire Drupal 6 series of releases, summarized the benefits of contributing as offering the ability to:

• Work on cool technology.
• Work in an international team.
• Show off your work and talent.
• Travel.
• Make money.

Gábor, one of the first hires by Acquia(the company co-founded by Dries Buytaert eight years after he founded Drupal), views contributing to open source projects as protecting one's career:

If you need a good way to ensure your job security, I think this is a way. Your active work life is documented all around the Internet, you've been to conferences, established your name in the industry. When you are compared to someone who worked on a closed source legacy system and can only be believed for the pieces in his Curriculum Vitae (further details of which are under a Non-Disclosure Agreement), who is less risk to take on for a company?

Without Contributions, There Is No Drupal

We—the authors writing, the readers reading—are here because of Drupal. Our ability to engage with Drupal (software, community events, knowledge) only exists because of all the earlier contributions of others, starting from the beginning when Dries opened his code. If no one had stepped up and contributed, there would be no Drupal.

Larry Garfield (Crell, drupal.org/user/26398), a core contributor, lead maintainer of Drupal's database layer, Senior Developer at Palantir, and Drupal Association Legal Affairs Director, uses the phrase “pay it forward” as a way to describe how free software works.

When you work on an open source project or release code under a Free Software license you are doing something for someone else. Someone you don't know, and who probably doesn't know you, is going to benefit from your actions. You may yourself benefit from the work you do, but so will other people that have not done anything for you. And that is the very point.

If one person does that, the world takes advantage of them. If a thousand people do that, you get Drupal. Or Linux. Or Apache. Or Firefox. Or the KDE desktop. Or, really, all of them combined. Every one of those projects is the result of thousands of people paying it forward, to each other and to you. The net result is a robust, healthy environment of quality code and, more importantly, a culture of sharing and mutualsupport, even across projects.

In my day job, I work with Drupal. I've written tons of code for Drupal, both core and contrib, as have my colleagues, and we release as much as we can back to the community. We are paying it forward to the rest of the web development world in return for the million man-hours that have already been put into building what we're leveraging for free. That is what makes open source work.

Drupal's success is largely due to the many ways in which people can contribute without barriers. Drupal is designed to be extended; it is designed to easily allow people to contribute along the way. The modular nature of the software has been essential to the phenomenal growth of both the technology and the community. While Drupal has paved an exemplary path by putting developers' needs and happiness at the forefront of the core technological design, the success of an open source technology project is the balance of the building, maintenance, and evolution of the code and the sustained development and happiness of the community.

“The principles that come to mind are those of self-organization and scratching your own itch. Getting out of people's way as much as you can, and enabling people to accomplish what they are passionate about. When people can come together and take action collaboratively, impressive things can happen.”

—Dries Buytaert

Taking That First Step

We can all relate to a time when it felt daunting to take that first step. You can feel like the new kid on the block when joining an already established community. The Drupal community takes care to continue to grow without any barriers to entry. Communities are often viewed as having insider groups, and to some extent this is inevitably true; the more active participants will work together more. This bonding based on related behavior and activities is common in life, but in the Drupal community it does not prevent anyone from joining. Membership in the community is defined by participation, especially contributing, and some of the many ways to contribute, open to everyone, will be covered in this chapter. Act like an insider (of whatever definition or group), and you will be an insider. Going far in Drupal is about knowing what you want and going after it. If you really want it, keep going!

The following tips apply no matter what you are contributing:

• Do not expect anything in return. A community is not a market arrangement (give X, get Y).
• Don't await the ticker-tape parade. Contributing to the community is being part of the community, not being celebrated by it.
• Have a thick skin. Don't take things personally. Katherine Senzee (ksenzee, drupal.org/user/139855) is a senior engineer who frequently helps people in IRC, writes documentation, and contributes significantly to Drupal code. She worked magic making the Overlay module for Drupal 7 core, and some insignificant author named Ben recommended disabling it in the first chapter of this book. Katherine doesn't need validation for her efforts except that people do benefit—many consider Overlay a key usability enhancement. If Katherine or the other people who make Drupal great let criticism stop them, we wouldn't have a single achievement.

Transparent Communication

Tim O'Reilly, speaking to Kent Bye, said that Drupal is one of the most important open source projects because it “has created a successful architecture of communication.” A very high proportion of Drupal interaction takes place in public, primarily on IRC and in the issue queues (drupal.org/project/issues). In fact, it's hard to entirely avoid the issue queues, and why would you want to? Here you can see friends and co-workers disagree with each other—and people on different continents work out solutions together! Conversation also takes place in other venues, such as groups.drupal.org; and if a question can be conveyed in 140 characters there's always Twitter and the drupal#.

The great honesty and transparency of the Drupal project is a part of the community ethos. We learn and fail publicly. We believe it's better to do and try publicly than to aim for perfection behind closed doors. But take care to converse with civility. We all have bad and good days. We don't always get the full context of a person's day in IRC or in the issue queueTake any comment the only way it can be: as one person's perspective at one moment in time. On the other side, if you notice curt behavior, especially directed to a newcomer who has made a basic beginner mistake such as asking a question inthe wrong IRC channel, do take the time to say, “Hey, I'm sorry you experienced that. This channel is not the best for your question. Let me help youin #drupal-support!”

Keeping a community happy, diverse, innovative, and active is no easy task, especially one relying on the collaborative power of individuals. The Drupal community is not perfect and we say it proudly. We learn and implement as we go along. The roads to Drupal contribution could be better marked and better-maintained. We need to get better at recognizing different kinds of contributions.

How do we remove unnecessary barriers to contributing? How do we ensure that someone putting in effort is acknowledged and supported? Do we need better tools for discussion or decision-making? These questions are a frequent matter of discussion among those who care about Drupal; in fact, working on these problems is another way of contributing to the well-being of the community. We'll look at some of these questions in the final section “Drupal as a Movement.”

In the next section, we look at ways that are available to all of us to make Drupal code and the Drupal community better than ever.

Ways to Contribute

There are as many ways to contribute to Drupal as there are motivations for doing so, and all can be a rewarding experience in their own right. At the core, a contribution is made up of two components:

• Time, which is great, since we all have time; it's just a matter of how we use it!
• Love, which is usually how we decide what or where to put our time towards.

We offer you 12 ways to contribute to the community—advanced members and newcomers alike. This list is only a sampling from the growing number of ways to contribute to the welfare of the community and advancement of the code base; if you have another suggestion, please share it at dgd7.org/suggestions. If you write your ideas on your blog, please leave the link and a short descriptive sentence. Additionally, you have permission to use information from this book to contribute to drupal.org documentation.

1. Providing Non-Technical Support

A thanks or acknowledgement goes a long way. Appreciation takes many forms. If a member of the community helps you out, send them thanks on Twitter. Or make them some cookies! Those who attended Maureen Lyons' session at DrupalCon Boston 2008 will always remember getting excellent vegan brownies.

If you really like a module, theme, particular Drupal distribution, or product, acknowledge its value to your life. Christefano's love letter to the Edit Term module (data.agaric.com/edit-term-love) surely helped give it the karmic boost it needed to get into core.

Ryan Aslett (Mixologic, drupal.org/user/391689) sent the Views team love instead of bugs. Ryan created a task in the issue queue to “Keep Up the Awesome.”

Every single project I work on I use Views. I never have problems with it... If the whole world understood Drupal, Views would immediately be championed as an epic work of art.

Thanks for creating/helping to maintain something positively awesome.

Fourteen other users added their praise, thanking the Views team—and thanking Mixologic for taking the time to express his gratitude publicly. The issue ended when Lynette Miles (esmerel,drupal.org/user/164022) changed the status to closed (works as designed) and wrote “Always fun to come across these ;)”. (As a rule, don't misuse the issue queues for any purpose— an even better way to show support is to help out in them, see way to contribute number 7.)

You can nominate and profile people for the Drupal Community Spotlight at drupal.org/community-spotlight. Or post your own spotlight, as Alan Palazzolo did before contributing to the Spotlight, and Andrew Riley, Michael Anello, and Ryan Price are doing with The DrupalEasy Podcast, a weekly review of new developments and announcements in the worldwide Drupal community (drupaleasy.com/podcast). Don't be afraid to share your thanks publicly. Others may be having similar thoughts.

2. Sharing Everything

“If someone helps you out with an open source project, be it using it, developing for it, or even just writing about it, you can thank them personally. But the true thanks, what will really show gratitude, is paying it forward. You've just gained new knowledge and understanding. Share that knowledge and understanding with others. Help out the next person, or better yet the next people, to come after you.”

—Larry Garfield (Crell)

Sharing what you have learned is one of the best ways to contribute back to the community. The process of explaining concepts and answering questions is one of the best ways to learn, too. There are a wide variety of opportunities for¬ mentoring, teaching and learning within the Drupal community, some of which include:

• Making a presentation at your local meetup.
• Sharing your blog posts; they don't have to be Planet-worthy to share.
• Sharing incomplete code.
• Starting some documentation and letting others improve upon it.
• Allowing distribution and modification of your documentation. You can allow access to your material under whatever Creative Commons level you prefer.

Sharing is a notable aspect of the Drupal community. It doesn't have to be Drupal specific. Karen Stevenson posted her cheat sheet about the Vi editor at lullabot.com/blog/using-vi-editor by stating “Here is my cheat sheet, in a public place that is easy to find.”

Whenever you get stuck on something, whether Git'ing your way out of a merge conflict, properly setting up Drush site aliases, configuring a module, or overriding theme functions, you're probably going to try searching for the answer. Record all the search terms you try. When you figure out how to get past the problem, or a piece of the problem, write up your notes. Put the notes up on your site in a post with all the search engine terms you tried. When the next person (anywhere in the world) has the same problem and enters the same search terms, the post you just made will come up.

Like Karen, part of the reason that Benjamin puts things online is to easily find them again. “I regularly search for answers across the whole web and find my own answers from two weeks or two years ago.”

You can drop the quality filter entirely and post every investigation and half-baked idea on your own site. If you're worried that this will make you look like you don't know what you're doing, well, quite the opposite: you will be raising awareness about yourself in the Drupal community. You'll be perceived as someone who is willing to find solutions and collaborates with all, which might help you get important clients in the future. Or maybe someone will correct you. Either way, make sure your company name or drupal.org username and contact information are available in your posts.

Documentation can be as simple as a record of the things you've tried in order to get something done. You don't need to know all the answers. In fact, you can contribute by sharing incorrect information!

Contribute by Being Wrong

“I stand corrected! Thanks to the commenters for enlightening me. Drush does in fact do this.”

—Ben Buckman

Drush is a powerful command line and scripting interface for Drupal, a veritable Swiss Army knife. It's designed to make common development tasks for developers and themers much easier. Expert Drupal developer Ben Buckman (drupal.org/user/342780) was looking for a way to synchronize a database between remote and local servers. He created a scripting technique because he was unable to do it with Drush. He shared his techniqueon his website. Commenters pointed out that Drush could in fact synchronize databases—and do it even better.

Why is this an inspirational story? Sharing his approach led other people to share theirs. Once Ben discovered how to achieve his original goal with Drush, he updated his post and helped many others learn something new. Ben paid forward the “new knowledge and understanding” he'd gained by sharing it with others. (If you develop Drupal using live and dev sites and haven't set up Drush site aliases for syncing databases and files, see Chapter 26!)

Mentoring

You don't have to be too far along in Drupal to mentor. Beginners willing to demonstrate what they have learned are highly encouraged and welcomed into the community as the need for assisting others with the most basic tasks and concepts is so great.

Check on people you mentor frequently and help them break down tasks to make sure they are not spinning their wheels without getting traction. IBM consultant Sacha Chua recommended this in reflections on mentoring a new Drupal developer, noting “otherwise, she might get lost or stuck, because she might not yet know where things are or whether she's getting closer to an answer.” Sacha's notes on work, connecting, and living an awesome life can be found at her blog sachachua.com and she shares her Drupal-related posts on Drupal Planet (drupal.org/planet).

Conversely, just telling someone what code to type without explaining the concept behind the code doesn't foster learning. Everyone learns differently. Be open to that as a mentor.

Mentoring can be informal, semi-formal as withthe Drupal Dojo project, or it can be part of formal programs such as the Google Summer of Code (GSOC) or Google Code-In (GCI, drupal.org/project/issues/gci). The Drupal Open Learning Initiative (DOLI; DrupalOpenLearning.org) outlines a number of projects and on-going programs produced by and for the Drupal community.

The Drupal Dojo (DrupalDojo.com/about) is well known for the successful series of free weekly webinars. Anyone may sign up to present an educational program in the Dojo simply by adding their event to the “Building with Drupal” program lineup at groups.drupal.org/node/52023. The long-term vision includes transforming DrupalDojo.com from a virtual meeting place with program archives into a more robust Drupal Learning Resource Center that catalogs and references Drupal Learning materials. The Dojo also supports the expansion of educational programs such as regular IRC chats in the Freenode #Drupal-dojo channel, local weekly Dojo Meetings for training, and co-working sessions. As of January 2011, Drupal User Groups in Austin, Boston, and Seattle have all expanded their monthly meetings to include a weekly Drupal Dojo training or working session. The Drupal Dojo group is one of the largest groups on Groups.Drupal.org.

Drupal Learning Projects (DrupalKata.com) provides opportunities to learn by doing, under the guidance of mentors, teams, or project managers. Projects are developed in the open by following workflow that insures documentation and opportunities to generate lessons, best practices, tips and tricks, tutorials, development strategies and a host of other learning materials, all based on the lessons learned during project development. These materials are then cataloged and distributed through the Drupal Dojo.

Dojo Barn Raisings help a local non-profit by building a Drupal 7 site as an open learning project. All planning and development is completed in the open using the Drupal Kata project resources and culminates in a public barn-raising, where Drupal volunteers, mentors, and apprentices work in teams to build the site in one or two public sessions. There are observation areas for the public to watch and learn as narrators explain the work as it's completed. The Seattle Drupal User Group (groups.Drupal.com/seattle) launched another barn raising project (groups.drupal.org/node/121624) in January of 2011.

Cataloging Drupal Learning was created shortly after DrupalCon San Francisco when a group of volunteers began the process of mapping Drupal learning by developing a questionnaire that associates job responsibilities and core competencies with Drupal learning objectives. The long-term goal is to establish standards for the cataloging of all Drupal learning content from courses to learning objects (groups.drupal.org/node/15975).

Drupal Open Curriculum Project is developing a complete curriculum and course materials that anyone can use. This project offers many opportunities for individuals to get involved, regardless of experience with instructional design (gitorious.org/drupal-open-curriculum/pages/Home).

Developing a Framework for Drupal Learning is an objective of the DOLI. It hopes to bring together the wide range of experts, mentors, trainers, and educators working to develop Open Drupal Curriculum in order to define a framework for Drupal Open Learning Curriculum, including guidelines and best practices for curriculum development.

Drupal In A Day is an effort to develop shortercourses that cover Drupal for the newcomer. Learn all about Drupal in a day.

3. Answering Questions in Forums, Groups, Mailing Lists, Meetups, and IRC

“Each time you visit drupal.org take a quick look at the ‘New forum topics' block. It only takes 5 minutes to help someone.”

—Wim Mostrey (wmostrey, drupal.org/user/21228)

Remember when you asked a question, especially one you were timid about, and got a helpful response? Helping earns you gratitude and increases your knowledge. Fox (drupal.org/user/426416, hefox on IRC) is establishing a reputation as an “honest to goodness [Drupal] genius” by answering questions in IRC. Fox is approaching an encyclopedic knowledge of Drupal and yet still has momentsof not knowing ananswer:“I was curious so I searched for it.”

It really is that simple: sometimes all someone really needs is for another soul to do a five second search for them instead of telling them to search on their own or read the handbook. Taking the extra 30 seconds to point them in the right direction also helps you; refining your search skills is never bad idea, especially when it comes to web development.

Angie Byron (webchick, drupal.org/user/24967) started in Drupal by answering questions, which eventually led to offers to do Drupal odd jobs for a few hundred dollars a pop. Now she's the Drupal 7 maintainer, a former Lullabot consultantand now director in the office of the CTO at Acquia, the author or Using Drupal, and all-around Drupal community superstar!

Chapter 9 lists places where you can get help; these are also the places where you can help others. Check in on the forums at drupal.org/forum, subscribe to some groups at groups.drupal.org, sign up for some mailing lists, go to Drupal meetups, or hang out in Drupal IRC channels.

4. Writing Documentation for Drupal.org

Perhaps the most important way to help the success of Drupal, and certainly one of the best ways to learn while doing, is to write documentation. You might build a powerful Drupal site equipped with all the bells and whistles and have it working perfectly without a single bug, but its impressiveness dims if people can't use it or continue its development. Complete documentation for people developing, administering, or simply using a Drupal site can make the difference in the success of any Drupal project.

There is a terrible misconception floating around that you are not allowed to write documentation if you don't know enough about writing or don't know enough about Drupal. We, the authors, don't know how this came to be but it is not the case at all.

First, anything is better than nothing. It's much easier for someone else to improve the writing style or technical detail of existing documentation than it is to write it from scratch and find where it belongs. Of course, you can also be the person who improves the clarity or updates information on the existing documentation.

Second, if you're reading this book and you've made this far, we're willing to bet you can read and write—and that you have some interest in Drupal. Congratulations! We now pronounce you qualified to write Drupal documentation. There are no tests to pass when it comes to writing documentation. Just write simple, non-verbose, step-by-step instructions.

In fact, a lack of Drupal sophistication can be a distinct advantage in a documentation writer! It makes you much more likely to notice areas where users will need help, processes that make no sense, and places that beg for explanation.

Anyone with a drupal.org account can add and edit documentation. You can get an account at drupal.org/user/register and you can create documentation pages via drupal.org/node/add/book. Before you add a new page, do a search to make sure what you want to add doesn't already exist. You may find that a page does exist but it wasn't linked where you expected to find it. Adding links to related documentation will help others find the right page and is one of the most high-value, low-effort contributions you can make.

Some pages can only be edited by people given the “documentation” role on drupal.org, which lets you post content with tables and images. If you are already a regular contributor to the other documentation pages, you will probably be granted this role. More information on getting more involved with documentation can be found at drupal.org/contribute/documentation and drupal.org/contribute/documentation/join.

That's all you need to know to get started! You certainly don't have to set out with the single-minded goal of contributing to documentation to make a big impact. As you work with Drupal, improve the documentation whenever it lets you down.

5. Contributing Patches

Contributing patches does not necessarily mean contributing code. The novice tag (drupal.org/patch/novice) is a way to tag and sort core issues that are relatively simple to resolve. Just changing the wording of a comment got Benjamin listed as a code contributor to Drupal 7!

The more users get hooked on making Drupal better, the better for all. Drupal will not be able to support the growing user base if contributions do not keep pace. Currently, less than 1% of Drupal users are contributing back. That means that 99% of users benefiting from Drupal are not paying it forward. But even at that meager percentage, Drupal is able to do amazing things!The leverage of your contribution is huge.

Another great way to start writing patches is to participate in a code or documentation sprint. These are self-organizing, informal gatherings of developers where participants work collaborative to complete code and documentation enhancements. The main Drupal Groups Events Calendar (groups.drupal.org/events) allows you to filter by event types if you aren't already a member of your closest Drupal group.

Keep an eye out for users who post topics in group forums or discussions that point back to the issue queue. These people are trying to rally troops to get something done! Documentation on creating patcheswith Git can be found at dgd7.org/patch. Additionally, you can find instructions for applying patches at drupal.org/patch/apply and creating patches at drupal.org/patch/create.

6. Contributing Code and Design

Contributing to Drupal by writing and maintaining projects is covered in Chapters 15 and 16 on theming, Chapters 18 to 24 on module development, and Chapter 37 on maintaining a project on drupal.org.

7. Curating Issue Queues

Another huge way to contribute to Drupal (and to the health and sanity of people writing code and documentation) is to help manage the vast number of questions, requests, and reports of problems. Every project on drupal.org has an issue queue. The goal of issue queue curation is the following:

• To close issues that aren't relevant or can't be reproduced (or understood).
• To get the right eyes on what is addressable.
• To try to fix the problem yourself!

If you are looking at an issue and it's not clear how to do any of these things or even add a useful question or clarification, simply move on to the next issue.

Authors throughout this book have encouraged you to file issues when you run into a broken part of a project (a bug) or even a missing feature. And as much as project maintainers want to hear from you, merely just adding to their pile of things to deal with is unlikely to win you many points. Daniel Kudwein (sun), a developer and designer who deals with dozens of pages of issues in his own projects' queues, has a suggestion on his user page (drupal.org/user/54136).

If you are asking yourself why your issue has not been resolved yet, then please have a look at my queue: drupal.org/project/user/sun. If you want me to help you, you want to help me—by testing other patches or answering support questions of other users. :)

Pitching in by sorting through the accumulated input from the Drupal-using public is a direct way to earn the good will of a project maintainer. If it's a project that you care about, you will also benefit from increasing your own knowledge about the project's rough edges and strengths. All the while you're paying it forward.

Sun's recommendations for helping in project issue queues are summarized below:

• Find maintainer directions. (Not all project maintainers offer them or are as responsive as sun.)
• Find duplicate issues.
• Set the status of one of the issues (usually the newer or less active issue) to closed (duplicate).
• Link to the open issue.

  Tip You can create a link that will expand to include the title of the issue you link to by entering only the node ID in brackets, preceded by a number sign, like this: [#1207734].

• Leave a comment on the open issue inking to the issue you closed, such as “Marked [#1234578] as duplicate.”

• Find related issues. Two issues may not be exactly the same, yet all the people involved in each should know about the other one to help each other. In Linux Journal's February 2011 interview with Angela Byron, she said that she spent a lot of her time as maintainer ensuring that developers who were working on similar initiatives in core were in touch with each other.
• Review patches. (This is covered separately later in this chapter under “8 Reviewing Contributions of Others.”)
• Answer support requestsand close support requests (set status to fixed) where the original poster seems to have received the information they need.
• Set the status of bug reports that don't have enough explanation or detail to be reproduced to postponed (maintainer needs more info).
• Close useless bug reports. In general, anything marked needs more information and without a new reply from the original poster (sometimes abbreviated “OP”) for more than a week or two is not reproducible and can be marked closed (cannot reproduce).

For an excellent example in community management of a project's issue queue, check out the Views Bug Squad. While some of the rules of engagement are specific to the Views module and the styles of Earl Miles (merlinofchaos, drupal.org/user/26979) and co-maintainers Daniel Wehner (dereine, drupal.org/user/99340) and Lynette Miles (esmerel, drupal.org/user/164022), most of the advice can be applied to any module, theme, or other project. In particular, see the “How to Use the Issue Queue” page (http://drupal.org/node/945492) in the Views Bug Squad Handbook (drupal.org/node/945414).

Figure 38–1. The Drupal core issue queue, sorted by Last updated.

In her talk about the Drupal community at the Pacific Northwest Drupal Summit, Angie Byron issues a challenge to us Drupallers to answer one support question or forum request a day. The goal is about making progress, moving along steadily instead of in one giant cram session. Angie's video and slides are available at webchick.net/node/80.

8. Reviewing the Contributions of Others

OK, so every method of contributing so far has started off with a claim that it's the most important and it's a great way to learn. They really all are! And in particular there is a crying need for reviewers. Reviewing, like writing documentation, is a particularly powerful way to learn how the Drupal software and community work while getting a sneak peak at upcoming developments.

Like so much else in Drupal, reviewing centers around the issue queue. Issues ready for review are marked with the status needs review. To find issues for Drupal core that need review, go to drupal.org/project/issues/drupal and filter by status.

One of Drupal 7's new features is the Dashboard. You can add blocks of information (direct links to content, Drupal news, project specific issue queues) that you want to have at your fingertips. Keep current on the number of issues per queue by adding the Contributor Links block to your Dashboard (Figure 38–2).

Figure 38–2. In the Contributor Links block, note the Patches to review link under Queues.

Using Dreditor to Review Patches

All the professionals and cool kids (well, a lot of them) use a Greasemonkey script called Dreditor to perform patch reviews. Dreditor stands for Drupal editor; it's script that turns your Firefox or Chrome browser into a patch reviewing machine. Created by Drupal angel Daniel Kudwein (sun), it's available at drupal.org/project/dreditor. To use Dreditor, simply highlight a part of code you want to comment on, type your comment in the box that appears on the left, and click Save.

Until you click Cancel, Dreditor assumes that you are you still are viewing the patch. If you try to review another patch by clicking Review, Dreditor won't bring up the new patch you want to review; instead, you continue editing the first patch.

9. Making Drupal.org Better

One of the ways to make the greatest impact on the whole Drupal community is to help improve drupal.org. It has gone through a major redesign in partnership with Mark Boulton Designs; all needs and goals are well-identified. The high-priority features are outlined at drupal.org/node/1006924. You'll notice that many sections still need to be upgraded to Drupal 7. There's no better time to be effective, to learn, and to be part of the team contributing to the Drupal project in the most direct and important way possible. Key parts of improving Drupal.org fall under the new Prarie Initiative, groups.drupal.org/prarie-initiative.

Drupal.org is the Drupal community's “online office”, as Angie Byron (webchick) called it in her DrupalCon Chicago panel on Scaling the Community. Angie is following up her three-year leadership stint on Drupal 7's development by concentrating on making drupal.org rock ever harder! What a fantastic member of the community to get to work alongside. Get started by reading “So you want to help make Drupal.org awesome?” at drupal.org/node/1006562. The unstoppable Derek Wright (dww, drupal.org/user/46549) maintains an installation profile for creating copies of drupal.org on which people can do testing and development at drupal.org/project/drupalorg_testing.

10. Hosting and Organizing Meetups, Camps, Summits, and More

“It is fascinating to think that only a few years ago, the main DrupalCon was smaller than today's DrupalCamps. It's even more staggering when you realize that on any given weekend, there are probably several DrupalCamps happening in cities all around the world. It blows my mind. In-person meetings have been instrumental to Drupal's success and growth. If you want to grow Drupal in your area, consider to put on a DrupalCamp and to organize regular meet-ups. It is the best way to bootstrap and foster your local Drupal community.”

—Dries Buytaert

The fact that we now have a half-dozen terms regularly used to describe Drupal gatherings indicates the demand for these events.

DrupalCons are multi-day conferences traditionally held twice a year (one in North America and one in Europe). DrupalCons are now reaching about 4,000 attendees. As Drupal grows, DrupalCons grow to reflect the diversity of the community attending from offering paid training to vendor booth areas. The week always culminates with a day of sprints, where people use the opportunity to work together on code and documentation. Conversations are happening in the world-wide community, particularly Asia-Oceana and Latin America, to add more DrupalCons outside North America and Europe axis.

Drupal Summits are like mini, regional DrupalCons, multi-day, multi-faceted events. Drupal Summits are a new category, and the Pacific Northwest Drupal Summit is given credit as being the first to use the term. The first Latin American Drupal Summit happened in January 2011 in Lima, Peru.

Drupal Camps are a one- or two-day event with multiple presenters that are usually held once a year per city. Camps can be organized BarCamp style (all sessions chosen on the day of the event) or the schedule may be set ahead of time. The Drupal Camp Organizing Guide can be found at groups.drupal.org/node/10437. There are also camps organized around a theme. Specific design-focused camps arose from people wanting to work together to improve design in Drupal. The first Design for Drupal (D4D) camp happened in Boston in 2008. Now there have been D4D camps in Boston, Los Angeles, Stanford, and Prague.

Drupal Meetups occur in cities and towns the world over. Many are held at a regular monthly time and feature lightening talks (5 to 10 minute presentations on what people are doing with Drupal) and time for attendees to ask questions and get help or advice. For information on hosting meetups, see the Local User Group Organizers group at groups.drupal.org/local-user-group-organizers, and Drupal educator Heather James' writeup of different meetup styles at acquia.com/blog/heather/what-do-you-do-your-drupal-meet.

Drupal Cafésare usually smaller gatherings than the meetups and always held where food and drink are readily available.

Drupal Dojos are smaller gatherings geared toward free, focused community learning. Austin, Boston, and Seattle hold weekly or twice monthly Drupal Dojo training/co-working sessions.

Drupal Katasare Dojo sessions focused on a particular project.

Sprintsare events that result in doing, such that organizing one is a double contribution. You can have code, documentation, marketing, and planning sprints. Sprints can be open or limited to advanced levels. Decide in the beginning whether you want to teach, code, or have a hybrid, and make sure to include your plan in your announcement. Sessions are always more productive when expectations are set up front.

Drupal parties are newer entries to the scene. There were more than 300 independently-organized Drupal 7 release parties in 96 countries in early January 2011!

Drupal Dev Days (drupaldays.org), a hybrid camp-sprint-summit event, drew hundreds of developers from a dozen countries to Europe in February 2011.

The most important thing to note is that hosting and organizing is not top down. You can't organize a DrupalCon by yourself but you can certainly be part of putting one on. You can put on smaller events yourself andbe the catalyst for the rest of the event types. Get creative—JohnZavocki (johnvsc)began to hold drupal Play Dates randomly across New York City, and George Matthes stepped up to be a regular host.

Here are some good points and tips to keep in mind when deciding to organize, host, and plan for a sprint or camp where code work is going to be executed:

• Find a place with stable Internet connection. Small code sprints can even be held in people's homes.
• Try to get veteran programmers involved and make sure someone with commit access to the project(s) is present or available remotely.
• Have one primary person record issues and who is working on them. Keep notes on a Drupal wiki page or real-time collaboration document such as Google Docs or Etherpad (piratepad.net).
• Have food available. Everyone will eventually get hungry!

11. Money

Writing a check is a perfectly valid way to contribute and is always appreciated. If you are unsure where to contribute or don't have time to give to coding or organizing, donating money is great way to demonstrate your support. It takes money to put on events, purchase food for code sprints, and get insurance for camp attendees. The following are ways to monetarily contribute to Drupal.

Donating to the Drupal Association

The Drupal Association pays for things relating to the drupal.org infrastructure and works on selected other things, such as promotion of Drupal and fostering the community. It is extremely important work. Drupal has distinguished itself by providing excellent community support. As communities grow, their support requirements change. If you become a member of the Drupal Association, your membership is an annual contribution. For more information on the benefits of membership, go to association.drupal.org/membership. Once you are a member, you can give more at association.drupal.org/about/donations.

Sponsoring Events

Drupal events can always use sponsors. Drupal conferences may not have a sponsorship slot you can afford, but the nearest Drupal Camp most certainly will. (And if there aren't any Drupal Camps near you, see the section about hosting your own events!)

Sponsoring Developers

Drupal developers are in high demand, but some of those who have contributed the most are doing so on their own time. Sponsoring development by people with a good community track record is a great way to give thanks. Say there's a module that you repeatedly use, but perhaps it isn't very popular because it serves a niche purpose—but it serves it well. Check in with the maintainer(s); they might be working on their own time and could use some monetary compensation.

Scholarships are another way to sponsor developers. There's no formal process for this, but if you know someone who should be presenting at a camp or conference, you can ask if they have train or plane fare or lodging. You can usually reach out to community members through their drupal.org contact forms.

12. Making the Drupal Community Welcoming

“It's really the Drupal community and not so much the software that makes the Drupal project what it is. So fostering the Drupal community is actually more important than just managing the code base.”

—Dries Buytaert

Our main challenge is keeping the community welcoming and supportive as the community scales. Drupal's Angela Byron (webchick) graced the cover of Linux Journal in 2011 for her leadership in the community and work on Drupal 7, yet her first contributions to any free software project came 10 years after she was introduced to and excited by the concept. The myth that kept her out was that you have to be Einstein smart to contribute to open source. “You don't have to be,” she said. “There are a lot of smart people, but there's also everyone else contributing and sharing what they know. And that can be anything.” Drupal is very, very lucky to have gotten webchick and not lost her to Linux, but how many potential awesome contributors have we (and all open source projects, and the world) lost? It is an inescapable conclusion that we're losing potential contributors because they do not have an inflated ego. We need to work to remove the false perception that you have to be some X level of smart to do Drupal and contribute to Drupal.

Studies have shown that doing something to break (or simply distract people from) a lack of confidence disproportionately and significantly helped the test scores of underperforming groups. This is called the stereotype threat, and you can help combat it simply by welcoming everyone as a contributor.

This also means we need to continue to be conscious of valuing all contributions, not only code. And just as people who come for the code stay for the community and begin to contribute in many other ways, so too people who start contributing through support, reviewing and testing, and documentation may end up making significant code contributions.

The opposite of treating everyone as a potential contributor is stereotyping anyone for any reason. Drupal IRC channels have guidelines disallowing talk that is sexist, racist, or homophobic (see drupal.org/irc/guidelines). Inappropriate comments become a problem when they are not addressed. People must speak up when they see someone undercutting another's right to equal treatment. By and large, the self-policing has worked. The advice is simple: Be sensitive to discrimination, and take action when it happens. It can mean the world to a community member to see someone step in and say “we don't do that here.” Avoid a long awkward silence. Hopefully other members will back you up and soon move through the discussion.

We must ensure that our community treats everyone well. We need to be conscious of valuing all contributions and members regardless of sex, age, race, or economic background. It is impossible to remain isolated from the larger issues of economic and social disparities but we can make an effort to ensure that we avoid reproducing or compoundingthem within our community. Rethinking our models of collaboration, funding for low income web-projects, teaching and training are great ways to start.

Diversity makes free software more powerful. Drupal has a pretty diverse group of contributors in terms of backgrounds and countries, but traditionally, open source free software has an abysmal proportion of women participating. In fact, less than two percent of open source developers are women, versus 20 to 30 percent of proprietary software engineers and developers. Drupal is doing somewhat better with a 10 percent female participation rate, but there is still vast room for improvement. The DrupalChix group (groups.drupal.org/drupalchix) exists to address the underrepresentation of women in Drupal with the fortunate fact that we can do something about it. All-in-all, the Drupal community is showing excellence in keeping our environments safe and friendly to all.

Building the Movement

There is no grand plan coordinating the contributors to Drupal, which, according to Angie Byron, “gets really interesting if you're trying to take the initiative of making something happen in the community because you're trying to make a lot of individuals believe that the same thing is important. The community is founded on the concept of “do-ocracy” ... the only way things get done is if someone actually does them. It's a pretty simple concept, but there's nobody being paid to care about Drupal core, there's nobody paid to care about their modules unless they have some sort of special arrangement, so people care about stuff because they need it and they just dive in.”

Amazing things have been accomplished (and amazing things are in the works) with this approach, but it's also worth noting that it is our ability to do some level of planning and coordination that makes it work. Drupal has been at its best in areas where:

• People are able to contribute without (or with easily obtained) approval.
• Tools for coordination exist and the process and authority for making decisions is clear.

Where either of these are true, such as in Drupal core and contributed projects, Drupal is often at its best. Whether ironically or fittingly, working on improving these two qualities in various places in Drupal are where you are most likely to require approval with no clear means of coordinating or making decisions (see dgd7.org/resistance).

Perhaps the most exciting thing about working on these points—how do many people work together on complex, crucial projects without structures of control or coercion, economic or otherwise?—is that they are critical, not just to Drupal's success but to making a better world.

A better world is what a surprisingly large amount of people mean when thinking about Drupal as a movement. Similarly, many people in Drupal are aware that Drupal, by giving them the ability to contribute to world-changing software and to make a living at the same time, is a unique and wonderful gift.

We share this gift each time we introduce others to Drupal but it's also possible to use our sense of community and the practices we put in place to build community beyond Drupal. This has not happened much yet, but Drupal has remarkably conscious people throughout the community. Josh Koenig (joshk, drupal.org/user/3313), founder of Chapter 3, one of the first Drupal shops, recently wrote on his blog: “We are entering a time where the potential exists for the first time to create an effective and non-oppressive set of rules that span the entire globe. Only within such a framework of global scope is a working post-industrial economy with 6 billion participants humanely possible.”

Acting on this widely-shared desire for a better world in concert with the work we are doing to build a stronger Drupal community could dramatically increase our effectiveness at building both. After all, the software itself is mostly about communication and coordination, the underpinnings of all accomplishment and power. We, the people working with Drupal, have an opportunity to transform a historically temporary increase in autonomy and fair pay intocrucial support of the struggle forliberty and justice for all.

The hardest work in Drupal is building the community while preserving its ethos: making it so people can contribute in every way possible and creating ways to coordinate to get great things done. This work, overlapping as it does with the pressing needs of our planet, is also the most exciting.

See you in the issue queues—and perhaps in person and in whatever else the community comes up with!