<div dir="auto">sometimes back after the event the BDFL1 said that "the new BDFL might be less demanding"<div dir="auto"><br></div><div dir="auto">hint to an imminent new one? i won't tell much the core devs (not all) have already shown their preferences</div><div dir="auto"><br></div><div dir="auto">fun fact: weirdly enough after BDFL1 took a vac (for life?), google made it's appearance on the mailing list</div><div dir="auto"><br></div><div dir="auto">THE NEED FOR CENTRAL AUTHORITY</div><div dir="auto"><br></div><div dir="auto">there is an absolute need for a central coordinator. the main threat to open source projects is politics. when you have someone to settle stuffs, fine you move on</div><div dir="auto"><br></div><div dir="auto">PROCEDURE OF ACCEPTANCE</div><div dir="auto"><br></div><div dir="auto">since BDFL1 is still alive, that saves the community some trouble. he is i presume aware of py-related stuffs and his choosing of a successor is a most viable option</div><div dir="auto"><br></div><div dir="auto">PREMISE OF CHOICE</div><div dir="auto"><br></div><div dir="auto">the choice should be made in consultation with the core devs as they are recognised members of the community based on their contributions. the core devs should orient the choice, they in themselves have not the power to veto, topple or reverse the decision. in the unlikely case of complete unfavouritism, the BDFL1 can pursue further</div><div dir="auto"><br></div><div dir="auto">CORE DEVS AS COMMITTEE</div><div dir="auto"><br></div><div dir="auto">the above hints to the core devs as a body in itself, beyond programming</div><div dir="auto"><br></div><div dir="auto">VALIDITY OF CHOICE</div><div dir="auto"><br></div><div dir="auto">the choice of BDFL1 must be acknowledged by the community. psf members should vote of whether they like the choice or not, fir it is the users who make the language valuable. by psf members, reference is made to the basic type of membership, open to all py programmers who have agreed to the psf rules. in case of non agreement, the process is to be repeated</div><div dir="auto"><br></div><div dir="auto">CRITICISM OF THE BDFLs BY FORMER AND LATTER ONES</div><div dir="auto"><br></div><div dir="auto">no BFFL shall criticise others. in case of non-acceptance of actions, a PHA shall be submitted</div><div dir="auto"><br></div><div dir="auto">PHA</div><div dir="auto"><br></div><div dir="auto">a Python Halt Appeal is a document submitted to the current core devs and the current BDFL to halt a specific activity considered "nuisible" to the growth and development of python. in case of majority acceptance of the core devs, it shall be accepted</div><div dir="auto"><br></div><div dir="auto">THE NEED FOR ALTERNATIVE NAMING OF DICTATOR OR EMPHASISING THE MEANING</div><div dir="auto"><br></div><div dir="auto">the python leader if he has absolute power should not be questioned or should not be made to back out as his appointment is by definition</div><div dir="auto"><br></div><div dir="auto">CITING THIS DOCUMENT / LICENSE</div><div dir="auto"><br></div><div dir="auto">this mail can be freely used, modified or built upon provided that attribution is made to the author in clear ways with no obfuscation whatsoever<br><br><div data-smartmail="gmail_signature" dir="auto">Abdur-Rahmaan Janhangeer<br><a href="https://github.com/Abdur-rahmaanJ">https://github.com/Abdur-rahmaanJ</a><br>Mauritius</div></div></div>