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.