I was also wondering if a bug with a higher number of votes should be
taken to be more severe. Or having higher priority?
Myrna
On 7/26/06, Kathey Marsden <[EMAIL PROTECTED]> wrote:
I agree. If a JIRA admin can enable the urgency field then the community
can start marking urgency for the 10.2 issues as they think appropriate
without regard to JIRA Priority (severity)/ The release manager, The
reporter, the assignee, or
Daniel John Debrunner wrote:
I see what you mean, even though there is no "transition from the
current scheme". We don't have a current scheme for defining
priority(jira urgency), only one for defining severity(jira priority).
I agree. If a JIRA admin can enable the urgency field then the co
Rick Hillegas wrote:
> I'm simply trying to clarify the transition from the current scheme to
> Kathey's preferred scheme. Someone has to fill in the value of Urgency
> for pre-existing issues. I'm asking whether this is the algorithm for
> determining Urgency values for 10.2 issues which have alr
Hi Kathey,
I think we're on the same page. I hope my reply to Dan's question
clarified the intention of my mapping table. I'm trying to figure out
how we assign Urgency values to existing 10.2 JIRAs. I'm asking whether
this is the algorithm you would use.
At the risk of being pedantic and cr
Daniel John Debrunner wrote:
Rick Hillegas wrote:
Thanks, Kathey. I think this does capture what I mean. I think this is
your proposal:
Priority - Means "severity" according to the JIRA definitions.
Urgency - Has the common-sense meaning of priority, not to be confused
with the JIRA sense
Rick Hillegas wrote:
Thanks, Kathey. I think this does capture what I mean. I think this is
your proposal:
Priority - Means "severity" according to the JIRA definitions.
Urgency - Has the common-sense meaning of priority, not to be confused
with the JIRA sense.
Yes, that makes sense , but
Rick Hillegas wrote:
> Thanks, Kathey. I think this does capture what I mean. I think this is
> your proposal:
>
> Priority - Means "severity" according to the JIRA definitions.
>
> Urgency - Has the common-sense meaning of priority, not to be confused
> with the JIRA sense.
>
> For current 10.
Thanks, Kathey. I think this does capture what I mean. I think this is
your proposal:
Priority - Means "severity" according to the JIRA definitions.
Urgency - Has the common-sense meaning of priority, not to be confused
with the JIRA sense.
For current 10.2 issues:
Priority==Blocker => Urge
Rick Hillegas wrote:
How is this field used? Does it take two values (Urgent, NotUrgent) or
does it cover a broader spectrum?
Here is the forrest definition, which looks closely correlated with
with what we are trying to achieve.
If I had my druthers I would alter Urgent a bit to include
Daniel John Debrunner wrote:
Rick Hillegas wrote:
For 10.2, I want to use the priority field to mean what it means in
other bug tracking systems: a field which helps engineers figure out
what to do next. I would appreciate it if people would use Blocker and
Critical to mean, respectively, "
Hi Kathey,
How is this field used? Does it take two values (Urgent, NotUrgent) or
does it cover a broader spectrum? This might help us separate the
concepts of priority and severity. However, I think there will continue
to be confusion as long as a field named "priority" is used to hold the
c
Rick Hillegas wrote:
> For 10.2, I want to use the priority field to mean what it means in
> other bug tracking systems: a field which helps engineers figure out
> what to do next. I would appreciate it if people would use Blocker and
> Critical to mean, respectively, "priority 1" and "priority 2"
Rick Hillegas wrote:
Hi Kathey,
I think that this is a defect in JIRA. If someone knows how to add a
severity field to our bug tracker, that would be great.
I notice when I take a Jira report there is an URGENCY option, under
custom fields with:
Blocker
Urgent
Normal
Low
But
Kathey Marsden wrote:
Rick Hillegas wrote:
. I would appreciate it if people would use Blocker and Critical to
mean, respectively, "priority 1" and "priority 2".
Can you put some words around "Priority 1" and "Priority 2" so I have
a better understanding of where to draw the line?
How'
Rick Hillegas wrote:
. I would appreciate it if people would use Blocker and Critical to
mean, respectively, "priority 1" and "priority 2".
Can you put some words around "Priority 1" and "Priority 2" so I have a
better understanding of where to draw the line?
Hi Kathey,
I agree that this is a bit confusing. In other bug tracking systems
which I have used, there is a distinction between the priority and the
severity of a bug. Priority is the field which helps engineers figure
out which bug to tackle next. Severity captures the bug's impact on
custo
Rick Hillegas wrote:
Hi Kathey,
If an issue would cause you to vote -1 on the 10.2 release, please
mark the issue as Critical or Blocker.
I am looking now at the known open regressions and am still struggling
with how to set the priority. Here is the current list of 4.
https://issues.apa
Kathey Marsden wrote:
* Mark Fix Version 10.2 for unassigned issues if we think it is
a high value fix that could be fixed in time for the release.
* Iteratively adjust Fix Version as we get closer to the release.
* Use Blocker/Critical to mark must fix issues.
Details here:
htt
Hi Kathey,
If an issue would cause you to vote -1 on the 10.2 release, please mark
the issue as Critical or Blocker.
Kathey Marsden wrote:
Kathey Marsden wrote:
Alternately we could just not muddy the Jira descriptions of these
fields and only mark only mark Fix Version 10.2 for an unas
Kathey Marsden wrote:
Alternately we could just not muddy the Jira descriptions of these
fields and only mark only mark Fix Version 10.2 for an unassigned if
we would vote -1 on the release if it is not fixed, mark the
priorities objectively based on the Jira priority descriptions[2 ]
Rick Hillegas wrote:
That leaves one last unassigned blocker:
I think two new issues DERBY-1569 and DERBY-1564 look potentially
*very* problematic and may quite possibly be serious regressions.
We also have two known regressions[1].If I would vote -1 on the
release if any of these ar
Thanks to David for taking DERBY-1377. That leaves one last unassigned
blocker: DERBY-936.
DERBY-936 is a Documentation issue. Recently, there was some discussion
about how to identify outstanding 10.2 documentation issues. This one is
definitely at the top of the list.
Regards,
-Rick
23 matches
Mail list logo
