That's exactly what I'm trying to avoid. I don't want us to manually go through the list because I fear that we'll tend to be rather inclusive and won't let go of the old stuff.
If someone wants to pick up an issue, they can just assign it to themselves and the issue automatically disappears from the list. Uli On 18.12.2012 20:44, Howard Lewis Ship wrote: > We should define some tags that can be used to mark issues that are either > likely to be picked up, or likely to be closed. > > > On Tue, Dec 18, 2012 at 11:30 AM, Ulrich Stärk <u...@spielviel.de> wrote: > >> On 18.12.2012 18:29, Kalle Korhonen wrote: >>> Uli, let's not make this a religious argument. If we all compromise a bit >> >> I'm not making this a religious argument. I simply don't see why we should >> delay cleaning the list >> any longer or put any of our valuable energy in outdated stuff. That's >> simply not economical. Half >> of these issues were last updated more than 2 years ago, almost all were >> updated more than a year >> ago. The last 5.0 (5.0.19) was released in 2009-12. 5.1.0.7 (last 5.1 >> release) was done in 2010-01. >> We are talking about issues affecting 3 year old and even older versions >> of our software. That >> simply doesn't make any sense to me. >> >>> we'll see that everyone wants the same thing, a smaller open bug count. >> Can >>> we just wait a bit for bulk closing anything, and in the meanwhile keep >> >> That's exactly what I wrote: >> >>>> If Robert wants to spend the time on it, I'm all for it. But I really >> want >>>> to see the list of open >>>> issues significantly reduced in the near future and I believe that the >> >> To rephrase: I'm OK with giving everybody a bit time to look at their >> favorite issues, assign them, >> update them, etc. But I want us to agree on a deadline when we will just >> close them. >> >> Can we agree on the following: >> >> 1. we compile a list of issues that we think can be closed for reasons of >> lacking interest, >> affecting outdated versions, being of low quality, or other reasons >> 2. we bulk-comment on those issues asking reporters and watchers to update >> them with more >> information by 2013-02-28 >> 3. on 2013-03-01 we bulk-close those that are still open and haven't been >> updated >> >> Uli >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: dev-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tapestry.apache.org For additional commands, e-mail: dev-h...@tapestry.apache.org
