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 <email@example.com
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.
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
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
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
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.
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