[Python-Dev] How do we tell if we're helping or hindering the core development process? (was Re: How far to go with user-friendliness)

[Stephen J. Turnbull]

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.[1]  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.[2]  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.

Steve

Footnotes: 
[1]  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.

[2]  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.