+1 to all of this
I really support the notion of "alpha" instead of "milestone" - I think
"alpha" at least carries with the the notion that this is a release.
Milestone to me just means a marker in time and doesn't signify any
particular effort towards fixing critical bugs specifically for that
release.
I'm going to venture slightly off-topic below - I don't want discussions
of my opinions below to derail Katie's efforts, so please don't let the
following discussions of release behavior dissuade you from voicing your
separate support/disagreement with Katie's original proposal.
Katie Capps Parlante wrote:
+ We spend more time testing and stabilizing each milestone.
This is what is I think most interesting to me personally, and what I
think could could mean the difference between regular old milestones
(like we do now) and real "releases" My personal take on two months
milestone/alpha releases:
1) We, as a team, anticipate an upcoming milestone/alpha release within
2-3 weeks of the actual release. This means we delay risky fixes until
the beginning of the next milestone. I would hope that this "buckle
down" period is identified as a part of the milestone schedule from the
get-go.
2) In the last week (?) of the release, the product release team
identifies the critical bugs necessary for the milestone and stops
accepting most "easy" fixes.
3) The development team doesn't try to accomplish too much in one
milestone. For instance, if we finish the bulk of the dashboard phase 1
work in the first 3 weeks of milestone 1, then we stop working on
dashboard in milestone 1 and focus on bringing other key tenets up to
milestone 1 level - or we make more robust tests, or we do architectural
planning for milestone 2, etc etc..
Anyway, that's my two cents. I'm sure I'm just echoing the details in
many folks heads but I thought it was important to get this stuff out in
the open.
Alec
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
