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 Drupal.org 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 Drupal.org 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.

DrupalCamp Indy 2010 is coming!  October 23rd will be here before you know it.

Here are a couple of fliers I put together, short but sweet, emphasizing our newbie-friendliness, awesomeness, and how we have something for everyone.  Please help us spread the word.

I rarely write about feminism.  When I have, it has to point out the foolishness of pushing non-tech women into technology in the name of gender equality, and trying to obscure the ability gap by pressuring competent women to spend too much of their time with the incompetent ones.

This time I'm writing about a brilliant article I came across on twitter (thanks @crell).

Many web developers, especially Drupal developers (who are in particularly high demand these days), won't touch speculative work, period. With so many options available to us, we can choose work that will pay now over work that might pay some day. Still, not everyone who has an idea has the front money to build it. I have had some luck with speculative web development work over the years, and I thought I'd talk about why I do it and how I choose which projects are worth speculating on.

Not long after I diverted from my former career path to pursue life as a Drupal consultant, I received the following advice from a trusted friend: "Every good independent web developer has a project or two that is their own, besides what they do for their clients." It's turned out that he is right. Good speculative work gives me a chance to build a product I'm really happy with, free of portfolio-harming client compromises and NDAs. It also provides me with important experience following a project through its entire life cycle, so that I can jump into my consulting projects and easily answer "where do we go from here?" no matter what state the site is in. Finally, good speculative work gives me something potentially profitable to do when my consulting business slows down. Instead of having tons of work or no work, I have tons of paying work and a little speculative work to fill in the gaps, which is better than no work!

Despite the potential benefits of developing a few well-chosen speculative projects here and there, there will always be far more demand for speculative development than there are developers available to fill it. I, like every other developer who considers speculative work, must somehow separate the wheat from the chaff. There isn't a formula for a successful project (if there were, we'd all use it and be rich) but here are some key points to consider before taking (or offering) a speculative web development project:

Today's BoF for new Drupal contributors went better than I could have hoped. I've seen three of the participants in the issue queue already! One thing that came up at the BoF session was taht new contributors aren't always sure how to set up their dev environment and choose tools that will make playing in the issue queue easier