Recently I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 11 licenses available - of the licenses I asked for last year, nine people took them up, so those are in use and come out of the allocation of 20.
Those of you who took up the licences last time should find that the tools continue to work normally. The licences expire on 27 November 2018.
If any others of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account.
On Thu, Jul 12, 2018 at 6:35 PM, Łukasz Langa <lukasz(a)langa.pl> wrote:
> I'm +1 to an Informational PEP around the state of the art in project governance.
I think this is a great idea. There's a lot of experience out there on
different governance models, but of course any given project only uses
one of them, so knowledge about what works and what doesn't is pretty
fragmented across the F/OSS community. And this is a really important
decision for us and our users, so we should do due diligence. For
example, we should think this through at least as carefully as we
thought through Github vs. Gitlab :-). A PEP is a good format to start
I volunteer to co-author such a PEP. But I'm not up to doing it on my
own. So... who else wants to be a co-author? (I'm not going to
pressure anyone, but Brett, Mariatta, and Carol, please know that your
names were the first ones that jumped to my mind when thinking about
What I'm thinking:
- While this might eventually produce some recommendations, the
immediate goal would just be to collect together different options and
ideas and point out their trade-offs. I'm guessing most core devs
aren't interested in becoming experts on open-source governance, so
the goal here would be to help the broader community get up to speed
and have a more informed discussion .
- As per the general PEP philosophy, I think this is best done by
having some amount of general discussion on
python-dev/python-committers, plus a small group of coauthors (say 2-4
people) who take responsibility for filtering ideas and organizing
them in a coherent document.
- Places where we'll want to look for ideas:
- The thread already happening on python-committers
- Whatever books / articles / blog posts / etc. we can find (e.g. I
know Karl Fogel's Producing OSS book has some good discussion)
- Other major projects in a similar position to CPython (e.g.,
node.js, Rust) -- what do they do, and what parts are they
- Large Python projects (e.g. Django) -- likewise
If you have suggestions for particularly interesting projects or
excellent writing on the topic, then this thread would be a good place
to mention them.
 The NumPy project has put a lot of energy into working through
governance issues over the last few years, and one thing that
definitely helped was coming up with some "assigned reading" ahead of
the main sprint where we talked about this. NumPy's problems are/were
pretty different from CPython's, but I'm imagining this PEP as filling
a similar role.
Nathaniel J. Smith -- https://vorpus.org
The result of the vote to to promote Pablo Salingo Salgado as core developer
after one week is positive: I declare that Pablo is now a core developer,
congrats! I will follow the usual process to actually make him a core dev,
and ask him to write a short introduction email to this list.
But I also noted that Pablo lacks experience to be fully autonomous on merging
pull requests, so I also requires that Pablo will have to be strictly mentored
by me for 3 months. By strict, I mean that Pablo will have to ask me to
merge any pull request. This strict mentoring may be extended depending on
Pablo's progress. As Eric Snow wrote, I vouch for Pablo: don't hesitate to
blame me directly if anything goes wrong :-)
Giving more responsibilities to Pablo is part of the learning process.
Reviewing as a core developer is different than a review as a contributor: core
developers are expected to actually merge a pull request once they approve the
change. Merging a pull request is a big responsibility and an investment in
the long-term, because the committer is expected to fix regressions and issues
related to this change for next months, if not next years.
Note: Cheryl Sabella has also been identified as an active contributor who may
be promoted as well. I am already discussing with her about that for 1 month,
but last month, Cheryl chose to wait. I will keep you in touch ;-)
Promote (+1): 8 votes
* Victor Stinner
* Terry Reedy
* Carol Willing
* Gregory P. Smith ("+0.5")
* Eric Snow
* Brett Cannon
* Nathaniel Smith
* Antoine Pitrou ("+0.5")
Wait (-1): 1 vote
* Berker Peksağ
Neutral (0): 1 vote
* Serhiy Storchaka ("-0")
At the Language Summit last week, after Mariatta's talk we had a
conversation around diversity and how to grow our contributor base, which
led to someone (Steve Dower?) suggesting we post a sort of "Office Hours"
list. This would be a list of current core developers who are interested in
being available at set time(s) for helping mentor newer contributors in our
community through our process and, if they're interested, mentoring them
through the process of becoming core developers themselves.
This "Office Hours" concept is a type of thing that has worked well
elsewhere, including around the software world, and we have some people
interested in offering said mentorship, so I would like to move on to
getting this list up somewhere so we can start doing it.
With that said, before I go make a PR to the devguide to start iterating on
the implementation, an important question:
As this is both an event similar to an in-person meetup and an event meant
to be a safe space for those getting started, it will explicitly mention
the code of conduct. As such, it needs a person/persons/list to contact
should something arise in this context that needs to be handled. What/who
should that be?
* Suggestion 1: use the already in-place core-mentorship-owner(a)python.org,
though I can't tell who's on there.
* Suggestion 2: Create some new list with a few key people on it.
* Suggestion 3: List some direct names. Who?
As for implementation, there are some tools out there we could possibly
use, but in the interests of getting something out there I'm just going to
make a table and fill in some common information, starting with my own.
Calendar apps and other integrations can come as we figure them out.
or: Replace Dictatorship with Democracy.
== Introduction: unjustified fears? ==
I see that many people are eager to replace the old governance based
on a single BDFL with a new governance with a new BD(FL) and/or a
council. My problem is that I don't see any clear definition of the
roles of these BD(FL) and/or council: what they are expected to do,
what they cannot do, etc.
It seems that the main question for a new governance is how to take a
decision on PEPs (accept or reject them with some variants like
Deferred). I read that core developers are unable to make a decision
themselves (fail to reach a consensus) and that letting core
developers decide would make Python "inconsistent" (as if only a
single BDFL is able to keep Python consistent). I also read that the
BDFL is required to make unpopular decisions to enhance Python.
Can someone please explain me the rationale behind these fears? Do you
have examples? Maybe examples outside Python?
In my experience, a consensus has been reached in less than one month
on most PEPs without the help of the BDFL. There were a few
controversal PEPs. The most controversial PEP is obviously the latest
accepted PEP, the PEP 572 (assignment expressions). OK. But do you
have other examples?
In a different thread,I gave the example of my PEP 446 "Make newly
created file descriptors non-inheritable": Guido approved it, even
though Charles-François Natali was against it (since it broke the
backward compatibility). If I recall correctly, the issue with that
PEP is that almost nobody cared about it: it was mostly
Charles-François and Guido :-) Hopefully, such cases are rare.
== What is the image send to the community and contributors? ==
Last year, I mentored multiple contributors. What I learnt is that
contributing to Python is much harder than what I expected.
Most core developers are core for 5 years or longer (maybe 10 years
for some of them?), and we (core developers) forgot how hard it is to
contribute. When your name is known in a community: it's very easy to
share your ideas, other people listen to you and respect your
experience. It's much faster to get a pull request merged... sometimes
simply because you merged your own PR :-)
Becoming a core developer takes between 6 months and 2 years, it
requires a lot of commitment, to have free time, etc. In short, it's
*very hard* to recruit new core developers. It seems like many people
What is the image sent to contributors if we create a subgroup inside
core developpers called "council"? What if we elect a new BDFL *for
life*? Does it mean that even core developers judgment are no longer
trusted, only the council decision matters? What about people outside
in the insider group of cores... regular contributors? Will anyone
still listen to them?
I'm not saying that a new governance will lead to such issues. I'm
only opening the question of the image sent to the community.
== Democracy: vote on PEPs open to all core developers ==
I would like to come back to my idea of using a vote restricted to
core developers: a PEP would require "50% +1" (at least 50% of votes +
1 voter) to be approved. Maybe some more sensitive PEPs would require
a bigger majority, like 66%+1, for example PEPs changing the Python
language. The vote would only be opened once we (core devs) consider
that the PEP is ready for a vote.
The main risk is that PEPs would fail to be approved if no consensus
can be found. In practice, it means that Python remains unchanged.
Honestly, I don't think that this consequence is a disaster:
sometimes, doing nothing *is* a wise choice :-) The PEP author is free
to retry in 6 or 12 months with a new PEP, maybe written differently,
maybe with better examples. For example, if everybody agreed to reject
the first version of the PEP 572, I expect a more positive result on
the latest flavor of the PEP. The issue is sometimes the PEP itself,
not the proposed change. Guido forced me to rewrite my very long PEP
540 "UTF-8 Mode" from scratch to make it shorter (and simpler), and it
was a major enhancement for my PEP :-)
OK, but sometimes everyone like the proposed change, but just not the
PEP itself. What can be done? Well, the PEP can be modified. Another
different PEP can be proposed. In the worst case, it's a dead end.
Again, IMHO it's fine to done nothing. Moreover, I would like to
insist that in last years, I don't think that such case occurred
frequently. To be honest, I fail to find any example...
We saw drawbacks. What are advantages of a democracy where every core
developer vote counts?
First, the BDFL is no longer a bottleneck. Last years, Guido became
less available, some PEPs took a lot of time to be approved, I'm
thinking about PEP 525 and PEP 530.
Moreover, core developers can take holiday. You are allowed to take
care of friends, family, and just have a break. It's fine. There are
other people who will take care of Python for you.
The decision becomes taken by "the community" (core developers in
practice) rather than an individual. Negative comments should no
longer target an individual but the collective decision. Being a
public person is not easy, it seems like Guido resigns partially
because of that pressure. I know that Brett Cannon also suffered of
negativity of some haters of the Internet. I also had a depression
recently caused partially by Python. Working on an open source and
public project causes specific issues.
== Annex For Council Lovers ==
We already have a concept of *councils*. When I have a question on
importlib, I will first ask Brett Cannon. If he is not available, I
would ask Nick Coghlan and Barry Warsaw. When I have a question on C
internals, I will ask Serhiy Storchaka and INADA Naoki. We even have a
written list of "experts" (or "maintainers"):
Note: this list is filled by core developers who add themselves :-)
These experts are known references in their domain, and it's common
that Guido delegates his BDFL role on PEPs. For example, INADA Naoki
is the delegate of two Unicode PEPs: Nick's PEP 538 "C locale
coercion" and my PEP 540 "UTF-8 Mode". If Naoki would reject my PEP, I
would be fine with that: I trust and respect his judgment.
== Summary ==
It is already very hard to become a core developer: a contributor only
becomes a core dev once other core developers trust them.
I propose to trust core developers judgment and let them all decide if
a PEP should be accepted (or rejected). Common PEPs would require
"50%+1" majority (1/2), sensitive PEPs (ex: modify the Python
language) would require 66%+1 majority (2/3).
Known experts will help to lead the discussion and to refine the PEP.
Core developers will decide when they consider that a PEP is mature
enough for a vote.
If a PEP is rejected by a vote, the author is free to make a new
attempt 6 to 12 months later with a new PEP, maybe with a new stronger
rationale and better examples. Or a competitor PEP can be proposed by
a different author. I expect that the common case will be that the
author will not attempt a new similar PEP since the vote result will
be explicit enough.
Rejecting a PEP doesn't mean a failure for Python: sometimes, doing
nothing is the wisest choice :-)
[tl;dr: We need some ground rules, because uncertainty makes it hard
to think straight. But if we get sucked into a complicated meta-debate
about the ground rules then that defeats the purpose. My proposal for
a Minimum Viable Ground Rule: let's all agree not to finalize any
governance decisions before October 1.]
We're in a constitutional crisis, and that's scary. There's no map and
none of us know what to expect. It feels like anything could happen.
You look at the mailing list and see people making big proposals -- is
one of them going to suddenly be adopted? If I look away for a few
days, will I come back and find out that something's been decided?
What are we even talking about? Do I need to jump into that thread
RIGHT NOW? It's scary.
People don't do their best work when scared. When we're scared it's
harder to listen and build up common ground with others -- but that's
exactly what we'll need to do to get through this. And also, like...
being scared sucks. I would prefer to be less scared.
So: can we do anything to make this less scary?
One thing that would help is if we had some ground-rules for how the
decision itself will be made. Knowing what to expect makes things less
scary. There's another thread going on right now trying to do that
(subject "Proposal on how to vote"). But... if you look at that
thread, it turns out deciding on how to vote is itself an important
decision with lots of subtle issues, where we probably want to give
people time to think, brainstorm, critique. Heck, in the end we might
decide a vote isn't even the best approach. So I'm not saying we
shouldn't be having that discussion, we definitely should, but... it's
also giving me a new source of anxiety: that we'll all be so eager to
get *some* certainty here that we'll end up trying to force a decision
prematurely. Kind of a catch-22: the decision about how to make
complex decisions is itself a complex decision, which is what we don't
know how to do yet.
Is there some way to avoid this loop? Can we come up with some ground
rules simple enough that we can agree on them without a big debate?
Well, there's one thing I am pretty sure of: this is a big decision,
there's a lot to think about and talk about, and that we won't regret
taking some time some time to do that. And besides, trying to force it
to happen faster will make people more scared and dig in their heels.
So here's my proposal for an initial, Minimum Viable Ground Rule: we
should set a date and promise that no actual decisions will be
finalized before that. Until then we are just talking and
brainstorming and gradually converging on points of consensus. (And to
be clear, the point of this is to give us breathing room, not set a
deadline -- we shouldn't dawdle, but if we get there and it turns out
we need more time, then that's OK.)
What would be a good date? The core sprint is coming up Sept. 10-14,
and this seems to be a likely topic of conversation there. And then
after the sprint, those who aren't present will need time to catch up
with any discussions that happened at the sprint. So to make things
concrete, I propose: no governance decisions finalized before October
Probably this is what will end up happening anyway, but if we make it
explicit in advance and tell everyone, then at least we'll all know
that it's OK to stop refreshing our email constantly and redirect that
energy in more useful directions.
What do you all think?
Nathaniel J. Smith -- https://vorpus.org
I’d like to propose an alternative model, and with it a succession plan, that IMHO hasn’t gotten enough discussion. It’s fairly radical in that it proposes to not actually change that much!
TL;DR: I propose keeping a singular BDFL and adding a Council of Advisors that helps the BDFL in various capacities, with additional responsibilities. I also have someone specific in mind for the NBDFL, but you’ll have to read on for the big reveal.
Why keep a singular BDFL? I think it’s clear that no one can completely replace Guido, and neither should we try, nor do we need to. The discussion to date has explored refactoring many of the roles that the BDFL has, and that’s all excellent, especially to reduce the burden and burnout factor of the NBDFL. But I think having a singular BDFL making the tough decisions, with the support and help of the community, is in the best interests of Python over the long term.
A singular BDFL provides clear leadership. With a council of elders, it will be more difficult to communicate both to the Python community, and to the larger, more peripheral user base, that any particular individual has the authority to make decisions. Regardless of size, there would ultimately be some one person communicating any council decision. There will inevitably be ambiguity as to the authority of said decision. How will folks, especially on the periphery, know that Alice Jones or Bob Smith are members of the council and can speak authoritatively on decisions for the language? “Bob Smith, on Behalf of the GUIDO” is IMHO less obviously and unquestionably authoritative than “Alice Jones, BDFL”.
This also comes into play for shutting down discussions early. With a committee, it’s possible that you’ll have some disagreement among the members as to whether a discussion is fruitful or not, whether it rehashes settled questions, or whether the change fits into the overall direction for Python’s evolution. Alice Jones may say “No, that’s not gonna happen” only to be overruled or undermined by Bob Smith’s “That’s a good idea”.
Taken together, these fall under the umbrella of having one voice for the decision making process. It may be possible for consensus within the council to come across as a single voice, but I think it will generally be harder. A council also opens the door for more back-channel lobbying of a sympathetic member. Yes, such lobbying is possible with a BDFL, but at least there should be less contention.
I also think a council will be much more risk adverse than a singular BDFL, and that’s not necessarily a good thing. While moratoriums and a more conservative approach to change may be appropriate at times, I would prefer those to be deliberate decisions for a specific purpose, rather than the unintended outcome of groupthink or lack of consensus. A singular BDFL with support from the community will have more authority to make decisions which probably will never be universally accepted, and much less prone to vapor lock due to lack of consensus or internal bickering.
I hope Guido won’t mind me relating a comment of his that has really resonated with me over the last few days, and for which I think a singular BDFL will be much more adept at communicating and shepherding. The question for any new leader is:
What is your vision for Python?
This question keeps coming to mind as I think about how the evolution of the language will be governed over the next few years or decades. Yes, Python is a mature language, but it’s far from stagnant. Guido always had a very clear vision of what Python should be, where it should go, and how new proposed features (or other changes to the Python ecosystem) fit into that vision, even if he didn’t or couldn’t always clearly articulate them. The NBDFL will necessarily have a different vision than Guido, and I think even he would agree that that’s okay! A strong vision is better than no vision. Python must continue to grow and evolve if it is to stay relevant in a rapidly change technology environment. As an almost 30 year old language, Python is already facing challenges; how will that vision address those challenges, even if to explicitly choose the status quo?
Will a council be able to articular, express, communicate, adapt, and follow through on that vision? Will a council be able to evaluate a proposed change as it supports or detracts from that vision? Will a council be able to break out of a primarily maintenance position, to actually move the language and its primary implementation forward? I’m not so sure.
For these reasons I propose that we retain a singular BDFL.
The formation of a formal Council is still a good idea! I just think that it shouldn’t be the ultimate arbiter of decisions for Python. So what would the Council do?
- It would serve as a check on the BDFL. If Bob Smith were one day employed by Evil Corp. and started making decisions that were directly detrimental to Python, the council should be able to effectively impeach. There should be checks and balances on this power, the BDFL shouldn’t continuously fear a coup, and impeachment will hopefully never be invoked, but the council can serve as the voice of the community for when the BDFL is abusing their power.
- The council would select the next BDFL if and when that time comes. No one will serve forever, so a clear succession plan should be in place. To avoid the tyranny of the majority, the council would serve similarly to a board of directors. They’d search for candidates, match them against well defined criteria, conduct interviews, serve as the voice of the community, and eventually select the N+1BDFL.
- The council would serve as trusted advisors to the NBDFL. The BDFL won’t be out there all alone! The council will provide advice when requested, and back up the BDFL when needed. The council helps legitimize the BDFL and their decisions.
We can debate how the initial council is selected, its make up, number of members, term limits, etc. I think much of the current discussion about a BDFL-like council would satisfy the requirements for a Council of Advisors. It’s just that the roles and responsibilities would differ. The COA wouldn’t make the decisions, but it would help the BDFL make the best decisions possible, and have their back against any detractors.
I definitely have my own thoughts on an initial make-up of said council, but I’ll reserve that for later.
If you’ve read this far - thank you! Now for the big reveal. I think the Next BDFL should be… (drum roll)…
I’ve long said — somewhat in jest, since I never expected Guido to actually ever retire! — that Brett would be my choice for the next BDFL. I think he’s the perfect candidate, and he’s already demonstrated qualities that I think make him a fantastic leader. He’s smart, compassionate, passionate, respectful, young, tall, and has the right mix of technical excellence and social skills. He believes deeply in diversity and community. As he’s shown with the decisions to move first to Mercurial, then to git/GitLab, he isn't afraid to make difficult decisions that he knows not everyone will agree with (and I say that having advocated the losing choice more than once :). He’s not afraid to say what’s on his mind. I think he can clearly articulate a Vision. He shares many of these same qualities with Guido, while being a different person with different sensibilities. And that is not only fine, but IMHO a *good* thing. We can trust his stewardship, and he already has legitimacy as a senior decision maker in the Python ecosystem. He has a wide technical knowledge of Python and its C implementation, and yet he knows what he doesn’t know. He has good relationships with most core devs, and is a well-known voice within the wider community. He’ll be able to delegate where appropriate, and make definitive pronouncements where needed.
Before you ask, yes I did check with Brett before making this proposal and he didn’t shoot it down. He may have specific requirements for accepting the position, but I’ll let him articulate those. I’m confident they would come across as completely reasonable. :)
* We retain a singular BDFL to lead Python
* A Council is selected to serve as advisors to the BDFL, a selection committee for succession, and a check against the BDFL.
That’s it in a nutshell. Thanks for listening.
if I remember correctly, we had a moratorium for language changes around
versions 3.2-3.3. I think during that time relatively few BDFL-level
decisions were required.
Perhaps we could have one again, say for 12 months so we can figure things
out. Other Python implementations may welcome the moratorium so they can
During that time we could just informally listen very closely to Guido if
anything requires a decision and he happens to be around. But there may be
no decisions at all.
And yes, I guess we can successfully attempt to be nice, especially to him
(thanks for this wonderful language!).