There are some links on the RoadMap pages for the likely Bugzilla queries.
* http://struts.apache.org/roadmap.html The vast majority of the tickets are enhancement requests. A good number of these might be already implemented and could be closed as redundant.. The others might be organized into some kind of wish list on the wiki, and then closed. There's a wiki page started along those lines at * http://wiki.apache.org/struts/StrutsIdeaJar The tickets that should receive the most attention are the * Problem tickets with patches, and then the * Problem tickets. We have been resolving all of the problem tickets regularly, and so most of these should be relatively recent. The tickets with patches could be reviewed and tested. If the description seems sound, and if the patches applies, a "works for me" comment can be added to the ticket, and perhaps we could change the status to verified. If the patch doesn't work, we could ping the submitter. If there is not a reply in 72 hours (our standard increment), and there is no clear way to resolve the issue, then we might close it for lack of a working patch. If there is a problem ticket without a patch, and there is no clear resolution, we have been know to close problem tickets for lack of a patch. We might setup a "known issues" page, and refer to those (closed) tickets there. We could draft a page like that on the wiki, and then move it to the website when ready, so that people don't add new issues to the wiki instead of bugzilla. Since this is an open source project, I personally don't feel it's our job to fix every problem. However, I do feel we should solicit and apply patches from the community, and record any known issues that we don't know how to fix. For very old issues, it might be reasonable that we move them to another area, like the website, just to keep bugzilla from bloating. As a rule, we shouldn't mark something WON'T FIX unless there is a specific reason why we aren't going to address the issue. For example, adding functionality to the original Struts Taglibs outside the scope of the HTML specification. Personally, I'm not keen on bulk-closing the enhancement tickets without review. But, if we did, six months is way too brief around here. It would have to be more like eighteen months. -Ted., On Sat, 12 Mar 2005 11:09:29 -0500, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > I'm willing to take on some of this. I figure a small step first... > > Can anyone verify for me the total number of tickets in Bugzilla as of > this day is 2404? I came to this by doing a search on product Struts > with all possible statuses selected. Are those the correct parameters > to get that metric? > > Next, I did the same search but *removing* the statuses CLOSED, RESOLVED > and ASSIGNED. I get 345, which should be the number of tickets left to > be worked on in some fashion that no one has stepped up to take on. > Does that sound correct? > > What I am offering to do is go through those 345 tickets and deal with > them in some way. Some debate is probably needed as what appropriate > actions are. Some suggestions: > > (1) Any ticket not modified in the last six months will be resolved as > CLOSED. My reasoning is that if no one has done anything on it in half > a year, a new ticket should be opened if it still applies (or I suppose > this ticket explicitly REOPENED by someone). > > (2) This will be controversial I suspect... Any ticket applying to a > version prior to 1.2.4 gets marked as WONTFIX. I am proposing > end-of-life'ing anything prior to 1.2.4. This doesn't seem quite as > radical to me in light of the recent discussions about how versions > develop. Everyone has said new features will only be applied to 1.3, > anything prior is bug fixes only. Why not go one more step and say only > the prior version (or two in this case, 1.2.4 and 1.2.5) will be > supported even for bug fixes? Anyone agree with this? > > (3) Any ticket that was REOPENED I will contact the person who reopened > it to get a status updated from them. My feeling is that if someone > reopened a ticket, I take that to mean they took responsibility for it. > > (4) Any ticket that is VERIFIED I will add a note to saying something to > the effect of "this ticket should be CLOSED in six months if not > resolved in the intervening time". My reasoning is that if no one takes > it on in half a year, chances are it isn't going to get resolved and > therefore it should be closed and a new ticket opened (or the ticket > reopened) if someone still wants it fixed. > > (5) Any ticket that is UNCONFIRMED I will put a note on it saying > something like "if no one VERIFIES this in 3 months, the ticket should > be closed". > > These are just some thoughts I had to clean up the database. The > suggested time periods are of course negotiable. I am of course open to > any other ideas, whether in addition to these or contravening these. > The bottom line though is I think there is an opportunity here to clean > up the database a bit and make it more useful, and I am willing to do > that work if there is support for the effort. > > -- > Frank W. Zammetti > Founder and Chief Software Architect > Omnytex Technologies > http://www.omnytex.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
