Re: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel
Emily and Lisa: welcome to the core team! (style note: I almost missed the presentations after the long line of dashes) Best regards Antoine. Le 14/09/2018 à 21:28, Raymond Hettinger a écrit : > 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 > ___ > python-committers mailing list > [email protected] > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] New core developers: Lisa Roach and Emily Morehouse-Valcarcel
On 09/14/2018 12:28 PM, Raymond Hettinger wrote: 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. Congratulations Emily and Lisa! I look forward to many years of arguing working with you on our favorite language. //arry/ ___ python-committers mailing list [email protected] https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] Governance Discussion #1 Notes
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 majorit
[python-committers] Governance Discussion #2 Notes
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
