Matt Hogstrom wrote:
Here is an additional set of questions I originally had in mind when
defining what a Version / Release is. So as not to overload that
thread I moved the addtional items here.
*When do we identify the content of a release?*
I expect this is the community as a whole that manages this. However,
before someone signs up to manage a release its probably only fair to
them to find out what the community is going to want to try and get in
so they know what they are signing up to manage.
What new features / function goes in? Do we poll the user community
periodically and use that input as the basis for content for the next
release?
I'm hoping this would be mostly organic but to set people's
expectations most significant thoughts should be know before the
release is cast and a schedule is set. Conversely, are we managing to
a time based release and what get's in get's in? If you're not done
and miss the cut off your out of luck until the next release.
We should time box the releases. I always thought that it was a pipe
dream to schedule features and bug fixes into a release and expect
people to show up and fix them.
We work from a prioritized list of bugs and features. These are
prioritized by the their impact, if they are bugs, and by the number of
Jira votes from the community.
*Who manages a release's content?*
Does the release manager have sole control over the content of a
release? I think to a certain extent this should be true but that a
person signing up for a release knows what content is proposed so it
is less dynamic than we've done in the past. If the person managing
the release doesn't have say so in this area they're likely to get
very tired, pop a cork, and send nasty notes to the dev list. I've
heard of this happening.
The release manager (RM) who is the steward of the communities wishes.
The RM reviews every issue for accuracy of classifications, e.g. bug,
blocker, etc. If the reporter has an issue with the classification then
the issue can be brought before the community. The RM is responsible
for deciding which issues will make it into a time boxed release and
which are too risky. If the developer thinks that an issue is not too
risky or that a release should be delayed, the issue can be brought
before the community.
*What is a "blocker" bug?*
How do we determine if a bug is a blocker and should delay a release?
One way is to classify the bugs in tiers of seriousness like:
Data Corruption Possible
Application Deployment Failure
- Can't it be bypassed or not
Error messages not useful
New feature not working (can it be supressed until the next release)
Using the policy that I outlined in the other thread obviates the need
to hold up *any* bug fix.
*What is a feature versus an improvement?*
This will always be a tricky one. Aaron had a few items he wanted to
add to 1.1 which made perfect sense from improving the user
experience. One might say they were bug fixes that were correcting
improper messages and the like and someone else might say they were
new features. How do we handle the resolution of those types of
issues? Does the release manager get a significant binding vote?
Why bother to make this distinction? Using the policy that I outlined
in the other thread obviates the need for such subjective distinctions.
To be honest, my big concern over feature / bug debates is that we
seem to be on a multi-month release cycle. At that rate and pace it
will be difficult to fix bugs / performance issues without making
users wait a very long time in between stable drops. Do others have
suggestions on how to handle this?
Disciplined time boxing.
Regards,
Alan
