Mailman 3 September 2018 - python-committers

GitHub: remove the "needs backport to 3.5" label?
by Victor Stinner 20 Aug '19

20 Aug '19

Hi, Python 3.5 entered security fix only mode. Should we now remove the "needs backport to 3.5" label? Other security only branches don't have this label neither (3.3 and 3.4). Victor

6 11

Licences for PyCharm and other JetBrains products
by Vinay Sajip 17 Dec '18

17 Dec '18

Recently I received 20 one-year licenses from JetBrains for the PyCharm IDE (Professional) and other JetBrains products (the licenses cover their "All Products Pack") for use in Python development. There are 11 licenses available - of the licenses I asked for last year, nine people took them up, so those are in use and come out of the allocation of 20. Those of you who took up the licences last time should find that the tools continue to work normally. The licences expire on 27 November 2018. If any others of you are interested in using these licenses, let me know off-list and I will forward the license access details to you. To access the licenses, you will need to have (or create) a JetBrains account. Regards, Vinay Sajip

2 1

1 week to Oct 1
by Mariatta Wijaya 11 Oct '18

11 Oct '18

It is now 7 days until October 1, the deadline for coming up with Python Governance PEPs. Some still relevant links: - https://www.python.org/dev/peps/pep-8000/ Python Language Governance Proposal Overview - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process - https://www.python.org/dev/peps/pep-8002 Open source governance survey These are current ideas and proposals, some are placeholders still. - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model - https://www.python.org/dev/peps/pep-8011 The Council Governance Model (I'm claiming this PEP) - https://www.python.org/dev/peps/pep-8012 The Community Governance Model - https://www.python.org/dev/peps/pep-8013/ The External Council Governance Model - https://www.python.org/dev/peps/pep-8014/ The Commons Governance Model I have some questions: 1. Is everyone still ok with the Oct 1 as deadline for coming up with governance PEPs? 2. How do we discuss these PEPs? 3. At the sprint, there's a small workgroup formed for coming up with the procedure to vote. How is that coming? Could someone please write up a brief summary? (perhaps as a separate email thread) I think it would be great to have this written up soon, before Oct 1. Thanks. Mariatta ᐧ

12 28

python-committers is dead, long live discuss.python.org
by Łukasz Langa 09 Oct '18

09 Oct '18

Hello committers, since this got pretty long, here's the tl;dr: - we're at the point where it is hard to make mailing lists work for us; - we're switching to Discourse; it's better in many ways; - go to https://discuss.python.org/ <https://discuss.python.org/> and create your account there; - please do not post to python-committers for the remainder of the year to give Discourse a real shot. And now the long version. What's the issue? During the core sprint in Redmond we discussed how we discuss. The overwhelming feel is that we have reached the limits of what is possible with mailing lists. We identified e-mail as a contributor to some of the problems we're dealing with now. To fix more and whine less, I talked with everybody in Redmond about a possible replacement for the trusty mailing list. We identified one: Discourse. What is it? Discourse is forum software started in 2013 by Jeff Atwood, Robin Ward, and Sam Saffron. It's used by many large scale open source projects and companies, including Github Atom, Twitter Developers, Rust, Kotlin, Elixir, Docker, Codeacademy, Patreon, EVE Online, and Imgur. It's open source (Ruby, GPL2), it supports plugins and has an API. Why is it better than e-mail? It's both a Web app and a terrific mobile application. It supports regular flat conversational threads and collapsible replies. There is community moderation where users can flag inappropriate messages to notify moderators, moderators and authors can lock topics, move discussions between categories, archive things that are no longer applicable, and so on. You can edit posts, quote posts, link between posts, add rich media, code snippets with syntax highlighting, there's Markdown support. You can still use it via e-mail similarly to how GitHub notifications work. See: https://meta.discourse.org/t/set-up-reply-via-email-support/14003 <https://meta.discourse.org/t/set-up-reply-via-email-support/14003> There is a user trust system where proven community members get more power in time, for example to fix typos and move topics to a better category. There's much more: dynamic notifications, topic summaries, emojis, spam blocking, single sing-on, two-factor authentication, social login support, and so on. Read: https://meta.discourse.org/t/discourse-vs-email-mailing-lists/54298 <https://meta.discourse.org/t/discourse-vs-email-mailing-lists/54298>. What about Zulip? Zulip is chat software which some of us find useful but its UI is proving to be challenging for many of us, the mobile application leaves a lot to be desired, and it did not end up moving discussions out of the mailing lists. I see Zulip as replacement for IRC whereas Discourse is replacement for mailing lists (or both; we'll see!). Where do I sign up? Create an account at https://discuss.python.org/ <https://discuss.python.org/>. You'll recognize the set up as essentially mirroring the main mailing lists: - Committers - Users - Ideas There's also Discourse-specific sections: - Discourse Feedback (post here if things don't work like you'd like) - Discourse Staff (hidden category for moderators and admins of the instance, boring discussion) - Inquisition (hidden category for users with trust level 3+) As you can see, I combined python-committers and python-dev into just "Committers". If we find in the future that this is too limiting, we can always open up another category. For now though I'd like to avoid the fate of python-dev where there's 20k+ subscribers and we don't know who is who. CALL TO ACTION We'd like to heavily test this new forum. As such, I would like to ask you to NOT USE python-committers for the remainder of the year and direct all conversation to Discourse. The goal to replace the mailing lists with Discourse met unanimous support at the core sprint. As long as we don't identify any deal breakers in October, I will send an e-mail like this to python-dev on November 1st, and to python-list and python-ideas on December 1st. If everything goes smoothly, those four mailing lists will be archived by end of this year. Other mailing lists are welcome to port over to Discourse too. Acknowledgements Pablo and Ernest worked on setting up this instance for us (thank you both! 🖤). The question whether Discourse or the Python Software Foundation are going to pay for this infrastructure is still open but, as Elon Musk likes to say, funding is secured. Yury and I are helping in configuring the instance. Future work We'll be enabling GitHub and social logins soon, ideally with adding identified committers to the committers group by default. We are looking into this right now. In the mean time, please request membership, an existing member will add you. We'd like to migrate old discussion off of the mailing lists to our Discourse instance so that search is immediately useful. We'll look into that after the governance crisis is resolved. - Ł

24 64

[PEP 8013] The External Council Governance Model
by Steve Dower 29 Sep '18

29 Sep '18

Here is the text of PEP 8013 for discussion and improvement (in isolation from the other proposals, of course -- we're not ready for the shoot-out yet.) I'm keen to see the model be considered, but I don't feel the need to tightly control the specific content in the PEP, so feel free to send your own PRs if you have definitive improvements. For the next few days I'm also going to have varying amounts of ability to read and respond to email. I'll try and catch up by the weekend or early next week. Rendered version at: https://www.python.org/dev/peps/pep-8013/ --- PEP: 8013 Title: The External Council Governance Model Author: Steve Dower <steve.dower(a)python.org> Status: Draft Type: Informational Content-Type: text/x-rst Created: 2018-09-14 Abstract ======== This PEP proposes a new model of Python governance based on a Group of Unbiased Independent Directors of Order (GUIDO) tasked with making final decisions for the language. It differs from PEP 8010 by specifically not proposing a central singular leader, and from PEP 8011 by disallowing core committers from being council members. It describes the size and role of the council, how the initial group of council members will be chosen, any term limits of the council members, and how successors will be elected. It also spends significant time discussing the intended behaviour of this model. By design, many processes are not specified here but are left to the people involved. In order to select people who will make the best decisions, it is important for those involved to understand the expectations of GUIDO but it is equally important to allow GUIDO the freedom to adjust process requirements for varying circumstances. This only works when process is unspecified, but all participants have similar expectations. This PEP does *not* name the members of GUIDO. Should this model be adopted, it will be codified in PEP 13 along with the names of all officeholders described in this PEP. Open Discussion Points ====================== Some suggestions in this document are currently weak suggestions, and are open to change during the discussion period. These include: * We can change the name of the group. "Council of Auditors" is the suggested alternative, though "Python Inquisition" is very tempting if we believe we can be clear about the source of the name [1]_ * We can change voting procedures, timelines, and tie-breakage rules The Importance of the Grey Area =============================== In any actual decision-making process, there is going to be grey area. This includes unexpected scenarios, and cases where there is no "correct" answer. Many process plans attempt to minimise grey area by defining processes clearly enough that no flexibility is required. This proposal deliberately goes the other way. The aim is to provide a robust framework for choosing the best people to handle unexpected situations, without defining how those people should handle those situations. Examples are provided of "good" responses to some situations as an illustration. The hope is that the "best" people are the best because they would live up to those examples. The process that is proposed has been designed to minimise the damage that may be caused when those people turn out not to be the best. Grey area is guaranteed to exist. This proposal deliberately embraces and works within that, rather than attempting to prevent it. Model Overview ============== Key people and their functions ------------------------------ The Group of Unbiased Independent Directors of Order (GUIDO) is a council of varying size, typically two to four people, who are elected for the duration of a Python release. One member of GUIDO is considered the President, who has some minor points of authority over the other members. GUIDO has responsibility for reviewing controversial decisions in the form of PEPs written by members of the core development team. GUIDO may choose to accept a PEP exactly as presented, or may request clarification or changes. These changes may be of any form and for any reason. This flexibility is intentional, and allows the process to change over time as different members are elected to GUIDO. See the later sections of this document for examples of the kinds of requests that are expected. GUIDO only pronounces on PEPs submitted to python-committers. There is no expectation that GUIDO follows or participates on any other mailing lists. (Note that this implies that only core developers may submit PEPs. Non-core developers may write and discuss proposals on other mailing lists, but without a core developer willing to support the proposal by requesting pronouncement, it cannot proceed to acceptance. This is essentially the same as the current system, but is made explicit here to ensure that members of GUIDO are not expected to deal with proposals that are not supported by at least one core developer.) GUIDO may not delegate authority to individuals who have not been elected by the core developer team. (One relevant case here is that this changes the implementation of the existing BDFL-Delegate system, though without necessarily changing the spirit of that system. See the later sections for more discussion on this point.) The Release Manager (RM) is also permitted the same ability to request changes on any PEPs that specify the release they are responsible for. After feature freeze, the RM retains this responsibility for their release, while GUIDO rotates and begins to focus on the subsequent release. This is no different from the current process. The process for selection of a RM is not changed in this proposal. Core developers are responsible for electing members of GUIDO, and have the ability to call a "vote of no confidence" against a member of GUIDO. The details of these votes are discussed in a later section. Where discussions between core developers and members of GUIDO appear to be ongoing but unfruitful, the President may step in to overrule either party. Where the discussion involves the President, it should be handled using a vote of no confidence. Members of GUIDO may choose to resign at any point. If at least two members of GUIDO remain, they may request a new election to refill the group. If only one member remains, the election is triggered automatically. (The scenario when the President resigns is described in a later section.) The intended balance of power is that the core developers will elect members of GUIDO who reflect the direction and have the trust of the development team, and also have the ability to remove members who do not honour commitments made prior to election. Regular decision process ------------------------ Regular decisions continue to be made as at present. For the sake of clarity, controversial decisions require a PEP, and any decisions requiring a PEP are considered as controversial. GUIDO may be asked to advise on whether a decision would be better made using the controversial decision process, or individual members of GUIDO may volunteer such a suggestion, but the core development team is not bound by this advice. Controversial decision process ------------------------------ Controversial decisions are always written up as PEPs, following the existing process. The approver (formerly "BDFL-Delegate") is always GUIDO, and can no longer be delegated. Note that this does not prevent GUIDO from deciding to nominate a core developer to assess the proposal and provide GUIDO with a recommendation, which is essentially the same as the current delegation process. GUIDO will pronounce on PEPs submitted to python-committers with a request for pronouncement. Any member of GUIDO, or the current RM, may request changes to a PEP for any reason, provided they include some indication of what additional work is required to meet their expectations. See later sections for examples of expected reasons. When all members of GUIDO and the RM indicate that they have no concerns with a PEP, it is formally accepted. When one or more members of GUIDO fail to respond in a reasonable time, the President of GUIDO may choose to interpret that as implied approval. Failure of the President to respond should be handled using a vote of no confidence. Election terms -------------- Members of GUIDO are elected for the duration of a release. The members are elected prior to feature freeze for the previous release, and hold their position until feature freeze for their release. Members may seek re-election as many times as they like. There are no term limits. It is up to the core developers to prevent re-election of GUIDO members where there is consensus that the individual should not serve again. Election voting process ------------------------ The election process for each member of GUIDO proceeds as follows: * a nomination email is sent to python-committers * a seconding email is sent * the nominee is temporarily added to python-committers for the purpose of introducing themselves and presenting their position * voting opens two weeks prior to the scheduled feature freeze of the previous release * votes are contributed by modifying a document in a private github repository * each core developer may add +1 votes for as many candidates as they like * after seven days, voting closes * the nominee with the most votes is elected as President of GUIDO * the next three nominees with the most votes and also at least 50% the number of votes received by the President are elected as the other members of GUIDO * where ties need to be resolved, the RM may apply one extra vote for their preferred candidates * accepted nominees remain on python-committers; others are removed No-confidence voting process ---------------------------- A vote of no confidence proceeds as follows: * a vote of no confidence email is sent to python-committers, naming the affected member of GUIDO, justifying the nomination, and optionally listing accepted PEPs that the nominator believes should be reverted * a seconding email is sent within seven days * the nominated member of GUIDO is allowed seven days to respond, after which the nominator or the seconder may withdraw * if no nominator or seconder is available, no further action is taken * voting opens immediately * each core developer may add a +1 vote (remove the GUIDO member) or a -1 vote (keep the GUIDO member) by modifying a document in a private github repository * after seven days, voting closes * if +1 votes exceed -1 votes, the GUIDO member is removed from python-committers and any nominated PEPs are reverted * if requested by the remaining members of GUIDO, or if only one member of GUIDO remains, a new election to replace the removed member may be held following the usual process. * in the case of removing the President of GUIDO, the candidate who originally received the second-most votes becomes President Examples of intended behaviour ============================== This section describes some examples of the kind of interactions that we hope to see between GUIDO and the core developers. None of these are binding descriptions, but are intended to achieve some consensus on the types of processes we expect. GUIDO candidates may campaign on the basis of whatever process they prefer, and core developers should allocate votes on this basis. Scenario 1 - The Case of the Vague PEP -------------------------------------- Often in the past, initial proposals have lacked sufficient detail to be implementable by anyone other than the proposer. To avoid this, GUIDO should read proposals "fresh" when submitted, and without inferring or using any implied context. Then, when an aspect of a PEP is not clear, GUIDO can reject the proposal and request clarifications. Since the proposal is rejected, it must be modified and resubmitted in order to be reviewed again. GUIDO will determine how much guidance to provide when rejecting the PEP, as that will affect how many times it will likely be resubmitted (and hence affect GUIDO's own workload). This ensures that the final PEP text stands alone with all required information. Scenario 2 - The Case of the Endless Discussion ----------------------------------------------- From time to time, a discussion between Python contributors may seem to be no longer providing value. For example, when a large number of emails are repeating points that have already been dealt with, or are actively hostile towards others, there is no point continuing the "discussion". When such a discussion is occurring on python-committers as part of a request for pronouncement, a member of GUIDO should simply declare the thread over by rejecting the proposal. In most known cases, discussion of this sort indicates that not all concerns have been sufficiently addressed in the proposal and the author may need to enhance some sections. Alternatively, and in the absence of any rejection from the other members of GUIDO, the President may declare the thread over by accepting the proposal. Ideally this would occur after directly confirming with the rest of GUIDO and the RM that there are no concerns among them. When such a discussion is occurring on another list, members of GUIDO should be viewed as respected voices similar to other core developers (particularly those core developers who are the named experts for the subject area). While none have specific authority to end a thread, preemptively stating an intent to block a proposal is a useful way to defuse potentially useless discussions. Members of GUIDO who voluntarily follow discussions other than on python-committers are allowed to suggest the proposer withdraw, but can only actually approve or reject a proposal that is formally submitted for pronouncement. Scenario 3 - The Case of the Unconsidered Users ----------------------------------------------- Some proposals in the past may be written up and submitted for pronouncement without considering the impact on particular groups of users. For example, a proposal that affects the dependencies required to use Python on various machines may have an adverse impact on some users, even if many are unaffected due to the dependencies being typically available by default. Where a proposal does not appear to consider all users, GUIDO might choose to use their judgement and past experience to determine that more users are affected by the change than described in the PEP, and request that the PEP also address these users. They should identify the group of users clearly enough that the proposer is able to also identify these users, and either clarify how they were addressed, or made amendments to the PEP to explicitly address them. (Note that this does not involve evaluating the usefulness of the feature to various user groups, but simply whether the PEP indicates that the usefulness of the feature has been evaluated.) Where a proposal appears to have used flawed logic or incorrect data to come to a certain conclusion, GUIDO might choose to use other sources of information (such as the prior discussion or a submission from other core developers) to request reconsideration of certain points. The proposer does not necessarily need to use the exact information obtained by GUIDO to update their proposal, provided that whatever amendments they make are satisfactory to GUIDO. For example, a PEP may indicate that 30% of users would be affected, while GUIDO may argue that 70% of users are affected. A successful amendment may include a different but more reliable percentage, or may be rewritten to no longer depend on the number of affected users. References ========== .. [1] The Spanish Inquisition, `<https://youtu.be/Ixgc_FGam3s>`_ Copyright ========= This document has been placed in the public domain.

3 3

Python 4.0 or Python 3.10?
by Yury Selivanov 28 Sep '18

28 Sep '18

What's the current plan for what version of Python we release after 3.9? The reason I'm asking this is because I frequently need to refer to *that version* of Python in the documentation, especially when I'm deprecating APIs or behavior. Right now I'm saying "Python 4.0" implying that 4.0 will be released right after 3.9. I've heard multiple opinions on this subject. One of them is that we should release 4.0 when we have a major new change, like removal of the GIL or introduction of a JIT compiler. On the other hand, we have no estimate when we have such a change. We also don't want Python 4.0 to be backwards incompatible with Python 3.0 (at least not at the scale of 2 vs 3). So to me, it seems logical that we simply release Python 4.0 after Python 3.9. After all, after 3.9 Python will be drastically different from 3.0 and from 2.7. It sounds better. :) Finally, I'm not sure we need a new governance in place to make this decision or maybe we can make it now. That's why I'm posting this to python-committers to see if core devs already have a consensus on this. Yury

17 27

[RELEASE] Python 3.7.1rc1 and 3.6.7rc1 now available for testing
by Ned Deily 26 Sep '18

26 Sep '18

Python 3.7.1rc1 and 3.6.7rc1 are now available. 3.7.1rc1 is the release preview of the first maintenance release of Python 3.7, the latest feature release of Python. 3.6.7rc1 is the release preview of the next maintenance release of Python 3.6, the previous feature release of Python. Assuming no critical problems are found prior to 2018-10-06, no code changes are planned between these release candidates and the final releases. These release candidates are intended to give you the opportunity to test the new security and bug fixes in 3.7.1 and 3.6.7. We strongly encourage you to test your projects and report issues found to bugs.python.org as soon as possible. Please keep in mind that these are preview releases and, thus, their use is not recommended for production environments. You can find these releases and more information here: https://www.python.org/downloads/release/python-371rc1/ https://www.python.org/downloads/release/python-367rc1/ -- Ned Deily nad(a)python.org -- []

1 0

Fw: CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause)
by Antoine Pitrou 25 Sep '18

25 Sep '18

Hi, I'm choosing to forward this to python-committers because I don't think python-ideas is a reasonable place to discuss CoC decisions. I think the action taken by Brett (apparently decided with Titus and a mysterious "conduct working group") is not the right one: - a definitive ban is an extremely strong decision that should only be taken if nothing else works. May I remind that Anatoly was able to post prolifically and unconstructively for several years, being warned several times, before being finally banned? Comparatively, this one ban seems expeditive. - the reasons given, to me, don't make sense at all. The word "n-----" is not a forbidden word if you want to describe, precisely, linguistics and the relativity of meanings (instead of actually *qualifying* someone or a groupe of people), which is what the OP claimed to do. The other reasons look like a similar kind of over-reaction. Even if something there looks inappropriate to you, it's still enough of a grey area that a ban is absolutely the wrong answer. I deduce that it's ok to say "slave" in a discussion instead of using an expression such as "the s-word". Why one term is allowed and the other, not, may be clear to Americans (or, perhaps, a large fraction thereof), but hey, it's not clear to other people around the world. Banning a (apparently) Dutch person because he doesn't understand American standards of offense is not only unfair, but it makes our community *not* inclusive of other cultures. As a French person myself, I could not, even if I wanted to, turn myself into an authentic American: what is obvious to you is not obvious to me and it would be extremely brutal and humiliating to ban me for having the wrong nationality and the wrong culture. I will ask: please consider the work and effort that it *already* takes for other people to adapt to standards of discussion that are, obviously, those of a particular culture. Otherwise you're raising barriers even more, not lowering them. At the end of it, it looks like we have a real moderation problem. python-ideas threads frequently veer out into unconstructive back-and-forths (and, well, that's not *only* the ethically-sensitive threads). The CoC is being applied erratically, sometimes precipitately, by apparently overworked and emotionally exhausted moderators, with bad consequences on the quality of the decisions. Moderators should not become emotionally exhausted (which means we need a more adequate discussion system *and* a more collegial, spread out, team of moderators); and, if they become so, I would humbly suggest it's a better idea - even if not always easy to follow - to step back and take some rest than make decisions in such a state. We also need real guidelines to the moderators as to which decision on the scale of possible decisions to apply, depending on severity of the offense / violation and on the "offendor"'s past behaviour. In the end, I hope we can set ourselves better moderation standards. As for me, I find the current situation very worrying, including for my ability to contribute constructively to Python. If I have to fear banning for every word that I say and that might be deemed inappropriate in the moderators' culture, I might just as well leave instead of feeling stressed and anguished everytime I post something. I would not want to live this in paid work: why would I endure it as a volunteer, while my main gratification should be the pleasure taken in contributing? Regards Antoine. ----- Message Transféré ----- Date : Thu, 20 Sep 2018 11:56:05 -0700 De : Brett Cannon <brett-+ZN9ApsXKcEdnm+yROfE0A(a)public.gmane.org> À : Jacco van Dorp <j.van.dorp-i74+SDIRvn1mR6Xm/wNWPw(a)public.gmane.org> Cc : python-ideas <python-ideas-+ZN9ApsXKcEdnm+yROfE0A(a)public.gmane.org> Groupe de discussion : gmane.comp.python.ideas Sujet : CoC violation (was: Retire or reword the "Beautiful is better than ugly" Zen clause) The below email was reported to the PSF board for code of conduct violations and then passed on to the conduct working group to decide on an appropriate response. Based on the WG's recommendation and after discussing it with Titus, the decision has been made to ban Jacco from python-ideas. Trivializing assault, using the n-word, and making inappropriate comments about someone's mental stability are all uncalled for and entirely unnecessary to carry on a reasonable discourse of conversation that remains welcoming to others.

15 34

bpo triage privileges for Karthikeyan Singaravelan
by Zachary Ware 23 Sep '18

23 Sep '18

On the recommendation of Ammar Askar and with Serhiy's endorsement on Zulip [0], I've given Karthikeyan Singaravelan (CC'd) triage privileges on bugs.python.org. Karthikeyan, please use your new-found powers for good, and don't hesitate to ask for guidance if you need it. Keep up the good work, and thank you! [0] https://python.zulipchat.com/#narrow/stream/116501-workflow/subject/bug.20t… -- Zach

2 1

Fwd: [Python-ideas] JS’ governance model is worth inspecting
by Guido van Rossum 21 Sep '18

21 Sep '18

Perhaps worth including in PEP 8002, the overview of other governance models? (Though the process described here seems to be JS's equivalent of our PEP process -- it doesn't say anything about how TC39 gets formed or how non-technical decisions are handled.) ---------- Forwarded message --------- From: James Lu <jamtlu(a)gmail.com> Date: Fri, Sep 21, 2018 at 4:25 AM Subject: [Python-ideas] JS’ governance model is worth inspecting To: <python-ideas(a)python.org> JS’ decisions are made by a body known as TC39, a fairly/very small group of JS implementers. First, JS has an easy and widely supported way to modify the language for yourself: Babel. Babel transpires your JS to older JS, which is then run. You can publish your language modification on the JS package manager, npm. When a feature is being considered for inclusion in mainline JS, the proposal must first gain a champion (represented by 🚀)that is a member of TC-39. The guidelines say that the proposal’s features should already have found use in the community. Then it moves through three stages, and the champion must think the proposal is ready for the next stage before it can move on. I’m hazy on what the criterion for each of the three stages is. The fourth stage is approved. I believe the global TC39 committee meets regularly in person, and at those meetings, proposals can advance stages- these meetings are frequent enough for the process to be fast and slow enough that people can have the time to try out a feature before it becomes main line JS. Meeting notes are made public. The language and its future features are discussed on ESDiscuss.org, which is surprisingly filled with quality and respectful discussion, largely from experts in the JavaScript language. I’m fairly hazy on the details, this is just the summary off the top of my head. — I’m not saying this should be Python’s governance model, just to keep JS’ in mind. _______________________________________________ Python-ideas mailing list Python-ideas(a)python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/ -- --Guido van Rossum (python.org/~guido)

2 1

3.7.1 and 3.6.7 Releases Coming Soon
by Ned Deily 21 Sep '18

21 Sep '18

I have updated the schedules for the next maintenance releases of Python 3.7.x and 3.6.x. My original plan had been to get 3.7.1, the first 3.7 maintenance release, out by the end of July. It was solely my fault that that did not happen so I hope you'll accept my apologies; I will try to not let it happen again. I have now scheduled a 3.7.1 release candidate and rescheduled the 3.6.7 release candidate for 2018-09-18, about a week from today, and 3.7.1 final and 3.6.7 final for 2018-09-28. That allows us to take advantage of fixes generated at the Core Developers sprint taking place this week. Please review any open issues you are working on or are interested in and try to get them merged in to the 3.7 and/or 3.6 branches soon - by the beginning of next week at the latest. As usual, if there are any issues you believe need to be addressed prior to these releases, please ensure there are open issues for them in the bug tracker (bugs.python.org) and that their priorities are set accordingly (e.g. "release blocker"). Thanks for your support! --Ned -- Ned Deily nad(a)python.org -- []

2 3

Recent buildbot.python.org changes
by Zachary Ware 20 Sep '18

20 Sep '18

Hi all, Most of my effort this week has gone into improving the state of buildbot.python.org, which has largely gone into improving Buildbot itself. Here are the relevant highlights: - Anyone can now log into buildbot.python.org via GitHub by clicking the 'Anonymous' dropdown in the upper right corner, then 'Login with GitHub'. The first time, GitHub will ask you for approval; subsequently you'll just be logged right in. - Stopping builds and triggering rebuilds is now restricted to members of the `python-core` team and the "owner" of a build. I've not had opportunity to test whether the author of a commit actually qualifies as the "owner" or if only the committer does, but if anyone runs into trouble with it please open an issue on the buildmaster-config repo. - Disabling/enabling schedulers is now restricted to members of the `python-release-managers` team. We had an issue some months ago where someone had apparently disabled the scheduler for one of our branches, resulting in no builds on that branch for several days before we noticed. That shouldn't happen again! - Buildbot now reports results from our stable builders on each tested commit. For now, we're still only running tests post-merge, so you won't see new status checks on PRs, but you can find results on https://github.com/python/cpython/commits/ Let me know if any of these changes negatively impact you, or if you have suggestions for further improvement. Regards, -- Zach

6 5

New core developers: Lisa Roach and Emily Morehouse-Valcarcel
by Raymond Hettinger 20 Sep '18

20 Sep '18

At the developer sprints this week, we collectively decided to grant core committer status to Emily and Lisa. Please join me in welcoming them to the team. Raymond ------------------------------- Emily is the Director of Engineering at Cuttlesoft. She has previously attended two Language Summits and three core development sprints at PyCon. Since July, Emily has worked with Guido's guidance to implement PEP 572, Assignment Expressions. She has also worked with Eric Snow to dive into CPython's runtime as well as subinterpreters. This year at PyCon she gave a talk on Python's AST. Here is her speaker bio https://us.pycon.org/2018/speaker/profile/283/ and a link to her talk video: https://www.youtube.com/watch?v=XhWvz4dK4ng Lisa has a background in network engineering and supported the Cisco sale engineer team to develop high quality Python product demonstrations. Later she moved to the Facebook security team. This is her third core developer sprint. She and Guido are co-authors of PEP 526, Syntax for Variable Annotations. Last year, she worked with Eric Smith on PEP 557, Data Classes. Here is her speaker bio https://us.pycon.org/2018/speaker/profile/824/ and a link to her Pycon talks: https://www.youtube.com/watch?v=hKxbO4rRlpg and https://www.youtube.com/watch?v=ww1UsGZV8fQ

18 17

Azure Pipelines Linux failures on PRs
by Steve Dower 20 Sep '18

20 Sep '18

Hi all Just a heads-up that the Azure Pipelines build failures for Linux machines are a known issue that should be fixed by the end of the week. It seems the service has become so popular since last week's announcements that many more builds are being run on machines that have been freshly imaged, and so they are racing with a background 'apt update' command. This causes an explicit 'apt update' to (correctly) fail to acquire its lock. I believe it's also related to the move from running builds within Docker containers to actual VMs, which happened around the same time. Until it's fixed, feel free to ignore the Azure Pipelines status for Linux builds. Apologies for the inconvenience with backports not auto-merging. Cheers, Steve

1 0

Governance Discussion #2 Notes
by Steve Dower 15 Sep '18

15 Sep '18

Hi all At the sprints this last week, probably unsurprisingly, we had some discussions relating to the future of Python's governance. Since not everyone could be involved, I'm going to be posting the notes from these meetings (taken by an independent note-taken, and reviewed/redacted by the participants before being made public). I want to be very clear that no final decisions were made at these meetings, but they were very helpful in helping those of us working on concrete proposals. You should start seeing PEPs 80xx filling out with content over the next few weeks. *Those* are the reference documents - these notes are simply a record of what came out of discussions. If you want to reply to and discuss particular points from these, *please* reply to the list, change the subject line, and clearly quote only the relevant part. There is a lot of content here and nothing to be gained by repeating it endlessly. (Also, if you want to thank me for copy-pasting into an email, it really is unnecessary but please do it off-list. We've already passed on our thanks to the note-taker as well.) For this second meeting, we reduced the audience to those particularly interested in the governance models. We had four represented there, which will be written up as PEPs 8010, 8011, 8012 and 8013 over the next few weeks. I have inserted links to the current drafts of these in the notes, though at this stage they are mostly still placeholders. Again, the proposals that we will vote on will be accurately described in the PEPs. the notes here are basically inaccurate summaries of the discussion, but we are sharing the notes to help everyone get a sense of what values we are thinking about when designing proposals, and the aspects of Python development that we like and the ones we want to change. This is not the thread to start arguing about details - if anything in this email makes you upset or nervous, please assume that the email is at fault and wait for the actual proposals. Cheers, Steve --- The previous meeting showed that there were three main areas of concern: * What do we want the culture of the team to be? * How do we want to interact with each other and with the larger Python community? * How can we build a system that encourages those interactions? * Example: if we don't use a mailing list, what do we use? * What's the five year plan of python? * How do we decide on a governance model? These are deeply interrelated questions; notes that follow attempt to summarize various contributor's points: * The answers to the first two questions can be determined by the new governance, whatever that is. * We must quickly get away from the perception that Python is leaderless. * We need specific structures, with specific people. * Both those structures and the people must be selected by a process that is perceived to be fair and open, without all our energy being consumed by debate about minutia. * It will be difficult to decide anything else until there is a clear leadership structure. * If we have multiple people who want a focus on async, or on performance, or on typing, we need some way to resolve what should be the focus for the next five years. * These all influence each other. "Where do we want Python to go?" is very germane to "what should the leadership model be?" * We can end up in a rathole. Can we identify constituencies that we want to serve? Education, science, kids, whatever. The structure is less important than choosing a structure and working towards goals that serve constituencies within that structure. * Governance is also heavily tied to communication: how do we make mundane decisions, how do we resolve controversies? This is all about communication. Other languages have specified details of their communication models in their governance arrangement: we put our notes here, we communicate with this channel, and so on * There may be different decision-making and communication models for different areas. * If you have a BDFL, do they take on everything Guido took on? Or are they the titular spokesperson who interfaces with the public, and delegates other decisions to committees? * Having no governance model is worse than having a suboptimal model. * The US Constitution was written knowing that the first order of business would be the Bill of Rights. * What is our list of things that we know we need to deal with as soon as we have a governance model? * Deciding how to commit to a governance model has highest priority. * Our goal should be to achieve general consensus on what looks like a fair voting model before we vote. * Wherever we end up at the end, we want the leadership to be perceived as legitimate and backed by the community. * The greater good is more important than any particular desired detail. * The governance model has to be backed by goodwill. * Should we first determine where Python is going, in order to ensure that the governance model supports it? * "I disagree with the details but I support the process" should be the goal * Python's governance model has been an active, top-down decision maker; most open source projects have a much more hands-off steering council. Split Guido's current roles across both formal, hands-off top-down model, and an organic, bottom-up community based model. * Do we know who wants to take a leadership role? * Are there people who want to actively be involved as a BDFL, a triumvirate, a council, and so on? * If we only have one volunteer for BDFL, this is a waste of time. * Triumvirates form as a mechanism for resolving conflict amongst leaders. * What if no one wants to step into a leadership role? * More people will be involved in lesser roles. * We can probably find five people who want to be involved in a council. * But perhaps nothing will happen with a leadership group of that size. * What about looking at it the other way: who will go along with whatever structure gets put in place? * Those people are contributors, not leaders, and they don't have to be involved in the discussion. * Three main proposals: (1) BDFL with advisory council and working groups model. (2) No BDFL, steering committee of say three people. (3) pure democracy, community driven, only working groups. * Can we aim for initial draft PEPs October 1st? * Each of these can be parameterized * If no one is interested enough to even write a proposal, we can reject it. * A rejection of a specific proposal is not an endorsement of its opposite. * Roles granted in perpetuity? Or a cycle? * This question should go into a session * These are parameters to the proposals -------------------------------------------------- Follow up two: Champion your ideas But remember this is not a competition; this is about doing what's best for Python Quick summary of earlier voting discussion: restricted to core developers who currently have commit bit (or who have commit bit by end of this week) ask people who are not affected by the decision to abstain private repo to post votes * votes will be made public after; this is not an anonymous vote * voting for individual positions later will likely be anonymous * this system encourages dialog * many people are fine with any of the proposed options but they have opinions about what is best * a public process helps avoid backroom complaining * it seems acceptable to have public vote on governance issues * quorum is whoever shows up to vote * 50% + 1. Supermajority is only 14 people more, so seems unnecessary * there are only 93 people in the set of possible voters *When creating proposals that involve a BDFL, or other role, do not name a person or group of people. Name a mechanism for choosing that person or group of people. *Put in as many specifics as necessary to make your proposal attractive *The constitution of the united states says how to update itself; do the same in a governance proposal. Proposal One: No BDFL, all democracy all the time PEP 8012 - https://www.python.org/dev/peps/pep-8012/ * Inspired by Rust and Django * Working groups are self-selected from people interested in focus areas * Non-experts in an area trust that experts will do well in an area * Regular decision making process is mostly "go ahead and do it" * Controversial decisions require a process with documented phases: make a PEP, find a champion, get comments, set a deadline, decide on whether it is accepted, rejected or postponed * How does veto work? Put it to a vote. * The "voice of Python" is expressed not by a person, but by the design documents produced * If you don't want assignment expressions, vote for my proposal Proposal Two: external auditors PEP 8013 - https://www.python.org/dev/peps/pep-8013/ * Working groups should continue to go forward — the people who are working on a specific PEP, and not necessarily core developers. * Normal decision process should continue * Controversial decisions should be taken to an elected group of three people who are NOT core developers who are arbiters of process concerns. Call them the auditors. * Appointed for how long? A year? Years? A release? This is a parameter. * No term limit; you can be re-elected * Not a developer; an escalation mechanism for when developers cannot reach consensus * Every time you take a controversial decision to the auditors, you have to explain the problem in detail well enough to convince them that you've done due diligence about design, user impact, and so on. * Auditors can veto controversial decisions until there is enough diligence done * Auditors can require that a decision goes to a vote if it is still controversial * Auditors can require that more people weigh in * Auditors cannot mess things up by proposing new bad stuff; they can only slow down (hopefully bad) decisions * We have a list of names of notable people who would be great at this; whether they'd be willing is another question * Microsoft would offer employees for this role, but maybe core developers are opposed to corporate influence Proposal Three: Trivumvirate of core developers PEP 8011 - https://www.python.org/dev/peps/pep-8011/ * a similar scheme to Proposal Two, but where the triumvirate must be core developers * We are too used to the BDFL model and may be worried to change it * Should be a diverse group of three people who can work together. * These people must be trusted; if that trust breaks down then we have a crisis — but of course we can always change the governance model if this doesn't work * Elected for longer than a year; semi permanent * Role similar to previous BDFL, but with multiple people coming to consensus. Proposal Four: Find another BDFL PEP 8010 - https://www.python.org/dev/peps/pep-8010/ * Elect a BDFL * Continue with working groups * Create a council as an advisory group to the BDFL, help find delegates, and so on * The BDFL has a broad view of the python ecosystem, and weigh in on large scale changes, say to the grammar, or changes that have broad impact, like deciding between performance and compatibility. * Must be seen as "the voice of Python" * The BDFL champions the overall vision of the evolution of the language, with the support of the community * "For life" is a misnomer. There should be a recall process or vote of no confidence. * Release manager has an important advisory role Thoughts: * These proposals are consistent in that most of the work is done in informal groups, there is some sort of leadership council who ensures that processes are followed. * The working group and PEP process is pretty much the same in all these proposals * The fundamental differences are in who has authority: (1) no authority, self-policing, (2) authority over process vested in non-developers, (3) authority vested in a group of developers and (4) one BDFL * We can always make a decision, try it, and if it doesn't have good outcomes, have this conversation again in two years * Consider the role of release manager in all of these; they have a lot of power in that they can file a release-blocking bug against stuff they don't like * Are there issues with how we induct/vote in new core developers? * Individual working groups are autonomous and have authority to decide who is core to their working group * How do we solve controversial issues? Take it to a vote, take it to auditors, take it to the BDFL. * Do we have examples of community-based open-source projects that are run using proposal 2? No. But we have lots of examples of that model in business-run projects, non-profit-run projects, and so on. * There are examples of members of technical committees secretly proposing features and then approving them, sock puppeting, and so on. We would want to avoid that. Similarly a BDFL will need to appoint a delegate if they are also proposing PEPs, and so on. * Need a graceful way for a leader to step down when their life requires them to do so. Burnout is real and insidious. * Be aware of conflicts of interest, double dealing. Financial self dealing is probably not a problem for us. * How do we ensure consistency in decision making? * Excessive churn in leadership works against this. * Having a set of core principles will help. * Election campaigning for leadership roles is a mechanism for people to choose direction. * Would be helpful if every PEP had a core developer to sponsor it. Particularly if final approval moves to python core devs.

1 0

Governance Discussion #1 Notes
by Steve Dower 15 Sep '18

15 Sep '18

Hi all At the sprints this last week, probably unsurprisingly, we had some discussions relating to the future of Python's governance. Since not everyone could be involved, I'm going to be posting the notes from these meetings (taken by an independent note-taken, and reviewed/redacted by the participants before being made public). I want to be very clear that no final decisions were made at these meetings, but they were very helpful in helping those of us working on concrete proposals. You should start seeing PEPs 80xx filling out with content over the next few weeks. *Those* are the reference documents - these notes are simply a record of what came out. If you want to reply to and discuss particular points from these, *please* reply to the list, change the subject line, and clearly quote only the relevant part. There is a lot of content here and nothing to be gained by repeating it endlessly. (Also, if you want to thank me for copy-pasting into an email, it really is unnecessary but please do it off-list. We've already passed on our thanks to the note-taker as well.) For this first meeting, roughly 30 of us sat/stood in a circle and briefly answered two questions: * what are you most concerned about right now? * in one word, what do you like most about Python? These notes are an anonymised, paraphrased, reorganised summary of the responses. Responses that deserved an immediate follow up have (as far as I'm aware) received it already. So take this as a bit more insight into community sentiment than could otherwise be obtained over email, but as nothing more significant than that. Cheers, Steve --- Python's Benevolent-Dictator-For-Life (BDFL) Guido has stepped down, which raises the question of how Python's core development team should proceed when making decisions about changes to Python. The attendees of the sprint had a meeting to sit down and all concisely express their biggest concerns. I took notes as people were speaking; hopefully I captured the gist of what they were saying if not their exact words. I'll start with a quick summary and the plan for immediate next steps, and then give individual points loosely grouped by broad area of concern. Executive summary: The biggest areas of concern are: * Choosing how to choose a new governance model * The principles that will guide the future of python * Effective, respectful communication and related social factors * related: Code of conduct issues, which already have a PSF working group looking into them. We went around the room and asked people to give a one or two word summary of what they like about Python. * community * people * elegance * consistency * ease for non-experts * good taste * accessibility * opportunity * productivity * trust * zen * fun * openness * thoughtfulness * Monty :-) Next steps: * Digest what we've discussed overnight * Meet in the morning and organize by areas of particular concern * Discuss further * Report back Specific concerns raised by individuals follow. These have been anonymized and rearranged, and are individual contributions and do not reflect any official position, or even necessarily a majority position of the core development team. Introductory thoughts: * Complexity is real * Any number of plans could work * What behaviours help communities be effective? * Which produce roadblocks and challenges? * What do we value about Python? Choosing how to choose: * There will be various proposals for governance models. How do we pick one? Can we get to consensus on that? * There's a PEP out to discuss how this process works in other languages. * Vote on a committee that makes governance recommendations * Give a small group of people a mandate to study and make recommendations * Can we determine what are roles that need to be filled? * Do not get bogged down in the meta-question of how to choose how to choose. * Any important change requires a working group of experts in the specific area affected by the change. How to choose members of this group? * Can we define the scope of problems that we need to bring to a higher authority? * Having working groups with autonomy is great, but there will be things where all the threads come together. Changes to the C API, changes to the core syntax. * We have always appealed to Guido's sensibilities, and that's where the power vacuum is now. Think about something like the Debian technical committee, where they make decisions that affect everyone in that community. * Some people will be unhappy with whatever decision is made, but we want people to agree that there is a clear authority and a process that is respected and legitimate. * Our existing model has BDFL delegates for specific issues. How should power be delegated to make specific decisions about features? Who can say "this will not happen"? * It's pretty nice to have a dictatorship when you have a good dictator. A democracy does not guarantee that the best choice will be made, or even that the will of the majority is carried out. * The language is now sufficiently complex that it may be difficult to have any individual that understands the whole thing enough to make decisions unilaterally. * Without a way to make the decision it is all talk; how do we have a consensus? * We should accept that we're not going to get to unanimity * What is the externally visible legitimacy of any decision process? If 52% say yes and the other 48% say no, is the decision legitimate? * The state we're in now is scary but many other projects have been here, like numpy. We need to shift from our respect for Guido to a shared sense of what's the right process, even if we don't agree on every detail. A 51% vote is not a good thing. * We are experts on programming languages, not on governance and decision making. Maybe bring in an expert on decision making models if this meta problem is going to get really thorny. * There are models of decision making that have been studied by experts and their characteristics are known. These models are all pretty good; pick a decision-making model and discuss it. * Think about what has worked well in the past and has not worked well. We've had a successful process delegating issues before. Maybe we don't need to worry too much about the fine details of delegation. We could fall into the trap of making this process too complicated, too overspecified and too legalistic. * The core development community is not as diverse as the broader Python community. Attitudes of the people making these governance decisions may not be aligned with those of the communities they're intending to serve. How can we address this? * People are too afraid of changes; we don't need a PEP or a formal process or a decision from Guido for everything. Some changes can just be made by people we trust to make good decisions. * Continue to rely on experts when making decisions about their areas of expertise. * There are disruption risks of changing too quickly but there are existential risks in changing too slowly. * The model so far is that the patriarch lets the kids run around but keeps them from running over the cliff. * Making one person or a small group an oracle for what is good is unfair and unrealistic, particularly if they have to not only understand and make decisions about every aspect of the language but also police bad process outcomes. * Consider models of projects that work; get people involved who are experts on project management and process. We need a Counsellor Troi for this project. Get a professional coach involved, who is already involved in successfully governed Python projects, for example the Jupyter project and the Django project. * If someone does not aspire to be leadership but still has something to offer, are they shut out of the decision-making process? If important things come up, people with depth of experience need to be heard and feel that they are heard. * No one really wants decision by committee and what that entails. * Historically we see that when there is a change in governance model and power structure, there will be a challenge. Hopefully there will not be a villain that brings us together. * Whatever we do, hopefully it will not require more effort by the volunteers of the core team; we like to work on technical issues rather than navigating political organizations and heavyweight processes. * Our work is founded on trust; take that into account and keep it from falling apart * Every core developer should have an idea of what they want to see from Python in the next five years. That will motivate choice of governance model. * Keep moving forward and get a governance decision made. We don't want to make a panic decision, but we don't want to sit and wait either. Figure out what we want and execute on it. * This is a human factors problem; burnout exists everywhere in an organization. Understand the roles that we are trying to refactor. * Things will not be the same, some changes will go smoothly, and some will not, and then they'll say that in the old days, things were great. * Define what roles need to be filled; that affects everything. * We should choose how we're going to choose before we leave, while being considerate of people who are not here. * Be clear that any new model of governance is specifically for core devs, not for the Python community as a whole What's important? * Python is a popular language; anything we change has a large impact and we need to take that seriously. Can we agree on how impactful decisions can be, and make sure that a governance process takes impact seriously? * Explicit is better than implicit; Guido is a mountain of implicit knowledge, and there is no one close to that. * We need a set of slogans or principles that summarize our design values; the Zen of Python is poetic and aspirational, but we should decide more specifically what Python should be or we will end up with C++ * What are the goals of Python as a language? Do we value stability, or evolving to achieve feature parity with other languages? Do we want to evolve fast or slow? Do we value performance or compatibility? It's easy to say "both", but design is about making compromises. The relationship between the PSF board and the core dev community * The role of a board member is to fulfill the mission of the organization in accordance with its guiding principles. * What are those guiding principles? Consistency, stability? What else? * What specific communities of users and developers are served? * Where does the PSF and its board of directors fit in to this decision? * Core developers don't see the PSF very often, and non-core-dev board members don't see much of what the developers are doing. * Does the board want to be involved in this process? * We should make sure that the board and the core devs are on the same track and share common goals * There is a clear difference between how the board sees the core developers and what the core developers do. New board members often ask how much influence they have on how core developers do their work. Very little. * The PSF owns the trademark and therefore what is done with the codebase. * Core developers are expected to participate in language development and writing code, not, say, raising money. The foundation manages that. Communicating decisions * How will this decision be communicated to the world? * People don't like to read long governance documents. * Get this sorted out well before the next pycon. The decision should be formally announced there, but it should be well known and accepted throughout the community long before that. Email is terrible, except when it isn't * The email list mechanism is both boring and annoying. Can we find another tool? * Python dev mailing list has 20K subscribers which is a scarily large number given the level of discussion. * The mailing list used to function better: * The participants were not necessarily nicer; some were mean, but the problem solving was effective. * How did those people interact together? * Get old timers out of retirement to participate and model effective problem solving. * What communication techniques can be used for problem solving that have intellectual depth while ensuring that everyone is heard? * It's easy to criticize the email lists but remember that these lists do in general work pretty well. Process suggestions and concerns * When someone exits a role, consider an exit interview. How do we not repeat mistakes of the past? (Not to put Guido on the spot.) * We took Guido for granted, and now need codification of those processes. * The PEP process is the biggest part of how we design python and it needs to be redesigned. We need a tighter PEP process with stages and rules. * The PEP process is more difficult than it needs to be. Conduct, and its code * The forum process dismisses and belittles people. That's not OK on the face of it, but worse, the people who are bullied are allies, contributors and advocates for this language. * The code of conduct feels like it is ostensibly there to protect people from abuse, but in fact can be used as a weapon against people who want to contribute * Python dev doesn't feel like a safe forum. We can't continue to let that happen. Women with deep knowledge and industry experience have real serious reasons to avoid this forum. * We need to change our interactions before a change of governance has a chance to work * There are "hot" topics that people are overly "active" in their participation; the code of conduct should be applied there. But let's remember that in general our communication mechanisms work well most of the time. We're capable of making good decisions. * If you see something that doesn't seem right on a list, mail a moderator; moderators don't see everything. * Maybe apologize once in a while. We have a responsibility to each other and to owning our mistakes. * Being a core developer is as much about establishing trust with each other as it does with technical ability. Work on establishing trust. * The metric of a successful technical decision is not its technical merit; it's whether everyone feels like they were heard. If it's a hard technical decision then you need a diverse set of opinions to get confidence that you've arrived at a good decision. And making people feel heard keeps them around and wanting to participate. * The code of conduct is supposed to make people feel more included but can make people feel excluded. * There are experts on this; get them involved. They're sensitive to being humane through this process. Pycon brought in consultants for this. * There is a conduct working group taking a holistic view, the board has approved getting help on this. * How does this affect core devs? We need buy-in. * The process is not far involved yet; just got budget. * Code of conduct enforcement should be prompt, kind and firm; don't get into a state where everyone is screaming at each other.

1 0

Automerge bot deployed
by Mariatta Wijaya 13 Sep '18

13 Sep '18

I've deployed the bot to automerge CPython pull request on the master branch. One benefit of this is you don't need to worry about replacing "#" into "GH-". To get the bot to automerge: - first edit the PR title and description, to be the commit message you want to use. - approve the PR (so it will have "awaiting merge" label) - apply the "🤖 automerge" label. It will wait for ALL status checks to pass, and merge the PR, replacing `#` with `GH-` I've made a demo video on YouTube: https://youtu.be/p85YtKKLNno See also previous discussions in https://github.com/python/core-workflow/issues/29 https://github.com/python/bedevere/issues/14 The previous way of merging PR still works. If you prefer merging the PR yourself, just don't apply the "🤖 automerge" label. Mariatta ᐧ

5 6

I have blocked someone from the Python org
by Brett Cannon 13 Sep '18

13 Sep '18

Someone left https://github.com/python/cpython/pull/9195#issuecomment-420646466 which was clearly written to upset Victor and insult him. I warned the person that such behaviour is not okay and future insults would have ramifications (I was actually asked to ban this person to begin with but I gave them the benefit of the doubt considering how heated the topic involved has become). They then decided to seek me out on Twitter berate me there for my warning: https://twitter.com/dolkensp/status/1039949212832722944 . For that I have followed through with my warning and banned them from the org.

6 8

3 weeks to Oct 1
by Mariatta Wijaya 11 Sep '18

11 Sep '18

Friendly reminder that it is now 3 weeks until October 1, the deadline for coming up with Python Governance PEPs. Barry has started several Governance PEPs: - https://www.python.org/dev/peps/pep-8000/ Python Language Governance Proposal Overview - https://www.python.org/dev/peps/pep-8001 Python Governance Voting Process - https://www.python.org/dev/peps/pep-8002 Open source governance survey The following three PEPs are for placeholders. I believe the idea is to have people claim the PEP they're planning to write, and finish writing the PEP. - https://www.python.org/dev/peps/pep-8010 The BDFL Governance Model - https://www.python.org/dev/peps/pep-8011 The Council Governance Model - https://www.python.org/dev/peps/pep-8012 The Community Governance Model And don't forget about the lucky PEP number 13. https://www.python.org/dev/peps/pep-0013/ Mariatta ᐧ

1 0

MSDN subscription renewal
by Andrew Svetlov 10 Sep '18

10 Sep '18

Hi. I've found that my MSDN subscription has expired. I don't use Window for daily tasks but sometimes need it for fixing Windows-specific bugs. Could you renew it or issue a new one? -- Thanks, Andrew Svetlov

1 0