Re: [python-committers] Fwd: EPS: Announcing the Guido van Rossum Core Developer Grant
Happy to see that you like the idea. Our hope is that more conferences will pick it up as well. On 31.01.2019 18:41, Raymond Hettinger wrote: > > >> On Jan 31, 2019, at 2:15 AM, M.-A. Lemburg wrote: >> >> To help with growing the team, putting it more into the spotlight and >> give them a place to meet, demonstrate their work and a stage to >> invite new developers, we decided to give Python Core Developers free >> entry to future EuroPython conferences, starting with EuroPython 2019 >> in Basel, Switzerland > > Thank for this. > > The cumulative cost of attending conferences has been high. -- Marc-Andre Lemburg EuroPython Society Chair http://www.europython-society.org/ http://www.malemburg.com/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Learning from PostgreSQL community: How to address the review bottleneck
I've attended FOSDEM over the weekend, where Jon Conway (one of the PostgreSQL committers) gave a talk about, among other things, the PG community and how it is structured: https://fosdem.org/2019/schedule/event/postgresql11/ (the community part starts at around 8 min into the video) What struck me as interesting is that they have seen and addressed the review bottleneck problem we're having in Python development years ago. They have a core team, which pretty much resembles the steering committee we've just voted on, with 5 members, and a group of 28 committers. Things are much less formalized than in Python land, but they are making great progress. Here's their approach to solve the review bottleneck: https://wiki.postgresql.org/wiki/PostgreSQL_8.4_Development_Plan (they started this in 2008) with what they call "commit fests". This is a process where people submit patches using timed slots, each author is requested to do at least one review of another patch of similar complexity and the authors can fix their patches as part of the review process to get them to a level where a core dev can than take a look. Other people can sign up as reviewers as well. That way the initial load of making sure the patch quality is appropriate is scaled up a lot and their core devs only have to deal with patches which already have passed reviews by a few people. The process is described in more detail in this blog post: https://blog.2ndquadrant.com/managing-a-postgresql-commitfest/ (with the experience after doing this for 8 years) To help them with the commit fests, they have a system in place to manage the patches: https://commitfest.postgresql.org/ See e.g. https://commitfest.postgresql.org/22/ for the next upcoming commit fest. Commit fests are done for one month each, and then leave one month for things to settle in, get core dev responses. Patches can be pushed back to the next commit fest in case a core dev finds them lacking or the author doesn't respond in time. I also talked to Magnus Hagander, one of the PG core team members, about their core team. They have had this since the early 2000s and interestingly, they are mostly dealing with non-developer questions. Their approach to decisions such as the PEP process we have is mostly based on consensus and trust among the committers, not formalized and thus the core team does not play into this a lot. https://www.postgresql.eu/events/pgdayparis2018/schedule/speaker/1-magnus-hagander/ Now, all that said, while there are many similarities between PostgreSQL and Python in how the communities work, PG does take a more conservative approach to things - most committers and core team members have had that status for at least 10 years, it typically takes several years to gain committer status and they rarely take on new people. Still, I think there's a lot we can learn from them and their experience with solving the review problem. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 04 2019) >>> Python Projects, Coaching and Consulting ... http://www.egenix.com/ >>> Python Database Interfaces ... http://products.egenix.com/ >>> Plone/Zope Database Interfaces ... http://zope.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ http://www.malemburg.com/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Learning from PostgreSQL community: How to address the review bottleneck
Hi Marc-André, I find this feedback very interesting :-) As PG is a sophisticated piece of high-quality software, if that process works for them, then it may deserve trying on our side as well. Regards Antoine. Le 04/02/2019 à 12:03, M.-A. Lemburg a écrit : > I've attended FOSDEM over the weekend, where Jon Conway (one of the > PostgreSQL committers) gave a talk about, among other things, the > PG community and how it is structured: > > https://fosdem.org/2019/schedule/event/postgresql11/ > (the community part starts at around 8 min into the video) > > What struck me as interesting is that they have seen and addressed > the review bottleneck problem we're having in Python development > years ago. > > They have a core team, which pretty much resembles the steering > committee we've just voted on, with 5 members, and a group of > 28 committers. Things are much less formalized than in Python > land, but they are making great progress. > > Here's their approach to solve the review bottleneck: > > https://wiki.postgresql.org/wiki/PostgreSQL_8.4_Development_Plan > (they started this in 2008) > > with what they call "commit fests". This is a process where people > submit patches using timed slots, each author is requested to do > at least one review of another patch of similar complexity and > the authors can fix their patches as part of the review process > to get them to a level where a core dev can than take a look. > Other people can sign up as reviewers as well. > > That way the initial load of making sure the patch quality is > appropriate is scaled up a lot and their core devs only have to > deal with patches which already have passed reviews by a few > people. > > The process is described in more detail in this blog post: > > https://blog.2ndquadrant.com/managing-a-postgresql-commitfest/ > (with the experience after doing this for 8 years) > > To help them with the commit fests, they have a system in place > to manage the patches: > > https://commitfest.postgresql.org/ > > See e.g. https://commitfest.postgresql.org/22/ for the next > upcoming commit fest. > > Commit fests are done for one month each, and then leave one > month for things to settle in, get core dev responses. Patches > can be pushed back to the next commit fest in case a core dev > finds them lacking or the author doesn't respond in time. > > I also talked to Magnus Hagander, one of the PG core team members, > about their core team. They have had this since the early 2000s > and interestingly, they are mostly dealing with non-developer > questions. Their approach to decisions such as the PEP process > we have is mostly based on consensus and trust among the committers, > not formalized and thus the core team does not play into this > a lot. > > https://www.postgresql.eu/events/pgdayparis2018/schedule/speaker/1-magnus-hagander/ > > Now, all that said, while there are many similarities between > PostgreSQL and Python in how the communities work, PG does take > a more conservative approach to things - most committers and > core team members have had that status for at least 10 years, > it typically takes several years to gain committer status and > they rarely take on new people. > > Still, I think there's a lot we can learn from them and their > experience with solving the review problem. > > Thanks, > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] [RELEASE] Python 3.8.0a1 is now available for testing
I packaged my first release. *wipes sweat off of face* Go get it here: https://www.python.org/downloads/release/python-380a1/ Python 3.8.0a1 is the first of four planned alpha releases of Python 3.8, the next feature release of Python. During the alpha phase, Python 3.8 remains under heavy development: additional features will be added and existing features may be modified or deleted. Please keep in mind that this is a preview release and its use is not recommended for production environments. The next preview release, 3.8.0a2, is planned for 2019-02-24. Apart from building the Mac installers, Ned helped me a lot with the process, thank you! Ernest was super quick providing me with all required access and fixing a Unicode problem I found in Salt, thank you! Finally, this release was made on a train to Düsseldorf. There's a PyPy sprint there. The train is pretty cool, makes this "Wasm! Wasm!" sound. - Ł signature.asc Description: Message signed with OpenPGP ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] 2019 Steering Council Election Results
Voting closed at 2019-02-04 12:00 UTC as prescribed in [PEP 8100](https://www.python.org/dev/peps/pep-8100/). Of 96 eligible voters, 69 cast ballots. The top five vote-getters are: - Barry Warsaw - Brett Cannon - Carol Willing - Guido van Rossum - Nick Coghlan No conflict of interest as defined in PEP 13 were observed. Eligible voters have received result notification emails from helios, and may return to the system to audit/verify the results. Thanks to all participants! It was an honor serving as the administrator for the governance votes. -Ernest W. Durbin III signature.asc Description: Message signed with OpenPGP using AMPGpg ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
On Mon, Feb 4, 2019 at 5:43 PM Ernest W. Durbin III wrote: > > Voting closed at 2019-02-04 12:00 UTC as prescribed in [PEP > 8100](https://www.python.org/dev/peps/pep-8100/). > > Of 96 eligible voters, 69 cast ballots. > > The top five vote-getters are: > > - Barry Warsaw > - Brett Cannon > - Carol Willing > - Guido van Rossum > - Nick Coghlan > Congratulations everyone for the participation and also to the members of the very first council. Kushal -- Staff, Freedom of the Press Foundation CPython Core Developer Director, Python Software Foundation https://kushaldas.in ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
> On 4 Feb 2019, at 13:34, Kushal Das wrote: > > On Mon, Feb 4, 2019 at 5:43 PM Ernest W. Durbin III wrote: >> >> Voting closed at 2019-02-04 12:00 UTC as prescribed in [PEP >> 8100](https://www.python.org/dev/peps/pep-8100/). >> >> Of 96 eligible voters, 69 cast ballots. >> >> The top five vote-getters are: >> >> - Barry Warsaw >> - Brett Cannon >> - Carol Willing >> - Guido van Rossum >> - Nick Coghlan >> > Congratulations everyone for the participation and also to the members > of the very first council. Fully agreed. Ronald ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
As a voter, I can see the full list of how many votes each candidate received. I wonder if this should be published somewhere? There are some interesting speculations possible about the spread of the numbers ,and they give extra data on how the voters seem to think and which (types of) candidates are likely to do well in future elections. On Mon, Feb 4, 2019 at 4:13 AM Ernest W. Durbin III wrote: > Voting closed at 2019-02-04 12:00 UTC as prescribed in [PEP 8100]( > https://www.python.org/dev/peps/pep-8100/). > > Of 96 eligible voters, 69 cast ballots. > > The top five vote-getters are: > > - Barry Warsaw > - Brett Cannon > - Carol Willing > - Guido van Rossum > - Nick Coghlan > > No conflict of interest as defined in PEP 13 were observed. > > Eligible voters have received result notification emails from helios, and > may return to the system to audit/verify the results. > > Thanks to all participants! It was an honor serving as the administrator > for the governance votes. > > -Ernest W. Durbin III > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- --Guido van Rossum (python.org/~guido) ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
Antoine noted the same lack of transparency at https://discuss.python.org/t/2019-steering-council-election-results/824/3?u=ewdurbin. Ultimately I chose to initial publish results ASAP at the minimum granularity necessary given that there wasn’t direction on what level of detail should be published. I agree that transparency is key here, but as it wasn’t specified on in 8016/13/8100 I went with what we have. I can open a PR to 8100 with detailed results if no objections are heard. -Ernest W. Durbin III On February 4, 2019 at 11:18:00 AM, Guido van Rossum ([email protected]) wrote: As a voter, I can see the full list of how many votes each candidate received. I wonder if this should be published somewhere? There are some interesting speculations possible about the spread of the numbers ,and they give extra data on how the voters seem to think and which (types of) candidates are likely to do well in future elections. On Mon, Feb 4, 2019 at 4:13 AM Ernest W. Durbin III wrote: Voting closed at 2019-02-04 12:00 UTC as prescribed in [PEP 8100](https://www.python.org/dev/peps/pep-8100/). Of 96 eligible voters, 69 cast ballots. The top five vote-getters are: - Barry Warsaw - Brett Cannon - Carol Willing - Guido van Rossum - Nick Coghlan No conflict of interest as defined in PEP 13 were observed. Eligible voters have received result notification emails from helios, and may return to the system to audit/verify the results. Thanks to all participants! It was an honor serving as the administrator for the governance votes. -Ernest W. Durbin III ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/ -- --Guido van Rossum (python.org/~guido) signature.asc Description: Message signed with OpenPGP using AMPGpg ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
On Mon, 4 Feb 2019 at 16:20, Ernest W. Durbin III wrote: > I can open a PR to 8100 with detailed results if no objections are heard. +1 Paul ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
Did voting require you to select 5 candidates? Or was it up to 5? I don’t recall, but if it was the latter that could explain it. > On Feb 4, 2019, at 11:28 AM, Tim Peters wrote: > > [Ernest W. Durbin III ] >> Of 96 eligible voters, 69 cast ballots. > > FYI, the total number of votes Helios showed me summed to 340. At 5 > approvals per ballot, I'd expect to see 5 * 69 = 345 for 69 ballots. > Are we missing a ballot? > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
[Ernest W. Durbin III ] > Of 96 eligible voters, 69 cast ballots. FYI, the total number of votes Helios showed me summed to 340. At 5 approvals per ballot, I'd expect to see 5 * 69 = 345 for 69 ballots. Are we missing a ballot? ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
On Mon, Feb 4, 2019 at 8:20 AM Ernest W. Durbin III wrote: > Antoine noted the same lack of transparency at > https://discuss.python.org/t/2019-steering-council-election-results/824/3?u=ewdurbin > . > > Ultimately I chose to initial publish results ASAP at the minimum > granularity necessary given that there wasn’t direction on what level of > detail should be published. I agree that transparency is key here, but as > it wasn’t specified on in 8016/13/8100 I went with what we have. > > I can open a PR to 8100 with detailed results if no objections are heard. > I would wait until you have explicit permission from every candidate. (You probably will have to reach out to some.) I hereby grant you mine. -- --Guido van Rossum (python.org/~guido) ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
On February 4, 2019 at 11:30:13 AM, Donald Stufft ([email protected]) wrote: Did voting require you to select 5 candidates? Or was it up to 5? I don’t recall, but if it was the latter that could explain it. It did not. Voting was "Up To Five" per PEP 13 and PEP 8100 signature.asc Description: Message signed with OpenPGP using AMPGpg ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
[Guido] > There are some interesting speculations possible about the spread of > the numbers ,and they give extra data on how the voters seem to think > and which (types of) candidates are likely to do well in future elections. Ir was already speculated about before the election ;-) As predicted by a brief article I linked to on Discourse, limiting the number of approvals to 5 favored a landslide victory of the best-known candidates. Except for Nick, the weakest "winner" got 50% more approvals than the strongest "loser". So "landslide" for 4. In pure Approval voting (which we've used for PSF Board elections), there is no limit, and then you get a clear picture of approval levels. The "losers" here should realize their relatively low approval levels _may_ be an artifact of the voting process. Like in "first past the post" plurality elections, with a limit there's pressure for voters to betray their actual favorite(s) if they _think_ they can't win, to avoid "wasting their vote". Without a limit, there's never a reason (regardless of whether a voter is 100% honest or 100% tactical) not to approve of your true favorites. In the Discourse discussion, there _seemed_ to be consensus that limiting to 5 was probably a mistake, but it would require a change to some PEP to remove the limit, and the issue didn't come up before it was too late. Beyond that, pure Approval is just unsuitable _if_ there's some goal to achieve some level of "diversity", in an extremely broad sense. While we don't have political parties, we are developing factions, like "old-timer vs new-comer", "conservative vs aggressive" wrt language changes, and so on. Some form of "proportional representation" voting is needed _if_ we want to cater to that (and, yes, there are _variations_ of Approval voting that address such concerns - but they're all more complicated and I doubt Helios supports them). ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] 2019 Steering Council Election Results
> On Feb 4, 2019, at 4:11 AM, Ernest W. Durbin III wrote: > > The top five vote-getters are: > > - Barry Warsaw > - Brett Cannon > - Carol Willing > - Guido van Rossum > - Nick Coghlan Congratulations to the new council members! I wish you all the best. Thank you to everyone else on the ticket as well. A new council is elected after each feature release, so your time may yet come. Raymond ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
