[Design] Desktop 0.7.1 Priorities

Katie Capps Parlante capps at osafoundation.org
Wed Sep 19 15:18:31 PDT 2007


When we created 0.7.1 as a milestone target, we had a loose notion that 
we'd move interop work there. We then added recorded script fixes, then 
some i18n/l10n work, then various odds and ends bugs that didn't make it 
into Preview. Now we have an odd grab bag -- perhaps time to take a step 
back and reframe/reprioritize 0.7.1.

A proposal for 0.7.1 priorities...

Tenet 1: Fix what is really, really broken (bugs that might really block 
users)
- interop: solve immediate problems for users migrating data into Chandler
- data integrity problems
- problems that paralyze users when they encounter them
- egregious polish problems
- fix small usability problems that users encounter right away

Mimi has nominated top 20 bugs in this category (not including interop): 
http://chandlerproject.org/Notes/DotSevenDotOneBugNominations

I assume we'll run into a few others as the first users encounter them.

Tenet 2: Recording script framework fixes
- QA team and John to prioritize work

Tenet 3: I18n/L10n
- solve immediate problems for localizers

How is this different from the current set of 0.7.1 bugs?
- Instead of tackling all interop issues, just focus on ones that block 
real users from getting data into chandler. By "real users" I mean, 
someone who tells us that they have their data in some other calendar 
and can't get it into Chandler.

- Mimi prioritized the non-interop, non-localization, non-testing 
related bugs to those top 20, others don't need to make the cut.

- No "interop with Apple calendar server"

- No "interop with Google"

Why have a quick turn around release? Just like with the server, we want 
a chance to scoop up the worst problems that we see the first users run 
into in the next month. Work on the most obvious list of fixes for this 
first month while we buy a little time to get real feedback from 
Preview, which will shape the roadmap from here. Show a sense of 
momentum and responsiveness to initial feedback.

Estimate requests:
- It would be great to have an estimate for interop with Apple's 
calendar server
- It would be great to have an estimate for interop with Google
- It would be great to have an estimate for the tenets above. Would we 
need a smaller set to cut a 0.7.1 in ~1 month? (We might need to scrub 
the interop bugs more carefully to answer this question).

What comes after 0.7.1? I'm currently thinking that we should move to a 
time-based system instead of a feature-based release schedule. (I know 
you all have been talking about this kind of plan). PPD would have some 
overall prioritization of tasks/work, and as tasks were completed they 
would land in the next release. A bigger feature might get worked on in 
a branch and land all at once, similarly for a refactoring. (A bigger 
change as proposed by PJE we might have to plan for differently). PPD 
would be able to reprioritize week to week (or cycle to cycle) based on 
feedback as it comes in.

FWIW, I wouldn't expect all users to pick up the latest dot release. New 
users who show up *would* get the latest release though, and any user 
blocked by a particular problem could go get the latest release. I think 
it is important to create "releases" and not just rely on checkpoints. 
We're now beyond "dogfooding" -- we now have real users who aren't going 
to want to pick up a checkpoint.

Interested in thoughts on all of this.

Cheers,
Katie





More information about the Design mailing list