What's the process for nominating additional bugs on the 0.7.1 list?
Should I just add it to this list:
http://chandlerproject.org/Notes/DotSevenDotOneBugNominations
and explain how it fits into our 0.7.1 tenets or should we do it over
email?
On Sep 19, 2007, at 3:18 PM, Katie Capps Parlante wrote:
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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Design" mailing list
http://lists.osafoundation.org/mailman/listinfo/design
