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: turnbull@sk.tsukuba.ac.jp University of Tsukuba Tel: 029-853-5175 Tennodai 1-1-1, Tsukuba 305-8573 JAPAN