[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 20 July 2015 at 22:34, Ben Finney <ben+python at benfinney.id.au> wrote:
> Paul Moore <p.f.moore at gmail.com> writes:
>
>> Again, I'm sorry to pick on one sentence out of context, but it cut
>> straight to my biggest fear when doing a commit (on any project) -
>> what if, after all the worrying and consideration I put into doing
>> this commit, people disagree with me (or worse still, I made a
>> mistake)? Will I be able to justify what I decided?
>
> That seems quite healthy to me. On a collaborative project with effects
> far beyond oneself, yes, any change *should* be able to be justified
> when challenged.

No, that's not how this works: if folks are thinking that being a
Python user, or even a CPython core developer, means that we're
entitled to micromanage core developers by demanding extensive
explanations for any arbitrary commit we choose, they're thoroughly
mistaken. Only Guido has that privilege, and one of the reasons he's
as respected as he is is his willingness to trust the experience and
expertise of others and only rarely exercise his absolute authority.

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.

There are *many* cases where we *don't know* up front what the right
answer is, so we'll actively seek consultation, whether that's through
a review request on the issue tracker, a focused python-dev
discussion, a more speculative discussion on python-ideas, or engaging
in the full Python Enhancement Proposal process.

There are also cases where we'll decide "it seems plausible that this
might be a good idea, so let's try it out and see what happens in
practice rather than continuing to speculate" - only ever doing things
that you're already 100% certain are a good idea is a recipe for
stagnation and decline (hence the "Now is better than never" line in
the Zen). A feedback cycle of a few years is a relatively short time
in programming language development, so if we discover with the
benefit of hindsight that something that seemed plausible really was
in fact a genuinely bad idea, that's why we have a deprecation process
(as well as the abilty to mark new APIs as provisional). If we want a
faster feedback cycle measured in days or weeks or months rather than
years, then we'll find a way to make the idea available for
experimentation via PyPI or at least as a cookbook recipe or in a
public source repo.

But the authority and responsibility to make changes, to decide what
constitutes a reasonable risk, to decide which updates are appropriate
to send out to tens of millions of Python users worldwide remains
*ours*.

Some of those decisions will be akin to deciding to paint a bikeshed
blue instead of yellow (or green, or red, or chartreuse, or ...).
Others will be about mitigating the observed negative consequences of
a previous design decision while retaining the positive aspects.

Those kinds of design decision are still more art than science -
that's why our solution to them is to attempt to recruit people with
the interest, ability and time needed to make them well, and then
largely leave them to it. Explaining design decisions after the fact
isn't about *defending* those decisions, it's about attempting to
convey useful design knowledge, in order to help build new core
contributors (and also because explaining something to someone else is
a good way to understand it better yourself).

All of this is why the chart that I believe should be worrying people
is the topmost one on this page:
http://bugs.python.org/issue?@template=stats

Both the number of open issues and the number of open issues with
patches are steadily trending upwards. That means the bottleneck in
the current process *isn't* getting patches written in the first
place, it's getting them up to the appropriate standards and applied.
Yet the answer to the problem isn't a simple "recruit more core
developers", as the existing core developers are *also* the bottleneck
in the review and mentoring process for *new* core developers.

In my view, those stats are a useful tool we can use to ask ourselves
"Am I actually helping with this contribution, or at the very least,
not causing harm?":

* participating in the core-mentorship list, and actively looking for
ways to improve the effectiveness of the mentorship program (that
don't just queue up more work behind the existing core developer
bottleneck) should help make those stats better

* sponsoring or volunteering to help with the upstream projects our
core workflow tools are based on (Roundup, Buildbot) or with updating
our specific installations of them should help make those stats better
(and also offers faster iteration cycles than core development itself)

* helping core developers that have time to work on "CPython in
general" rather than specific projects of interest to them to focus
their attention more effectively may help make those stats better (and
it would be even better if we could credit such triaging efforts
appropriately)

* exploring ways to extract contribution metrics from Roundup so we
can have a more reliable detection mechanism for active and consistent
contributors than the "Mark 1 core developer memory, aka the
notoriously unreliable human brain" may help make those stats better

* helping out the upstream projects for one or both of the
forge.python.org proposals (Kallithea, Phabricator) that are designed
(at least in part) to remove core developers from the critical path
for management of the support repos like the developer guide and
Python Enhancement Proposals may help make those stats better

* getting more core contributors into a position where at least some
of their work time can be spent on facilitating upstream contributions
may help make those stats better (shifting at least some core
contribution activity to paid roles is also one of the keys to
countering the "free time for volunteer activities is inequitably
distributed" problem)

* alienating veteran core developers and encouraging them to spend
their time elsewhere will contribute to making those stats worse

* discouraging newly minted core developers from exercising their
granted authority will contribute to making those stats worse

* discouraging veteran core developers from recruiting new core
developers by contributing to creating a hostile environment on the
core mailing lists will *definitely* contribute to making those stats
worse

Make no mistake, sustainable open source development is a *genuinely
hard problem*. We're in a much better position than most projects
(being one of the top 5 programming languages in the world has its
benefits), but we're still effectively running a giant multinational
collaborative software development project with close to zero formal
management support. While their are good examples we can (and are)
learning from, improving the support structures for an already wildly
successful open source project without alienating existing
contributors isn't a task that comes with an instruction manual :)

Regards,
Nick.

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