On Fri, Nov 29, 2013 at 11:34 AM, Brett Cannon <br...@python.org> wrote:
> > > > On Fri, Nov 29, 2013 at 1:56 PM, Guido van Rossum <gu...@python.org>wrote: > >> On Fri, Nov 29, 2013 at 10:41 AM, Georg Brandl <g.bra...@gmx.net> wrote: >> >>> Am 29.11.2013 19:22, schrieb Tim Peters: >>> > I pretty much ignore Anatoly, and that works really well for me - try >>> it ;-) >>> >>> It's a nice option, I agree -- but someone has to triage his issues, or >>> they >>> will rot in the tracker for eternity. >>> >> >> Plenty of issues do rot there, it doesn't bother me much. If you don't >> want to triage Anatoly's issues, don't; maybe someone else (Mark Lawrence? >> :-) will. >> > > Maybe, but not the issues for stuff some of us are heavily invested in. If > he starts to file importlib bugs I am going to triage them because I try to > close all importlib bugs. I try to at least triage the ast issues as well > which is where I have been bumping up against him as of late. The idea of > having to change how I and others triage bugs because of one individual > seems like the wrong cost/benefit ratio for dealing with the problem. > The question is, how effective will the alternative solution (banning him) be? I worry that it's just going to make things worse. > > >> >> The key thing to understand here is that you can't win an argument with >> Anatoly. You can only avoid *getting* into one. >> > > I'm sure you have developed skills at ignoring people based on the amount > of unsolicited communication sent your way as BDFL. But the rest of us > really only have to put up with this consistently with a single individual. > I know you're worried about some PR problem, but this isn't some knee jerk > reaction but a multi-year issue that everyone has sustained. And this > slowly leaks into everything because new people come, try to participate > with him, and then get the negative consequences of that which becomes a > low, simmering PR problem of its own that we are not more welcoming and > tolerate rude individuals. > Do you have examples of new people engaging him? I mostly see him engaged by old-timers or other known "difficult" users (Kristjan, Mark Lawrence). I guess I haven't managed to teach you all well enough how to do this. Honestly it's not easy. :-( > > If someone turns away from the community because we decided we didn't want > someone who is rude participating and ruining the experience for others > then I'm fine with losing that person's participation just like anyone who > chooses not to come to PyCon because we have a CoC (they can still use > Python, they can just choose to not participate in the community). But if > we lose a single individual because they didn't like someone being rude to > them or others then that is a loss I don't want to see. Once again, the > cost/benefit ratio of everyone as a group having to ignore a single > troublemaker does not seem like the best solution. > Again, I haven't seen Anatoly interfere with others. I imagine that most people seeing his posts will recognize him as the nutcase he is. > > If you want to go with ignoring him, then that's fine. But to go along > with that, I think it's reasonable to actively tell others who are new to > not engage him if they start to in order to spare them the stress and > aggravation and potentially losing their participation, otherwise how are > they to know that this is not normal community behaviour and that he holds > no sway? I do not want to continue to feel sorry for people who happen to > reply to one person's emails knowing full well there was something I could > do about it. > When I see this kind of thing happen to people who have already contributed positively but haven't been around long enough to recognize specific trolls I usually send them an off-line message suggesting to ignore the troll. This happens a few times a year, and it's not just Anatoly. -- --Guido van Rossum (python.org/~guido)
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
