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.
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 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
