Some topics I have suggested for the language summit
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" ncoghlan@gmail.com Date: 13 Jan 2014 01:25 Subject: Re: Two new topics for the language summit To: "Michael Foord" fuzzyman@voidspace.org.uk 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" ncoghlan@gmail.com 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.
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.
On 13 January 2014 06:29, Terry Reedy tjreedy@udel.edu wrote:
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.
Yes, that's exactly the kind of thing I have in mind. However, there would likely need to be some meta-discussions around structure and authorial "voice", since that's where we sometimes have conflicts even today, and at the moment, how those are handled varies a fair bit depending on who originally authored a piece of text.
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 12 Jan 2014, at 15:47, Nick Coghlan ncoghlan@gmail.com 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.
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.
How many people are the Outreach and Education committee? We could cope with another 5-10 people attending. If the committee is less than 20 then we're probably fine inviting them as I doubt all will be able to attend.
All the best,
Michael Foord
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" ncoghlan@gmail.com Date: 13 Jan 2014 01:25 Subject: Re: Two new topics for the language summit To: "Michael Foord" fuzzyman@voidspace.org.uk 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" ncoghlan@gmail.com 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 python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
-- http://www.voidspace.org.uk/
May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 13 January 2014 23:38, Michael Foord michael@voidspace.org.uk wrote:
On 12 Jan 2014, at 15:47, Nick Coghlan ncoghlan@gmail.com 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.
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.
How many people are the Outreach and Education committee? We could cope with another 5-10 people attending. If the committee is less than 20 then we're probably fine inviting them as I doubt all will be able to attend.
To be honest, I don't actually know. However, I was actually thinking in terms of asking them to send a few interested representatives, rather than necessarily having them all attend.
Assuming http://www.python.org/psf/committees/#outreach-education-committee-orec is reasonably up to date, I expect they could come up with a few volunteers that are going to be in Montreal on the day of the summit and can spare the time to come chat with us about ways we could work better together :)
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 13 Jan 2014, at 13:59, Nick Coghlan ncoghlan@gmail.com wrote:
On 13 January 2014 23:38, Michael Foord michael@voidspace.org.uk wrote:
On 12 Jan 2014, at 15:47, Nick Coghlan ncoghlan@gmail.com 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.
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.
How many people are the Outreach and Education committee? We could cope with another 5-10 people attending. If the committee is less than 20 then we're probably fine inviting them as I doubt all will be able to attend.
To be honest, I don't actually know. However, I was actually thinking in terms of asking them to send a few interested representatives, rather than necessarily having them all attend.
Assuming http://www.python.org/psf/committees/#outreach-education-committee-orec is reasonably up to date, I expect they could come up with a few volunteers that are going to be in Montreal on the day of the summit and can spare the time to come chat with us about ways we could work better together :)
That sounds fine - are you ok to issue the invite and ask them to let me know who will be attending?
Michael
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-- http://www.voidspace.org.uk/
May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
On 14 January 2014 00:05, Michael Foord michael@voidspace.org.uk wrote:
Assuming http://www.python.org/psf/committees/#outreach-education-committee-orec is reasonably up to date, I expect they could come up with a few volunteers that are going to be in Montreal on the day of the summit and can spare the time to come chat with us about ways we could work better together :)
That sounds fine - are you ok to issue the invite and ask them to let me know who will be attending?
Sure, that sounds good. I'll say that we'd like at least a few representatives to come along to talk about ways we can better combine efforts, and that we can definitely accommodate 5 people, but to check with you regarding numbers if more OREC folks will be in Montreal for the summit day and would like to attend.
Which day is the summit again? April 6th?
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 13 Jan 2014, at 14:47, Nick Coghlan ncoghlan@gmail.com wrote:
On 14 January 2014 00:05, Michael Foord michael@voidspace.org.uk wrote:
Assuming http://www.python.org/psf/committees/#outreach-education-committee-orec is reasonably up to date, I expect they could come up with a few volunteers that are going to be in Montreal on the day of the summit and can spare the time to come chat with us about ways we could work better together :)
That sounds fine - are you ok to issue the invite and ask them to let me know who will be attending?
Sure, that sounds good. I'll say that we'd like at least a few representatives to come along to talk about ways we can better combine efforts, and that we can definitely accommodate 5 people, but to check with you regarding numbers if more OREC folks will be in Montreal for the summit day and would like to attend.
Great.
Which day is the summit again? April 6th?
The 9th!
Michael
Cheers, Nick.
-- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
-- http://www.voidspace.org.uk/
May you do good and not evil May you find forgiveness for yourself and forgive others May you share freely, never taking more than you give. -- the sqlite blessing http://www.sqlite.org/different.html
participants (3)
-
Michael Foord -
Nick Coghlan -
Terry Reedy