On 6 March 2015 at 03:16, Marcus Smith <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Distutils-SIG maillist - [email protected] https://mail.python.org/mailman/listinfo/distutils-sig
