Thanks for looking at this, Myrna! Myrna van Lunteren <[email protected]> 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
