Home / Comment permalink

Starter tips to engage with the Drupal community

It is very common for people to have a hard time starting out with Drupal and gradually improve their relationship with it–I mean both the software and the community! I'm going to take the liberty here of sharing some of the insights I have gained over the years that can help you in and help you through the tough spots.

My history in open source

I started actively contributing to the PHP community in 2000 and Drupal a few years later, so I have had time to figure out how you can find your place and become an active member of an open source community. I presented sessions titled Come for the software, stay for the community and This is horribly broken - how can we fix it, at Drupalcon Copenhagen 2010 and Drupalcon Chicago 2011 respectively, approaching the problem from two different angles.

Get into Drupal, the software

While Drupal is great software, you still need to add modules to get the features you need for your website, and themes to dress it up. Most people find it hard to pick the right modules and figure out how to assemble their site with the thousands of more or less compatible building blocks available. Thankfully, help is available nowadays, in the shape of books like Using Drupal, a stream of Drupal.org success story posts detailing site recipes, and the increasing numbers of ready-made distributions. There is even a site called Drupal Distro Watch to help you find your way through the maze of distributions available – drupal.org doesn't offer a good way to follow these developments, yet.

Keeping your finger on the pulse of the community can also help you follow the constant innovation that is going on. Site recipes, techniques and technologies can be considered best practices one year and obsolete the next. Your best community resources are the Drupal Planet and Groups.drupal.org. If you don't subscribe to the planet and find the groups that talk about the topics that interest you on Groups.drupal.org, you are missing out big time!

Get into Drupal, the community

Get to know Drupal in person! Drupal is as much about its community (if not more) than its software. The best way to become part of it is through local meetups (technical and social meetings of all sizes) and Drupal Camps (usually one- or two-day mini-conferences with up to hundreds of attendees). You can find these on the Drupal events calendar (and Drupal Planet and by finding your local or regional group on Groups.drupal.org). Meeting people involved with the local Drupal community can give you friendships, contracts, business partners, employees or even just a bunch of fun.

So now you have a problem

Once you know some Drupal, some Drupal people, and some Drupal people know you, you have a better chance of getting your questions answered or getting some help when you are stuck, neck deep in your Drupal project. One thing, though: being polite and articulate gives you the best chance of getting (good or productive) answers. Being rude or expecting that your priorities are other people's won't get you very far. If you can establish that a problem you are having is a problem with some part of Drupal, learn to turn your polite articulate questions into concise issues for the module in question–include enough information to reproduce the problem, no more, no less. Submitting issues is a great way to contribute to the community and doing it well can get problems fixed and boost your reputation as a productive Drupalist. People might find your issues later and work on them, or others might decide to steer clear of a particular module when they read your issue.

Submitting issues is still no guarantee that they will be solved any time soon, if ever. Sad, but true. If you want an issue you submitted to get priority treatment, finding the right people can help! Project maintainers are listed at the top of the project page and Drupal 7 now has a MAINTAINERS.txt file where you can look up people to talk to. Most project (module, theme, etc.) issue queues have some dedicated volunteers who spend time there, too. If a module is critical to you, these people might well have similar interests and be your best audience when looking for help, but it's still no guarantee. All of the above mentioned people are busy. You might have luck with people active in popular discussions about your topic or module on Drupal.org. Check who edited relevant documentation pages recently, names that come up in commit logs and files ... if you come up with any other clever ways of tracking down helpful people, I'd love to know how you did it!

Of course my very bright colleagues at Acquia and I, don’t just know about the intricacies of various modules, we are also eager to help you architect your site and fix issues from small to highly complicated. Whether you use Drupal Gardens to build your sites, need your custom Drupal setup assembled or scale to big enterprise needs, we help you find solutions for your problems.

Everything you do with Drupal is a contribution

I looked at Drupal.org statistics while preparing for my Drupalcon Chicago session, and saw that there were 2.2 million unique visitors on Drupal.org in January 2011. In that time, 7000 unique users submitted posts and 10000 unique users submitted comments. This means that for every poster, there are about 300 who will just consume the content. This means that your contributions are very valuable! Even if you only submit issues, you are making a contribution, but you’ll be exceptionally well-loved if you help issues move forward or improve documentation pages. Find places where you can help out, become a household name! And by the way, making a name for yourself by being helpful will help you get your issues fixed, too. People will know you come back with contributions yourself. Anybody can contribute to documentation on drupal.org, the documentation pages are free to edit. If you know a foreign language, translations are easy to add to and even micro-contributions are very welcome and important.

Welcome, you've made it!

If you made it this far, you are a full-fledged, card-carrying, secret-handshake-knowing member of the Drupal community. If you can find time to contribute, do so. Make your voice heard; do presentations about what you know at Drupal meetups, camps, cons; blog about Drupal and get your blog on the Drupal Planet; contribute your custom modules to Drupal.org; submit issues as you find them (and work on them yourself). You’ll be thankful you did, the rest of us will be thankful you did, and we will all benefit from being part of the community instead of just pulling down the software as it is being produced.

See you there!

Comments

Posted on by David Hernandez.

I've been reaching out recently to a number of people about helping out with various initiatives. It is a bit messy, without Drupal having a well-defined hierarchy of who to go to to volunteer for various things. I think people also need to understand that high visibility also creates high prominence. A lot of new people don't feel comfortable directly contacting someone highly "visible", assuming they are being a bother. I've spoken with a number of other people who would also like to volunteer, but are not coders, so they aren't sure where they fit in. Everyone points to documentation, but I feel there should be other options. Not everyone is comfortable writing public documentation, but they might be excellent project managers, organizers, designers. It appears Drupal needs some, well, sheep herding.

Posted on by Gábor Hojtsy.

Yes, it might not be an ungrounded idea that the top listed people are busy. That is why having the MAINTAINERS.txt might not help you contact people in the right areas. I've mapped out an idea in my talk which would need implementation however.

We should tag the Drupal core files as well as modules with meaningful tags based on their code. Then we should use more meaningful tags on issues and can tag documentation pages. Now once we have all these tags, we can aggregate them based on people! So the people who are mentioned in commit messages for a file, contributed to issues tagged similarly and edited doc pages tagged with certain tags will get those tags on their user profile. So you could look up not one but dozens of people working on field API, form API, views or drupal commerce. This would let you find people who are probably less busy but equally interested.

Finally, some modules do have the herders that you wish there were. Views for example, has an issue queue squad helping maintainers to clean up and respond to issues that do not require the maintainers. Unfortunately the project page will only expose the committers, not all the others who have herding permissions in the issue queues (and therefore high likeliness they have insight into things regarding the module). This would be a matter of having a front end UI for the data which is already in the permissions assignments on the admin page of the module.

I think this later simpler improvement and the former more complex but very powerful improvement would let you find people related to certain efforts, figure out structures, who's most active, etc. without putting in lots of individual time to track this down. For the former idea, all the data is there, you just need the time to dig. We should eliminate the human effort there I think.

Posted on by David Hernandez.

Tagging Drupal core files is fine for things that are directly module/code related. Tagging documentation pages is fine for documentation. But, what about everything else? It seems like this is a more sophisticated way of finding people that commit code. Which is great, if that is what you need. But what about people who want to participate in redesigns, or community outreach? A module maintainer is not necessarily someone who wants to participate in that, or even be the right person for that.

I guess I'm thinking if groups.drupal.org was better organized, it could be the place for that. Every initiative and part of Drupal (I don't mean code) can have a separate group and the admins of those groups are empowered to make actual changes in their respective areas. As it stands now, it doesn't seem like people are empowered to make change, or know who to go to do so.

Posted on by Thomas Svenson.

I agree totally with @davidhernandez. I'm one of them he kindly took the time and contacted in person about helping me being able to help out more.

I have also been quite active lately in some very good discussions on g.d.o that have highlighted a lot of these issues. At least for me these discussions have been very fruitful and I have been able to get in contact with the right people. Resulting in getting involved with a few things that will help improving the community.

Still, as David say there are most likely a lot of great users in the community that we miss out on and would be able to become fantastic resources for project management, organising, designing and so on. We just need do find ways to make that step a little easier and more comfortable for them to take. I'm sure many of them want, but feel their skills are not really needed.

Add new comment

Plain text

  • No HTML tags allowed.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Lines and paragraphs break automatically.

Filtered HTML

  • Use [acphone_sales], [acphone_sales_text], [acphone_support], [acphone_international], [acphone_devcloud], [acphone_extra1] and [acphone_extra2] as placeholders for Acquia phone numbers. Add class "acquia-phones-link" to wrapper element to make number a link.
  • To post pieces of code, surround them with <code>...</code> tags. For PHP code, you can use <?php ... ?>, which will also colour it based on syntax.
  • Web page addresses and e-mail addresses turn into links automatically.
  • Allowed HTML tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <h4> <h5> <h2> <img>
  • Lines and paragraphs break automatically.
By submitting this form, you accept the Mollom privacy policy.