[Distutils] Getting more momentum for pip

[Nick Coghlan]

On 6 March 2015 at 03:16, Marcus Smith <qwcode at gmail.com> wrote:
> So I guess my suggestions boil down to:
>>
>>
>> - Add more humans
>> - Add more money to make humans more efficient
>> - Add more computer automation
>
>
>
> maybe agree to always maintain < X open issues and < Y open PRs, before
> adding features.
> where x can vary as needed, but for starters, x=250, and y=25 sounds
> reasonable.

This is one of the key differences between open source projects and
corporate projects. In a corporate context, it's important to keep
your backlog under control by saying "we're never going to invest time
in fixing this" and declare such issues as "won't fix".

In a community driven open source project, the situation is different.
Here, because everyone is free to spend their time however they like
(or however they can persuade someone to pay them), the only real
reason to "won't fix" an issue is because it's a genuinely bad idea
(or based on a flawed understanding of the situation) and there's no
way to redeem the suggestion. For anything else, it's often better to
leave it open as an opportunity for someone to persuade the core
developers that it's worth accepting the liability of maintaining that
code into the future - those that do the work, make the rules.

It does require a lot of education work, though. Most folks
(especially when just starting to learn to code) are inclined to think
that contributing more code is purely beneficial. It's not, as code is
a liability that costs you long term effort to maintain. As Jack
Diederich puts it: "code is the enemy and you want as little of it in
your product as possible". What you actually want is to *solve
people's problems in the general case*, such that the net gain in time
saved across the user community vastly outweighs the maintenance cost
of allowing that code to exist in the project. For mature projects
with a fairly well defined scope, this means the default answer is
going to be "no", and the most positive likely initial answer is
"maybe". Hence the split of the core CPython mailing lists into
python-dev (where the default answer is just a straight up "no") and
python-ideas (where the default answer is more along the lines of
"that's a potentially interesting idea, let's discuss it further").

This is arguably a flaw in more recent approaches to getting folks
engaged in open source projects, with a focus on quick wins and
immediate contributions. While those do exist in most projects,
they're generally about implementing *existing* ideas, or improving
docs, or fixing bugs. For folks that want to get a *specific* issue
fixed, then what they generally need to do is to learn what the core
contributors care about, and how to get them interested in addressing
that problem. There isn't the simple "I'm a paying customer, this is a
problem I'm reporting, we have an SLA, please resolve my issue in
accordance with that" dynamic that exists in a traditional vendor
relationship.

While it's only been intermittently effective, one useful tactic
CPython core developers have occasionally applied is a "5-for-1"
review trade: if someone else reviews 5 open patches, then they'll
review one that the new reviewer cares about. That's a pretty
straightforward quid pro quo, and gets people into the habit of
contributing time to things others are interested in so as to get time
contributed back to their own issues in return. It relies on core
contributors having the spare capacity to offer that deal though.

pythonmentors.com describes another approach, which allows folks to
self-identify as wanting to invest time in becoming a core
committer/reviewer themselves, rather than just wanting to get a
drive-by patch merged. Those folks then gain the benefit of getting
the attention of the more active mentors in the core developer group,
as well as a community of like-minded peers all attempting to learn
the tricks of navigating the vagaries of CPython core development.

Another way is when an existing contributors deliberately recruits
someone they trust to take over a task from them. In those cases, the
mentorship relationship already formed outside the particular
community of contributors, and is transferred into the new context.

Finally, there's straight up trading of favours: if you contribute
something an existing core contributor wants themselves, a) you'll
likely get their attention on that original review pretty easily; and
b) if you have something *else* you want reviewed, they're far more
likely to try to find the time if you're already helped them cross a
lingering item off their generally voluminous todo lists.

Regards,
Nick.

P.S. The other useful thing to do is to better educate folks on how to
make the case for spending work time on upstream projects and key
dependencies, *without* a specific near term business need. I'm pretty
happy with this piece I recently wrote for Red Hat as an example of
that kind of thing:
http://community.redhat.com/blog/2015/02/the-quid-pro-quo-of-open-infrastructure/

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