[Python-Dev] No response to posts

[Stephen J. Turnbull]

Steve Holden writes:

 > No, you don't, and the current discussion about how to ensure that bug
 > reporters get at least the courtesy of a relatively quick reply is one
 > of the most promising developments in building a welcoming community
 > that I can remember.

C'mon Steve, it's not hard to see that's unfair.  Mark deserves to be
complimented for the work he's doing, that side of your comment is
perfectly fair, but you of all people should take care to recognize
that python-dev is "welcoming people to the community" every day.

As Steven d'Aprano pointed out (admittedly with a bit of hyperbole) a
very high percentage of issues (about 97%) do get some response, and
nearly 87% of all issues ever submitted to Python have already been
closed (based on the end-of-July tracker summary).  Remember that many
of those that are still open are open because nobody's willing to call
them "walking dead" and close them as "unsalvagable."  Any serious
effort at triage by the people who would do the work to resolve them
will surely result in a very large fraction closed with "wontfix",
what is known as "a self-fulfilling prophecy".  It's not clear that's
a win; some users surely think so, others not.

Now, let's take a look at some recent numbers about issue flows.  Of
the 264 issues submitted in June, 126 (47.7%) have already been
closed.  Of the 138 still open, 38 (27.5% of open issues) have
activity in July, meaning that 62.1% of the sample of 264 recent
issues have either been resolved or are receiving ongoing support (and
maybe better than that).[1][2]

In fact, the numbers I'm looking at are really promising, too, and the
whole Python crew deserves a big round of applause for producing them
every day!  Those numbers mean that not only have hundreds of users
been "welcomed to the community", but a huge majority of them got some
kind of fix for their problems, too, or at least a comment from a
qualified expert.  That compares very favorably with my experience
with other products, both commercial and volunteer-developed.

I don't claim that these numbers are a reason for doing nothing about
issues that have been hanging fire for years.  But it clearly suggests
that those hangfires are mostly very hard issues for some reason.
They are not a systematic problem with the project's overall response
to issues; it is extremely effective in dealing with them.

What's left is a pure PR effort:

 > But let's not let that stop us trying to build a crew of
 > ambassadors to take care of the more touchy-feely side of things as
 > long as it operates to the language's ultimate benefit.

Nobody's interfering with that *at all*.  In fact, it's quite clear
that everybody is happy with Mark's work, and wants him to continue.
They just want him to give up on the idea that they're going to put in
a lot more effort on resolving issues than they already do, and his
claim that something's horribly wrong.  The numbers above show why.


Footnotes: 
[1]  "June" and "July" are approximations.  First, *creation date* was
queried with "from -2m to -1m", and then was filtered with *activity*
"from -1m" and *status* "open".

[2]  These are conservative estimates of activity in my opinion.  Eg,
depending on how many of the open issues not touched in July are
waiting on OP response, return of a developer from vacation, or
perhaps a release before being committed to a branch, it may be that
the number of issues waiting for developer attention is much smaller
than 100.

It's hard to develop more precise statistics, and this is obviously
not a random sample.  But the sample is probably not unrepresentative.
The corresponding numbers for May submissions, closures to date, and
June-July activity are 281, 151 (53.7%), and 44 (33.8% of still open
issues).  Interestingly enough, for issues submitted in May and still
open, the June activity is 23 and the July activity is 21, so they are
entirely disjoint!  This means that delays of a month or so don't
imply that an issue is being dropped on the floor at all in the May
sample, just that half the time it takes a developer a month or two to
get to his issues.

Footnote 1 applies here, too.