[python-committers] Anatoly Techtonik's contribution

[Terry Reedy]

This is a continuation of my answer to Christian

On 12/25/2012 5:56 PM, Łukasz Langa wrote:
> Dnia 25 gru 2012 o godz. 13:37 Nick Coghlan <ncoghlan at gmail.com>
> napisał(a):
>
>> I'm well and truly to the point of caring far more about the
>> feelings of people who get frustrated trying to deal with his
>> obtuseness (whether that arises deliberately or through genuine
>> cluelessness) than I care about his feelings. He has the entire
>> internet to play on, we don't have to allow him access to
>> python.org controlled resources.
>
> +1
>
> I opened this thread so I feel somewhat responsible to carry this out
> to finish. Give me a day or two to contemplate on how to achieve the
> following:

Please do wait. Contemplation and sleep can work wonders.

> 1. Communicate what happened clearly and openly to our community.

I am not sure how broadly you mean 'our community', but please no. 
Nothing need or should be said beyond this list. (Unless Anatoly says 
something elsewhere -- but let him be the first.

Spam accounts and messages on the tracker are routinely cancelled 
without notice. The one time I know of that a contributor was banned 
(suspended, actually, soon followed by an offer of re-instatement 
without admin privileges), it was pretty much handled privately (though 
I would have preferred notice on this list first).

> 2. Communicate to Anatoly the decision to cut him off.

I think any cut-off should be in stages: tracker, pydev, python-ideas.
Anything beyond the tracker should be approved by Guido.

As far as the tracker goes, I think it should be clearly communicated to 
him and everyone in plain English (and specified in the user guide if 
not already) that a) the purpose of the tracker is to help committers 
receive reports, communicate with reporters and others, and to manage 
issues, and b) after an initial report, the administrative fields are 
mostly intended for the use of tracker administrators, including 
committers. The only reason a submitter can edit the status field is so 
that they can close an issue to withdraw it (possible after review). If 
we can enforce that in the database (only admins (or possibly only 
committers) but not the submitter can reopen), I think we should! That 
would eliminate bogus reopenings by anyone, not just Anatoly.

I say this because he specifically justified his re-open action on the 
basis that *he* also uses the tracker to track issues. So he does not 
quite understand what it is for. As I said in my previous post, if he 
reopens a third time, act. He has not yet that I have seen. I also 
notice that he just 'voted' to reopen http://bugs.python.org/issue7083 
but did not do so himself (possible because he cannot).

Going a bit further, I actually would not let a non-admin submitter edit 
any field as long as an issue is closed. I see this as a sensible 
refinement of the database policy based on years of experience and not 
directly specifically at Anatoly. Another tweak based on experience 
would be that only committers can set version to security issues. I 
routinely unset 2.6 and 3.1 with a short explanation. Better that the 
ignorant cannot even make that mistake (I know, submit to the metatracker.)

> 3. Arrange for feasible technological ways to execute the ban on
 > python.org resources,

See the suggestion above for the tracker. I presume that the mailing 
list software can reject specific users and the the gmane is or can be 
set up to honor rejections. But if that have ever been done, it has been 
done so privately that I am not aware of it. I would ban from pydev 
before I would ban from python-ideas. The latter is intended to be a bit 
more open to off-the-wall posts. I do not see that Anatoly has really 
abused python-ideas. His post today has 16 responses from other people 
and only 1 from him. People could have just ignored him after 1 response.

Another technological fix: enforce no cross-posting to peps editors list 
and anything else by rejecting cross-posted messages, both at the 
editors list and all other python.org lists. My theme with all these 
suggestions is that making mis-behavior impossible, when possible, is 
preferable to scolding and banning. Pushes to the repository by 
unauthorized people are just rejected. If anyone were to complain 
publicly about such rejection, they would just be laughed at.

 > preparing also for vengeful action (which given
> the history is unfortunately likely).

Shaming anyone publicly is more likely to get such action, and would 
almost make it justified in my view.

> 4. Prepare for rectifying unjust PR by the banned person, etc.

Better to not unnecessarily provoke it, and worry about it when it 
actually happens.

For months, Jim Fauth (sp?) has repeatedly trashed 3.3 on python-list to 
the point of telling people not to use it, and implicitly slandered us 
developers, because he hates the new Unicode implementation (it is 
'unfair' because some people benefit more than others). I find Jim more 
annoying than Anatoly because unlike Anatoly, he does not acknowledge 
contrary facts or answer questions but just repeats the same stupid or 
irrational generalizations that are based on one fact.

The one fact is that str.find, and hence str.replace, is much slower in 
3.3 than 3.2. Because of his report of that fact, there is an issue on 
the tracker. Jim will not even acknowledge that he did get an issue 
opened because *that* fact undercuts his narrative about our indifference.

Anyway:
1. I find Jim *much* more annoying and destructive than Anatoly. (This 
is possibly one reason Anatoly, by comparison, does not bother me as 
much as others).
2. The response on python-list is that one or more regulars (sometimes 
me, often others) responds to each repetition, more of less politely and 
rationally, as the spirit moves us. If you are worried about bad PR, 
driving Anatoly to become like Jim on python-list would be the wrong 
thing to do.

> I'm seriously considering writing all this as a PEP (most likely
> without any personal details). I hope this won't be useful in the
> future but it might help having this gathered as written policy, if
> only for transparency reasons.

This strike me as over-reaction.

--
Terry Jan Reedy