The Drupal Support Gap

Categories: imported

The Problem

We lack a clear and inviting path from discovering Drupal and learning how to use it to becoming an active and productive contributor. As a result, our most active developers are plagued by the support demands of intermediate users who have outgrown the forums and don't know where to go. This effect is compounded both by our failure to attract and assimilate new highly qualified support-givers, and the myriad bad behaviors that newbies are learning in "newbie ghettos" such as the forums -- behaviors that make it difficult-to-impossible to adequately support them and bring them into the wider Drupal community.

The Solution

  • Phase out the forums in favor of a more straightforward Q&A format resource.
  • Treat posts that resource as not just the answering of this question here and now, but building a useful searchable reference into the future. Be brutal in eliminating off-topic chatter and duplication (but as kind as possible in explaining why a question was closed) ala StackExchange.
  • Provide easy gateways from that resource to more active participation in the Drupal community: IRC, issue queues, doc team, translation teams, GDO, etc.
  • Improve the consistency of IRC and Q&A moderation by setting up a venue for moderator docs and discussion.


Why is this important?

Most users' first community interaction will be in the form of seeking support. That support-seeking experience will form the basis for how they interact with the Drupal community in the future.

If we can sufficiently improve our primary support venue, we can expect:

  • Fewer people trying to get support in inappropriate ways, such as by clogging the issue queues or demanding the personal attention of our most active devs every time they have a problem.
  • More new Drupal consumers to eventually evolve into active Drupal contributors.
  • Fewer behavior problems in IRC and the issue queues.
  • Users utilizing a search engine to solve their Drupal problems to get more useful results more often.
  • The Drupal learning curve to seem a little less onerous to new Drupallers.
  • Giving support on to suck a lot less for the support-givers.

What is wrong with what we have now?

The most active, experienced Drupallers are not active in the forums due to:

  • Poor signal:noise ratio
  • Too much overhead (read: time suck) in following discussion on the webforums
  • A format that does not lend itself to passive participation (i.e. following well enough, with a minimum expenditure of energy, that one would know if a question one actually wants to answer has come up)
  • The support mailing list suffers from the above, plus:
  • Poor searchability
  • Publication of participants' email addresses
  • Intermediate and advanced questions in the venues above get too few helpful responses. There is no clear path to the "next level" of community participation and support. Thus, the post-newbie spillover tends to land in the issue queues, developers' inboxes, and other places where it interferes with active development.

  • Though the forums especially, and to a lesser degree the support mailing list, are sometimes praised for their low barrier of entry due to the lack of behavior corrections present on IRC and the issue queues, this comes at an enormous cost. These newbies visit our supposedly newbie-friendly support venues, learn behaviors (reinforced in the forums) that are exactly what keep the experienced folks out, then are shocked to be treated with less than total acceptance in more active venues. After all, they learned the behaviors we taught them. Why shouldn't they fit in? They're doing it "right".

  • Of course, some newbies never make it that far. Many get caught in the forum cul-de-sac and never find their way to the vibrant, geeky community that really powers Drupal.

What could we be doing better?

A new support venue should:

  • Make it easy for participants to understand the venue's expectations, and how to best get support.

  • Encourage behaviors and approaches (RTFM, search, ask smart questions) that will serve one well throughout one's entire Drupal career, not just among other newbies.

  • Be thoroughly indexed and easy to search. Ideally, this should be part of the main search so that the support-seeker has as few places to search as possible.

  • Reduce duplication as much as possible so that answers are clearer and easier to find, and volunteers aren't needlessly burnt out by having to explain how to log in to a Drupal site in maintenance mode 4,000 times.

  • Have extremely low participation overhead (that is, how much time you have to invest clicking around in order to ask/answer questions).

  • Have an extremely good signal:noise ratio.

  • Provide easy, obvious bridges to other parts of the Drupal community.

  • Be a great example of the culture surrounding Drupal, rather than an isolated ghetto not particularly representative of or connected with our community.

  • Address support questions across a broad range of skill levels and subspecialties within the Drupal ecosystem.

  • Successfully help people with their problems and questions regarding using, theming, and developing for Drupal.


  • In order to successfully address questions in all areas and at all skill levels, the support venue must be attractive to Drupallers with all levels of experience.

  • In order to be of the greatest utility to both individual Drupallers and the Drupal community as a whole, a community support venue should go beyond just answering the question at hand: it should act as a reference for future support-seekers to find, and nudge people toward the behaviors and attitudes that will make their Drupal experience successful in the long run.

  • The Q&A format would be a huge improvement over current venues for Drupal support, specificially because it:

  • Has a good track record. Drupal questions are frequently asked and answered on StackOverflow, and there are nearly 200 people committed on a proposal to add a drupal sub-site to Stack Exchange. (No, this site isn't going to be created, for reasons beyond the scope of this post.)

  • Has low participation overhead, while still being very searchable.
  • Helps teach newcomers the mindset that this venue is a place to get things done, rather than a place to visit (as forums tend to lead them to believe).
  • Puts moderators in the position of being able to close questions for not being real questions, for being duplicates, etc. without the lashback of confused forum users (who generally have expectations based on experience with discussion forums, not support venues).
  • Is an easier format from which to bridge users to proper IRC and especially issue queue behavior: the Q&A format is, in a way, an issue queue designed solely around support issues rather than coding, docs, etc.
  • NO support venue will serve the purposes described above without consistent, appropriate moderation. Consistency would be greatly increased if moderation procedures were documented, and if moderators had a place to privately sanity-check borderline situations before acting. Additionally, moderation standards should be set with the focus on encouraging the right attitudes and behaviors all the time, rather than letting things go until these poor attitudes become expectations and these poor behaviors become habits.

Posted on January 21, 2011 View Comments


Categories: imported

I was recently asked what one needs to know before becoming a Drupal developer. It's a tricky question, both because Drupal draws strength from the diversity of our community, and because it's hard to pinpoint the precise point where one becomes a dev. Below is my attempt at an answer; feel free to suggest additions or changes:

The Basics

Have Patience

Rome wasn't built in a day, nor will your Drupal-fu be. Prepare for trial and error; it's part of life in the open source world.

Speak Fluent English

While Drupal itself has been translated for use in many languages, the lingua franca for development is English. English is spoken in the issue queues, on the [contributor IRC channel)(irc://, and at DrupalCons. If you don't speak, read, and write English fluently, you will miss out on most of what is going on, and you will never reach a high level of Drupal developer-fu.

Use Drupal

You might think this goes without saying, but we do get wanna-be devs who don't really grok what Drupal is or how to install it. It's not necessary to be an expert Drupal admin before your first issue queue visit, but you should have installed drupal at least once and be be using it regularly.

Understand Your Computer

We're accustomed to walking new contributors through using git, rolling patches, etc. We'd rather not have to teach you how to use:

  • Your OS (desktop and server)
  • A web browser
  • email
  • IRC
  • A syntax-highlighting editor with *nix-style line-endings
  • SCP / FTP
  • SSH
  • Your web server
  • basic set-up
  • configure domains
  • view logs
  • Your database server
  • basic set-up
  • create databases
  • create users
  • dump and restore databases
  • empty a database
  • manage permissions
  • A search engine
  • A syntax-highlighting pastebin
  • An issue queue

Understand Markup

A basic understanding of HTML and CSS is needed, nothing extreme.

Understand Programming

It's not necessary to come in knowing PHP, but if you don't, you should have enough programming knowledge to pick up a new language quickly. Some of our devs also know Javascript (especially jquery), some don't; its usefulness depends on what kind of Drupal work you like to do.

Finally, and most importantly,

Know How To Be Worth Helping

  • Ask each question in the right venue.
  • Pay it forward by supporting others, doing issue queue triage, testing patches, contributing code, and documenting things.
  • Be patient.
  • Observe good IRC/forum/ML/issue queue courtesy.
  • Have thick skin; take criticism well.
  • Ask Smart Questions
  • Don't be a Support Leech.
  • Be willing to try things out.
  • Embrace Best Idea First

Bonus Round

You don't really need to know this stuff when you first show up, but any of it that you do know will be helpful in some way:

Resources docs Forums Drupal IRC Channels Drupal Planet Mailing Lists The Cathedral and the Bazaar The Jargon File Using Drupal Pro Drupal Development New Drupal Developer Toolkits W3C

Posted on January 04, 2011 View Comments

Learn this--hacker culture is not optional

Categories: imported

In the past couple of weeks, I've become increasingly aware of how much conflict younger open source projects I'm involved in have compared to more mature projects and projects run by folks with an extreme number of years in open source.

Then I had to explain to my housemate who Donald Knuth is... ...and tell a fellow Drupalista what the Jargon File is... ...and define "grok" for a colleague from the XMPP community... ...and stifle a laugh while my 7-year-old tried to describe the wumpus to someone who should know better... ...after which I read Eric Raymond's recent post on the social utility of hacker humor.

Then I grokked.

In the projects that have been around for a dozen or more years, or those run by hackers who have been, there is a common culture and identity shared by all: we're hackers. Whatever else we are -- country bumpkins, urbanites, gay, straight, bi, male, female, transgender, a particular religion or nationality, old or young, single or married, parent or not, rich or poor -- we are hackers, and all we need to know to work together is that we share that cultural bond of hackerdom.

In the younger open source projects, people are expected to recognize that we all come from different cultures. Not only are we to recognize it, but we are supposed to keep track of these cultural differences and be sensitive to them, which of course means being constantly aware of them. It's all about differences, and "what do people think because I'm a $whatever?"

Meanwhile, I've worked with old-school hackers who were evangelical Christians -- the kind that are as certain of the corruptive nature and future damnation of pagans as they are of the sun rising -- and never had an issue. To those of us immersed in hacker culture, a hacker is a hacker; hackerdom provides enough common ground for us to work together and enjoy it. Without that, people end up bailing out of development discussion because of cultural claptrap.

Successful open source draws on talented people regardless of their religions, sexual identities and preferences, nationalities, disabilities, ages, and other differences. A couple of decades have shown that an extremely successful way to do that is to have -- regardless of whatever else we are part of -- a common hacker culture.

So for the sake of harmony and productivity, PLEASE:

  • Grok some Heinlein.
  • Hunt a Wumpus or two.
  • Remember to bring your towel.
  • If you have trouble remembering your towel, consider investing in sapient pearwood luggage.
  • Read The Art of Computer Programming (yes, the entire series).
  • Read RFC 1149
  • Play Adventure and/or Nethack.
  • Try to "man woman"
  • Keep in mind that Tux is not randy (that would be impolitic!) he's full of fish.
  • And see what Alice and Bob are up to now. ...because failure to look up any of the above via the Jargon File or a search engine kills kittens.

Also, to those of you already indoctrinated in the ways of the hacker, help the newbies around you get some culture. Trust me, it makes us all less isolated from one another, less at odds with one another, and more able to focus on the code.

Posted on September 11, 2010 View Comments

Next Page ยป