+1 (for what it's worth) to any proposal which includes one (or more) GUIDOs :)
S. On Tue, Oct 23, 2018 at 11:57 AM Victor Stinner <vstin...@redhat.com> wrote: > Hi, > > Last July, Guido van Rossum decided to resign from his role of BDFL. > Python core developers decided to design a new governance/organization > for Python. 6 governance PEPs have been proposed. It has been decided > that discussions are reserved to core developers (everyone can read, > but only core devs can write), since the governance will mostly impact > the life of core developers. I'm writing this email to python-dev to > keep you aware that something is happening :-) > > Core developers (of the GitHub team) will vote to decide the new > Python governance in 3 weeks: > "The vote will happen in a 2-week-long window from November 16 2018 to > November 30 (Anywhere-on-Earth)." > > See PEP 8001: Python Governance Voting Process > https://www.python.org/dev/peps/pep-8001/ > > > Below are links to the governance PEPs, their abstract, and link to > the Discourse discussions. > > Note: a Discourse instance is experimented at discuss.python.org to > maybe replace python-{ideas,dev,committers} mailing lists. See the > "Discourse Feedback" category at https://discuss.python.org/ :-) > > > (1) PEP 8010: The BDFL Governance Model > https://www.python.org/dev/peps/pep-8010 > > Abstract: > """ > This PEP proposes a continuation of the singular project leader model, > euphemistically called the Benevolent Dictator For Life (BDFL) model > of Python governance, to be henceforth called in this PEP the Gracious > Umpire Influencing Decisions Officer (GUIDO). This change in name > reflects both the expanded view of the GUIDO as final arbiter for the > Python language decision making process in consultation with the wider > development community, and the recognition that "for life" while > perhaps aspirational, is not necessarily in the best interest of the > well-being of either the language or the GUIDO themselves. > > This PEP describes: > > * The rationale for maintaining the singular leader model > * The process for how the GUIDO will be selected, elected, retained, > recalled, and succeeded; > * The roles of the GUIDO in the Python language evolution process; > * The term length of service; > * The relationship of the GUIDO with a Council of Pythonistas (CoP) > that advise the GUIDO on technical matters; > * The size, election, and roles of the CoP; > * The decision delegation process; > * Any changes to the PEP process to fit the new governance model; > > This PEP does not name a new BDFL. Should this model be adopted, it > will be codified in PEP 13 along with the names of all officeholders > described in this PEP, as voted on per the guidelines in PEP 8001. > """ > > Discussion: > https://discuss.python.org/t/pep-8010-the-singular-leader/188 > > > (2) PEP 8011: Python Governance Model Lead by Trio of Pythonistas > https://www.python.org/dev/peps/pep-8011 > > Abstract: > """ > This PEP proposes a governance model for the Core Python development > community, led by a trio of equally authoritative leaders. The Trio of > Pythonistas (ToP, or simply Trio) is tasked with making final > decisions for the language. It differs from PEP 8010 by specifically > not proposing a central singular leader, but instead a group of three > people as the leaders. > > This PEP also proposes a formation of specialized workgroups to assist > the leadership trio in making decisions. > > This PEP does not name the members of the Trio. Should this model be > adopted, it will be codified in PEP 13 along with the names of all > officeholders described in this PEP. > > This PEP describes: > > * The role and responsibilities of the Trio > * Guidelines of how trio members should be formed > * Reasoning of the group of three, instead of a singular leader > * Role and responsibilities of Python core developers to the trio > * Sustainability considerations > * Diversity and inclusivity considerations > """ > > Discussion: > > https://discuss.python.org/t/pep-8011-leadership-by-trio-of-pythonistas-top-or-simply-trio/199 > > > (3) PEP 8012: The Community Governance Model > https://www.python.org/dev/peps/pep-8012/ > > Abstract: > """ > This PEP proposes a new model of Python governance based on consensus > and voting by the Python community. This model relies on workgroups to > carry out the governance of the Python language. This governance model > works without the role of a centralized singular leader or a governing > council. > > It describes how, when, and why votes are conducted for decisions > affecting the Python language. It also describes the criteria for > voting eligibility. > > Should this model be adopted, it will be codified in PEP 13. > > This model can be affectionately called "The Least Worst Governance > Model" by its property that while far from ideal, it's still the most > robust one compared to the others. Since avoiding issues inherent to > the other models is a paramount feature of the Community Governance > Model, we start the discussion a bit unusually: by rejecting the other > models. > """ > > Discussion: > https://discuss.python.org/t/pep-8012-the-community-model/156 > > > (4) PEP 8013: The External Council Governance Model > https://www.python.org/dev/peps/pep-8013/ > and > > https://mail.python.org/pipermail/python-committers/2018-September/006141.html > > Abstract: > """ > This PEP proposes a new model of Python governance based on a Group of > Unbiased Independent Directors of Order (GUIDO) tasked with making > final decisions for the language. It differs from PEP 8010 by > specifically not proposing a central singular leader, and from PEP > 8011 by disallowing core committers from being council members. It > describes the size and role of the council, how the initial group of > council members will be chosen, any term limits of the council > members, and how successors will be elected. > > It also spends significant time discussing the intended behaviour of > this model. By design, many processes are not specified here but are > left to the people involved. In order to select people who will make > the best decisions, it is important for those involved to understand > the expectations of GUIDO but it is equally important to allow GUIDO > the freedom to adjust process requirements for varying circumstances. > This only works when process is unspecified, but all participants have > similar expectations. > > This PEP does not name the members of GUIDO. Should this model be > adopted, it will be codified in PEP 13 along with the names of all > officeholders described in this PEP. > """ > > Discussion: > > https://discuss.python.org/t/pep-8013-the-external-council-governance-model/181 > > > (5) PEP 8014 -- The Commons Governance Model > https://www.python.org/dev/peps/pep-8014/ > > Abstract: > """ > This PEP proposes a governnance model with as few procedures, defined > terms and percentages as possible. It may also be called The Anarchist > Governance Model but uses Commons for now because of possible negative > connotations of the term Anarchist to some audiences. > > The basic idea is that all decisions are voted on by a subset of the > community. A subset, because although the whole community is in > principle entitled to vote in practice it will always be only a small > subset that vote on a specific decision. The vote is overseen by an > impartial council that judges whether the decision has passed or not. > The intention is that this council bases its decision not only on the > ratio of yes and no votes but also on the total number of votes, on > the gravity of the proposal being voted on and possibly the individual > voters and how they voted. Thereby this council becomes responsible > for ensuring that each individual decision is carried by a sufficient > majority. > """ > > Discussion: > https://discuss.python.org/t/pep-8014-the-commons-model/173 > > > > (6) PEP 8015: Organization of the Python community > https://www.python.org/dev/peps/pep-8015/ > > Abstract: > """ > This PEP formalizes the current organization of the Python community > and proposes 3 main changes: > > Formalize the existing concept of "Python teams"; > Give more autonomy to Python teams; > Replace the BDFL (Guido van Rossum) with a new "Python Core Board" of > 3 members which have limited roles. Their key role is mostly to decide > how a PEP is approved (or rejected or deferred). > > Note: the "BDFL-delegate" role is renamed to "PEP delegate". > """ > > Discussion: > > https://discuss.python.org/t/pep-8015-organization-of-the-python-community/193 > and > > https://mail.python.org/pipermail/python-committers/2018-October/006250.html > > > -- > > See also: > > PEP 8000: Python Language Governance Proposal Overview > https://www.python.org/dev/peps/pep-8000/ > > PEP 8002: Open Source Governance Survey > https://www.python.org/dev/peps/pep-8002/ > > Victor > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/sfermigier%2Blists%40gmail.com > -- Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier - http://linkedin.com/in/sfermigier Founder & CEO, Abilian - Enterprise Social Software - http://www.abilian.com/ Chairman, Free&OSS Group @ Systematic Cluster - http://www.gt-logiciel-libre.org/ Co-Chairman, National Council for Free & Open Source Software (CNLL) - http://cnll.fr/ Founder & Organiser, PyParis & PyData Paris - http://pyparis.org/ & http://pydata.fr/
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
