<p dir="ltr"><br>
On 18 Jul 2015 1:19 pm, "Nick Coghlan" <<a href="mailto:ncoghlan@gmail.com">ncoghlan@gmail.com</a>> wrote:<br>
> 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</p>
<p dir="ltr">Sorry, I crossed a line there - I know everyone posting to this thread is doing so with the best interests of Python at heart.</p>
<p dir="ltr">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).</p>
<p dir="ltr">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.</p>
<p dir="ltr">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?".</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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?"</p>
<p dir="ltr">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.</p>
<p dir="ltr">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.</p>
<p dir="ltr">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?".</p>
<p dir="ltr">Regards,<br>
Nick.</p>