Labels are now a native feature in recent releases of Jira and they are really useful to tag issues for a need like this one. We could use them also to give a complexity level of the issue, ... The need is to define them and follow a common convention
Another solution is to have a custom workflow with a default state "Need Triage" and additional status like "Verified" ... This is what they have @ Atlassian if i remember well. It's not really difficult to create if we want. The only limitation is that we need to be admin of the jira instance to create our own workflow. Arnaud, who is fighting in // to upgrade a Jira 4.2 instance to 4.3 .... On Sun, Jun 19, 2011 at 7:13 PM, Dennis Lundberg <denn...@apache.org> wrote: > On 2011-06-19 18:46, Kristian Rosenvold wrote: > > Is there any smart way to tag a bug as processed in a triaging process > > so we can focus on the remaining bugs? > > > > I've always wondered if there's any option to tag an issue or create > > shared custom lists...? > > We should be able to use "Labels" for this: > http://confluence.atlassian.com/display/JIRA043/Labelling+an+Issue > > I haven't used them myself yet, but they seem to fit the bill. > > > > > > K > > > > Den 19. juni 2011 kl. 18:42 skrev John Casey <jdca...@commonjava.org>: > > > >> +1 > >> > >> Great idea! > >> > >> On 6/18/11 10:22 PM, Benson Margulies wrote: > >>> If no one objects to this idea, I'd like to add a component, which is > >>> an email like the following to the user list. > >>> > >>> --snip-- > >>> > >>> Dear Maven Users, > >>> > >>> Over the years, the JIRA for core Maven > >>> (http://jira.codehaus.org/browse/MNG) has accumulated many unresolved > >>> issues. All this clutter makes it difficult to tell where the real > >>> problems are. Further, many of these issues do not contain > >>> self-contained test cases. Practically speaking, it is very difficult > >>> to diagnose and resolve a problem without a test case 'on the bench.' > >>> We developers would like to turn over a bit of a new leaf. We're going > >>> to ask you to supply a test case to go with your bug reports. In > >>> return, we're going to try very hard to attend to them. You can tar it > >>> up and attach it to the jira, or just push it to github and add a > >>> link. > >>> > >>> To clean up the current mess, we plan to start going through the > >>> backlog. We'll add comments asking for test cases or other followup. > >>> If we don't hear back in two weeks, we're going to close. > >>> > >>> We're sorry for any frustration felt by the originators of > >>> long-neglected reports, but we believe that this process will help us > >>> be more responsive in the future. > >>> > >>> --snip-- > >>> > >>> > >>> On Sat, Jun 18, 2011 at 7:22 PM, Stephen Connolly > >>> <stephen.alan.conno...@gmail.com> wrote: > >>>> they can always reopen if they want after the issue has been closed if > the > >>>> 2nd weeks was too short > >>>> > >>>> - Stephen > >>>> > >>>> --- > >>>> Sent from my Android phone, so random spelling mistakes, random > nonsense > >>>> words and other nonsense are a direct result of using swype to type on > the > >>>> screen > >>>> On 19 Jun 2011 00:20, "Stephen Connolly"< > stephen.alan.conno...@gmail.com> > >>>> wrote: > >>>>> +50 > >>>>> > >>>>> I say lets give each issue a ping, wait 2 weeks and close if no > response > >>>>> > >>>>> - Stephen > >>>>> > >>>>> --- > >>>>> Sent from my Android phone, so random spelling mistakes, random > nonsense > >>>>> words and other nonsense are a direct result of using swype to type > on the > >>>>> screen > >>>>> On 18 Jun 2011 23:30, "Benson Margulies"<bimargul...@gmail.com> > wrote: > >>>>>> I just looked at the 'blocker' issues. We have a variety of very old > >>>>>> JIRAs here. None of the ones I looked at have a self-contained test > >>>>>> case that would can be downloaded, run, and converted to an > >>>>>> integration test, etc. > >>>>>> > >>>>>> What's the policy? My temptation would be to comment on them asking > if > >>>>>> the OP is still interested (in some cases, 5 years later), and, if > so, > >>>>>> can they come up with a repeatable test case, and if not close as > not > >>>>>> a real bug. > >>>>>> > >>>>>> I don't mind in some cases doing work to build a test case, but to > go > >>>>>> to all this trouble for a bug that was opened about maven 2.0.x, > where > >>>>>> it may not be that easy to reconstruct the critical components of > the > >>>>>> problem, seems a dubious use of time. > >>>>>> > >>>>>> > --------------------------------------------------------------------- > >>>>>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>>>>> For additional commands, e-mail: dev-h...@maven.apache.org > >>>>>> > >>>> > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >>> For additional commands, e-mail: dev-h...@maven.apache.org > >>> > >> > >> -- > >> John Casey > >> Developer, PMC Member - Apache Maven (http://maven.apache.org) > >> Blog: http://www.johnofalltrades.name/ > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > >> For additional commands, e-mail: dev-h...@maven.apache.org > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > > For additional commands, e-mail: dev-h...@maven.apache.org > > > > > > > -- > Dennis Lundberg > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > >
