Python to use a non open source bug tracker?

[Giovanni Bajo]

Tim Peters wrote:

> None are /totally ignored/ -- indeed, at least I see every one as it
> comes in.  You might want to change your claim to that no work
> obviously visible to you is done on them.  That would be better.

Please notice that my mail was in the context of "user satisfaction with the
bug tracker". I was claiming that it is useless to provide a blazingly fast
support turnaround for technical issue, when there is "no visibile work" being
done on most bugs that are submitted. And, in turn, this was in the context of
hiring 6-10 people as the only acceptable minimum to maintain and admin a bug
tracker. I was claiming that, if such a group was ever formed, it was better
spent on bug triage rather than keeping their keys ready all day long to
quick-fix any server breakage in minutes.

> These are the actual stats as of a few minutes ago:
>
> Bugs:  938 open of 7169 total ~= 87% closed
> Patches:  429 open of 3846 total ~= 89% closed
> Feature Requests:  240 open of 479 total ~= 50% closed

I claimed different numbers based on personal perception; I stand corrected,
and apologize for this. I could just say that my perception was wrong, but I
guess there's something in it that could be further analyzed. For instance, I
would be really curious to see how these figures look like if you consider only
bugs/patches/rfe *NOT* submitted by python committers. I don't think
Sourceforge can ever compute this number for us, so I'll wait to ask Roundup
about it (or, uh, Jira...).

> There's an easy way to improve these percentages dramatically,
> although they're not bad as-is:  run thru them and close every one
> that isn't entirely clear.  For example, reject every feature request,
> close every patch that changes visible behavior not /clearly/ fixing a
> bona fide bug, and close every "bug report" that's really a feature
> request or random "but Perl/Ruby/PHP doesn't do it this way" complaint
> in disguise.

Either close directly any nonsense, or ask for more feedback to the poster,
until the bug/patch/rfe is sufficiently clear to be handled, or 3 months are
passed and you close the bug for "no further feedback from the poster". If this
would dramatically reduce the number of open bugs, then yes, Python really
needs someone to do bug triaging.

> For example, the oldest patch open today is a speculative
> implementation of rational numbers for Python.  This is really a
> feature request in disguise, and has very little chance-- but not /no/
> chance --of ever being accepted.  The oldest bug open today is from 6
> years ago, and looks like an easy-to-answer /question/ about the
> semantics of regular expressions in Python 1.6.  I could take time to
> close that one now, but is that a /good/  use of time?  Yes, but, at
> the moment, even finishing this reply seems to be a /better/ use of my
> time -- and after that, I'm going to get something to eat ;-)

It might be not a good use of your time at all, since you are a developer. But
having a database with 938 open bugs most of which are
incomplete/nonsense/unconfirmed is much less useful than it could be. It also
raises the bar for new developers: it's much harder to just "pick one" and fix
it. I know because I tried sometimes, and after half an hour I couldn't find
any bug that was interesting to me and "complete" enough to work on it. I also
noticed that most bugs are totally uncommented like nobody cared at all. This
is where my thought about Python missing bug triaging started.
-- 
Giovanni Bajo