Thanks for initiating this. The cleanup is something I've worked on from time to time and each time burned out before getting to the end :) It's definitely a case of "many hands make light work".
At the moment, we use versions to measure triage, but labels sound like a much better alternative. I like yours, though I think "backlog cleanup" should apply to all issues regardless of test case / old / new / patch that we can work down to 0. You also have a gap - there's nothing to specify that it's reviewed, has sufficient information to reproduce (preferably a test case), but doesn't have a patch. How about we have 3 label states to describe triage: * no label in this group - brand new issue, needs review. We should send this list to dev@ once a week to remind us to look at them... * maven-backlog-cleanup - old issues that have not been reviewed recently * maven-triaged - new issues get this once they've been reviewed but nobody is ready to work on it yet Then the other two labels are additive to the above: * maven-needs-testcase * maven-patch-available Both are self explanatory, the first calling on the reporter to push it forward, the second calling on the committers to push it forward. What we have now: 1) 1 issue for 2.2.2 (because it's a regression on the 2.2.x branch) We can either discard the changes on the 2.2.x branch (resume from 2.2.1 if we ever need a patch release), or fix this and push 2.2.2 as the EOL version 2) 1 issue for 3.0.4 Something Hervé is working on - but in general we need a list of stuff to do for this release, if at all. 3) 42 issues for 3.1 This list is probably out of date now, but they were at least triaged. We should decide what really is going to constitute 3.1, and move the rest to the "triaged" area 4) 325 "Issues to be reviewed for 3.x" Not yet triaged issues, moved out so that new stuff coming in could be more easily identified (!). I suggest we remove this version and label them maven-backlog-cleanup 5) 30 in 3.x / Backlog Triaged issues (bearing in mind that it happened over a year ago, and so may have aged again). I suggest we remove the version and label it maven-triaged 6) 52 "Documentation Deficit" These would be best moved to a dedicated documentation project, or a label within MNG. We sometimes use MNG, sometimes MNGSITE - a strategy around this would be helpful. I continue to favour versioned documentation, but I know that's not everyone's preference - best leave that decision to those working on it more recently :) 7) 96 Unscheduled Not yet triaged issues. We can either keep these as new, or filter by time and put some in the "cleanup" bucket. Cheers, Brett On 20/06/2011, at 5:34 AM, Benson Margulies wrote: > We're good here. I just added the label maven-messy to > http://jira.codehaus.org/browse/MNG-2258 as an experiment. > > I suggest that we use a specific label for the backlog, so: > > Old report, no test case: > > maven-backlog-cleanup > > New report, no testcase: > > maven-needs-testcase > > Has a patch (this works better than the checkbox) > > maven-patch-available > > Needs design attention and not just a bug fix: > > maven-design > > > > > On Sun, Jun 19, 2011 at 3:28 PM, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: >> as far as I know ben made you me and brett admins... but that might be for >> maven stuff only... I can always bash ben on the head if we want to ;-) (our >> at least ask someone to bash ben on the head) >> >> - 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 19:53, "Arnaud Héritier" <aherit...@gmail.com> wrote: >>> 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 >>>> >>>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org > For additional commands, e-mail: dev-h...@maven.apache.org > -- Brett Porter br...@apache.org http://brettporter.wordpress.com/ http://au.linkedin.com/in/brettporter --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
