[Python-Dev] Interested in serving on Steering Council
On 03Jan.2019 0515, Antoine Pitrou wrote:
> The primary question I would ask an external candidate is: how is it
> that you never became a core developer (which implies some amount of
> effort and dedication) but nevertheless would be willing to spend the
> effort and dedication needed for serving on a Steering Council (*)?
> (*) (or Committee, I don't remember :-)
David may of course provide an answer for himself, but allow me to
provide my answer (and this is why I pushed for allowing external
Historically, the only reason to become a core committer was to commit
code. Some of us no doubt desired or demonstrated greater influence, but
all of us have committed code or reviewed and merged PRs, either
directly to CPython or one of the related projects.
This is not a job for everyone, but it's been the only job we had on offer.
The closest alternative job was to be elected to the board of the Python
Software Foundation. But this is still not a job for everyone. They also
are not considered core committers, despite making significant
We now have a new job on offer. Exactly what that job involves isn't
quite defined yet, but it will certainly include some amount of
project/program/process management, likely some customer/user engagement
(or relationship management, if you prefer), and potentially some
independent decision making.
Guido is the only core developer who has previously contributed to
Python in this way (whatever "this way" turns out to mean). The rest of
us happily worked under "someone else" doing it.
Meanwhile, many non-core committers in the Python community have spent
their time building companies, consulting businesses or educational
courses. Spending time writing code and reviewing PRs is not how they
want to contribute, and so they have contributed in other ways -
including writing and often reviewing PEPs. There was no need for them
to be a core committer, since they weren't doing any of the
In the PEP 8016 discussions (pre vote), we agreed that if we chose to
elect someone who is not currently a core developer, we would also
probably vote to make them a core developer, so there is no harm in
allowing externals to be nominated. Also since the core committers are
voluntarily submitting to their guidance, it makes sense that voting to
elect/dissolve is restricted to us.
In summary, members of the Steering Council are filling a new role with
only one explicit precedent within the core committers. The
qualifications are different, and so the pool of candidates is
different. The existing core committers will submit to the Steering
Council, and so are the ones who elect them.
(Note that I've carefully used "core committer" and "core developer"
above. I believe it's very important to distinguish between "write
access on GitHub" and "project decision maker", and no reason to force
an arbitrary overlap.)