As we're moving into the flurry of effort leading up to our rounds of
closed and open beta, we'll be seeing more and more opportunities for
people to get involved in the Dreamwidth project -- either working on
the Dreamwidth open-source code, or working on dreamwidth.org the
hosted product. Both Mark and I think that the amount of enthusiasm
we're seeing from y'all is incredible, and we're very much looking
forward to (very, *very* soon!) having a product that will be visible
without having to check a bunch of code out from our source
repository. :)
As we enter into this new phase of the project life, however, there
are three important principles that we need to keep in mind, and I
think it's important that we integrate them into the site
volunteerism culture as early as possible, because they're what will
allow us to build a vibrant team and a vibrant product. These three
principles are:
1). Don't forget we have to use what we're building.
2). Don't repaint the bikeshed.
3). Don't let process kill innovation.
*
These are glib summaries for complex concepts. Let me take these one
at a time and elaborate a little on how this applies to the
Dreamwidth project:
1). Don't forget we have to use what we're building:
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.
The current state of the LiveJournal code, in many cases, is a result
of compounding instances of people choosing the former option:
getting things done quickly now, but requiring complex amounts of
manual workarounds later. (Some examples that will be familiar to
people who have done any LJ volunteer work in the past: the FAQ
system, the Support system, the translation system...)
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.
I like to joke that I'm the laziest workaholic I know. My goal in any
environment is to simplify the processes I've inherited and
streamline the functions I have to do every day to make them more
efficient, even if it means tearing everything out and starting over
from scratch, because I know it'll save me time later. As we're
building the Dreamwidth code and dreamwidth.org's operating processes
and procedures, let's keep this in mind. "It is better to do things
right the first time" is a cliche, but it also holds a grain of the
truth.
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. I would much rather spend the
extra ten hours now to save me a hundred hours a month over the life
of the site.
(We do have to be careful not to over-engineer up front and make it
so that things never get released at all ... but I'd rather do it
*once*, correctly, than do it half-assed and then have to keep
redoing it over and over again.)
*
2). 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. A good post explaining the problem can
be found here:
http://bikeshed.com/
In essence, this scenario boils down to: 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.
To use the bikeshed metaphor, everyone wants to feel like they've
contributed to building this thing we're building here. That's a
wonderful sign that this community journey we're embarking upon is
something that will speak to a number of people. We run into the
danger, however, of hitting the same point that a lot of open-source
projects have hit over the years: everyone standing around and
arguing, and nothing gets done because everyone's too busy yelling
about what color paint we should buy.
Mark and I are both committed to letting Dreamwidth's users paint the
shed whatever color they want; we've promised ourselves and each
other that we're both going to stop sweating the small stuff. I think
this is something that we need to ingrain in the development culture
from moment one (and I don't just mean software development; I mean
anything involving how the site runs, how we build our processes,
what our policies are, etc). Our goals, as we "staff up", should be
to create a culture where we can all agree to compromise on the
little things along the way, so that we get a final product that will
satisfy as many people as possible, and I hope we can all promise
ourselves right now that we'll try to let the little things go. 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.
To drive a metaphor into the ground, I'm aiming for an approach where
the bikeshed we build might not be the color I initially wanted it to
be, but at least I don't look at it and think it's an eyesore. :)
*
3). Don't let process kill innovation.
This is, in some ways, an outgrowth of #2. I'm sure we've all been in
situations where having more than three people on a project team can
drive the project team into the ground, because everyone wants to
talk things over until everybody agrees on everything. (Then, of
course, it has to go up the chain, get comments made, go back down,
go through another round of changes, etc, etc ...)
One of the things Mark and I want to do with Dreamwidth is aim for an
ideal of community empowerment. We want project leaders to feel like
they can make decisions quickly, for the overall good of the project,
and we want project leaders to encourage people working on their
project teams to make independent decisions as well.
Our philosophy here is that we aren't the Evil Overlords standing
over everyone with whips; we're the people who are providing
direction and guidance, and making the overall long-term decisions
for the site operations, but we want people to feel empowered to jump
into the project and do the things that need to get done as quickly
as they can get up to speed, without having to wait for someone to
micromanage them. (I'm allergic to micromanagement, giving *or*
receiving.)
In a lot of community-based projects like this, it's very easy for
project leaders to build committes in order to avoid excluding people
who want to help, and then get bogged down in the process while
trying to make everybody happy. We need to keep this tendency in mind
as we start building project teams, and work to curb it whenever
possible.
If you volunteer to take point on a particular project, or pick up a
particular task, remember that Mark and I trust you guys to make good
judgement calls! Get input from others, but don't feel bound by it,
and don't try to please everybody. If you join a particular project
team, remember that we're looking to encourage and nurture
innovation! A task you claim is *your* task; we want to empower you
to make decisions based on your own best judgement.
Mark and I promise that we're not going to yell about what color the
bikeshed ends up being. We'll give you as much or as little direct
input and supervision as you feel comfortable with. Our end goal for
the project involves a number of small, fast-moving project teams
(consisting of engineers, designers, testers, documentation-writers,
etc) who form around a particular task or idea, see it through from
beginning to end, and then dissolve and move on to the next task:
we'll lay out the overall vision for the project, and let the team
decide on the implementation.
*
I know this email is long, and I fully expect to be returning to
these concepts as we move from "crazy-ass idea" to actual functioning
site. I wanted to set them forth now at the beginning, though,
because over the next few weeks, we'll be opening up more and more
tasks to the community for people who want to contribute to the
development and vision of Dreamwidth-the-code and dreamwidth.org the
hosted service. Having these philosophies expressly stated up front,
I hope, will save us a lot of trial and error through our "growing
pains" phase.
Over the next few weeks, we'll be writing up clear documentation on
the overall goals of the Dreamwidth project: more design guidelines,
project management guidelines, volunteer guidelines, etc. I look
forward to seeing what we're all going to manage to build together.
--D
--
Denise Paolucci
[email protected]
Dreamwidth Studios: Open Source, open expression, open operations.
Coming soon!
_______________________________________________
dw-discuss mailing list
[email protected]
http://lists.dwscoalition.org/cgi-bin/mailman/listinfo/dw-discuss
