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
Ted Husted wrote:
+1
Except that Apache open source projects don't really "allow" people to fill roles.
People start filling the roles, and then we recognize their contribution -- mainly by granting the system permissions (or "karma") to make the contributions directly.
Right now, anyone has karma to bugzilla or the wiki, where most project management type tasks would take place.
In practice, documentators and managers are very hard to find. Things like code we can use in our day-jobs, but documentation, including management documentation, not so much.
-Ted.
On Fri, 11 Mar 2005 16:23:22 -0500, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Quoting "Frank W. Zammetti" <[EMAIL PROTECTED]>:
As much as I hate to say it, sometimes engineers being project managers is a bad idea. Perhaps open-source community-driven development projects should come to that conclusion and separate the project managers from the developers. Just a thought (not even sure *I* would agree with it yet).
Project management in itself isn't a bad thing, but a very good thing. It's when the project managers are perceived to be the bosses of development, instead of its secretaries, that there's a problem. I think there are folks who could contribute alot to open source projects, and benefit the projects greatly, if they were allowed to fill a project manager roll.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
