On 1/12/2014 10:47 AM, Nick Coghlan wrote:
Working across multiple projects has highlighted for me lately how much unnecessary overhead we're currently dealing with in core development, and how ineffective we are at delegating responsibility for parts of the docs that aren't tied directly to the standard library and interpreter implementation.
As far as I know, we have not had any problems with people given socially restricted commit privileges over-stepping the restrictions. I think we should look* for people who would like /Doc/.../*.rst commit privileges. Even in the Language and Library, such people could commit typo and grammar changes and technical wording changes submitted or approves by a code committer.
* As in post a notice to various python lists. There are multiple non-committers who have posted articulately to python-list for years. Perhaps a couple would be interested if they knew they would be welcome. I would be willing to help people to get started (other than with .rst markup).
I would note (to candidates) that doc-only commits are easier than general commits. Since the doc tools run with installed python, one does not have to do the extra setup needed to build Python itself. Simple changes that do not involve .rst markup do not need testing. Markup changes can be tested on the local machine; there in no need to monitor buildbots. If a News entry in needed (and I think not for spelling and grammar changes), it goes into separate section with a low rate of entry and hence a low rate merge conflicts.
In particular, the "core reviewer" model in OpenStack makes substantially more effective use of core developer time than our core committer model - if I say a change looks good, it merges cleanly and passes the tests, why do I need to do the last step manually? (While I don't work on OpenStack, I work on QA tools for Red Hat. I'm considering deploying Zuul in particular, since it's at the heart of being able to adopt a core reviewer model). The other part is that I've suggested we invite the PSF's Outreach & Education committee to the summit. There are some things we're currently trying to run entirely from within the existing core dev team (like maintenance of the tutorial and the howto guides) where that may not be the most sensible model.
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
