Hi Kathey,
Thanks for your additional comments. Some more thoughts inline...
Kathey Marsden wrote:
Rick Hillegas wrote:
At this point, all of the chunks of bugs have been claimed.
Thanks everyone who did this, especially Dag for coordinating and
those that took multiple chunks. I think it was really good to have
it split up so that folks could take the time to try repros, attach
new ones etc.
I think after going through the process and thinking about urgency
with relation to a release, I would propose the following changes to
the process for next time.
1) Make urgency specific to a release by also setting the fix version
field for open bugs.
For issues marked Urgent or Blocker I think it would be good to also
mark a fix version. That way we could manage urgency for multiple
releases and I think could safely get rid of High value fix. I think
in the past there was some objection to setting fix version on open
issues, but it is still indicated I noticed in the release process [1].
I'm not sure I understand what you're suggesting. I thought we had
agreed that the Urgency field was owned by the release manager. Once
the bugs have been triaged, I'm happy to let successive release managers
express their individual judgments via the Urgency field. I can see that
there would be a conflict if two release managers were putting out
releases at the same time--but that's not a problem we seem to have and
I'd be happy to solve that problem when it actually arises.
I don't see much value in using this field to mean either of the following:
1) A commitment by a developer that they are going to deliver a fix in a
particular release. I think that the "assigned to" field works well for
that purpose already.
2) A subjective statement that a bug is important coupled with a request
that someone else should fix the bug. I can see that this is useful to
the two large teams of developers which are working on Derby--this would
be a way to flag your teammates about what your manager thinks is
important. But I see two problems with trying to encode this information
on our JIRAs:
a) The two teams may have different priorities and can easily confuse
one another or, worse, overwrite one another's judgments.
b) "Please scratch my itch" seems like an odd request to make in a
scratch-your-own-itch community.
2) Set a regular schedule for this triage. Once a month for new
issues (those with no urgency marked) and a full pass again about 2
months before release. Hopefully with more time the triage will have
more impact on bug fixing decisions.
I see great value in tackling the untriaged issues regularly. Once a
month sounds good. I see less value in revisiting the already triaged
issues. Some of the facts may change (for instance, "repro available"),
but many won't (e.g., a crash yesterday is still a crash tomorrow).
Which fields do you think need to be revisited every release cycle?
Thanks,
-Rick
Kathey
[1] http://wiki.apache.org/db-derby/DerbySnapshotOrRelease
