On Jul 21 2015, Nick Coghlan email@example.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/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.
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
-- 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.«