Jeroen Demeyer writes:
> I would like to propose to the new steering council to review PEP 580.
> Is there already a process for that?
I hope we can start with "same as it ever was." Looking at the list,
it's not like anything needs to change immediately. Guido, Barry,
Nick, and Brett have all been extremely active in general governance
as well as the PEP process. They know what they're doing, but the
Council is new. It will take some time to get going. Carol has not
been so prominent on these lists, but I bet she has ideas -- they all
have ideas. But ideas take time to implement.
They're also all very busy. They are not experts in everything --
even Guido has been happy to delegate because he acknowledges that
there are people who know more about specific requirements and
implementations than he does. Delegation is explictly permitted in
the Steering Council model. At least at the start, it should be
employed while the Council is figuring out their own business, IMO.
So, has has this been done in the past? For many PEPs, the pattern
has been
1. Proponent(s) write PEP, discuss on -ideas.
2. Proponent(s) stick a fork in it, it's done enough. Either the
BDFL Delegate is obvious from the discussion, or they negotiate
with somebody, and propose a delegate.
3. Guido decides, including anointing a delegate if he wants. On
Reject -- stop.
Half-baked -- go to 1. (Never seen an inappropriate delegate
proposed.)
Approve -- go to 4.
4. Delegate, with the help of (usually) python-dev or some
appropriate SIG, picks over the PEP and comes up with an
implementation plan.
5. When brown and toasty (but not perfect, nothing ever is) delegate
accepts, proponent commits, and the beta testers get to work.
This is *good enough*, with the exception of s/Guido/Council/ in Step
3 -- for now. I'm sure it will evolve.
I'm not proposing the following as an application form to be adopted.
The Council knows what they need, they'll come up with something in
due time. In view of the stylized process above, I believe this
format will help speed things up for proponents and relieve some of
the burden on the Council at this time when things are still pretty
fluid:
Hi, I'm the proponent of PEP 666 "Adding Perl ~ Regexp Operators
to Python", along with Mad Max, who is doing most of the
implementation. We've been discussing the PEP on Python Ideas,
and we've believe it's ready for pronouncement. Max is by far the
most informed about the API and implementation, and is well-
qualified to be Delegate. Rufus T Firefly has been deeply
involved in the discussion, is very expert, and would also be a
good delegate.
With apologies to the real PEP 666, which I'm pretty sure exists and
has nothing to do with Perl or regexps. :-)
Of course one could go on to give more information, a full status
report, open issues that the delegate or Council should decide, etc.
But a lot of that could also be left for the delegate to deal with --
the only thing the Council *must* do is pick a supervisor for the
approval process, and this format helps with that.
Also, the Council might decide they're not confident in any of the
candidates for delegate (or it's an empty set), and pick a different
person or do it themselves. If they do it themselves, I'm sure it
will be for good reason, but it's likely to take more time than if
there's a single delegate. Proponents will need to be prepared to
accept that outcome.
I am not criticizing Jeroen here. I'm a social scientist -- group,
and especially organization, dynamics are what I think about all day
every day. Rather, Jeroen's post was a good thing -- "hey, we've done
stuff! now how do we get it in?" If he didn't post, given the above,
why would that particular PEP get attention? The Council is not
necessarily on top of the progress of every PEP! I am merely
suggesting some additional information to help move things along.
Y'r ob'd't servant,
--
Associate Professor Division of Policy and Planning Science
http://turnbull.sk.tsukuba.ac.jp/ Faculty of Systems and Information
Email: [email protected] University of Tsukuba
Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
