Enter Blogofile

Categories: uncategorized

You may have noticed that this blog just got a new look. While I love Drupal, I've accumulated so many Drupal instances on my various side projects that the maintenance overhead was becoming a bit much. There's really no reason to maintain an install of any CMS for some of my rarely-changing handful-of-pages sites. So, my personal blog became the guinea pig.

I chose Blogofile for this task because, while the project is still young, it is flexible enough to easily handle both "normal" pages and blog content and it is written in Python (which I've been learning for another project). I'm running a slightly patched version of Blogofile and the blogofile_blog plugin, and still fighting a bit with teaser generation.

Overall, it's been a good experience. The community is helpful, turning a simple html+css mockup into blogofile templates was easy (even for a non-themer like me), and there's something incredibly freeing about knowing that the site itself won't ever need a security update. All the code execution happens on my machine, then I push the resulting HTML and CSS files to my server. The only executable code in this whole blog is the snippet of js that integrates Disqus comments with my blog posts.

Posted on July 14, 2012 View Comments

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

Rationale

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

Conclusions

  • 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

Prerequisites

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://irc.freenode.net/drupal-contribute), 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
  • api.drupal.org

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

Drupal.org docs api.drupal.org Drupal.org Forums Drupal IRC Channels groups.drupal.org Drupal Planet Drupal.org 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

Next Page ยป