Difference between revisions of "Volunteer philosophy"

Revision as of 19:44, 12 January 2009

(Adapted from an email that rahaeli wrote for the dw-discuss mailing list.)

We believe that Dreamwidth should be something that the community builds together. To that goal, we are always eager to listen to our volunteers, and we believe that jumping in to volunteering should be a quick, painless, and easy process.

There are three very important philosophies to keep in mind when working on this project:

• Don't forget we have to use what we build.
• Don't repaint the bikeshed.
• Don't let process kill innovation.

Don't forget we have to use what we build.

There are always at least two ways to design processes: the way that will require 10 hours of effort now, but require 100 hours of effort a month spent on process upkeep, and the way that will require 100 hours of effort now, but 10 hours a month spent on process upkeep. This also applies to situations where we take the easy choices when designing a feature and decide to address any problems by user education later: when we don't spend the extra 10 hours during development to figure out a flexible and intuitive interface, we wind up spending thousands of person-hours over the next five years teaching users how to use the feature.

Our goal, in every situation possible, is to simplify the processes we create and streamline the functions we have to do every day to make them more efficient, even if it means tearing everything out and starting over from scratch, because it'll save us all time later.

If you have the option between doing things quickly and doing things in such a way that will save considerable time down the road, choose the second option. Ideally, both our site and our process will be flexible, intuitive, and expandable.

Our process-design philosophy should be "motivated lazy": do the work now to save the work later.

Don't repaint the bikeshed.

The bikeshed metaphor, also known as "Parkinson's Law of Triviality", is an old management adage that's particularly applicable to open-source or community projects.

People who feel out of their depth commenting on big and complex problems will feel very comfortable commenting on trivial problems, and will advocate passionately about their opinions on those trivial problems because they're familiar and non-threatening enough to feel 'safe'. On many projects, this can result in solutions to major problems getting implemented quickly and without fuss, while minor or trivial problems get bogged down in debate for days and weeks.

Denise and Mark are both very committed to letting Dreamwidth's users paint the shed whatever color they want. This is something we need to ingrain in process development from moment one. Our goal, as we create our volunteering culture, is to place an emphasis on compromise. The vehemence with which we argue a particular viewpoint should be directly proportional to the severity of the problem; "don't sweat the small stuff" should be a major project guideline.

When a project group is brainstorming, or when you receive feedback on a project you're designing, keep this principle in mind. Always ask yourself: am I arguing about what color the bikeshed should be? It's always okay to suggest improvements or brainstorm ideas, but keep a careful eye out for signs that you're perpetuating a holy-war that should be allowed to die a graceful death. And if someone says "hey, I think we might be having a bikeshed problem here", don't hesitate to ask for a third-party arbitrator.

Don't let process kill innovation.

Mark and Denise want Dreamwidth's organizational culture to be fast-moving: project teams will form around particular issues/enhancements/ideas, either with Denise and Mark assigning a project leader or someone taking point on an enhancement they want to develop. Project leaders should feel like they're empowered to make decisions. Mark and Denise will give as much or as little feedback and supervision as the team collectively desires.

Every process we build should keep this goal in mind. Micromanagement kills projects dead; we want to avoid it at all costs. Project leaders should encourage innovation and independent thinking! Our organizational structures should be as shallow as possible, and everyone should be given authority to make decisions for their area of specialty.