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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
