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:15:13 GMT
Thanks for looking at this, Myrna!

Myrna van Lunteren <m.v.lunteren@gmail.com> writes:

> I'm also wondering if we should add a flag indicating that (perceived)
> incorrect behavior is happening in a production application.

Doesn't the present "Wrong query result", "Data corruption", "Crash"
and cover this need? How is this flag different? Of course, strictly,
"query" doesn't cover a wrong update, insert etc, but. Would it help
if this wording was generalized a bit? 

Another thing is what Rick mentioned in his post, how we track users'
view of things. IF we consider the JIRA a database for developers,
ideally, we would leave users' impressions alone, but we have a need
to capture our own understanding of issues as well. In the past, I
have worked with separate bug tracking databases for external,
customer facing issues, and internal developer facing bug
databases. In Derby JIRA, we have only one, so it is a compromise. I
think that my present view is that we should have Jira reflect our
best understanding. To the extents users see things differently, we
should rely on the voting system. But, as I suggested, if we change
user's appraisals, say of priority, we should explain why.

I think I agree with Rick that "Priority" should somehow reflect
"hassle" (or "severity as I like to think of it as), in contrast to
Urgency. But I am not sure we can change the possible values and/or
wording of the generic Jira fields? (e.g. Priority) Does anyone know?

> How about changing the 'Existing application impact' flag to 'fix
> impacts existing application' and adding 'problem encountered in
> production application'?

+1

Dag

Mime
View raw message