We've been in hiring mode for a while now. As most any Drupal Service provider will tell you, there's big demand for people and companies that have an expertise in Drupal. There's also a bit of a shortage of people to satisfy that demand. We've decided on a strategy of hiring great people regardless of Drupal experience and then getting them plugged into the "Drupal way" of doing things as quickly as we can.

There are really two pieces to that process - learning the Drupal code, API, modules and learning how to interact with the the Drupal community and the social values of that community. I distilled some information into a quick document that gives a guide to what I consider to be required reading and actions for anyone serious about being a full time Drupal developer.

Learn the Mantras and the Standards

"Code is gold." Idle discussion or complaining is not valued and will decrease your karma in the eyes of many. Contributing high quality issues, ideally with patches attached, is valued. But don't take the phrase too literally - "Code" is just one thing that's valued. In a big project like Drupal all substantive contributions (e.g. documentation, spam-policing) are valued.

"The drop is always moving." New major releases of Drupal will break the API. This is not a bug, it's a feature. On that topic, releases happen between every 9 months and 18 months. Generally there are about 5 months of feature enhancements before the "code freeze". After the code freeze the only changes allowed are UI improvements, performance improvements, and bug fixes. Once the beta releases start the only changes allowed are bug fixes and string changes. At some point in the betas there will be a "string freeze" to allow localizers to translate the interface. Once a release candidate has been released which saw no new critical bugs a final release will be made. There is no calendar schedule for releases. Only the current and last versions are supported, but more could be if someone skilled enough were willing to do it.

"Where's the roadmap." There is no official roadmap. But with a little effort you can guess it, and if you provide the code then can write it. There are Dries' wishlists, personal battle plans, and predictions for each year. Official roadmaps only barely make sense in command-and-control environments like corporations. Open source projects are Do-Ocracies - the roadmap is determined by those doing the work. That said, the predictions and battle plan threads are great ways to glean a roadmap.

Join Forces With Others. Don't fork modules. We have many modules that do basically the same thing in a slightly different way. That's a great way to lose karma points. Instead you should work together with other developers to make one really great module.

"Don't hack the core." Drupal is built from the ground up to be extensible without having to edit the core code. You shouldn't ever have to edit any of the core or contrib code unless you are providing that as a patch. Instead, use the hooks, overrides, and theme layer to alter the behavior of the code (Laura has written more about this as a theory of open source and practically in our presentation at OSCMS2007).

One-Way Communication you Should Tap Into

• planet.drupal.org - aggregated feeds from around the web
• Drupal.org front page rss feed
• Groups.Drupal.org/rss.xml
• Association.Drupal.org front page feed
• Lullabot podcasts - listen to them all.
• Read Pro Drupal Development - it's really good, particularly if you already know PHP/MySQL.

The Community

• Mailing lists support and devel for everyone. Themes or consulting or others if they interests you.
• Drupal Dojo - great for developers looking to improve their Drupal chops. Provides a Library of past screencasts, documentation, great tips and tricks discussion on g.d.o. Avoid the desire to just use this as replacement for general support!
• Drupal.org forums - they're OK but often deteriorate to lower quality conversation and bickering. Find the ones of interest and grab the respective RSS feeds.
• Groups.Drupal.org - look through the group list, find some of interest, subscribe, and then hit http://groups.drupal.org/unread on a daily basis to see what's new in your groups. In particular look for a regional group near you and working groups on topics that interest you. Both are valuable.
• irc - pound the #
  • #drupal - devel/coding talk only. Unless you are on topic and/or have serious karma don't go off-topic. It's a friendly room, but not always patient.
  • #drupal-dojo - a little nicer than #drupal, but don't push the boundaries. largely for discussion of dojo specific stuff.
  • #drupal-support give and receive support.
  • #drupal-themes - theme discussion
  • #drupal-ecommerce - ecommerce discussion
  • #drupal-consulting - you get the idea
  • See also: Drupal.org Handbook Page

The filtered firehose

If you want to know the top posts from mailing lists but don't need to see a color of the bikeshed discussion, these filtered lists are valuable. drupaldashboard.com - cvs commit messages, important module releases - "Our editors read the lists so you don't have to."

The Contributions

First, go to your Drupal.org account, edit it, and turn on the Contributions Block. Those links are really handy. Here are tips organized by tasks appropriate to your skills.

Aspiring Coder - hit the patch bingo button, apply the patch, test it out and review it (really review, not just +1). Look for any ways to improve the patch that are in the scope of the issue. This process will teach you tons about Drupal's inner workings and endear you to other developers.

Coder - contribute patches (hit the bug bingo), create a module, conform to the coding standards, read the CVS README/FAQ, ask for a CVS account, contribute that module AND support it. Fame, glory.

Themer - provide patches for existing themes (including themes that are in Drupal core). Once you learn theming, write your own theme, read the CVS README/FAQ, ask for a CVS account, contribute that theme AND support it. Fame, glory.

Not a coder or a themer but want to help?

• Refine bugs by using the "HOWTO Make good issue" guide and applying that wisdom to the bugs you find from the bug bingo button. Enormously helpful to all parties.
• Provide help in the handbook refining the documentation. Do it enough and you can join the docs team. Fame, glory.
• Join the support team. Ok, we don't have one. But you can self-appoint yourself to it. See sepeck and michelle for examples of members of the support team - all you have to do is consistently provide help which both of them do in amazing amounts AND they have huge community karma as a result.

Zero to Hero

To go from Zero to Hero in terms of your community karma and also your skills try to figure out the answer to someone else's problem. Great places to find problems are in #drupal-support, the support forums, and the support mailing list. Just pay attention to the chatter, find a problem that interests you and figure out how to solve it. Your knowledge and reputation will shoot through the roof and the discussions of how to solve the problem will teach you about parts of Drupal you would never investigate on your own.

Stay Safe Out there

The Drupal.org Handbook has a section on Writing Secure Code. Drupal provides lots of facilities to make it easy to write secure code, but if you ignore them then you risk danger.

So, what else is out there? Does anyone have any other good, quick ideas for learning the code and the community?

• Greg's blog
•