[Design] Desktop 0.7.1 Priorities

[Aparna Kadakia]

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