On Tue, Apr 27, 2010 at 10:46 AM, Barry Warsaw wrote:

I have two somewhat unrelated thoughts about PEPs.

* Accepted: header

When PEP 3147 was accepted, I had a few folks ask that this be recorded in the PEP by including a link to the BDFL pronouncement email.  I realized that there's no formal way to express this in a PEP, and many PEPs in fact don't record more than the fact that it was accepted.  I'd like to propose officially adding an Accepted: header which should include a URL to the email or other web resource where the PEP is accepted.  I've come as close as possible to this (without modifying the supporting scripts or PEP 1) in PEP 3147:

   http://www.python.org/dev/peps/pep-3147/

I'd be willing to update things if there are no objections.

I'd rather not build a single point of failure into the process. Instead of insisting on BDFL pronouncement, the community should switch do something like "last call for objections." There should also be a timeline so that unproductive discussion can't be dragged on forever.

* EOL schedule for older releases.

We have semi-formal policies for the lifetimes of Python releases, though I'm not sure this policy is written down in any of the existing informational PEPs.  However, we have release schedule PEPs going back to Python 1.6.  It seems reasonable to me that we include end-of-life information in those PEPs. For example, we could state that Python 2.4 is no longer even being maintained for security, and we could state the projected date that Python 2.6 will go into security-only maintenance mode.

I would not mandate that we go back and update all previous PEPs for either of these ideas.  We'd adopt them moving forward and allow anyone who's motivated to backfill information opportunistically.

SGTM. -- --Guido van Rossum (python.org/~guido)

On Tue, Apr 27, 2010 at 23:55, Nick Coghlan wrote:

I believe the more important part of Barry's suggested change here is requiring a link to the archived message (usually from python-dev) where the PEP was accepted (be it directly by you as BDFL, or by consensus from a "sufficient" number of core developers). This will likely also help with reminding people to announce on python-dev when PEPs are accepted by consensus (or by you) somewhere like PyCon or a sprint.

Though maybe it should be called Conclusion instead of Accepted and used for Rejected PEPs, as well? Cheers, Dirkjan

As to Guido's point about the decision making process, Nick's right. I just want to make sure we can capture the resolution in the PEP, be it by BDFL pronouncement or "hey, silence is acceptance" email.

I don't think "silence is acceptance" will work out in practice. For issues where a PEP was written in the first place, somebody will *always* object, and forever so, hoping that what he considers a mistake will not be done. The advantage of Guido acting as BDFL was that somebody would make an decision ultimately, one which both proponents and opponents of the PEP would accept. Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers. Regards, Martin

On Fri, Apr 30, 2010 at 1:28 PM, Steve Holden wrote:

Martin v. Löwis wrote:

...

...

As to Guido's point about the decision making process, Nick's right.  I just want to make sure we can capture the resolution in the PEP, be it by BDFL pronouncement or "hey, silence is acceptance" email.

I don't think "silence is acceptance" will work out in practice. For issues where a PEP was written in the first place, somebody will *always* object, and forever so, hoping that what he considers a mistake will not be done. The advantage of Guido acting as BDFL was that somebody would make an decision ultimately, one which both proponents and opponents of the PEP would accept.

Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers.

Couldn't we just go with the FLUFL?

IIRC in the IETF this is done by the committee chair. I think it's a good idea to have this be a single person to avoid endless indecision.

regards  Steve -- Steve Holden           +1 571 484 6266   +1 800 494 3119 See PyCon Talks from Atlanta 2010  http://pycon.blip.tv/ Holden Web LLC                 http://www.holdenweb.com/ UPCOMING EVENTS:        http://holdenweb.eventbrite.com/

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org

-- --Guido van Rossum (python.org/~guido)

Martin v. Löwis wrote:

...

...

Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers. Couldn't we just go with the FLUFL?

Not sure whether that's a serious proposal (April 1 is already some days back now). As a starting point, Barry would have to indicate whether he is interested in that role.

If he isn't then we can depose him and replace him with a puppet. regards Steve PS: Barry: sorry I can't make the gig tonight. Hope it went well ... -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

On Apr 30, 2010, at 3:51 PM, "Martin v. Löwis" wrote:

...

As to Guido's point about the decision making process, Nick's right. I just want to make sure we can capture the resolution in the PEP, be it by BDFL pronouncement or "hey, silence is acceptance" email.

I don't think "silence is acceptance" will work out in practice. For issues where a PEP was written in the first place, somebody will *always* object, and forever so, hoping that what he considers a mistake will not be done. The advantage of Guido acting as BDFL was that somebody would make an decision ultimately, one which both proponents and opponents of the PEP would accept.

Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers.

Regards, Martin

Consider this a plaintitive -1 to any sort of rule-or-decision based on committee. I'd much rather a 2x4 to the forehead. jesse

2010/4/30 Antoine Pitrou :

Jesse Noller writes:

...

Consider this a plaintitive -1 to any sort of rule-or-decision based on committee.

I'd much rather a 2x4 to the forehead.

Oops, sorry but what does "a 2x4 to the forehead" mean? (and "plaintitive" by the way?)

The former means being hit by a board and by the latter, he probably means "plaintive" meaning melancholy. -- Regards, Benjamin

On 01/05/2010 00:08, Benjamin Peterson wrote:

2010/4/30 Antoine Pitrou:

...

Jesse Noller writes:

...

Consider this a plaintitive -1 to any sort of rule-or-decision based on committee.

I'd much rather a 2x4 to the forehead.

Oops, sorry but what does "a 2x4 to the forehead" mean? (and "plaintitive" by the way?)

The former means being hit by a board and by the latter, he probably means "plaintive" meaning melancholy.

And 2x4 refers to a board with cross-section of 4 inches x 2 inches; the inch being an obsolete unit of measure from the old British imperial system now defunct throughout the civilized world. Michael -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer.

2010/4/30 Maciej Fijalkowski :

On Fri, Apr 30, 2010 at 5:08 PM, Benjamin Peterson wrote:

...

2010/4/30 Antoine Pitrou :

...

Jesse Noller writes:

...

Consider this a plaintitive -1 to any sort of rule-or-decision based on committee.

I'd much rather a 2x4 to the forehead.

Oops, sorry but what does "a 2x4 to the forehead" mean? (and "plaintitive" by the way?)

The former means being hit by a board and by the latter, he probably means "plaintive" meaning melancholy.

Does it only work for english speaking non-metric system users? (2x4 is probably something imperial)

Yes, that's a 5,04 by 10,08 for you. :) -- Regards, Benjamin

Michael Foord wrote:

On 01/05/2010 00:08, Benjamin Peterson wrote:

...

2010/4/30 Antoine Pitrou:

...

Jesse Noller writes:

...

Consider this a plaintitive -1 to any sort of rule-or-decision based on committee.

I'd much rather a 2x4 to the forehead.

Oops, sorry but what does "a 2x4 to the forehead" mean? (and "plaintitive" by the way?)

The former means being hit by a board and by the latter, he probably means "plaintive" meaning melancholy.

And 2x4 refers to a board with cross-section of 4 inches x 2 inches; the inch being an obsolete unit of measure from the old British imperial system now defunct throughout the civilized world.

The last time I was in a UK builders' yard I hear someone asking for "two meter pieces of two by four". At the time the UK was notionally metric (and the timber was planed to the nearest metric size) but the old names still survived. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

On Fri, Apr 30, 2010 at 7:08 PM, Benjamin Peterson wrote:

2010/4/30 Antoine Pitrou :

...

Jesse Noller writes:

...

Consider this a plaintitive -1 to any sort of rule-or-decision based on committee.

I'd much rather a 2x4 to the forehead.

Oops, sorry but what does "a 2x4 to the forehead" mean? (and "plaintitive" by the way?)

The former means being hit by a board and by the latter, he probably means "plaintive" meaning melancholy.

Yes, well, what Benjamin said. jesse

IIRC in the IETF this is done by the committee chair. I think it's a good idea to have this be a single person to avoid endless indecision.

It then seems that this role should go to the release manager of the upcoming feature release. Assuming Georg can accept this additional responsibility. Regards, Martin

On Fri, Apr 30, 2010 at 11:25 PM, Guido van Rossum wrote: [..]

...

...

Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers.

Couldn't we just go with the FLUFL?

IIRC in the IETF this is done by the committee chair. I think it's a good idea to have this be a single person to avoid endless indecision.

BPD = Benevolent Pep Dictator BPC = Benevolent Pep Caliph (sounds good in French, not sure in English ;) ) What about naming several BPD + and have one BPC elected each year by all the core devs ? == BPD == I am not sure if this would work for all areas in Python-core, but looking at the maintainers.rst file, it looks like we could name for example Brett for all the import machinery things, Marc-André for all the unicode things, I could be the one about packaging, etc. If we could manage to split the python-core development into categories, and add these categories in the PEP metadata, that would define who takes the final decision in case we can't reach consensus. == BPC == Of course some PEPs could concern several categories, so we would still need some kind of Pep dictator if there's no consensus. So what about electing a BPC every year ? Tarek -- Tarek Ziadé | http://ziade.org

Martin v. Löwis writes:

I think having a single body/person pronounce on all PEPs is sufficient; as that person should certainly listen to the opinions of the respective experts.

The issue is more a question of personal bandwidth. Giving an informed decision requires reading and listening to a lot of advice, material etc. Then it's not obvious that we will have many PEPs in the future. The syntax is pretty much frozen (even after the moratorium, it seems unlikely anything big will happen -- except if we want to add first-class coroutines). Many enhancements (e.g. new APIs in existing library modules) can be done, and are done, without PEPs at all. Regards Antoine.

On Sat, May 1, 2010 at 12:34 PM, Antoine Pitrou wrote:

Martin v. Löwis writes:

...

I think having a single body/person pronounce on all PEPs is sufficient; as that person should certainly listen to the opinions of the respective experts.

The issue is more a question of personal bandwidth. Giving an informed decision requires reading and listening to a lot of advice, material etc.

Yes that was the idea. For instance in packaging matters, I don't expect other core devs to have the time to learn about every aspect of a particular packaging problem to be able to make the best decision. Now if the release manager takes the decision, I guess the result will be the same at the end, as Martin says: he'll ask for the opinion of the respective experts so I guess it works too.

Regards

Antoine.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ziade.tarek%40gmail.com

-- Tarek Ziadé | http://ziade.org

On Sat, May 1, 2010 at 02:00, Tarek Ziadé wrote:

On Fri, Apr 30, 2010 at 11:25 PM, Guido van Rossum wrote: [..]

...

...

...

Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers.

Couldn't we just go with the FLUFL?

IIRC in the IETF this is done by the committee chair. I think it's a good idea to have this be a single person to avoid endless indecision.

BPD = Benevolent Pep Dictator BPC = Benevolent Pep Caliph (sounds good in French, not sure in English ;) )

What about naming several BPD + and have one BPC elected each year by all the core devs ?

== BPD ==

I am not sure if this would work for all areas in Python-core, but looking at the maintainers.rst file, it looks like we could name for example Brett for all the import machinery things, Marc-André for all the unicode things, I could be the one about packaging, etc.

If we could manage to split the python-core development into categories, and add these categories in the PEP metadata, that would define who takes the final decision in case we can't reach consensus.

This sounds like the lieutenant setup they have for the Linux kernel. I have no clue how that works out for them.

== BPC ==

Of course some PEPs could concern several categories, so we would still need some kind of Pep dictator if there's no consensus. So what about electing a BPC every year ?

So there is a "single voice" issue here (that also applies to Martin's idea of having the release manager make the call as that is a rotating position). One of the reasons, I think, the BDFL style of decision making has worked out is that it lets Guido keep Python consistent; the language is always striving to meet his mental model of the language more and more. Having this rotate amongst us will not allow us to have this benefit. It also raises the chance of arguing over who takes over the rotating position and that just falls down into the hellish hole of politics that I don't think any of us want to see happen. But even ignoring my worry/point, what are we even discussing here? Guido has said multiple time he is not retiring, simply scaling back his involvement. So are we trying to figure out how to make our own decisions about Python when Guido is not available to make one or simply doesn't care enough to pronounce? If that's the case then we should probably choose a vice BDFL (sort of a Benevolent Dicatator at Guido's Discretion) to keep the voice of Python as uniform as possible. I guess this person would become the assumed successor of the BDFL title if Guido ever does retire and the decision is made to continue on with active development of the language instead of just going into maintenance mode, but hopefully that problem will be a long ways off. If we are discussing something else, then I don't know what we are all talking about here other than measurements of standard pieces of wood. =) -Brett

On Mon, May 3, 2010 at 11:30 AM, Barry Warsaw wrote:

but in fact, the scripts make Resolution optional (it's kind of a pain to make it required just for Standards Track PEPs - contributions welcome).

It will also be a pain to retroactively update older PEPs with the newly-required metadata; leaving it optional (in practice) seems acceptable. It should only apply to newly-resolved PEPs, which is also likely a pain to build into the script. -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller

On May 01, 2010, at 07:12 AM, Martin v. Löwis wrote:

...

IIRC in the IETF this is done by the committee chair. I think it's a good idea to have this be a single person to avoid endless indecision.

It then seems that this role should go to the release manager of the upcoming feature release. Assuming Georg can accept this additional responsibility.

I do think it makes sense for the RM to assume these responsibilities where Guido either can't or doesn't want to make the final decision. I think it will fairly substantially increase the workload on the RM, so perhaps there are ways to off-load some of the current responsibilities (e.g. updating the website for each release). I also think that RMs should be term-limited so that we can spread more experience within the community. And past-RMs can provide a sort of consultation group where contentious decisions can be discussed and advice gathered. -Barry

In the meantime, let's groom Benjamin to be the Sacred Next Uncle Galvanizing the Gamut of Language Evolution.

I don't think anybody having such a position permanently can really work. Regards, Martin

Benjamin Peterson wrote:

2010/5/3 Guido van Rossum :

...

On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw wrote:

...

I do think it makes sense for the RM to assume these responsibilities where Guido either can't or doesn't want to make the final decision. I think it will fairly substantially increase the workload on the RM, so perhaps there are ways to off-load some of the current responsibilities (e.g. updating the website for each release). I also think that RMs should be term-limited so that we can spread more experience within the community. And past-RMs can provide a sort of consultation group where contentious decisions can be discussed and advice gathered.

I'm very -1 on the release manager making decisions on PEPs. The RM right now basically makes a release schedule and cuts releases. The little power he has is mostly used for rejecting features in the beta period. This task should not be politicized.

That seems reasonable, but it also seems reasonable to try and simplify the task of updating the web site for each release. There's plenty to do without having to fight that issue too. I'm copying this message to Rich Leland, who is currently making a study of the PSF's web requirements, to make sure this gets folded in. Many of the tasks are essentially macrogeneration, and unless automated will remain error-prone. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/

Georg Brandl wrote:

I agree, and I wouldn't want to make these decisions. That person (or group) needs to have some weight in the community, or there will be a feeling of "... and who is he to decide anyway". We haven't emphasized RMship in the past; it's not a special position, except when something about a release goes wrong and blame must be placed ;) I think, being Guido, you are still the best single person to do this job.

Not to wish anything bad on Guido, but I think it does behoove us as responsible stewards of the reference interpreter to at least consider the "bus" factor (as in "hit by a..."). I suspect Martin is right that some form of committee (at least initially) would be inevitable. While I doubt that we could find any one person that everyone would agree to defer to, I suspect we could find a small group of 3 or 4 people who's consensus everyone else would respect. And if that small group couldn't agree on whether or not something was a good idea, then the old "status quo wins a stalemate" would kick in. That said, this is hopefully something that we won't have to worry about for real until some time well into the future when Guido decides he wants to retire. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia ---------------------------------------------------------------

Am 05.05.2010 13:24, schrieb Michael Foord:

On 05/05/2010 12:15, Nick Coghlan wrote:

...

Georg Brandl wrote:

...

I agree, and I wouldn't want to make these decisions. That person (or group) needs to have some weight in the community, or there will be a feeling of "... and who is he to decide anyway". We haven't emphasized RMship in the past; it's not a special position, except when something about a release goes wrong and blame must be placed ;) I think, being Guido, you are still the best single person to do this job.

Not to wish anything bad on Guido, but I think it does behoove us as responsible stewards of the reference interpreter to at least consider the "bus" factor (as in "hit by a...").

Sure, but I think we wouldn't have too much trouble finding a replacement if and when that happens. (Let's hope it doesn't.) This is not something that requires weeks of preparation, and even if it did, no pronouncement on a PEP for a few weeks isn't the doom of Python.

...

I suspect Martin is right that some form of committee (at least initially) would be inevitable. While I doubt that we could find any one person that everyone would agree to defer to, I suspect we could find a small group of 3 or 4 people who's consensus everyone else would respect. And if that small group couldn't agree on whether or not something was a good idea, then the old "status quo wins a stalemate" would kick in.

Sounds like a sensible arrangement.

Yes, I could imagine that too. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out.

On Thu, Sep 2, 2010 at 9:08 PM, Raymond Hettinger wrote:

On Apr 30, 2010, at 12:51 PM, Martin v. Löwis wrote:

...

Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers.

I like Guido's idea.  Just appoint have one of the experienced developers who is independent of the proposal and have them be the final arbiter. For example, Guido had earlier suggested that I decide the fate of the "yield from" proposal because I had experience in the topic but was not not personally involved in the proposal.

Guido has set a good example for others to follow: * let a conversation evolve until an outcome is self-evident * or kill it early if it has no chance * or if discussion teases out all of the meaningful thinking   but doesn't reach a clear conclusion, just make a choice   based on instinct * have biases toward real-world use cases, towards ideas proven in   other languages (category killers),  towards slow rates of language   evolution, and think about the long-term.

It is better to have one experienced developer decide than to have a committee.

+1. BTW, Barry just asked me about PEP 3149 and we decided to leave the ultimate decision to Georg and Benjamin. That's about as large a committee I'd be comfortable to appoint for any specific PEP. -- --Guido van Rossum (python.org/~guido)

On Sep 02, 2010, at 09:08 PM, Raymond Hettinger wrote:

On Apr 30, 2010, at 12:51 PM, Martin v. Löwis wrote:

...

Without a BDFL, I think we need a committee to make decisions, e.g. by majority vote amongst committers.

I like Guido's idea. Just appoint have one of the experienced developers who is independent of the proposal and have them be the final arbiter. For example, Guido had earlier suggested that I decide the fate of the "yield from" proposal because I had experience in the topic but was not not personally involved in the proposal.

Guido has set a good example for others to follow: * let a conversation evolve until an outcome is self-evident * or kill it early if it has no chance * or if discussion teases out all of the meaningful thinking but doesn't reach a clear conclusion, just make a choice based on instinct * have biases toward real-world use cases, towards ideas proven in other languages (category killers), towards slow rates of language evolution, and think about the long-term.

It is better to have one experienced developer decide than to have a committee.

I completely agree that it's good we're beginning to give Guido a break so that he doesn't have to follow every thread, think hard about every PEP and make every decision. Having just gone through this as a PEP author with 3149, I have a couple of thoughts on how we might begin to formalize this process. Of course, we want to keep it lightweight, but also effective and as always in the best interest of Python. One thing that would help would be for Guido to let us know early on when he'd prefer to delegate the decision. This goes along with identifying the ultimate PEP arbiter (UPA? :) as early as possible. As Raymond says, it should be someone independent of the proposal, but with the interest, time, and experience necessary to make an informed decision. We might even want to capture the arbiter selection in a PEP header (similar to the new Resolution header for capturing the final decision reference). While I agree that we don't want decision by committee, I think we should consider a preference for paired arbiters. I have the highest respect for all the senior developers who would likely make up the pool of PEP deciders, but it gave me great confidence to have both Benjamin and Georg decide the fate of PEP 3149. As someone who might serve a similar role in the future, I would value a second person to sanity check my own thoughts on the matter and to identify any holes in my understanding (or <shudder> missed emails :). I'd say, let's state a preference (not a requirement) for two arbiters for any PEP that's not decided by Guido. We'd talked before about allowing the RM for the target version to make the decision. Maybe the RM can serve as that second arbiter when no other obvious candidate is available. Raymond, you identified a great set of criteria that the arbiters should use to guide them to a decision. I'm willing to write up an informational PEP that codifies this and any other guidelines we come up with for non-BDFL PEP decisions. Finally a reminder to PEP authors that it is your responsibility to shepherd your PEP through the process. Don't be a pest, but do keep an eye on the release calendar so that you're not scrambling for a snap decision at the last minute. 18 months can go by quickly. :) -Barry

On Fri, Sep 3, 2010 at 08:45, Guido van Rossum wrote:

On Fri, Sep 3, 2010 at 8:15 AM, Barry Warsaw wrote:

...

One thing that would help would be for Guido to let us know early on when he'd prefer to delegate the decision.

Hey! I'm still here! :-)

More to the point, you can assume that I'm happy to have every PEP decision made by someone else *except* if you see me participate in the thread. If I don't show up in the thread, you can assume that either (a) I don't care or know enough about the topic, or (b) I am confident that it's going in the right direction.

I guess the real question comes down to whether you want us to bug you to select the temp dictator or just make a call amongst ourselves?

...

This goes along with identifying the ultimate PEP arbiter (UPA? :) as early as possible.

I prefer acronyms derived from BDFL, like BDFM ("BD for the moment") or perhaps BDFP ("BD for the PEP"). (BDFM sounds better but BDFP is more accurate. I'll leave it up to the FLUFL to pick one.)

I personally like BDFN ("BD for now") or BDAGW ("BD at Guido's whim"), but this will bikeshed into eternity, so I am happy with the FLUFL being the dictator for the new acronym choice. =)

...

 As Raymond says, it should be someone independent of the proposal, but with the interest, time, and experience necessary to make an informed decision.  We might even want to capture the arbiter selection in a PEP header (similar to the new Resolution header for capturing the final decision reference).

While I agree that we don't want decision by committee, I think we should consider a preference for paired arbiters.  I have the highest respect for all the senior developers who would likely make up the pool of PEP deciders, but it gave me great confidence to have both Benjamin and Georg decide the fate of PEP 3149.  As someone who might serve a similar role in the future, I would value a second person to sanity check my own thoughts on the matter and to identify any holes in my understanding (or <shudder> missed emails :).  I'd say, let's state a preference (not a requirement) for two arbiters for any PEP that's not decided by Guido.

Hm... As long as we can make sure not to pick the same pair all the time this makes sense. (Not that I have any objections to how the Georg+Benjamin pair decided PEP 3149 -- to the contrary -- but I think it would be good to spread the power.)

I agree, and a RM as the backup/sanity check would not spread it out. Considering the position is held for 1.5 years (or more) and has in the past been held sequentially by the same person, that wouldn't exactly spread it about. It also limits trying to bring new people into the process as RMs tend to be old-hands and not new blood. Plus we are not about to make the lead on a PEP decision be a new person either.

But if a pair can't be found I think a single BDFM/BDFP will work too.

I agree. I would trust anyone who is given the ability to make a call to listen to reason enough to not necessarily need the sanity check. But a duopoly is not a bad thing overall either.

...

We'd talked before about allowing the RM for the target version to make the decision.  Maybe the RM can serve as that second arbiter when no other obvious candidate is available.

Good fallback plan.

As long as it gets spread around and the fallback is not the default, I agree.

...

Raymond, you identified a great set of criteria that the arbiters should use to guide them to a decision.  I'm willing to write up an informational PEP that codifies this and any other guidelines we come up with for non-BDFL PEP decisions.

Finally a reminder to PEP authors that it is your responsibility to shepherd your PEP through the process.  Don't be a pest, but do keep an eye on the release calendar so that you're not scrambling for a snap decision at the last minute.  18 months can go by quickly. :)

Well, realistically, there's only so much grief that anyone PEP author can be expected to put up with. I expect that a lot of PEPs won't be written or will be withdrawn in the face of prolonged discussion. Early selection of a BDFM (maybe the M can also refer to mentorship) ought to help in encouraging where encouragement would help -- and of course sometimes the best thing to do is to encourage the PEP author to drop the idea, if no consensus is in view (or if the author is particularly hard-headed).

Hopefully PEPs like this will get stopped before they even get checked in. The PEP editors have been sending PEPs back to their authors to share on python-ideas first for a little while now and that seems to have helped make sure the PEPs that do reach us are of sufficient quality.