PEP 8011: Minor edits for clarity (#806)
This commit is contained in:
parent
7808074692
commit
97cb9542da
35
pep-8011.rst
35
pep-8011.rst
|
@ -10,8 +10,8 @@ Created: 2018-08-24
|
|||
Abstract
|
||||
========
|
||||
|
||||
This PEP proposes a governance model for Core Python development community,
|
||||
lead by a trio of equally authoritative leaders. The Trio of Pythonistas
|
||||
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.
|
||||
|
@ -26,7 +26,7 @@ described in this PEP.
|
|||
This PEP describes:
|
||||
|
||||
- The role and responsibilities of the Trio
|
||||
- Guidelines of how to trio members should be formed
|
||||
- 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
|
||||
|
@ -78,9 +78,9 @@ The following are not the expected out of the trio, however they can do these if
|
|||
will eventually defer to the trio when there are major disagreements among core developers.
|
||||
- Does not run / decide on Python language summit and its logistics.
|
||||
- Does not run / decide on Python core sprint and its logistics.
|
||||
- Does not handle CoC cases, those are responsibilities of the CoC workgroup, but
|
||||
will speak out if they witness those cases.
|
||||
- Does not make decisions about other Python implementation (Cython, IronPython, etc).
|
||||
- Does not handle CoC cases. Those are responsibilities of the PSF CoC workgroup,
|
||||
but will speak out if they witness those cases.
|
||||
- Does not make decisions about other Python implementations (Cython, IronPython, etc).
|
||||
- Does not run / decide on Python conferences and its logistics.
|
||||
- Not an evangelist of Python. The trio is not expected to preach/advertise for
|
||||
Python. They can if they want to, but not expected.
|
||||
|
@ -95,17 +95,17 @@ Guidelines for the formation of the trio
|
|||
========================================
|
||||
|
||||
The success of this governance model relies on the members of the trio, and the
|
||||
ability of each trio members to collaborate and work well together.
|
||||
ability of the trio members to collaborate and work well together.
|
||||
|
||||
The three people needs to have similar vision to Python, and each can have
|
||||
different skills that complements one another.
|
||||
The three people need to have similar vision to Python, and each can have
|
||||
different skills that complement one another.
|
||||
|
||||
With such team, disagreements and conflict should be rare, but can still happen.
|
||||
With such a team, disagreements and conflict should be rare, but can still happen.
|
||||
We will need to trust the people we select that they are able to resolve this among
|
||||
themselves.
|
||||
|
||||
When it comes to select the members of the trio, instead of nominating various
|
||||
individuals and choose the top three, core developers will nominate
|
||||
individuals and choosing the top three, core developers will nominate trios
|
||||
and vote for groups of threes who they believe can form this united trio.
|
||||
|
||||
This PEP will not name or nominate anyone into the trio.
|
||||
|
@ -173,14 +173,14 @@ in the future.
|
|||
If this PEP is chosen, it is not meant to be the only governance model for Python
|
||||
going forward.
|
||||
|
||||
This PEP proposed a transition into a community lead by a group of people (although small),
|
||||
while also introducing concept of additional specialized workgroups.
|
||||
This PEP proposed a transition into a community led by a group of people (although small),
|
||||
while also introducing the concept of additional specialized workgroups.
|
||||
|
||||
|
||||
Why not more than three
|
||||
=======================
|
||||
|
||||
Too many chefs spoil the soup.
|
||||
*Too many chefs spoil the soup.*
|
||||
|
||||
The goal of having a leadership team is for team Python core developers to be
|
||||
able to come to consensus and decisions. The larger the leadership team is,
|
||||
|
@ -261,9 +261,12 @@ Scenario if one member of the trio needs to quit (open for discussion)
|
|||
|
||||
This is open to further discussion.
|
||||
|
||||
Effective governance models provide off-ramps or temporary breaks for leaders
|
||||
who need to step down or pause their leadership service.
|
||||
|
||||
What if one member of the chosen trio has to quit, for unforseen reasons?
|
||||
|
||||
There are several options:
|
||||
There are several possible options:
|
||||
|
||||
- The remaining duo can select another member to fill in the role
|
||||
- The trio can choose to disband, core developers can nominate other trios
|
||||
|
@ -330,7 +333,7 @@ When the trio disbands, these workgroups are disbanded too.
|
|||
Why these workgroups are necessary
|
||||
----------------------------------
|
||||
|
||||
This is an effort to 'refactor large role' of the previous Python BDFL.
|
||||
This is an effort to 'refactor the large role' of the previous Python BDFL.
|
||||
|
||||
|
||||
Reasoning for choosing the name trio
|
||||
|
|
Loading…
Reference in New Issue