Thank you for allowing me to join you. All of your kind and encouraging
words on my nomination is quite overwhelming. My goal when I started
contributing was to learn and to try to help out and that's what I hope to
continue to do. Being recognized and appreciated for my contributions is
icing on the cake. :-)
And thank you to Victor and Terry for mentoring and guiding me! I hope you
both know how much I appreciate it.
I opened a vote during 1 week to promote Cheryl Sabella. She got the
excellent score of 21 “+1” vs 0 “-1” with very encouraging comments.
Moreover, the Steering Council accepted the vote.
Welcome aboard Cheryl!
I offered to mentor her for one month to guide her in her new
responsibilities. For example, I asked her to ask me before merging a
Cheryl: Would you like to introduce yourself shortly?
I sent an email to GitHub admins to add her to the GitHub python-core
team and to subscribe her to the python-committers mailing list. In
the meanwhile, I added her in copy of this email.
Ah, I already added her to
https://discuss.python.org/groups/committers and switcher the
"committer" bit in her https://bugs.python.org/user25861 account :-)
Night gathers, and now my watch begins. It shall not end until my death.
tl; dr How can we decide if we should stop using mailing list or if we
should stop using discuss.python.org?
https://discuss.python.org/ is getting more and more categories:
packaging, users, ideas, committers, core workflow, etc. Slowly, more
and more existing mailing lists get their category on
Problem: Nobody decided if a topic should always be started on
discuss.python.org or the "related" mailing list. I just started "Vote
to promote Cheryl Sabella as a core developer" thread on the
Committers category of discuss.python.org. I'm not sure that everybody
"migrated" to discuss.python.org, so sometimes I like to send an email
"hey, by the way, have a look at this thread on discuss.python.org:
(...)" to ensure that everybody will see my message. For a vote to
promote a contributor it's important that everybody is aware that a
vote is open (but everyone is free to decide to vote or to abstain).
There is also a high risk of having a topic discussed twice on mailing
list and discuss.python.org. I will happen on controversal changes
(PEPs), trust me :-)
More generally, I dislike having too many communication channels for
the same thing :-( (I'm not talking about Zulip/IRC vs mail/Discourse,
Zulip/IRC is a different way to discuss, and ways are useful/needed.)
"PEP 8100 -- January 2019 steering council election" says "Of the 96
eligible voters, 69 cast ballots." The Python core developers group of
GitHub has currently 96 members:
But I only count 72 members on discuss.python.org:
I count 27 core devs who didn't vote for PEP 8100 and 24 who are not
on discuss.python.org yet.
I see the following options:
(A) Close the mailing list: make it read-only, but keep archives. Ask
all mailing of the mailing list to move to discuss.python.org.
(B) Close discuss.python.org. Ok, it was nice, but it's time to move
back to mailing list. discuss.python.org becomes read-only.
(C) Do nothing: keep mailing list and discuss.python.org
We can make the same choice for all "categories" / "mailing lists", or
we can have a different choice (ML vs Discourse) per category /
Please, don't start a long serie of "+1" or "-1". My question here is:
how can we take a decision? Should we ask the fresh Steering Committee
to take a definitive decision?
Please don't start a thread about the advantages and disavantages of
mailing lists and Discourse. It has been discussed multiple times.
There is a dedicated section on discuss.python.org!
IMHO we had enough time to "experiment" Discourse. The 10 governance
PEPs have been mostly discussed there: PEP 8000, 8001, 8010, 8011,
8012, 8013, 8014, 8015, 8016, 8100. We saw many threads with more than
50 messages. Search for threads about voting methods for example :-)
We had enough time to see advantages and drawbacks of Discourse. We
started to see "real" moderation (handle trolls / CoC incidents). I
also saw the nice Discourse feature "start a new thread": move some
messages into a new topic.
Right now, I mostly care about python-committers mailing list vs
Committers category on discuss.python.org. But we will quickly have a
similar question for python-dev mailing list vs <whatever on
discuss.python.org> (I asked to create a new category, it's not
It's not easy for me to not give my opinion on the topic :-) But
again, my only question here is: how can we take a decision? Who will
take the decision?
Night gathers, and now my watch begins. It shall not end until my death.
I packaged my first release. *wipes sweat off of face*
Go get it here:
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
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,
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.
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:
(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
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:
(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
The process is described in more detail in this blog post:
(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:
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
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.
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
FYI... perhaps you now understand why I was keen to get the committers
listed somewhere :-)
-------- Forwarded Message --------
Subject: EPS: Announcing the Guido van Rossum Core Developer Grant
Date: Thu, 31 Jan 2019 10:25:52 +0100
From: M.-A. Lemburg <mal(a)europython.eu>
Organization: EuroPython Society (EPS)
To: EuroPython Announcement List <europython-announce(a)python.org>
At the last General Assembly of the EuroPython Society (EPS) at
EuroPython 2018 in Edinburgh, we voted on a new grant program we want
to put in place for future EuroPython conferences.
We all love Python and this is one of the main reasons we are putting
on EuroPython year after year, serving the "cast of thousands" which
support Python. But we also believe it is important to give something
back to the main team of developers who have contributed lots of their
time and energy to make Python happen: the Python Core Developers.
This group is small, works countless hours, often in their free time
and often close to burnout due to not enough new core developers
joining the team.
Free Tickets for Python Core Developers
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
In recognition of Guido’s almost 20 years of leading this team, and
with his permission, we have named the grant “Guido van Rossum Core
Details of the grant program are available on our core grant page:
PS: If you are a core developer and want to organize a workshop,
language summit or similar event at EuroPython 2019, please get in
touch with our program workgroup (program(a)europython.eu) soon, so that
we can arrange rooms, slots, etc.
PPS: If you want to become a core developer, please have a look at the
Python Dev Guide:
Help spread the word
Please help us spread this message by sharing it on your social
networks as widely as possible. Thank you !
Link to the blog post:
Ballots have been distributed per PEP 8100 and voting is open.
This election is scheduled to end at Feb. 4, 2019, noon (UTC).
If you expected to receive a ballot but did not, please contact me at ernest(a)python.org.