Re: [Python-Dev] How do we tell if we're helping or hindering the core development process?

On Jul 21 2015, Nick Coghlan <ncog...@gmail.com> wrote:
> 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/iss...@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.
As a random datapoint:

Early last year I wanted get involved in CPython development. In the
next months I submitted and reviewed maybe 20 - 25 patches in the bug
tracker. After seeing all of them languish, I stopped submitting and
reviewing and just tried to get someone to look at the issues that I'd
worked on. Eventually, I managed to get almost all of them committed
(the last one sometime this February, after more than a year). However,
it was such an uphill battle just to get someone to look at my
contributions that I haven't touched the bugtracker ever since.

If it were up to me, I'd focus all the resources of the PSF on reducing
this backlog - be that by hiring some core developers to work full-time
on just the open bugtracker issues, or by financing development of
better code review and commit infrastructure. The current situation
looks like a downward spiral to me. New contributors are frustrated and
leave because they feel their contribution is not welcome, and core
developers get burned out by the gigantic backlog and the interaction
with frustrated patch submitters - thus further reducing the available
manpower.

(I am aware of the forge PEPs that you mention below, but as far as I
know even those are stalled because of - guess what - lack of available
core developer time).

Working on Roundup, the CPython infrastructure or Kallithea may be less
frustrating for new contributors (I don't know), but what this boils
down to is that you're contributing to a different project, and not to
CPython. But if you've decided to work on something else, there is (at
least for me) little reason to restrict the choice to projects that are
used *for* CPython development. And compared to the whole range of other
open source projects, I suspect the above options just don't look all
that interesting to many people. In other words: you typically can't
tell volunteers what to work on - you've got to accept the contribution
in the area they're interested in, or you loose the contributor. In case
of CPython the latter may be unavoidable at the moment, but I think it's
illusory to think that this can be solved by "redirecting" the stream of
contributions. Suppose you just found a bug in Python and you want to
upstream the patch so you don't have to carry the workaround
forever. Now you see there are already a lot of open issues with patches
- are you going to forget about your patch and e.g. decide to work on
the buildbots insteads?


Best,
-Nikolaus

-- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

             »Time flies like an arrow, fruit flies like a Banana.«
_______________________________________________
Python-Dev mailing list
Pyth...@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: https://mail.python.org/mailman/options/python-dev/python-dev-ml%40activestate.com