On Tue, 21 Sep 2010 20:16:52 -0400 Jack Diederich wrote:

On Tue, Sep 21, 2010 at 7:58 PM, Mark Lawrence wrote:

...

I'm rather sad to have been sacked, but such is life.  I won't be doing any more work on the bug tracker for obvious reasons, but hope that you who have managed to keep your voluntary jobs manage to keep Python going.

Umm, what? You mean http://bugs.python.org/issue2180 ?

""" Mark, please stop closing these based on age. The needs to be a determination whether this is a valid bug. If so, then a patch is needed. If not, it can be closed."""

Am I missing something?

Simply, situations like the above (Mark closing a bug just because nobody would answer his message on a short delay) have happened multiple times - despite people opposing, obviously -, and we decided that it was better to remove his tracker privileges since his contribution has not really been productive for us. There was a whole python-dev thread some time (weeks? months?) ago where several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR. Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another) Regards Antoine.

On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan wrote:

On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou wrote:

...

Simply, situations like the above (Mark closing a bug just because nobody would answer his message on a short delay) have happened multiple times - despite people opposing, obviously -, and we decided that it was better to remove his tracker privileges since his contribution has not really been productive for us.

There was a whole python-dev thread some time (weeks? months?) ago where

I think it was the thread "No response to posts" started (by Mark) on July 31.

...

several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR.

Yup. In that thread (and others) I see lots of evidence where Mark responded very negatively (from "I disagree entirely" to "I find this response quite pathetic") when people explained how we treat the tracker, and stuck to his guns no matter how many people tried to explain that he should stop. His attitude can be summarized by his "Fly back at me if you like. I don't care about me. I don't care about you. I do care about Python." Which to me sounds defiant and passive-aggressive. I don't want to go into analyzing, but I expect that Mark has issues that are beyond what this community can deal with.

...

Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another)

I still prefer the "trust but monitor" approach over excessively high barriers to entry, but we do need to recognise that one consequence of that approach is that we *will* get into situations where we need to tell people "thank you for your contributions, but we think, on balance, we will be better off if you don't contribute in this way any more".

Mark *did* do quite a bit of good in his time with tracker privileges.

Right, that was my impression from the issues he touched on which I happened to be subscribed.

A number of lingering issues that would have otherwise continued lingering did indeed get closed. That work is still appreciated, even if it was ultimately deemed by the other tracker admins not to be sufficient to balance out the hassles created by his aggressive stance towards closing older issues (which, while unloved, are not automatically invalid).

How and how often was Mark reminded about this?

If this had happened *without* the prior discussion regarding more appropriate handling of tracker issues, then I would have an issue with it. However, given that the first reaction was to provide additional mentoring, with revocation of privileges only happening when the problems continued, that seems to me like the way this process is *meant* to work.

Where was the decision to revoke privileges discussed? Not on any mailing list that I am subscribed to. Was Mark given an ultimatum? Given that this came out rather unfortunately (even if the end result is the best that could have happened) I would recommend that in the future more attention is paid to "documenting" publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient. -- --Guido van Rossum (python.org/~guido)

On 22/09/2010 15:33, darren@ontrenet.com wrote:

If you guys continue to make a public jury of this, no one else will want to step into that role....

One of the perhaps-downsides of projects with an open community and open development processes is that any dirty-laundry there might be tends to get washed in public. Difficult decisions will always be accompanied by a measure of soul-searching and disagreement. I guess this is what you mean by "public jury". I think reaching decisions like this in private, without public discussion, would be worse (decisions could only be made by a 'secret cabal' with much less accountability and opportunity to improve). I don't think this kind of process can ever be easy (unless we eliminate the involvement of humans in Python development altogether), but we do have a process. Particularly bearing in mind the comments of Guido on the topic we can further improve the process. I too found Mark's contributions to issues I'm involved in helpful, but I understand the decision entirely. We all need to be able to work together and despite best efforts that just wasn't working out. I also wish Mark the best for the future and hope that he is still able to find some way to contribute to Python. All the best, Michael Foord

...

...

On Wed, Sep 22, 2010 at 8:47 PM, Antoine Pitrou wrote:

...

Simply, situations like the above (Mark closing a bug just because nobody would answer his message on a short delay) have happened multiple times - despite people opposing, obviously -, and we decided that it was better to remove his tracker privileges since his contribution has not really been productive for us.

There was a whole python-dev thread some time (weeks? months?) ago where I think it was the thread "No response to posts" started (by Mark) on July

On Wed, Sep 22, 2010 at 4:07 AM, Nick Coghlan wrote: 31.

...

...

several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR. Yup. In that thread (and others) I see lots of evidence where Mark responded very negatively (from "I disagree entirely" to "I find this response quite pathetic") when people explained how we treat the tracker, and stuck to his guns no matter how many people tried to explain that he should stop.

His attitude can be summarized by his "Fly back at me if you like. I don't care about me. I don't care about you. I do care about Python."

Which to me sounds defiant and passive-aggressive. I don't want to go into analyzing, but I expect that Mark has issues that are beyond what this community can deal with.

...

...

Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another) I still prefer the "trust but monitor" approach over excessively high barriers to entry, but we do need to recognise that one consequence of that approach is that we *will* get into situations where we need to tell people "thank you for your contributions, but we think, on balance, we will be better off if you don't contribute in this way any more".

Mark *did* do quite a bit of good in his time with tracker privileges. Right, that was my impression from the issues he touched on which I happened to be subscribed.

...

A number of lingering issues that would have otherwise continued lingering did indeed get closed. That work is still appreciated, even if it was ultimately deemed by the other tracker admins not to be sufficient to balance out the hassles created by his aggressive stance towards closing older issues (which, while unloved, are not automatically invalid). How and how often was Mark reminded about this?

...

If this had happened *without* the prior discussion regarding more appropriate handling of tracker issues, then I would have an issue with it. However, given that the first reaction was to provide additional mentoring, with revocation of privileges only happening when the problems continued, that seems to me like the way this process is *meant* to work. Where was the decision to revoke privileges discussed? Not on any mailing list that I am subscribed to. Was Mark given an ultimatum?

Given that this came out rather unfortunately (even if the end result is the best that could have happened) I would recommend that in the future more attention is paid to "documenting" publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient.

-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/darren%40ontrenet.com

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

On Sep 22, 2010, at 7:17 AM, Guido van Rossum wrote:

Where was the decision to revoke privileges discussed? Not on any mailing list that I am subscribed to.

It was on IRC.

Was Mark given an ultimatum?

I sent him a nicely worded email. The tracker privs were set back to the normal level which most participants have (can comment, submit patches, etc. but not close or reprioritize). That would have allowed him to contribute and participate. If that had worked out, it would have been easy to add back close/reprioritize capabilities No one needed to be hurt. Unfortunately, he responded with drama and another dev shut-off his tracker access entirely. Raymond

On Thu, 23 Sep 2010 00:29:23 +0900 "Stephen J. Turnbull" wrote:

Guido van Rossum writes:

...

I would recommend that in the future more attention is paid to "documenting" publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient.

+1 on explaining "what" and "why" where the committers can see it, and +1 on limiting distribution.

The one time I lifted someone's privileges that's the way I did it (by luck, mostly). In hindsight, the fact that it was all done in plain sight of the committers made it easy for us to put the incident behind us. The fact that it was only visible to the committers made it easier mend the relationship later.

I guess python-committers would have been the best recipient indeed. Sorry for that. Regards Antoine.

On 22/09/2010 16:44, Guido van Rossum wrote:

On Wed, Sep 22, 2010 at 8:29 AM, Stephen J. Turnbull wrote:

...

Guido van Rossum writes:

...

I would recommend that in the future more attention is paid to "documenting" publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient.

+1 on explaining "what" and "why" where the committers can see it, and +1 on limiting distribution.

Agreed on both counts.

...

The one time I lifted someone's privileges that's the way I did it (by luck, mostly). In hindsight, the fact that it was all done in plain sight of the committers made it easy for us to put the incident behind us. The fact that it was only visible to the committers made it easier mend the relationship later.

I understand the desire to keep dirty laundry in. I would like to keep it in too. Unfortunately the offending person in this case chose not to; I will not speculate about his motivation. This is not unusual; I can recall several incidents over the past few years (all completely different in every detail of course) where someone blew up publicly and there wasn't much of a chance to keep the incident under wraps. I see it as the risk of doing business in public -- which to me still beats the risk of doing business in back rooms many times over.

If you're referring to me I'm extremely offended. Yes or no? Kindest regards. Mark Lawrence.

On Wed, Sep 22, 2010 at 5:18 PM, Tim Peters wrote:

Yikes - Mark has done terrific work in some very demanding areas, & I'd hate to see him feel unwelcome.  So that's my advice:  find a way to smooth this over.  You're welcome ;-)

[Guido]

...

...

... I understand the desire to keep dirty laundry in. I would like to keep it in too. Unfortunately the offending person in this case chose not to; I will not speculate about his motivation. This is not unusual; I can recall several incidents over the past few years (all completely different in every detail of course) where someone blew up publicly and there wasn't much of a chance to keep the incident under wraps. I see it as the risk of doing business in public -- which to me still beats the risk of doing business in back rooms many times over.

[Mark Lawrence]

...

If you're referring to me I'm extremely offended.  Yes or no?

Have to confess I can't see what's offensive in what Guido wrote there.  If you're inclined to feel offended, how about going back to Guido's:

   Which to me sounds defiant and passive-aggressive. I don't    want to go into analyzing, but I expect that Mark has issues    that are beyond what this community can deal with.

Even I felt a bit offended by that one ;-)

That was not one of my finer moments, and I apologize. -- --Guido van Rossum (python.org/~guido)

On Thu, 23 Sep 2010 10:18:39 am Tim Peters wrote:

Yikes - Mark has done terrific work in some very demanding areas, & I'd hate to see him feel unwelcome. So that's my advice: find a way to smooth this over. You're welcome ;-)

I'd like to second that. Mark has been pushy, annoying and demanding, although he has his bad points too *grins*. Seriously, Mark has brought a remarkable amount of energy to the tracker, for good and bad. The good shouldn't give him a Get Out Of Jail Free card forever, but in the absence of any knowledge of what lead to Mark's tracker privileges being revoked, I have no objections in principle to giving him a second chance if the devs decide that is acceptable and Mark is willing. (Not that my objections carry much weight.) Either way, I would like to publicly thank Mark for his efforts and wish him the best for the future. [...]

Have to confess I can't see what's offensive in what Guido wrote there. If you're inclined to feel offended, how about going back to Guido's:

Which to me sounds defiant and passive-aggressive. I don't want to go into analyzing, but I expect that Mark has issues that are beyond what this community can deal with.

Even I felt a bit offended by that one ;-)

I don't see why. Mark's emails often do sound defiant and passive-aggressive. Is that something we're supposed to ignore? And as for issues, Mark himself has explicitly and publicly mentioned them on this very list, and we *can't* deal with them. Nor should we be expected to. Mark has done good work, dealing with many issues in the tracker during a remarkably short time. But he's also managed to annoy and upset a number of people in a remarkably short time too. The long term health of Python depends more on the community than the existence of a few bugs more or less. -- Steven D'Aprano

Given that this came out rather unfortunately (even if the end result is the best that could have happened) I would recommend that in the future more attention is paid to "documenting" publicly that someone's being booted out was inevitable, by an exchange of messages on python-dev (or python-committers if we want to limit distribution). And no, I don't think that IRC (where I suspect this happened) is sufficient.

While the community should be informed in public, I think that the actual revocation of privileges should happen in private. People getting such a "blue letter" often react overly negative, and then regret that their response is recorded in the public. The only downside of this approach is that people may feel that this is a unilateral decision by one committer, then appeal to you (I'm sure you recall cases that went that way :-). Also, I think it would be better to ask the contributor to step back "on his own" (acknowledging that this isn't really voluntarily), instead of revoking privileges and then informing about that decision. Regards, Martin

Cameron Simpson writes:

I've just read that thread. Mark doesn't sound that way to me. "I disagree entirely" is an entirely valid response, when backed up with argument, such as his immediately following sentence:

Perhaps we should simply agree to disagree,

Agreeing to disagree *on actions* does not work with shared resources, and the tracker is a shared resource. It's not a valid response here. According to reports, his disagreement *did* extend to action.

"I find this response quite pathetic" does seem an overreaction to a single point clarification-type post. The "Fly back at me if you like. I don't care about me. I don't care about you. I do care about Python." quote I actually think this quite laudable in its way; he's expressing a commitment to getting things done, and a determination to focus on the core issue (response workflow, from the sounds of it) in the face of the emotional responses the disagreement will inevitably produce in the discussions.

Expressing a commitment and emotional discussion are not problems worthy of even thinking about changing privileges. The problem is that (according to reports) he *imposed* his opinion on all the other tracker workers by making changes to the public database (ie, closing bugs), after being told by several people that the consensus was otherwise. And did this several times. While this was not clearly expressed in several of the key posts in this thread, I suspect that this is what was meant by "other ways are more fruitful" and Guido's now retracted psychoanalytic comment. There is a delicate balance to be kept between "he who does the work makes the decisions" and "polluting the common pool." In this case, the balance was clearly upset. Triaging and closing bug reports are not the only functions of the tracker, and in fact they are subsidiary to actual bug-fixing work. It's pretty clear to me that if a triager disagrees with the priorities of the bug fixers, his only recourse is public discussion, and to do what he personally can to respond to issues.

On 23/09/2010 10:59, Antoine Pitrou wrote:

...

Triaging and closing bug reports are not the only functions of the tracker, and in fact they are subsidiary to actual bug-fixing work. +1. What we really need is people analyzing issues, posting patches or reviewing existing ones. Pushing for resolution of issues by

On Thu, 23 Sep 2010 13:32:07 +0900 "Stephen J. Turnbull" wrote: threatening to close them isn't effective; it doesn't magically create more free time for us to deal with them.

Well, useful things that can still be done in triaging on old issues: checking that a bug still exists checking that a patch still applies and that tests still pass pointing out if a patch lacks tests seeing if the issue is duplicated elsewhere If it is a *feature request* (as opposed to a bug report - and I appreciate that the difference is often unclear) and the original poster has 'lost interest' then closing the issue may be a reasonable response. As others have mentioned, bumping old issues can bring it to the attention of developers monitoring on IRC or the bug mailing list who may not have seen the original report. On all issues, new or old, additional potentially useful things to do: make sure the issue is assigned to the right person if appropriate add relevant keywords to make it easier to find in searches ensure other fields in the tracker are filled in correctly closing the issue if it is invalid or expired (for example it only applies to an out of maintenance version of Python) Some developers (Martin and Antoine at least) have complained about the 'noise' of receiving extra emails on issues they are nosy on. Several developers have stated that they have found it useful (myself, Guido and Tim Golden at least) - so there is certainly no consensus that this work is pointless. All the best, Michael Foord

Regards

Antoine. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.u...

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

On 23/09/2010 13:11, "Martin v. Löwis" wrote:

...

make sure the issue is assigned to the right person if appropriate -1. We typically don't assign issues to others.

Some people have requested to be assigned to issues. (Myself for unittest, Ronald for Mac OS X issues etc.)

...

add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful.

Hard as it may be to believe, we do have (and are trying to cultivate) people who want to contribute to Python and start by searching for issues at the bug tracker. All the best, Michael

...

ensure other fields in the tracker are filled in correctly Likewise.

Regards, Martin

-- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

On 23/09/2010 13:28, "Martin v. Löwis" wrote:

...

...

...

add relevant keywords to make it easier to find in searches -0. Going through old issues just to make sure the keywords are right seems wasteful.

Hard as it may be to believe, we do have (and are trying to cultivate) people who want to contribute to Python and start by searching for issues at the bug tracker.

Sure. However, on any specific search, many issues come up already. So people searching for stuff to do will easily find tasks already.

Seems to me that the distinction to be made here is between activity which might, to some, appear a waste of time (eg setting flags and versions on existing calls) but which at worst provides no benefit and in fact might help someone narrow down a search more easily; and activity which is simply flatus vocis and which actually distracts or irritates. Individuals' thresholds clearly vary. TJG

On Thu, 23 Sep 2010 11:50:26 -0600, "Zooko O'Whielacronx" wrote:

Also, I would like to point out that, not having read the other traffic that this thread alludes to, either from earlier mailing list threads or from IRC, I don't really understand what exactly Mark did wrong. The complaints about his behavior on this thread seem to be a little... non-specific. Did he continue to close tickets after he was asked not to do so? I didn't see any quotes or timestamps showing what happened or when.

Yes. It was necessary for the devs to monitor his work and re-open tickets he closed inappropriately. We always explained why the closure was inappropriate. The number of tickets closed inappropriately was growing rather than shrinking. It was this latter fact that, I believe, led to what happened. I think this could have been handled better, but thankfully this is not a situation we often find ourselves in, so we don't have much practice at dealing with such. Good ideas for procedures have been aired here as a result, so if the next incident is not too far in the future hopefully we'll handle the next one more smoothly. (But you'll excuse me for hoping it is so far in the future that we forget :) Again, there was nothing preventing Mark from continuing to comment on issues, test things, ask questions, and even suggest that issues be closed. However, his inappropriate response to losing triage privileges was causing significant problems on the tracker, and so we were forced to disable his account. This disabling does not need to be permanent. -- R. David Murray www.bitdance.com

On 9/23/2010 1:44 PM, Terry Reedy wrote:

On 9/23/2010 8:11 AM, "Martin v. Löwis" wrote:

...

...

make sure the issue is assigned to the right person if appropriate

-1. We typically don't assign issues to others.

What I and Mark (that I know of) did in that respect was to assign doc issues, including old issues reclassified as doc issues, to docs@python.

...

...

add relevant keywords to make it easier to find in searches

-0. Going through old issues just to make sure the keywords are right seems wasteful.

...

...

ensure other fields in the tracker are filled in correctly

Likewise.

I am guessing that you have never done professional database management. And I suspect you would not be temperamentally suited to such. To repeat what I said in another post, if it does not matter how a field is set, it should not be there.

You seem really antagonistic to, or at least dismissive of, people who contribute in ways other than how you do. That strikes me as unhelpful.

And before this descends into a general discussion of various people's approach to collaboration, let me remind us all that it does indeed "take all sorts to make a world".

From what I have seen on this list, nobody has suggested that Mark's work was *all* unhelpful. The fact that he can be difficult to work with doesn't remove the value of much of the work he was doing, and I am happy to note that there doesn't seem to be any blanket verdict that Mark should never have tracker privileges again.

Mark courageously admitted on this list to having personal problems to overcome. That made me, at least, more sympathetic to his case, and more tolerant of his foibles and style of communication. I appreciate that a disruptive team member might eventually have to be isolated for the good of the team, but I am sorry to note that it came to that in Mark's case, and I hope that eventually he can return to the fold somehow. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/

On 9/22/2010 6:47 AM, Antoine Pitrou wrote:

There was a whole python-dev thread some time (weeks? months?) ago where several of us already tried to suggest more fruitful ways of contributing, suggestions which weren't received very welcomingly AFAIR.

There were two types of criticisms and suggestions, somewhat contradictory. The first type was something like 'Your tracker work is fine, but your pydev post berating others for not doing the same thing as you is not. Relax, do what you think is worthwhile, and let others decide what they will do." When I reiterated that in private email, he agreed with me and as far as I know he changed his behavior. The second type, which apparently included your response, began "Your tracker work is not all good. Change what your are doing ...". If the continuing disagreement and upset with his tracker (versus posting) behavior, to the point of possibly canceling admin privileges, had been brought up for instance on the committers list, I would have suggested to him that the low-hanging fruit had been picked (or discarded) and that a more careful approach was needed for the future. Would that have had any effect? I do not know.

Now I understand that opinions over this may vary and involve multiple factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another)

Mentoring would be easier if there were clearer and more complete written guidelines. I was under the impression that this was being worked on. It would also be easier if it were clearer who is/are the deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement? -- Terry Jan Reedy

On Wed, Sep 22, 2010 at 18:24, R. David Murray wrote:

On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy wrote:

...

On 9/22/2010 6:47 AM, Antoine Pitrou wrote:  > Now I understand that opinions over this may vary and involve multiple

...

factors, but I would suggest that at least a bit of mentoring is needed if we want to give privileges early on. (and the amount of mentoring needed can vary wildly from one person to another)

Mentoring would be easier if there were clearer and more complete written guidelines. I was under the impression that this was being worked on. It would also be easier if it were clearer who is/are the

Brett is planning to work on it.  Because he is, I suspect everyone else is waiting for that, instead of working on it now.  Just one of those things.  (I believe his target is January-ish?)

Yep. I am planning on starting my two month PSF grant in January and the first thing on the agenda is a complete rewrite of the developer docs and moving them into the Doc/ directory (after that is managing code in Python 2/3 HOWTO and then after that most likely testing stuff, but maybe Python 3 stdlib fixes instead if that is deemed more important). -Brett

...

deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement?

We discussed this a while back and I don't think we really have a tracker BD.  Brett and Martin come closest, but mostly we just sort of evolve a rough consensus.  I think once Brett reduces that operating consensus to a written document things will be clearer.

--David _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org

On Wed, Sep 22, 2010 at 11:46 PM, Raymond Hettinger wrote:

On Sep 22, 2010, at 6:24 PM, R. David Murray wrote:

...

On Wed, 22 Sep 2010 19:18:35 -0400, Terry Reedy wrote:

...

deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement?

We discussed this a while back and I don't think we really have a tracker BD.  Brett and Martin come closest, but mostly we just sort of evolve a rough consensus.

IMO, Benjamin and Antoine are the closest.  They devote a substantial portion of their lives to Python and have been our most active contributors in the last year.   They read almost every tracker post, read every check-in, and continuously monitor the IRC channel.

Off topic-er. Does anyone have scripts that pull data on how many committers commit or how many trac admins admin? I'm not asking for punitive reasons - I'd be the first against the wall - but I wouldn't mind graphing it. Power law, methinks. With big, confounding, and jumbley spikes in the Spring for PyCon. Likewise for mailing list subscriptions. Personally I've gone back and forth between subscribing to everything (-list -dev -commits -bugs -ideas, et al) and subscribing to almost nothing. -Jack

On Thursday 23 September 2010 08:36:47 Georg Brandl wrote:

This should be easy to do with a hg repo such as the test conversion one on hg.python.org -- the "activity" extension already does the graphing, and I'm sure it can easily be tweaked to your liking.

http://www.freehackers.org/thomas/2008/10/31/activity-extension-for-mercuria...

Hi all, This blog entry is old, and I have improved 'hg activity' since then, for example the extension can now display several graphs, splitting the activity by authors, branches, files, ... And, of course, I would be very happy to help 'tweaking' the script for the python community. best wishes, Thomas ps: i'm not subscribed to python-dev. -- Thomas Capricelli http://www.freehackers.org/thomas

...

deputed tracker authority/ies. Not everyone has the same idea about how to handle the various fields and processes. Who decides in cases of disagreement?

We discussed this a while back and I don't think we really have a tracker BD. Brett and Martin come closest, but mostly we just sort of evolve a rough consensus. I think once Brett reduces that operating consensus to a written document things will be clearer.

I personally think that the tracker fields and how they should be set is of minor importance. If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug). Asking every now and then "is this still an issue", or setting the version number, doesn't really advance the issue. Regards, Martin

On 23/09/2010 09:46, Georg Brandl wrote:

Am 23.09.2010 09:18, schrieb "Martin v. Löwis":

...

I personally think that the tracker fields and how they should be set is of minor importance. If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug). Asking every now and then "is this still an issue", or setting the version number, doesn't really advance the issue.

It does however attract attention from developers who either weren't around when the original issue was submitted, or didn't feel competent enough to fix it then.

It is also helpful to try reproducing the bug with a current version, in case the issue has been fixed already -- whether because of a duplicate bug report or by "chance".

I think my experience is that of several others. The work done by Mark and other tracker-trawlers has been useful: to dust off issues, attempt to assess their current validity, add suitable people to nosy lists, and where possible to try to reproduce or to encourage an OP to provide patches or other useful input. I've addressed, closed, or at least taken note of several issues in this way which I might not otherwise have done. The two less useful overspills of this generally useful activity have been: simple noise of the "Is anyone interested in this?" variety -- although even that might be useful, as Georg says, in highlighting older issues to newer developers; and the over-eager closure of calls on the basis of lack of response, and it seems to be an excess of this last which has brought the matter to a head. Let me ask a question which I don't think has been asked in this thread: are there guidelines for tracker-trawlers? I'm never sure where to look for this kind of thing myself. If there's nothing, I'm happy to pen a dos-and-donts (which I might do anyway, simply as a blog entry...) TJG

On 23/09/2010 10:38, "Martin v. Löwis" wrote:

...

Let me ask a question which I don't think has been asked in this thread: are there guidelines for tracker-trawlers? I'm never sure where to look for this kind of thing myself. If there's nothing, I'm happy to pen a dos-and-donts (which I might do anyway, simply as a blog entry...)

Can you please rephrase the question? What's a "tracker-trawler"?

My invented terminology for someone -- like Mark -- who invests time in going through issues in the tracker with a view to assessing them, prioritising them, de-duplicating, etc. As opposed to someone who's looking through issues with a view to finding things to fix within a particular area of competence. TJG

On 9/23/2010 3:18 AM, "Martin v. Löwis" wrote:

I personally think that the tracker fields and how they should be set is of minor importance.

As of just now, if you were to wonder "What (security) bugs are open for 2.5" and search on open 2.5 issues, you would get a list of 44 issues. It is only 44 instead of hundreds because of the work I and Mark have done in the last 4 months. It it 44 instead of perhaps 5 because Tarek and Eric insist on marking all disutils2 issues for all versions even though though these issues have nothing to do with maintenance releases. It is a real nuisance when trying to do tracker cleanup. Trying to do searches in databases with inaccurate key data is a pain.

If there is a bug in Python, the most useful contribution is to submit a fix (or provide a rationale why this is not a bug).

Agreed,at least abstractly, with applying a fix a close second. That does not mean that other activities are useless. However, there are currently 1034 issues with the patch keyword set and perhaps others with pacthes. So I think one can legitimately ask whether adding more *new* patches, to possibly sit unreviewed for years, is the most useful contribution at the moment. In any case, asking whether a patch submitted for 2.5 (and now 2.6) is relevant to future maintenance releases amounts to suggesting that is may not be a bug for current purposes. Certainly, anyone fixing a bug for 2.7 should also know whether or not it is also a 3.x bug.

Asking every now and then "is this still an issue", or setting the version number, doesn't really advance the issue.

Numerous issues have been advanced by the questions I and Mark have asked. Some were legitimately closed as out of date (the bug reported for 2.4/5/6 had already been fixed). Others were closed as fixed when someone committed something. The fact that Mark got over-zealous in closing issues too soon does not negate this. Some of our questions were more specific, and asking questions was not the only things we did. I tested some old reports against 3.1 and I believe Mark also did some testing himself. Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted? -- Terry Jan Reedy

On 9/23/2010 3:50 PM, Georg Brandl wrote:

ISTM that the "versions" field is not very useful if the other fields are filled accurately.

For example, feature requests almost always only belong to the current trunk. Yes, for features that fall under the moratorium, the "versions" field would be different; however, we already have an "after moratorium" keyword that signifies this. Other than this, we currently don't assign feature requests to specific milestones, and I don't ever see us doing that.

Bug reports by nature almost always belong to all branches in maintenance;

For various reasons, there bugs that are 2.x or 3.x specific. Those that are not may require sufficiently different fixes that a fix is applied for one branch while the issue is left open for the other. -- Terry Jan Reedy

On 9/23/2010 6:17 PM, Nick Coghlan wrote:

On Fri, Sep 24, 2010 at 5:50 AM, Georg Brandl wrote:

...

...

Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted?

ISTM that the "versions" field is not very useful if the other fields are filled accurately.

It's useful for bug reports to flag affected versions. We should probably just *not set it* for feature requests, though.

Now that 2.7 is out, so that feature requests can only be for a future 3.x, I would actually like the tracker to restrict the allowed values for non-doc feature requests either to 3.2/3.3 or to Not Applicable or whatever. It is a nuisance that people can still file such for 2.7, for instance. -- Terry Jan Reedy

On 9/23/2010 7:12 PM, darren@ontrenet.com wrote:

So if there turns out to be a major security hole or sever bug in 2.7, then it shouldn't be filed against 2.7? and fixed in a 2.7.x sort of branch? In that case, would you just suggest everyone using 2.7 to jump to 3.x?

As long as a 2.x version is supported, filing bugs, branching and even releasing critical updates is, although rare, a fact of life.

I am not sure who or what you are responding to. The below is based on the fact the 2.7 is now closed to *new features* and will be as long as the CPython pydev group maintains it. In another post I said that the Versions field is needed for *bugs* as long as we are maintaining 2.7, which will be for several years, because there are and will continue to be 2.7 and 3.x specific bugs. If you want *new features*, then yes, you need to jump to 3.x. Otherwise you can relax, and perhaps contribute to 2.7 bug fixes if you want.

...

Now that 2.7 is out, so that feature requests can only be for a future 3.x, I would actually like the tracker to restrict the allowed values for non-doc feature requests either to 3.2/3.3 or to Not Applicable or whatever. It is a nuisance that people can still file such for 2.7, for instance.

-- Terry Jan Reedy

In article <4C9C6A6F.6010202@netwok.org>, Éric Araujo wrote:

How about revamping the type/versions fields?

Issue type () Feature request (blocked by moratorium: () yes () no) () Bug (found in: [] 2.7 [] 3.1 [] py3k) () Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k)

I’m getting tired of explaining the meaning of the versions field again and again, let’s put this information directly under the eyes of the bug reporter.

I believe there is another separate use case for the versions field that hasn't been mentioned yet: for issues with "release blocker" priority, the versions field is often used to identify the upcoming release for which a resolution is deemed mandatory. However, having a single versions field is not totally satisfactory for this, particularly when - as has happened in the recent past - two different release cycles overlap (say, Python 2.7.x and 3.2.y). A given issue may or may not apply to both, it may be a "release blocker" for one or both, and, if both, a fix may be checked-in for one branch but not the other. The release managers for the two releases may end up using the one priority field and the one set of version fields for conflicting purposes. It certainly makes it more difficult to automate a tracking report of exactly what are the release blocker issues for a specific release. Besides adding fields to the database for an issue, there are other ways to handle the ambiguity, of course. The simplest might be to just open a separate duplicate issue for each additional release blocked. Presumably that level of detail might only be needed in the endgame of a release, beta or rc stages. It still places a restriction on the use of the version field and possibly other fields. In issue workflow documentation, there should be some description of how "release blocker" should work, perhaps including something along the lines of "once a release enters stage <x>, 'release blocker' priority should only be changed with the approval of the release manager". -- Ned Deily, nad@acm.org

On Fri, Sep 24, 2010 at 10:26 PM, Antoine Pitrou wrote:

On Fri, 24 Sep 2010 11:07:59 +0200 Éric Araujo wrote:

...

How about revamping the type/versions fields?

Issue type () Feature request (blocked by moratorium: () yes () no) () Bug (found in: [] 2.7 [] 3.1 [] py3k) () Security bug (found in: [] 2.5 [] 2.6 [] 2.7 [] 3.1 [] py3k)

I’m getting tired of explaining the meaning of the versions field again and again, let’s put this information directly under the eyes of the bug reporter.

But we also have "performance", "crash", "resource usage"... Are we suggesting we devise a separate list box for each of these issue types?

I must admit, I've never actually found much use for those additional options. If I'm flagging a bug I'll nearly always mark it "behaviour", otherwise I'll mark the issue "feature request". The characterisation of "what *kind* of bug is it?" is something that can usually be left until later in the process. Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On Sat, Sep 25, 2010 at 12:31 AM, Antoine Pitrou wrote:

...

...

But we also have "performance", "crash", "resource usage"... Are we suggesting we devise a separate list box for each of these issue types?

I must admit, I've never actually found much use for those additional options. If I'm flagging a bug I'll nearly always mark it "behaviour", otherwise I'll mark the issue "feature request". The characterisation of "what *kind* of bug is it?" is something that can usually be left until later in the process.

I have often used searches on "performance" or "resource usage" to find what was needing a review or a patch. I think it would be a mistake to remove those two categories.

That purpose would be served just as well by keywords though (particularly since those attributes aren't mutually exclusive - resource usage problems will usually *cause* performance problems, and you may notice the latter first). A generic "bug" classification would also better suit documentation bugs. The simpler we can make the more common fields, while still providing the essential information, the better. When someone like me is looking at a field pondering what to set it to for a comparatively simple issue report, what hope does someone submitted their first issue have? Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On Sat, Sep 25, 2010 at 12:50 AM, Antoine Pitrou wrote:

Le samedi 25 septembre 2010 à 00:42 +1000, Nick Coghlan a écrit :

...

...

I have often used searches on "performance" or "resource usage" to find what was needing a review or a patch. I think it would be a mistake to remove those two categories.

That purpose would be served just as well by keywords though (particularly since those attributes aren't mutually exclusive - resource usage problems will usually *cause* performance problems, and you may notice the latter first).

A generic "bug" classification would also better suit documentation bugs. The simpler we can make the more common fields, while still providing the essential information, the better.

But how should a performance improvement be filed? Bug? Feature request? Or should "feature request" be renamed "improvement"?

It's a feature request (since we won't backport it unless there is a genuine performance problem being addressed as a bug fix). Whether that warrants changing the name, I don't know. A third option for "other improvement" may also work (since that would also cover things like clarifying doc wording, fixing comments, adjusting code to be more readable/obviously correct, etc). Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On Sat, Sep 25, 2010 at 1:12 AM, Antoine Pitrou wrote:

...

...

But how should a performance improvement be filed? Bug? Feature request? Or should "feature request" be renamed "improvement"?

It's a feature request (since we won't backport it unless there is a genuine performance problem being addressed as a bug fix). Whether that warrants changing the name, I don't know.

I think most people won't intuitively file performance issues as "feature requests", since it doesn't sound like a feature.

Agreed.

...

 A third option for "other improvement" may also work (since that would also cover things like clarifying doc wording, fixing comments, adjusting code to be more readable/obviously correct, etc).

But then why not keep a clear categorization of these "other improvements"?

Because it's asking people to make a decision too early in the process. The clear categorisation as to what *kind* of bug/feature/improvement it is can be supplied later on by selecting the appropriate components and keywords.

By the way, doc wording fixes and cosmetic code changes often get backported. :)

Yep, hence why I think the basic "bug, feature, other" split may be a good way to go. It's a quick and easy decision most of the time (including a clear choice for "I don't know if this is a bug or not"), and makes a meaningful procedural distinction (bugs are usually backported, new features are not, and other changes may be backported depending on the details). Cheers, Nick. -- Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

On 9/24/2010 10:50 AM, Antoine Pitrou wrote:

Le samedi 25 septembre 2010 à 00:42 +1000, Nick Coghlan a écrit :

...

...

I have often used searches on "performance" or "resource usage" to find what was needing a review or a patch. I think it would be a mistake to remove those two categories.

That purpose would be served just as well by keywords though (particularly since those attributes aren't mutually exclusive - resource usage problems will usually *cause* performance problems, and you may notice the latter first).

Keywords are generally better than a restricted vocabulary for richness of content, but worse for finding the appropriate search term. You "pays yer money and takes yer chance". Given that we could (if necessary) overlay some sort of Python-specific semantic category generation to searches if we needed to, I tend to favor the "liberally tag with keywords" approach. But without any smarts being applied to the problem it's always to know whether you are searching for the right keywords.

...

A generic "bug" classification would also better suit documentation bugs. The simpler we can make the more common fields, while still providing the essential information, the better.

But how should a performance improvement be filed? Bug? Feature request? Or should "feature request" be renamed "improvement"?

Not all features would be improvements (and I'm thinking specifically here of 2.x's "print >> f" as an egregious design wart added for entirely pragmatic reasons). They could, however, be classified along with performance improvement requests as "Enhancement requests". The big problem, I suspect, is that we don't give clear enough guidance to almost total noobs about how to fill in the issue tracker form. If you can't remember what your first month as a programmer was like then you probably aren't qualified to be writing int on-line help for the tracker. (The tracker does *have* on-line help, right?) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010 http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/

Éric Araujo writes:

How about revamping the type/versions fields?

Issue type () Feature request (blocked by moratorium: () yes () no)

I think the information about "blocked by moratorium" is not something that users or devs will care about much. The users can be informed about the fact of the moratorium ("There is currently a feature moratorium in effect. If this feature is determined to be a change in the language, it will not appear until Python 3.4 or later. Changes to the standard library functions are acceptable. If no progress is made on the issue in a reasonable time, you may request discussion on python-dev@python.org.") in the reply page that confirms receipt of the issue. However, devs already know about the moratorium, and if there's a question of interpretation it will be discussed on python-dev. Users only care that their request is (not) being addressed; the moratorium is only one of many reasons why action is delayed.

Am 23.09.2010 22:51, schrieb Éric Araujo:

Le 23/09/2010 19:22, Terry Reedy a écrit :

...

As of just now, if you were to wonder "What (security) bugs are open for 2.5" and search on open 2.5 issues, you would get a list of 44 issues. It is only 44 instead of hundreds because of the work I and Mark have done in the last 4 months. It it 44 instead of perhaps 5 because Tarek and Eric insist on marking all disutils2 issues for all versions even though though these issues have nothing to do with maintenance releases. It is a real nuisance when trying to do tracker cleanup.

Let’s fix this. Two days ago, I said this in http://bugs.python.org/issue2200#msg117003 :

distutils2 has to work with 2.4-2.7 and (soon) 3.1-3.2, so Tarek told me to set all available versions for those bugs (2.5-py3k), even if I think “3rd party” is more appropriate and useful (since a distutils2 bug would not for example block a CPython 3.2 release).

I’ve been following these rules since before GSoC, when I had less confidence and no will to conflict with Tarek on such a small thing <wink>. Now I argue that the versions field is not really useful for d2, since it lacks 2.4 which we support and chiefly because it does not actually help our workflow: We don’t have separate branches for backporting fixes, we apply patches and run tests for all supported versions before committing on a single branch. There is no use case of setting a version to remind that a port needs to be done. For bug purposes, I actually see distutils2 as a value for the versions field of distutils bugs.

Thanks Eric, that sounds good.

respect-my-non-ASCII-diversity-write-my-acute-accent-thanks’ly yours,

Oops. My bad. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

...

Asking every now and then "is this still an issue", or setting the version number, doesn't really advance the issue.

Setting Versions properly helps anyone searching for issues relevant to a particular version. If having a field set properly does not matter, then is should not be there. Are you suggesting that Versions be deleted?

I didn't say the field does not matter. I said adjusting it doesn't advance the issue. Anybody *really* working on the issue might choose to update it, or might choose to leave it incorrect when the issue is going to be closed, anyway. I do believe that much of the information on closed issues is irrelevant - yet I would oppose to deleting them entirely from the database. Regards, Martin

On 9/24/2010 1:41 AM, Stephen J. Turnbull wrote:

Yes, and we'd all like more people to do more "real" work. But not everybody has the time or skills. I think this is a case where "agreeing to disagree" is the best we can do.

There is also the matter of letting people start with something they feel condident with and grow into more complicated tasks.

Specifically, Terry has made a strong case that "a few minutes per issue" *can* improve the tracker in ways that *are* noticable to some of the developers (and some of them have acknowledged that). It would be nice if the "tracker trimmers"[1] could assemble 60 of those into a few hours, and do some "real work", but that's often just not possible (especially for people with minimal programming expertise as yet).

Footnotes: [1] Trawlers take fish out of the ocean: not really the best metaphor. Gardening is a better metaphor.

For instance, while 'gardening', I discovered 4! duplicate open issues about the bug created by the difflib.SequenceMatcher heuristic. I consolidated them into one, got intrigued, did some tests with 3.1, read difflib.py, ..., and now have a patch posted written with Eli Bendersky. -- Terry Jan Reedy