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