[Design] Preview Meeting - Monday Feb 26th @ 1:15pm

[Aparna Kadakia]

On Feb 28, 2007, at 11:09 PM, Philippe Bossut wrote:

> Sheila Mooney wrote:
>> -> We could also track some sub-milestone criteria such as the  
>> following....
>>
>> + What features have we done?
>> + What features are left to do?
>> + What workflows are complete?
>> + What workflows are incomplete?
>> + What's been tested?
>> + What hasn't been tested?
>> + What non-code deliverables are complete?
>> + What non-code deliverables are incomplete?
>
> I think it's useful for individual contributors to identify such  
> sub-milestones for themselves but, for the overall project, this is  
> not extremely useful as only a couple of persons at a time would be  
> on hook for any such micro granular milestone. I think at the  
> project level we should pace ourselves with criteria that are  
> applicable to all and are relevant to all.

Philippe, I think we do need the regular milestones like Feature  
Freeze, Code Complete etc that you mention. We are not debating that.
But I also proposed the feature driven sub-milestones in our Preview  
Meeting and here's my rationale for it. Having these sub-milestones  
based on feature work and workflows actually helps QA (and the Design  
team) focus on the specific feature to test in that milestone.  
Identifying which features and workflows work and which don't and  
making those notes for each sub-milestone helps us better track the  
progress of that feature. It helps us get a more holistic view of the  
release in terms of what functionality is working and what is not and  
what it would take to get us to the finish line.
  Also, when we do feature driven milestones the quality of the  
feature tends to be higher given that's what this milestone is about.
Eventually it will also help us target specific IRC QA sessions on  
testing these features. We have used this model before (back in  
Chandler 0.5) and it has worked great.
So here's my +1 for the above proposal.


>>
>> Tracking workflows helps me as well since this makes it easier to  
>> punt stuff. We could decide to defer a complete workflow which  
>> entails punting a group of bugs across multiple features.
>
> I think workflows are a way to consider a product which are  
> orthogonal to the way a product is architectured so they are not  
> very well suited to identify milestones.
>> -> The other thing I heard is that we could also agree on our  
>> ultimate end-user goals and set those expectations properly. Do we  
>> want real users or just people trying out the app to give us  
>> feedback? A proposal...
>>
>> *Dogfood Goals:*
>> Get people outside of OSAF to dogfood Chandler the way Mitch,  
>> Sheila, Priss and Mimi have been dogfooding:
>> + Using Sharing
>> + Using the Dashboard
>> + Using the Calendar
>> + Using Edit/Update
> +1, we need real users, even for a limited set of features. As long  
> as we don't get there, we're nowhere.
>> -> Also, giving people some visibility into how we are going to  
>> prioritize/punt bugs is also worthwhile so that they know what  
>> categories the P1s and P2s fit into and they understand we aren't  
>> gold-plating but fixing very core problems. Then we can make  
>> decisions like "punt all bugs in the convenience category" or say  
>> that anything which doesn't make it into those buckets gets  
>> deferred automatically. (We may need an additional bucket for  
>> developer/build/qa related stuff - this is just an example).
>>
>> *Buckets for prioritizing features and bugs:*
>> + Playing around with the app, trying out the features
>> + Stuff that blocks day to day usage
>> + Stuff that confuses people
>> + Stuff that makes it more likely for people to stick with  
>> Chandler (conveniences)

+1
I think this is more from looking at the end user point of view.  
Again, more around workflows and scenarios in the app that can be  
exercised.

>
> +1, I would use more stringent categories though like:
>  + crash
>  + dataloss
>  + broken functionality, no workaround
>  + broken functionality, workaround available
>  + interop
>  + cosmetic

>
> We can use the keyword in bugzilla to mark bugs (some of those  
> categories already have keywords) and make clear which categories  
> of bugs are being considered for each debug period.
>
> Cheers,
> - Philippe
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> Open Source Applications Foundation "Design" mailing list
> http://lists.osafoundation.org/mailman/listinfo/design