[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)

[Nick Coghlan]

On 21 July 2015 at 21:19, Paul Moore <p.f.moore at gmail.com> wrote:
> On 21 July 2015 at 11:03, Ben Finney <ben+python at benfinney.id.au> wrote:
>> * If challenged to do so, could one (the contributor) present a
>>   compelling justification for the change?
>>
>>   This is what I claim Paul Moore's doubt (fear?) is indicative of. I
>>   maintain that this doubt is quite healthy: it helps the contributor to
>>   pause, reflect, seek assistance in making decisions, and thereby also
>>   tends to exclude poorly-justified changes which would otherwise be
>>   committed.
>
> That is *not* what I was trying to express. My fear is that I will be
> subjected to the sort of unreasonable level of debate and frankly
> criticism that came up in this thread, and I'm not sure if I have the
> energy to deal with it. I wouldn't ever commit something unless *in my
> judgement* it was OK to go in. Whether my judgement is sufficient is
> the whole point here.

Exactly. Being granted a commit bit means "The folks that got CPython
to where it is today trust you to take appropriate risks in guiding
CPython's future". It can be safely assumed that *everyone* that has
that authority takes it *very* seriously (otherwise they wouldn't have
been granted commit privileges).

If there weren't any risks to be weighed and judgment calls to be
made, we could let a computer decide what commits should go in (and
indeed "make patchcheck" already handles some of those basic tasks,
and we'd like to automate even more of them like "does this patch
apply, and do the tests still pass on x86_64 under at least Windows
and a long term support Linux distro after applying it?"). This
challenge is reflected in the fact that the Zen of Python is
deliberately self-contradictory, as it articulates competing design
principles to take into consideration, rather than being able to
provide ironclad rules that avoid the need for human judgement in
determining *which* of those design guidelines are most salient in any
given situation.

Now, proposing further *enhancements* to a change is perfectly
reasonable, especially if the feedback is based on practical
experience with the original version of the change. The implementation
of PEP 492 (async/await), for example, underwent some fundamental
changes during the beta process, as developers' feedback showed that
some of the design decisions we made in the original version were
quite problematic. The original exception suppression mechanism in PEP
409 (which made clever-but-idiosyncratic use of Ellipsis), was
replaced with the simpler mechanism in PEP 415 (which instead uses a
more conventional setter-with-side-effects-on-other-attributes
approach).

Reverting changes because they broke the buildbots, or because they're
determined to cause bugs worse than the original problem is also not a
problem - in those cases, there's new information introduced into the
situation that changes the original risk assessment. An example of
that was deciding to deprecate and remove contextlib.nested() before
I'd figured out how to replace its legitimate use cases - I'd flat out
missed a fundamental problem with the way it interacted with open()
and similar resource allocation functions.

The draining and demotivating cases are the ones where *no new
information is introduced*, but the design decision is *challenged
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".

For new core developers, or folks aspiring to become core developers,
it is *literally* the scenario that inspired Poul-Henning Kamp to
write the post at http://bikeshed.org/ (hit refresh if you get a low
contrast colour scheme, it will change). 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. Knowing we're trusted to build power
plants, but will get grief for working on smaller things creates an
even greater incentive to work solely on the big changes, and those
are already inherently more fun to work on anyway - they really don't
need the extra help.

Regards,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia