2010/7/31 Éric Araujo :

Good call.

Alternative idea: Have a new status “unread” to make searching easier for bug people. Or a predefined custom search for nosy_count == 1.

Please, let's stop messing with the tracker for everything. I think the current set up works reasonably well, and we should focus on the real problem: manpower -- Regards, Benjamin

Benjamin Peterson writes:

Please, let's stop messing with the tracker for everything. I think the current set up works reasonably well, and we should focus on the real problem: manpower

Ignoring issues (probably even with some patches attached) will drive contributors away. That's not the way to increase manpower. - Ralf

On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt wrote:

Benjamin Peterson writes:

...

Please, let's stop messing with the tracker for everything. I think the current set up works reasonably well, and we should focus on the real problem: manpower

Ignoring issues (probably even with some patches attached) will drive contributors away. That's not the way to increase manpower.

- Ralf

Overall the "no response" query just passes the buck. Let's say we get that query down to zero issues. What does that give us? Now we have 500 issues with 2 responses. Sure, it makes further correspondence more likely, but it's not solving any real issues and making any measurably significant impact. While I do think the "no response" query can be helpful, let's not attribute too much value to tiny tweaks of the tracker and reporting. Benjamin is right -- manpower is where we'll benefit the most, not in the manner we paint the current issue situation.

If I may comment *as* a new contributor: Terry responded almost immediately to my first issue raised, and that was a huge boost. If no-one had replied at all, I suspect I would never have spent any more time contributing to any part of Python. (And I contributed 8 more hours today.) Incidentally, given that this is my first post: Hi everyone, my name's Mark Smith. I'm a Python contractor based in Edinburgh, and my nick on IRC is juD2k (for strange, yet dull historical reasons) :-) --Mark

Sure it could make a difference. People who submit issues will appreciate *some* response a great deal more than no response.

That depends. Sometimes, people post to the bug tracker to get help, and they will get sad/driven away/angry when they get no response; sometimes, if they get a response but no help, they will still get sad/driven away/angry. Driving them away pointing out that the bug tracker is not a place to obtain help might be as much help as "we" can offer. Other people post to the tracker to offer help. Those are the ones that should not be driven away. Unfortunately, just responding to them doesn't improve anything, IMO. If people only post to the issue without any plan of actually doing something about the issue likely still drives people away.

Sure. *Part* of drawing in more manpower can be engaging with those submitting issues and seeing if we can get them to post patches and / or tests - and suck them as far into Python development as we possibly can. ;-)

I think it's important to find out what people expect when posting to the tracker. Maybe a mandatory radio list with these options would help: - I post this to get help from you - I'm willing to work on other issues to expedite processing of this one - The issue is not urgent, take your time Regards, Martin

On 8/2/2010 12:54 PM, Brian Curtin wrote:

On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt mailto:ralf@brainbot.com> wrote:

Benjamin Peterson mailto:benjamin@python.org> writes:

> Please, let's stop messing with the tracker for everything. I think > the current set up works reasonably well, and we should focus on the > real problem: manpower

Two months ago, I discovered and reported that about 1/5 of open issues had no responses. Is that 'reasonably well'? I do not remember other reports on that, at least not for a few years. A 'show unanswered' link might make it easier to recruit people to be first-responders by making it easier to do first response. This hardly amounts to 'messing with the tracker'. Rather, it is using the current mechanism by adding a link.

Ignoring issues (probably even with some patches attached) will drive contributors away. That's not the way to increase manpower.

As a said before, I think people who have posted, certainly people who have had fixes committed, should get an invitation letter. One suggestion on that could be to click 'show unanswered' if that were available.

Overall the "no response" query just passes the buck. Let's say we get that query down to zero issues. What does that give us? Now we have 500 issues with 2 responses. Sure, it makes further correspondence more likely, but it's not solving any real issues and making any measurably significant impact.

If a question response elicits no answer, the issue can be closed as out-of-date. But several times in the past two months, first responses have lead to more responses from both OP and developers who watch the tracker message list. Some have been closed as fixed already. Example: http://bugs.python.org/issue3874 The OP's first response was to gripe about no response earlier. His second was to write an entry that Georg could cut, paste, format, and commit. -- Terry Jan Reedy

On Tue, Aug 3, 2010 at 7:18 AM, Benjamin Peterson wrote:

I'm only referring to the infrastructure when I say "the current setup." I don't think repeatedly tweaking the tracker is likely to close more issues.

But tweaking the tracker to improve the way we *interact* with potential contributors may get more developers in the long run, as well as closing more issues. Currently, if a bug doesn't get responded to immediately by people monitoring the bugs list, then there's no easy way to go back and query "hey, are there any bugs nobody has even looked at yet?". All this discussion is about is acknowledging that that is something we should try to keep under control by listing them in the weekly summary and by making them easy to look up. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On Mon, 2 Aug 2010 17:13:01 -0500 Benjamin Peterson wrote:

2010/8/2 Nick Coghlan :

...

On Tue, Aug 3, 2010 at 7:18 AM, Benjamin Peterson wrote:

...

I'm only referring to the infrastructure when I say "the current setup." I don't think repeatedly tweaking the tracker is likely to close more issues.

But tweaking the tracker to improve the way we *interact* with potential contributors may get more developers in the long run, as well as closing more issues. Currently, if a bug doesn't get responded to immediately by people monitoring the bugs list, then there's no easy way to go back and query "hey, are there any bugs nobody has even looked at yet?". All this discussion is about is acknowledging that that is something we should try to keep under control by listing them in the weekly summary and by making them easy to look up.

Well, I just feel like we keep changing things to little result, creating an organic mess of fields and statuses. Adding more queries is fine, but let's not bow to the temptation to add more fields.

FWIW, I completely agree with Benjamin. Regards Antoine.

Mark Lawrence writes:

I completely disagree.

Mark, please stop being disagreeable.<wink> The above is *not true*. You've made no statements I can recall insisting that the only way to skin a cat is to use a GNOME theme, only that the cat needs skinning. Before you posted that, Benjamin had already clarified that his worry is that new fields will be added to the tracker, or available values for some fields will be changed. He's right, experience shows that adding fields to the tracker confuses reporters and responders alike, unless it's done very carefully. But he has no objection to improving the tracker's reporting capabilities. I think the tracker currently has plenty of information to do a much better job of responding in a timely fashion than was done in the past, so there's plenty of room for you to do your work without imposing new bureaucracy on others, yes? There's no real disagreement here (unless you think it would be a good idea for Benjamin to stop doing release manager and do issue triage instead, in which case, I certainly hope he disagrees!<wink>)

On 02/08/2010 22:18, Benjamin Peterson wrote:

2010/8/2 Terry Reedy:

...

On 8/2/2010 12:54 PM, Brian Curtin wrote:

...

On Mon, Aug 2, 2010 at 11:39, Ralf Schmittmailto:ralf@brainbot.com> wrote:

Benjamin Petersonmailto:benjamin@python.org> writes:

> Please, let's stop messing with the tracker for everything. I think > the current set up works reasonably well, and we should focus on the > real problem: manpower

Two months ago, I discovered and reported that about 1/5 of open issues had no responses. Is that 'reasonably well'?

I'm only referring to the infrastructure when I say "the current setup." I don't think repeatedly tweaking the tracker is likely to close more issues.

I find this response quite pathetic. The bulk of Terry's post has been snipped. My own earlier response has been ignored. Please Benjamin get out of your ivory tower, there are people such as myself who want to help, but we feel locked out. Yes I am aware that I've more than trodden on a few toes as part of my learning curve, but all in all in I'm very proud of the fact that in my brief tenure I've helped the Python community. The number of responses that I've had stating "Thanks I've forgotten that one" far out number the negative ones. Actually I've never had any negative ones. I guess that some of you are not as bold as I pretend to be. Honestly by nature I'm very quiet and shy so when I start talking like this I'm being very serious and it's taken me years to get there. Further, issues don't have to be closed, but what has to happen is that any issue that get raised *MUST* have a response. This doesn't mean someone bumping the Python versions up five years after the issue was raised. Fly back at me if you like. I don't care about me. I don't care about you. I do care about Python. Kindest regards. Mark Lawrence.

On 03/08/2010 00:24, Antoine Pitrou wrote:

On Tue, 03 Aug 2010 00:00:46 +0100 Mark Lawrence wrote:

...

Fly back at me if you like. I don't care about me. I don't care about you. I do care about Python.

Well, you should care about people. Free software is as much as about building welcoming communities than it is about writing good software.

Regards

Antoine.

Do you build welcoming communities by ignoring posts for ten years? Mark.

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.

Steve, thanks for your care-full reply. Steve Holden writes:

Particularly when the issue tracker works ...

Well, sometimes it's down. <shrug /> But Roundup is more flexible as a database engine than a lot of people realize. Better docs would help, I'm sure, but we can also create new standard queries quite easily. While it's not really possible to get good statistics on time-to-close, for example, we can do a pretty good job of identifying "ignored" issues, and we can target reducing the count to some extent.

It seems to me that something would be *really* wrong if nobody cared about the relatively few issues that had received no response.

Phrased as "care about", that's a straw man. Pretty much everybody cares about those issues. Phrased as "care for", well, now we've found the friction, I suspect. Applying real TLC to many of the hangfire issues is going to require highlevel skills and/or lots of time, resources that are scarce around here (because they're being applied to other important tasks).

The fact that Mark is on that case means that those who want to shrug their shoulders about it can do so.

Indeed, that's the way I feel about it. But Mark clearly doesn't think he alone is enough. There's a genuine difference of opinion here somewhere, even if I've misrepresented Mark's opinion. Maybe it would help if we scheduled a bug day, and try to make sure that a couple senior devs rendezvous with Mark so he can advocate some of the issues that bother him the most, and he can get a look at the issue resolution process in action.

I see the current efforts to ensure that new issues *all* receive an effective as complementary to the other activities that have always taken place.

Again, there's friction here. Somebody said that it's really no help if the acknowledgment is automatic, and that's true. The reply was that a polite response from a human isn't necessarily going to be much better unless there's real help in it, and that's true too. As I understand Mark, that's a lot of his frustration; he doesn't yet know enough to be of genuine help in most of the issues he handles, so he has to be satisfied with either dropping it on the floor again, or sending out an embarrassing "Hi, I'm from the Python triage team, and I'm sorry to tell you that after five years of dead silence, we still have nothing to say." Anyway, I know *I* find that frustrating when I have to do it! Where do we find the resources to provide that "real help"? Again, maybe one bug day to show what can be done, and then more or less regularly-scheduled bug days to keep up the momentum?

2010/8/2 Mark Lawrence :

On 02/08/2010 22:18, Benjamin Peterson wrote:

...

I'm only referring to the infrastructure when I say "the current setup." I don't think repeatedly tweaking the tracker is likely to close more issues.

I find this response quite pathetic.  The bulk of Terry's post has been snipped.  My own earlier response has been ignored.  Please Benjamin get out of your ivory tower, there are people such as myself who want to help, but we feel locked out.

You feel locked out by the current tracker? -- Regards, Benjamin

On Tue, 3 Aug 2010 04:27:53 am Terry Reedy wrote:

On 8/2/2010 12:54 PM, Brian Curtin wrote:

...

On Mon, Aug 2, 2010 at 11:39, Ralf Schmitt mailto:ralf@brainbot.com> wrote:

Benjamin Peterson mailto:benjamin@python.org>

writes: > Please, let's stop messing with the tracker for everything. > I think the current set up works reasonably well, and we > should focus on the real problem: manpower

Two months ago, I discovered and reported that about 1/5 of open issues had no responses. Is that 'reasonably well'?

I don't know. What percentage of new issues get ever get a response? My wild guess is that it's probably about 99.9%, but the 0.1% that don't remain languishing forever, skewing the statistics. What's the average age of those 1 in 5 issues? Maybe 1 in 5 is exactly right, given the realities of people available to respond to issues versus people available to report issues. Maybe 1 in 5 is supernaturally good, given our resources available. -- Steven D'Aprano

On 01/08/2010 02:00, Brian Curtin wrote:

On Sat, Jul 31, 2010 at 19:48, Mark Lawrencewrote:

...

Hi all,

I have been wading through outstanding issues today and have noticed that there are several where there has been no response at all to the initial post. Failing that, the only response has been Terry Reedy back in May 2010, and that only updating the versions affected.

Would it be possible to get some code in place whereby if there is no response to the initial post, this could be flagged up after (say) 24 hours? Surely any response back to the OP is better than a complete wall of silence?

Kindest regards.

Mark Lawrence.

We could just add globally visible query which shows all issues with a message count of 1. That query currently shows 372 issues, most of which were entered within the last few months.

The query strikes me as KISS, let's try it and see how we go. On this thread on c.l.py "500 tracker orphans; we need more reviewers" started by Terry Reedy it was quoted that there were 510 orphans as at Jun 19, 3:37 am. We're getting there.

24 hours seems too soon for any kind of notification. Who would receive this notification?

I plucked this figure out of the air thinking that if an issue was going to drop under the radar, this would be the most likely time. I was considering a worst case scenario where several core triage people are at a big Python event, others are on holiday [ shame on you :) ], some looking after the kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what about a week, opinions anybody? Notifications would go to the bugs mailing list and/or #python-dev. But this is hypothetical anyway if the message count of 1 query works. Only one way to find out, let's try it. Kindest regards. Mark Lawrence.

Perhaps just another number to track in the weekly bug summary?

*puts bug person hat on* I made the same suggestion to Ezio, so +1 I’ve just created a public query named “Reports without replies”, you should be able to add it to your queries list, or a tracker admin could decide to add it to the queries that are always visible in the sidebar. Regards

On 08/01/2010 06:14 PM, Terry Reedy wrote:

On 8/1/2010 7:44 AM, Éric Araujo wrote:

+1 On a prebuilt search

This is not as easy as it seems. A nosy count of 1 misses posts where someone added themself as nosy without saying anything, waiting for someone else to answer (and maybe no one ever did). A message count of 1 misses posts where a person follows up with a correction (because he cannot edit!) or addition. nosy = 1 or message = 1 would be better, and one cannot do that from search form, which, ANDS things together. Can a custom sql query do an OR?

There is an activity field which gets any issues with activity on a specific day. I'm not sure how useful that is. <shrug> Something that may be more useful, is a "no activity" search field with choices of day, week, month, year, etc... and make the output sortable on time without activity. That not only would cover the short term cases of no response, but also the longer term items that slip though the cracks. Ron

On 08/02/2010 03:57 AM, Stephen J. Turnbull wrote:

Ron Adam writes:

...

Something that may be more useful, is a "no activity" search field with choices of day, week, month, year, etc... and make the output sortable on time without activity.

That's exactly what a sort on date of activity gives you, though, and it can be from longest down.

Yes, but when I do it, I either get a single specific day, or 2700 issues.

Also, I think that most of the "date" fields actually allow ranges (iirc something like "today - 1 year, today" works, I've never actually used them), but I don't think this can be easily negated in the stock Roundup. What could be done though is something like "created Jan 1 1970, today - 2 years AND open" to find bugs that have been hanging fire for more than two years.

Have you tried it? I tried various different spelling and could only enter one specific day, "today" works, but "1 month" or "2 years" doesn't. What does work is entering a partial date, ie... 2010-07 for all issues with activity this july. Or 2010 for all issues with activity this year. Ron

On Sun, 01 Aug 2010 21:28:05 +1000, Nick Coghlan wrote:

On Sun, Aug 1, 2010 at 5:41 PM, Mark Lawrence wrote:

...

I plucked this figure out of the air thinking that if an issue was going to drop under the radar, this would be the most likely time. I was considering a worst case scenario where several core triage people are at a big Python event, others are on holiday [ shame on you :) ], some looking after the kids, yet more off sick etc. Hum, perhaps 24 hours is too soon, what a bout a week, opinions anybody? Notifications would go to the bugs mailing list and/or #python-dev. But this is hypothetical anyway if the message count of 1 query works. Only one way to find out, let's try it.

Perhaps just another number to track in the weekly bug summary?

Better, a table section giving the bugids, titles, and URL. Ezio just finished reworking the summary script to be more easily modified, so I bet he would find this easy to add at this point. --David