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@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.
- 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).
- 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.)
- 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.
- 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: thing to do.
- 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).
- 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
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