Okay, I've copied this plan into Wiki and tweaked it into a milestone/task format:
http://www.inkscape.org/cgi-bin/wiki.pl?DevelopmentRoadmap
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.
Bryce
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:
Getting it building with a C++ compiler
Fixing the remaining XML compliance bugs
Removing the hacked-in Qt stuff
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, anyway.
How does that sound?
-mental