Nick Coghlan writes:
The draining and demotivating cases are the ones where no new information is introduced, but the design decision is challenged anyway.
But this particular thread is an extreme case, that demonstrates why this kind of thing happens despite the good intentions of everyone involved. The design decision (to special-case a typo) that was made is a true "WTF?!" The "meta" of "special cases aren't special enough to break the rules" is that no design decision that violates it should be dismissed as "minor". In context of a mailing list, doing so is going to be taken by readers as "I know what I'm doing, and you don't know what you're talking about, so STFU."
The average poster to Python-Dev surely trusts the core developers to know what they're doing. If you (as the developer or developers on the spot) don't have time to explain, at least indicate that the process implied in
Folks are granted core committer privileges because we trust their instincts. We trust them to know when they're acting within the limits of their own expertise and experience, and we trust them to know when it would be beneficial to seek feedback from a wider audience before making up their minds.
was followed. Something like
The special case of trapping the typo "assret" was discussed on python-committers. The conclusion was that in the special context of mock this is a case where "practicality beats purity". In any case, the decision has been discussed thoroughly and isn't going to change in the absence of truly new information, so further discussion here is pointless. Let's move on.
would have stopped the thread in its tracks, I believe. But repeated unexplained assertions that the design decision is "minor" were just a red cape to a bull. That explanation just feels wrong, it causes massive cognitive dissonance -- and makes it very hard for readers to respond appropriately to perfectly valid explanations that "this is not the time to make a change anyway".
Those are the ones that feel like folks are saying "We don't actually trust you with that authority and responsibility you've been granted, so we're going to closely police the way you use it, and expect to be able to persuade you to change your mind not through reasoned argument, but through sheer volume".
This is a fallacy, very human, but still the fallacy of anthropomorphizing a crowd. A very few people repeatedly posted with the content limited to "Special cases aren't", but most expressed their puzzlement in varied ways over time. Of course all of them started with "special cases aren't", which is why the proponents feel browbeaten.
Both roles in this comedy of errors are natural, they are inherent in human cognition (citations on request), and nobody is to be blamed. At Python's scale, some (not all) of the core developers are going to need to recognize the "crowd" dynamic and deal with it -- or Python won't scale any further IMO. (In theory there may be better channels than mailing lists which would inhibit this dynamic, but I don't know of any practical ones.)
Don't bother trying to improve anything, you'll just get grief and opposition for it rather than community support.
For experienced core developers, it's a "Right, so you trust me to build the nuclear power plant, but not to choose the colour of the bike shed behind it" situation.
Et tu, Brutus! This point has been made so many times in this thread. Surely you don't think anybody missed it!<wink/>
The only practical suggestion from "the core" has been self- restraint on the part of "the crowd". But that has severe limits because the "crowd" is made up of people who "aren't Dutch yet". They are going to ask questions, and as Python Dev gets bigger, more of them are going to ask questions, and in particularly controversial cases they are going to ask more or less simultaneously, resulting in the "browbeating effect".
I think it's time to either end this "meta" thread, or refocus it from "why contributors feel sad" and "why we should trust committers" (AFAICS there is actually consensus on both, although sometimes expressed as apparent disagreement) to discussion of practical ways to resolve the conflict. That is the conflict between the need of actual contributors to get to-the-point feedback and the need of contributors- in-embryo to learn what's going on. Sadly, as long as the proposed "Communication" section in the devguide concentrates on the responsibility of commenters to exercise restraint to the exclusion of the possibility of "somebody" managing threads, it's not going to help much IMO. Python Dev is already as civil a forum as any I've seen, considering its scale and its success in recruiting new contributors at all levels of maturity.
Footnotes:  It occurs to me that pointing to existing discussion actually is the responsibility of an OP who "promotes" a discussion from the tracker or python-committers to python-dev. Or perhaps the proponents should have promoted to python-dev themselves. But I haven't got time to think that through.
 N.B. Those four sentences were indeed posted several times in various combinations. But never all at once and together, and that's what's needed to have the thread-stopping effect.