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.
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.
Forwarded to the committers list since there's no reason for these notions
to be secret, but please remember they're just that: notions. Turning them
into reality would require a lot of work, and we'd need to understand how
that was going to happen.
(Given point one above, we probably want some of the PSF infrastructure
team there as well)
Regards,
Nick.
-- Forwarded message --
From: "Nick Coghlan"
Date: 13 Jan 2014 01:25
Subject: Re: Two new topics for the language summit
To: "Michael Foord"
Cc:
On a related note - perhaps it would make sense to invite the PSF Outreach
& Education committee?
I'd like to start letting the core team move to a model where we still
ensure the reference docs are up to date, but start handing over more
responsibility for the tutorials and howto guides to folks that are more
focused on education (there will be some overlap, of course, since some
core devs are professional trainers and others may *like* writing
introductory guides).
I'd also like us to consider a more consistent structure like the logging
module now uses (reference, beginner how to guide, advanced how to guide,
cookbook), but there's no way that is feasible in a context where the core
developers are still writing most of the docs.
Unrelated to the above, note that I'm also happy to give an update on the
state of packaging changes. Guido may like to hear what I'm doing with that
authority he delegated to me :)
Cheers,
Nick.
On 12 Jan 2014 23:47, "Nick Coghlan" wrote:
> Docs maintenance and encouraging tech writers to get involved in updating
> docs.python.org
>
> Possible infrastructure updates to improve the core development workflows.
>
> Idea 1: deploy RhodeCode to manage hg.python.org (adds pull request
> support, for example, and makes it easy to create forks and share access
> with non core devs)
>
> Idea 2: finally automate NEWS updates to avoid spurious conflicts
>
> Idea 3: Integrating Zuul (OpenStack merge gating system) with Reitveld,
> RoundUp and BuildBot with the aim of allowing merge gating with our
> existing tools, making it much, much simpler to get trivial changes and
> docs fixes merged (patch review = last manual intervention. From there, if
> the test suite passes on the stable buildbots after merging with the
> relevant branch, it lands automatically)
>
> Cheers,
> Nick.
>
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers
