db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dag.Wan...@Sun.COM (Dag H. Wanvik)
Subject Re: Jirs field definitions
Date Fri, 22 May 2009 22:30:20 GMT

Thanks for your comments, Rick! My replies inlined.

Rick Hillegas <Richard.Hillegas@Sun.COM> writes:
> I think this is fuzzy at the edges. Above you listed some consumers
> and uses of JIRA. Would any of those consumers or users be frustrated
> if we removed NewFeature and just offered the Improvement choice?

I would not think so. I, for one, would feel little if any pain by
merging these two. Other opinions?

> To my mind, the example you give could be classified as either Task or
> Improvement. To me, a good example of a Task would be one of the
> placeholder JIRAs which track the work done by a release
> manager. However, I don't think we'd lose any important information if
> we eliminated the Task issue type.

Again, I would not miss it, I think, although i don't think this isseu
type is misused much, so I am not sure it's a problem.

> ..Issue type "Test"..
> I think this is another confusing, redundant synonym for
> Improvement. Whack it!

I would love to. +1

> o Hassle. This is the issue's importance to the person who bothered to
> log it. I think we do a lousy job of tracking Hassle. In fact, we
> actively clobber it.

> 1) Priority = Hassle

What field would you suggest for capturing this? If we user the
Priority field, we can't use this field for other things. Since we
don't have special fields for tracking user's conception of bugs, I
would argue that we should try to adjust "Priority" (or "severity" as
I prefer), to some objective norm, but explain why we change its value
if we do.
>
> o Recoverability. This is some generic ranking of the issue's
> type. For instance DataCorruption > Crash > WrongResult > Abort >
> HardToUse > Ugly. We could track Recoverability better given a little
> concentration.

For me this, would be covered by the "priority" cum severity field,
augmented by the flags ("crash", "data corruption" etc).

>
> o Votes. This attempts to capture how much users in general care about
> the issue. The accuracy of this fact is dubious right now because
> users don't vote much.

Again, I think this should be the main tool for measuring how strongly
user's feel about issues. We should encorage its use more.

>
> o Releasability. This expresses how important the issue is to the
> release manager. I'm not sure the release managers handle this
> consistently, but, at the end of the day, this ranking is communicated
> to the dev list.

> 2) Urgency = Releasability

I agree this can be covered by the "Urgency" field well! +1

>
> Extra credit if we could actually rename Priority and Urgency. As long
> as they keep their original names, they will be mis-used. It doesn't
> matter if we write a clear, slim primer on how to operate
> JIRA. Self-revealing, intuitive controls always trump RTFM.

I agree this would be good, but is it possible (with the Jira being
shared among Apache projects)?

> Do we really need this much granularity? What if we pared this back to
> Blocker, Major, and Trivial?

Maybe not, but I don't see this as a major problem.

> If Urgency is basically Releasibility, then does this field need any
> values other than Blocker and Non-blocker?

Hmm. I think 3 values would be preferable, but I don't have a strong
feeling for this. Others?

Dag

Mime
View raw message