On 20 July 2015 at 22:34, Ben Finney <ben+python@benfinney.id.au> wrote:
Paul Moore <p.f.moore@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@gmail.com | Brisbane, Australia