[python-committers] Some topics I have suggested for the language summit

[Terry Reedy]

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.