Re: [Python-Dev] Closing old bugs

Raymond writes:
Is there anyone else on python-dev who thinks it's a bad idea to automatically close reports without checking whether the issue is real?
Raymond: I'm speaking up with some trepidation here, since I am NOT one of those who frequently closes bugs. But I think that at least sometimes there IS an advantage to closing old bugs. I can envision a world in which there would be only 5-10 open bug reports at any given time, with enough developer volunteers available to respond to new reports as they come in. And I realize that we are nowhere near such a world and we're not going to be getting there anytime soon. But it is still the case that MOST people are intimidated by the enormous stack of open bugs. Perhaps "intimidated" is the wrong word... what I want to convey is that most people have no idea what's important or where to start -- it's just too big a pile. Perhaps all of the people who would actually work to close Python bugs are perfectly happy with the existing system. Or perhaps we scare off some potential volunteers because they have no idea where to start. I've seen some systems that solve this problem by allowing users to "vote" for favorite bugs... then you can tell the "important" bugs because they are more likely to have lots of votes. As I see it, Facundo is using a variant of that system. He is asking whether there is *ONE PERSON* out there who cares enough about a bug to subscribe to it and then to respond to his inquiry. If there's not even one such person, then he's closing the bug (but if one such person comes along later, they can re-report it). Sure, we may be throwing away some useful information by closing a bug report without proper investigation. But we're not in a situation where we are short of information... we've got plenty of information (bug reports), what we lack is developer time. If throwing away information helps to better focus the developer time we have, then it may be a useful process! And someday when nirvana arrives and there are only 5-10 open bugs, we can send intrepid volunteers digging through the archives to examine bugs that got closed without proper investigation. I'm not holding my breath. -- Michael Chermside

I've seen some systems that solve this problem by allowing users to "vote" for favorite bugs... then you can tell the "important" bugs because they are more likely to have lots of votes. As I see it, Facundo is using a variant of that system. He is asking whether there is *ONE PERSON* out there who cares enough about a bug to subscribe to it and then to respond to his inquiry. If there's not even one such person, then he's closing the bug (but if one such person comes along later, they can re-report it).
-1 This is both silly and harmful. It in no way resembles a professional approach to bug resolution. It throws away valuable information based on some vague theory of developer marketing (i.e. threatening to close a bug will cause a qualified, interested developer to suddenly have both the time and inclination to address it properly). If the real goal is to "kick some life" into bug resolution, then do something that directly fulfills that goal. Host a bug day. Make a newsgroup posting requesting thoughts on your favorite ten bugs. Write email to people who you think are capable of addressing the particular issue in question. Go recruit some qualified developers. Or just find a bug that interests you and fix it. Closing bugs without reading them is an anti-contribution. If it were a best practice, then there would already be a cron job in place to do it automatically. Raymond

Raymond Hettinger wrote:
I've seen some systems that solve this problem by allowing users to "vote" for favorite bugs... then you can tell the "important" bugs because they are more likely to have lots of votes. As I see it, Facundo is using a variant of that system. He is asking whether there is *ONE PERSON* out there who cares enough about a bug to subscribe to it and then to respond to his inquiry. If there's not even one such person, then he's closing the bug (but if one such person comes along later, they can re-report it).
-1 This is both silly and harmful. It in no way resembles a professional approach to bug resolution. It throws away valuable information based on some vague theory of developer marketing (i.e. threatening to close a bug will cause a qualified, interested developer to suddenly have both the time and inclination to address it properly).
ACK so far.
If the real goal is to "kick some life" into bug resolution, then do something that directly fulfills that goal. Host a bug day. Make a newsgroup posting requesting thoughts on your favorite ten bugs. Write email to people who you think are capable of addressing the particular issue in question. Go recruit some qualified developers. Or just find a bug that interests you and fix it.
Well, to "fix it" is not so easy for most people. You have to post a patch or attach it to the bug and then wait for someone to check it in. It's not sure that this is done anytime soon (no complaint; time is short, I know). Even fixes that are agreed upon by several people are not always checked in for a long time. Reinhold -- Mail address is perfectly valid!
participants (3)
-
Michael Chermside
-
Raymond Hettinger
-
Reinhold Birkenfeld