[Python-Dev] How far to go with user-friendliness

[Nick Coghlan]

On 18 Jul 2015 1:19 pm, "Nick Coghlan" <ncoghlan at gmail.com> wrote:
> I'm with Antoine in wondering why we even bother with contributing when
the thanks we can expect is for people to feel entitled to demand we spend
hours of our time debating trivial details

Sorry, I crossed a line there - I know everyone posting to this thread is
doing so with the best interests of Python at heart.

I also know that from the questioners' side this kind of thread feels like
a perfectly reasonable request for further explanation. However, from the
core developer side, some folks are averaging more than 3 commits a day,
and we have the ever looming presence of almost *five thousand* open issues
that we haven't had the opportunity to address (I'm personally on the nosy
list for more than 400 of them).

Whenever someone offers a patch to address one of those issues, we have to
decide how fussy we want to be - every time we say "No, that's not ready
yet", there's a chance other priorities will come up for the contributor
(even when it's another core developer) that mean we end up with a patch
languishing on the tracker with unaddressed feedback rather than a resolved
issue.

As a result, the question asked about potential changes isn't generally "Is
this perfect?" but rather "Is this usable, maintainable, complete and an
improvement over the status quo?".

If a contribution passes that *second* barrier, then it's likely to be
accepted. This is also the standard we'll apply to *ourselves* in deciding
whether or not we'd like a pre-commit review on a particular change.

This means the kind of question raised in this thread has a standard
answer: the change was made because the contributor addressing the issue
wanted to address it that way, and the core developer committing the change
was willing to accept public responsibility for any *actual* (as opposed to
hypothetical) long term harm arising from the decision.

We can sometimes construct an after-the-fact rationalisation, but honestly,
it usually comes down to asking ourselves the question "Am I prepared to
reject this improvement entirely over that one potentially controversial
aspect?" and deciding that we'd prefer to accept the long term technical
risk over the near term social risk of potentially alienating the patch
author.

The *problem* with threads like this one is that they end up feeling like
punishment for being accommodating to the wishes of contributors on minor
design details. The end result of such a process isn't a better CPython -
it's *higher* barriers to contribution and *more* unresolved issues, as
core developers become ever more reluctant to accept responsibility for
contributed changes that may in any way be controversial.

Potential core developers are also likely to be put off by the prospect of
"you too can volunteer to be micromanaged by a large community mailing
list, doesn't that sound like fun?"

Review throughput is our primary bottleneck in getting fixes and
enhancements into CPython. While tooling improvements can help us make
better use of the time of the core developers we already have, and better
track and acknowledge the efforts of potential future core developers, the
reasons folks *quit* are social ones, as are the reasons folks get
discouraged from contributing in the first place.

That's the tension at the heart of open source development - every time we
object to someone else's decision or reject their work, we run the risk of
contributing to one of our peers deciding to stop volunteering their time
and energy. We run the same risk every time we use our control over
infrastructure and tools to enforce a change in process and practices.

Not taking those risks isn't the answer - that's a recipe for stagnation,
rather than continuous improvement. Rather, we want to be taking those
risks deliberately and consciously, having already asked ourselves "If this
is the final straw in someone deciding that contributing to our community
isn't a worthwhile use of their time, am I prepared to accept that
responsibility over this particular topic?".

Regards,
Nick.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20150719/212c77a2/attachment.html>