iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP-8013: Add example scenario for BDFL-Delegate role (#795)

This commit is contained in:
Steve Dower 2018-09-29 13:34:30 -07:00 committed by GitHub
parent 711924d619
commit 6e05003e1b
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 29 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
pep-8013.rst
View File

@ -103,7 +103,8 @@ GUIDO may not delegate authority to individuals who have not been
elected by the core developer team. (One relevant case here is that
this changes the implementation of the existing BDFL-Delegate system,
though without necessarily changing the spirit of that system. See the
later sections for more discussion on this point.)
later sections, particularly example scenario four, for more
discussion on this point.)
The Release Manager (RM) is also permitted the same ability to request
changes on any PEPs that specify the release they are responsible for.
@ -323,6 +324,33 @@ may argue that 70% of users are affected. A successful amendment may
include a different but more reliable percentage, or may be rewritten
to no longer depend on the number of affected users.
Scenario 4 - The Case of the Delegated Decision
-----------------------------------------------
Some proposals may require review and approval from a specialist in
the area. Historically, these would have been handled by appointing a
BDFL-Delegate to make the final decision on the proposal. However, in
this model, GUIDO may not delegate the final decision making process.
When GUIDO believes that a subject matter expert should decide on a
particular proposal, GUIDO may nominate one or more individuals (or
accept their self-nomination) to a similar position to a BDFL
Delegate. The terms of these expert's role may be set as GUIDO sees
fit, though GUIDO always retains the final approval.
As a concrete example, assume a proposal is being discussed about a
new language feature. Proponents claim that it will make the language
easier for new developers to learn. Even before an official proposal
is made, GUIDO may indicate that they will not accept the proposal
unless person X approves, since person X has a long history teaching
Python and their judgement is trusted. (Note that person X need not be
a core developer.)
Having been given this role, person X is able to drive the discussion
and quickly focus it on viable alternatives. Eventually, person X
chooses the alternative they are most satisfied with and indicates to
GUIDO that they approve. The proposal is submitted as usual, and GUIDO
reviews and accepts it, factoring in person X's opinion.
References
==========