Thanks all for voicing your concerns and all the feedback.
So far I hear people opposing the strict deadline because they're afraid it means we'll be making rush decisions for the sake of meeting deadlines. 

Well here are my reasonings of why I'm setting deadlines and timelines:

We all know it, discussions in mailing list can go on forever. And now that we don't have a BDFL who will shut down and end discussions, these things can really go literally forever. Therefore we should timebox these discussions.

I believe that none of us actually want Python without governance and without decision forever. The Python community is waiting for core developers to come together and figure out Guido's successor.

For myself, January 1, 2019 is reasonable deadline, it will be 6 months since Guido announced his permanent vacation.

In separate thread, it seems that we're in agreement that Oct 1, 2018 for deadline to come up with proposals of governance model.

So then, what needs to happen between Oct 1 to Jan 1? (3 months period?) How do we go from "here are the proposed governance model" into "we have selected the successor(s)"?
Clearly, if we want to have decision by Jan 1, people can't still be arguing about governance model on Dec 31st. If we're going to vote on things, people need to know when they need to show up to vote. We probably need someone to volunteer and set up the voting system, or get in touch with The PSF for setting it up, and maybe account for flexibilities in case there are last minute technical difficulties and so on. All of these require coordination and concerted effort.

From there, I've started breaking down the different phases of how this will go, and also allowing ample time for people to catch up and read their emails. For example, in my timeline, I suggested 2 weeks time of voting in each round. In reality, voting is probably just going to take a few clicks on a website, not 2 full weeks.

I'm just drawing from my own personal experience of having organize and coordinate a group of volunteers. What I've learned is that the group will be more successful when each volunteers know their roles, responsibilities, the goal of the group, and in a lot of cases, they need to know when they should deliver and complete their task.

Python core devs are all volunteers, living in different timezones, in different part of the world, and we all have other commitments to our employer and family. But right now we all have responsibilities to come up with a plan of succession for this community. It was the last task Guido gave to us before retiring as BDFL.

These timelines are not meant for you to rush and make decision last minute just because there is a deadline.
On contrary, I hope that by knowing these timelines ahead of time, you all can account for these dates, you can be responsible, and if needed, adjust and plan ahead your volunteering schedule surrounding these dates.

If you are proposing a governance model, and someone else here have questions about it, it will be appreciated if you can respond in timely manner, and not wait 4 months before you respond.

Similarly, if you have question and concern or just want to argue about a proposed governance model, you should do it sooner, within these timeboxed periods, and not wait until 2020, and don't wait until last minute either. You'll need to give time for the proposer to respond to you. (again we all live in different timezones).

I'm also guessing that not everyone here is planning to come up with 100 different proposals, and not everyone here wants to argue at all. Perhaps some of you are just waiting for the ballot to arrive in the email?
There is value in knowing in advance of when you need to vote, so you can plan on watching their mailbox, or alert us if they didn't receive the ballot.

I hope by knowing these timelines people can be more considerate with each other, and that they'll be able to express their thoughts more effectively in emails.

Without clear deadlines, sure there is less pressure of not rushing into making decisions, but it also allows for discussions to stall forever.
I also don't want people to come up with yet a new proposal every other week.

So I still would like us to have clear deadlines and timebox this whole succession process.

"clear" does not need to be "strict". What I will try to do is to post reminders here, a week before the expected "deadline" and ask if people need extensions, and we'll extend the dates accordingly. (similar to what Python release managers normally do).
But maybe the extension will be for only another one week or two, not forever.
What do people think about this?  

It seems like several people (Barry, Brett, Steven) and myself are ok with January 1, 2019 as the a deadline of choosing the successor.
For those opposing the deadlines, do you have a different date in mind? 

Here are my proposed timeboxes again, adjusted to AoE timezone, and including Barry's guidance of using PEP 8k+ number.
For each of the dates below, we will allow +1-2 weeks of flexibility.

Oct 1 AoE (2 months from now): Deadline of coming up with proposals of governance model. 

To be included in the proposal at the minimum:
- explanation and reasoning of the governance model
- expected roles and responsibilities
- candidate for the role need not be included at this time, since we're only choosing the governance model. Depending on the governance model chosen, we might have different people to be nominated. There will be a separate process for nominating the candidate. 
- the term of governance: is it for life? 5 years? 10 years?

Who can submit the proposal?
Python core developers. Individual core devs can submit a proposal, or co-author the proposal with another core dev. 

How to submit the proposal?
Proposal should be in a form of a PEP, numbered 8K+, and merged into peps repo by Oct 1 AoE. Proposals not merged after Oct 1 AoE will not be considered.

Oct 1 - Nov 15: Review period. (6 weeks)
All core developers will review the PEPs, and ask any questions to the PEP author. This timeline allows for enough time for all core devs to carefully review each PEPs, and for authors to respond.

In addition, if there is any governance PEP that comes before Oct 1 deadline, you can definitely start reviewing and discussing those. Oct 1 (+1-2 weeks) is just the cutoff for coming up with new proposals. 

There will be two parts of this:

Review phase 1: Oct 1- Nov 1 (1 month): Allow changes and tweaks to the proposed PEPs.
This is the period where people can ask questions or argue about the proposed PEPs.  Again, these dates are meant so you know when you need to start reading these PEPs, ask and answer questions in timely manner, and request one week extension if needed.

Review phase 2: Nov 1 - Nov 15 (2 weeks): No more changes to the above PEPs.
No more discussions. This is what I consider the "cool off" period. Questions and concerns were meant to be addressed in the previous phase. This is the final chance to carefully review all governance PEPs, and formulate your decisions.

Nov 15 AoE: Voting for new governance model starts, and will go for 2 weeks
Send reminders for folks to vote.

Who can vote:
Only core developers can vote.

Vote will be anonymous.
We will use the system used to elect PSF board members.


Dec 1 AoE: Voting ended.
The most voted proposal will be accepted.
Depending on the chosen governance model, we'll begin nominating candidates to fill the role(s). 

Dec 10 AoE Deadline for nominating candidates to fill the role
Maybe just one PEP to list all the nominations, instead of separate PEPs of each candidates.

Who can nominate: Python core developers
Who can be nominated: Python core developers

Dec 15 AoE Voting for new successor starts
(Depends on the governance model chosen on Dec 1)
Who can vote:
Only core developers can vote.

Vote will be anonymous.
We will use the system used to elect PSF board members.

Jan 1 AoE Voting for new successor ends. Most voted candidate(s) is chosen.


Mariatta