Okay, I've copied this plan into Wiki and tweaked it into a
The idea here is that as we each have ideas of how things should
develop, we add them to this plan, into the appropriate milestone.
This is a working document, and based on past project work, this will be
the most important document that we as developers have. This document
helps us coordinate who does what and gives us a way to force decisions
that need to be made, to be made and nailed down.
Some techniques I've picked up for best using these plans...
* Make the plan your friend. Don't let it feel like shackles or
constraints. If the plan isn't right, change it so that it is.
* Indicate your name for tasks you want to own. If you need/want
someone to do a task for you, put their name in brackets. If someone
puts your name for a task you're unsure about doing, email them and
work it out.
* If a given task seems too intractable, break it down into more
specific sub-tasks. The ideal task-unit is something that'll require
a single "work session" to achieve.
* All the items in the current/next milestone should be known as to how
to implement them. If you need to "figure out how to..." then list
that as the task, and move the "implement" into the future.
* Strive to keep the quantity of work per milestone modest. There is
nothing important about the milestone numbers; we can have as many as
we like. What's important is that we hit milestones with frequency;
this gives us a feeling of accomplishment and helps keep up our
motivation. If the next milestone is always within sight it helps us
avoid feeling intimidated by the sheer amount of work to be done.
Focus on incremental achievements.
* Skip setting dates. We either end up burning ourselves out to meet
the dates or get discouraged at missing them. We're not in a hurry.
We'll get things out when we're ready for them to get out, not before.
Hopefully we should meet milestones every week or two or three. If
one takes three months for some reason (like having lives), well,
three months it is.
* Tying code releases to milestones is a good thing. You finish a
milestone, make a code release, and can go have beers. :-)
* Try to avoid adding 'new' tasks to the current milestone; this
increases the amount of work needed to achieve the milestone. If at
all possible, add them to the next milestone (or later). Or insert
another (small) milestone to follow after the current one.
* Try to avoid bumping tasks to the next milestone just because the task
is annoying or unexciting. Use the pending completion of the
milestone as motivation to get the grunge work done too. You'll feel
prouder of the achievement.
* Follow the plan and push towards each milestone. It takes dedication
to remain focused. There's tons of interesting things that are fun to
get distracted by, but having a plan like this gives something to tie
your attention to.
On Wed, 29 Oct 2003, MenTaLguY wrote:
> On Wed, 2003-10-29 at 03:43, Bryce Harrington wrote:
> > Since we cannot distribute a forked Sodipodi under the same name, I
> > think we're going to need to rebrand it. It's logical to rebrand it as
> > 'inkscape' since that will be the name of the project.
> > The next question we face is how to get from Point A to Point B.
> > Knowing this will help determine what to call your codebase.
> > I can easily see us slip into [rewriting from scratch] with Inkscape,
> > but feel strongly that [reworking the existing codebase], while less
> > glamorous, would be much more likely to succeed.
> That's been my experience as well, although it can really suck for
> prototyping -- especially with things like some of the radical UI
> changes that I have in mind.
> Your advice is well-taken, anyway.
> So... here's what I'm thinking at this point...
> * Sodipodi fork becomes the 'inkscape' module
> * My sketch becomes ... 'experimental', maybe?
> * I think our first tasks in inkscape should be:
> 1. Getting it building with a C++ compiler
> 2. Fixing the remaining XML compliance bugs
> 3. Removing the hacked-in Qt stuff
> 4. Cut a release
> * While I'm wrangling patches on the inkscape side, I will keep
> attacking the prototyping/experimental side of things (along with anyone
> else who's interested). Eventually, depending on how they converge, we
> might start seeing code being merged both ways.
> * At that point we may want to think about cutting an 'inkscape2'
> module based more on one side or the other, depending on how each have
> matured. It'll be an opportunity to lose any vestiges of the old
> Sodipodi directory structure, which I'm not particularly fond of,
> How does that sound?