PEP 8011: Clarify open points (#816)
- term limit (5 years, same as release manager's role) - disbanding the trio when one member quits - use same voting mechanism as PEP 8001 - clarify that an individual can be nominated in more than one slate
This commit is contained in:
parent
19d46ea7b1
commit
45d2b7d0ab
24
pep-8011.rst
24
pep-8011.rst
|
@ -106,15 +106,16 @@ themselves.
|
|||
|
||||
When it comes to select the members of the trio, instead of nominating various
|
||||
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.
|
||||
and vote for groups of threes who they believe can form this united trio. There
|
||||
is no restriction that an individual can only be nominated in one slate.
|
||||
|
||||
This PEP will not name or nominate anyone into the trio.
|
||||
|
||||
Only once this PEP is accepted, any active core developers (who are eligible to vote)
|
||||
can submit nomination of groups of three.
|
||||
|
||||
Once this PEP is accepted and core devs have submitted their nominations, each
|
||||
active eligible core devs can vote for one group of three.
|
||||
Once this PEP is accepted and core devs have submitted their nominations, voting
|
||||
can begin, and the voting mechanism described in PEP 8001 will be used.
|
||||
|
||||
Qualities desired out of the trio:
|
||||
|
||||
|
@ -215,14 +216,18 @@ Roles and responsibilities of Python Core Developers to the trio
|
|||
- Set good example of behavior, culture, and tone to Python community.
|
||||
|
||||
|
||||
Term (open to discussion)
|
||||
=========================
|
||||
Term Limit
|
||||
==========
|
||||
|
||||
The trio is not expected to serve for life, however a longer term is
|
||||
desired. The purpose of longer term service is to avoid unnecessary churns of
|
||||
needing to “elect”, and to provide stability and consistency in the language and
|
||||
the community.
|
||||
|
||||
Currently, Python release managers hold their position for 5 years (one release
|
||||
cycle), and that seems to work so far. Therefore, this PEP proposes that the
|
||||
trio hold their position for 5 years.
|
||||
|
||||
|
||||
Succession planning of the trio (open for discussion)
|
||||
=====================================================
|
||||
|
@ -256,10 +261,8 @@ not necessarily all, qualities of the trio as laid out in this PEP.
|
|||
Therefore, the guidelines for selecting trio members can also be used
|
||||
as guidelines when identifying future Python core developers.
|
||||
|
||||
Scenario if one member of the trio needs to quit (open for discussion)
|
||||
----------------------------------------------------------------------
|
||||
|
||||
This is open to further discussion.
|
||||
Scenario if one member of the trio needs to quit
|
||||
------------------------------------------------
|
||||
|
||||
Effective governance models provide off-ramps or temporary breaks for leaders
|
||||
who need to step down or pause their leadership service.
|
||||
|
@ -271,8 +274,9 @@ 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
|
||||
- Core developers can choose a different governance model
|
||||
- ??
|
||||
|
||||
Since the trio were elected as a slate and so the loss of one breaks that unit
|
||||
that was elected. Therefore, a new election should be held.
|
||||
|
||||
Formation of working groups/area of expertise/ownership (previously BDFL delegate)
|
||||
==================================================================================
|
||||
|
|
Loading…
Reference in New Issue