Re: [python-committers] Official python-dev docker images
On Dec 7, 2017, at 19:34, Christian Heimes wrote: > > Shiny! You'll get extra bonus points for not running as root. :) Don’t forget, there’s a bug tracker you can submit requests to. > I'm curious, what is the reason of compiling CPython yourself? Ubuntu > has the deadsnakes project. Fedora has packages for Python 3.3, 3.4, and > 3.5. I really want clean builds of upstream tarball releases. Debian/Ubuntu for sure, and I would bet Fedora too, has downstream deltas applied, so if something fails there, how do you know it’s because of your package or something the distro added? Note that we do install the build dependencies for the Pythons so they’ll link against platform libraries and such. > Could I convince you to put some builds of OpenSSL and LibreSSL into the > container, too? You can totally file an issue so we can discuss it. :) https://gitlab.com/python-devs/ci-images/issues Cheers, -Barry signature.asc Description: Message signed with OpenPGP ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Promote Julien Palard as core developer
Enthusiastic +1 from me. Great work on docs and localization. On Thu, Dec 7, 2017 at 3:02 PM, Ned Deily wrote: > On Dec 6, 2017, at 19:48, Victor Stinner wrote: > > I propose to promote Julien Palard as a core developer. > > A big +2 from me. Julien has been extremely helpful over the past half > year or so with multiple behind-the-scenes documentation build issues. As > Victor notes, he is familiar with the doc infrastructure, processes, and > the people who work on them. I've found him to be easy to work with and to > display good judgement. I would be very happy to see Julien take on a more > formal role with our documentation process and any other area that he would > like to get involved with. > > -- > Ned Deily > n...@python.org -- [] > > ___ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- *Carol Willing* Research Software Engineer Project Jupyter at Cal Poly SLO cawil...@calpoly.edu *Signature strengths* *Empathy - Relator - Ideation - Strategic - Learner* ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Official python-dev docker images
On 2017-12-07 19:00, Barry Warsaw wrote: > As part of the importlib_resources skunkworks project Brett and I have been > working on (just announced), we’ve also put together a nice Docker image that > we’re using for our automated testing. This image is based on Ubuntu 16.04 > and provides the latest stable releases of Python 2.7, and 3.4-3.6, along > with a mostly up-to-date git checkout of master, currently Python 3.7 of > course. Once 3.7 is released to beta, we intend to track its release > tarballs too. > > We also install a few other commonly needed tools, like pip, git, unzip, > wget, mypy, and tox. > > Here’s the project repo: > > https://gitlab.com/python-devs/ci-images > > Huge shout out to Abhilash Raj who helped us clean up and compactify the > image, and also for setting up automated publishing to quay.io. In case you > weren’t aware, Abhilash is who I passed GNU Mailman project leadership to, so > he has a lot of Python experience, and a ton of expertise in the image space. > He’s an amazing amount of work to improve the quality of this image! > > Brett and I want to promote this more widely within the Python community as > the “official Python Docker image” that projects can use in their own testing > environments, or base their own images on it. We wanted to give you guys a > heads up first to get your feedback, and maybe thoughts on the best places to > promote this, e.g. on the python.org website or other places. > > We welcome your participation too of course! I’m happy to give write access > to the project to any Python committer who wants to help. Shiny! You'll get extra bonus points for not running as root. :) I'm curious, what is the reason of compiling CPython yourself? Ubuntu has the deadsnakes project. Fedora has packages for Python 3.3, 3.4, and 3.5. Could I convince you to put some builds of OpenSSL and LibreSSL into the container, too? Ubuntu 16.04 has only OpenSSL 1.0.2. A while ago I added a script to CPython that downloads, compiles and installs multiple versions in a shared directory (../multissl relative to cpython checkout). The script can be used to run the SSL test suites (ssl, asyncio, urllib, smtp, ...) against all installed versions. https://github.com/python/cpython/blob/master/Tools/ssl/multissltests.py Regards, Christian ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Official python-dev docker images
On 2017-12-07 22:28, Barry Warsaw wrote: > That’s good feedback! I want to be clear about the purpose of this image, > both in that it’s blessed and maintained by us, and that its focus is on the > Python library and application developer (primarily for testing purposes). > > So maybe: Python.Org Official Multiversion Development Docker Image > Doubleplus Good! Why is there 'Docker' in the name? Is the container image restricted to Docker runtime or can I use it with lxc, systemd-nspawn, rkt, or any other container runtime, too? There are likely legal issues with the name, too. After all 'Docker' is a registered trademark of Docker, Inc [1]. I'd be careful and call it 'Python.Org Official Multiversion Development Supercalifragilistic Container Image' instead. Christian [1] https://www.docker.com/brand-guidelines ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Number of contributors
Le 07/12/2017 à 23:20, Victor Stinner a écrit : > > 2017-12-07 0:39 GMT+01:00 Antoine Pitrou : >> Therefore, we should strive to attract more contributors in the hope >> that the number of core developers selected out of those contributors >> will also increase. > > Over the last 9 months, Stéphane Wirtel accounted 586 different > contributors (who got pull requests merged). I'm not sure that we have a > real issue with the number of contributors. That number is not very interesting in itself, since Github indeed makes it easy to submit and integrate small fixes. So you can have many occasional contributors but very few regular contributors keen on tackling non-trivial tasks. It would be more interesting to know how many of those contributors submitted several (for example 5 or more) non-trivial fixes or improvements. Regards Antoine. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] RFC: Process to become a core developer
Le 07/12/2017 à 23:38, Victor Stinner a écrit : > > Another option is the idea proposed in parenthesis, that contributors > mentor them each other. I wouldn't count as the official required > mentoring, but it would help anyway. I think that it is already > happening right now on the core-mentorship mailing list, helping each > other. Yes, well... core-mentorship has existed for years now (*), yet the number of promoted core developers has dwindled. I wouldn't count it as a success, at least not from that perspective (even though it may be a success from other perspectives) ;-) (*) it was created in 2011 AFAICT: https://mail.python.org/pipermail/python-dev/2011-March/110077.html Regards Antoine. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] RFC: Process to become a core developer
2017-12-07 19:21 GMT+01:00 Antoine Pitrou : >> == Step 2: Bug Triage Permission == >> >> Once a contributor becomes active enough, a core developer can propose >> to give the bug triage permission to the contributor. > > It sounds like you are not taking into account what was said by various > people during the previous discussion. I did, but I'm not sure that you (Antoine and others) understand properly my intent. Please see the reply that I just sent on the other "Requirements to get the "bug triage" permission?" thread. >> == Step 3: Getting a mentor == >> >> Python project is big and has a long history. Contributors need a >> referrer to guide them in this wild and dangerous (!) project, and in >> the development workflow. > > Perhaps you are overdoing this? :-) Maybe, who knows? :-) >> Required mentor skills: >> >> * Be a core contributor. >> * Be available at least during one whole month. >> * Follow the contributor: must get an update at least once a week, >> especially if the contributor doesn't show up. > > I'm afraid these requirements may make the process actually harder than > it currently is. What if there is no potential mentor available? This > reminds of the Google Summer of Code... I would lie if I would say that being a mentor is a trivial task that doesn't take any time. But from what I hear around me, mentoring the *key* difference to train faster motivated contributors. A single people cannot be the mentor of too many contributors at the same time. The bootstrap is going to be hard :-( Oh, if you didn't see it yet, I strongly suggest to watch Mariatta Wijaya's talk about mentoring at the last Pycon US: https://www.youtube.com/watch?v=Wc1krFb5ifQ She explained that mentoring is also valuable for the mentor! It goes in both directions. Another option is the idea proposed in parenthesis, that contributors mentor them each other. I wouldn't count as the official required mentoring, but it would help anyway. I think that it is already happening right now on the core-mentorship mailing list, helping each other. In the past, I mentored Xavier De Gaye and Xiang Zhang during one month *after* they became core developers. Honestly, it took me less than one hour per week. Ok, maybe they are not the best examples of contributors, since they already had a good background. But I'm not less afraid of being a mentor ;-) The "Step 3: Getting a mentor" isn't the first step just after "Step 0: Newcomers". The expectation is that the contributor already knows enough about Python workflow and code, before getting a mentor. For steps before the step 3, there is already the core-mentorship mailing list. IMHO this list is working well as intended. People who reply are kind, take time to explain, and contributors usually get a reply quickly. Bonus point: multiple core developers can be found there and actually answer, including Guido van Rossum! Mariatta got Guido van Rossum as a mentor (and also Raymond Hettinger if I understood correctly) and it was very successful, she became "quickly" a core developer and she is now involved in many parts of the Python development! (Sorry Mariatta to "use you" as an example!) I'm taking Mariatta as a concrete example of the success of mentoring. Victor ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Requirements to get the "bug triage" permission?
(I tried to answer to all replies. Since I chose to reply in a single email, so I chose to reply to own initial email.) Hi, It seems like I didn't express my ideas with the right words and so misguided the discussion. I'm sorry about that. I wrote a full "promotion process" document where I tried to pick better words. For example, I replaced "award" with "responsibility" ;-) My email: https://mail.python.org/pipermail/python-committers/2017-December/005000.html 2017-11-20 19:12 GMT+01:00 R. David Murray : >> Did it happen in the past that we removed the bug triage permission >> to someone who abused this power? > > Only once that I'm aware of. IMHO it's ok remove permissions if we have to. Instead of making such event abnormal, I proposed a training period of one month when the permission can be reverted anytime if the contributor misbehaves while being told to change their behaviour. I hope that the removal of the permission after the training period will be exceptional. I also added the need to get a mentor to reduce the risk even further. The mentor is not responsible of the behaviour of the contributor, but is here is guide and help the contributor. R. David Murray : >> Maybe we can give some guide lines on how to behave on the bug >> tracker? > > Enhance the bug triage section of the devguide, by all means :) To not forget, I created an issue in the devguide project! https://github.com/python/devguide/issues/308 2017-11-20 19:59 GMT+01:00 Ezio Melotti : > but we don't have a well defined procedure and sometimes people keep > contributing for weeks before someone realizes they could become > triagers. Aha. Maybe we need some tooling, like statistics on contributions to the bug tracker, just to detect earlier active "bug triagers"? On Git, it's simpler, there already many tools computing statistics on the number of commits. 2017-12-06 18:45 GMT+01:00 Ezio Melotti : > Depends on what you exactly mean with "award". Contributors might > want to be able to edit more fields on the tracker, and the triage bit > allows them to do it. This is beneficial for both the contributor and > the other triagers, since they have one more helping hand. (...) Here is where I failed the most to explain myself. If you consider that the long term goal is to train contributors to become core developers, bug triage is just one of the task and responsibility of a core developer. To exagerate, you cannot become a core developer if you don't know how to triage bugs properly. In my point of view, giving the bug triage permission is first a new responsibility, not a permission or an "award". The contributor becomes able to make bigger mistakes and so must be careful. The idea is to give permissions and responsibilities step by step to contributors, rather than giving them as once as the "core developer package". To come back to bug triage itself, obviously, the permission gives access to features not available to regular contributors, and so allows to better triage bugs. 2017-12-06 19:45 GMT+01:00 Ned Deily : > In general, I agree with David's and Ezio's comments, in particular > the idea that "bug triage" should not be an "award" nor a necessary > first step towards being a committer. I think the skills necessary to > be a good bug triager are not the same as being a good core developer. > While the skill sets and experience level needed can overlap, I think > we should consider the two roles as separate "career paths". In other > words, some people would do a fine job as triager without wanting to > be a core developer or contributing their own code patches, and that's > fine. I agree and like the idea of contributors who enjoy bug triage without wanting to contribute to the code. But technically, when I say "bug triage permission", I understand at least being able to close a bug. It would be annoying if a core developer doesn't get this permission and so would be unable to close a bug once a fix is pushed, no? 2017-12-06 20:37 GMT+01:00 Terry Reedy : > I agree. Database maintenance is a separate skill and interest from > the 3 skills of patch writing, reviewing, and merging. Committers > need to be able to maintain and ultimately close the issues they work > on, but need not engage in general tracker gardening. While I agree that core developers are not *required* to triage bugs, I consider that it's a responsibility shared by core developers to take care of the bug tracker. As I consider that core developers should review pull requests, not only produce pull requests, and that's one of the difference I see between a regular contributor and a core developer. Again, I wouldn't say that it's a hard requirements, more a best effort responsibility ;-) 2017-12-06 23:35 GMT+01:00 Antoine Pitrou : > I wonder: is this the right question to ask? There are contributors > who will never become core developers. It's not a failure. How many > of us actually hoped or expected to become a core developer wh
Re: [python-committers] Cheryl Sabella was promoted to get bug triage permission
2017-12-06 18:43 GMT+01:00 Victor Stinner : > FYI She pushed not less than 14 commits into the master branch since > August, 2017. Oops, I used the wrong command to count her number of commits. vstinner@apu$ git log --author='Cheryl Sabella'|grep ^commit|wc -l 14 In fact, she changed her full name in her Git configuration in August, but not her email: vstinner@apu$ git log --author=cheryl.sabe...@gmail.com|grep ^commit|wc -l 36 The correct number is that she got **36** commits merged into master since June 2017. Great! GitHub counts 52 commits, maybe it accounts also backports: https://github.com/python/cpython/graphs/contributors?from=2016-07-10&to=2017-12-07&type=c "csabella: 52 commits 7,647 ++ 4,601 --" I prefer to only count commits in master. Victor ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Official python-dev docker images
[Continuing to CC Abhilash, who is not on this list. -B] > On Dec 7, 2017, at 14:36, R. David Murray wrote: > > On Thu, 07 Dec 2017 13:00:31 -0500, Barry Warsaw wrote: >> Brett and I want to promote this more widely within the Python >> community as the “official Python Docker image” that projects can use >> in their own testing environments, or base their own images on it. We >> wanted to give you guys a heads up first to get your feedback, and >> maybe thoughts on the best places to promote this, e.g. on the >> python.org website or other places. > > Well, the place to get a python Docker image listed would be > https://hub.docker.com/_/python/. That's the first google hit for python > docker, and it already has a host of images available. How does yours > differ from those? It sounds like it is by having multiple versions > and tox so you can test your library/ap against multiple Python > versions using a single container. That does sound useful :) There are several differences. Probably the two biggest are that 1) the ones on docker hub are not maintained by *us* but instead by “the Docker Community”; 2) AFAICT, the ones on docker hub aren’t development focused images, so they only have one single version of Python installed. For any Python-based project that wants to e.g. run CI against multiple versions of Python, that isn’t helpful (and hence why we built this one). Our image is bigger, but more generally useful to library and application developers, rather than say, application deployment users. > But, be careful with names. "official Python Docker image" sounds like > what one would use when one wants to *run* a python application in a docker > container, which is what the images that are currently listed on the > page mentioned above seem directed at. That’s good feedback! I want to be clear about the purpose of this image, both in that it’s blessed and maintained by us, and that its focus is on the Python library and application developer (primarily for testing purposes). So maybe: Python.Org Official Multiversion Development Docker Image Doubleplus Good! :) Seriously, audience and naming are important to get right. -Barry signature.asc Description: Message signed with OpenPGP ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Promote Julien Palard as core developer
On Dec 6, 2017, at 19:48, Victor Stinner wrote: > I propose to promote Julien Palard as a core developer. A big +2 from me. Julien has been extremely helpful over the past half year or so with multiple behind-the-scenes documentation build issues. As Victor notes, he is familiar with the doc infrastructure, processes, and the people who work on them. I've found him to be easy to work with and to display good judgement. I would be very happy to see Julien take on a more formal role with our documentation process and any other area that he would like to get involved with. -- Ned Deily n...@python.org -- [] ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Cheryl Sabella was promoted to get bug triage permission
On Wed, 6 Dec 2017 at 10:25 Ethan Furman wrote: > On 12/06/2017 09:43 AM, Victor Stinner wrote: > > > Congrats Cheryl! > > Possibly a dumb question, but is Cheryl on this list? > Nope, but that's because we have kept this list to only core devs and not people who have triage powers on the issue tracker. -Brett > > -- > ~Ethan~ > ___ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity
On Wed, 6 Dec 2017 at 15:17 Victor Stinner wrote: > Hi, > > I wrote a quick & dirty parser to compute statistics on *new* CPython > core developer per year using the following page as data: > https://devguide.python.org/developers/ > > 2007: 15 > 2008: 19 > 2009: 11 > 2010: 20 > 2011: 12 > 2012: 9 > 2013: 4 > 2014: 10 > 2015: 2 > 2016: 5 > 2017: 2 > > Compare these numbers to Stéphane Wirtel's statistics on pull requests: >https://speakerdeck.com/matrixise/cpython-loves-your-pull-requests > > => Number of active core developerson on GitHub pull requests: 27 > (stats from February 2017 to October 2017) > (I'm not sure of the meaning of this number, it's the number of core > developer who authored pull requests, I don't think that it counts > core developers who only made reviews.) > > If you look at the size of the source code, it's still growing > constanly since 1990: > https://www.openhub.net/p/python/ > > 2007: around 783k lines > 2010: around 683k lines > 2013: around 800k lines > 2015: around 875k lines > 2017: around 973k lines > > The number of bugs is also constanly growing. Statistics on bugs since > 2011: > https://bugs.python.org/issue?@template=stats > > 2011: around 2500 open issues > 2013: around 4000 open issues > 2015: around 5000 open issues > 2017: around 6200 open issues > Do realize that open issues is a really misleading statistic as they include enhancement requests which we historically never close unless there's zero chance we will accept such a change. > > The size of the CPython project is constantly growing as its > complexity (technical debt? what is this? :-)), but the growth of core > developers is slowing down. > Well, you added code to speed up Unicode encoding/decoding, right? So it's just adding stuff to keep things performant as well as new things. It's just what happens when you're willing to improve things. > > I do consider that we need more people to handle the growing number of > issues and pull requests, so the question is now how to find and > "hire" (sorry, promote) them ;-) > > Maybe we have a problem with mentoring. Maybe the CPython code base > became too hard to train newcomers? Maybe we are too conservative? I > don't know. > I think it's partially a fact that Python's popularity has increased the pool size of contributors, so lots of people grabbing individual things. This leads to less of a chance to make sustained contributions. E.g. when I became a core dev it was because I was able to grab a new issue to work on that was easy at a very regular cadence, but I don't know if I could rectify that at this point. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Official python-dev docker images
On Thu, 07 Dec 2017 13:00:31 -0500, Barry Warsaw wrote: > Brett and I want to promote this more widely within the Python > community as the âofficial Python Docker imageâ that projects can use > in their own testing environments, or base their own images on it. We > wanted to give you guys a heads up first to get your feedback, and > maybe thoughts on the best places to promote this, e.g. on the > python.org website or other places. Well, the place to get a python Docker image listed would be https://hub.docker.com/_/python/. That's the first google hit for python docker, and it already has a host of images available. How does yours differ from those? It sounds like it is by having multiple versions and tox so you can test your library/ap against multiple Python versions using a single container. That does sound useful :) But, be careful with names. "official Python Docker image" sounds like what one would use when one wants to *run* a python application in a docker container, which is what the images that are currently listed on the page mentioned above seem directed at. --David ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] RFC: Process to become a core developer
Le 07/12/2017 à 19:01, Victor Stinner a écrit : > > IMHO the current blocker issue is that it is too hard to become a core > developer. I don't think so. It should not be harder than it was in 2010, yet we are promoting way less core developers than we did. See previous discussion. > A promotion is decided with a vote. If a > voter doesn't know the contributor, it can be very stressful to take a > decision. If someone doesn't know the contributor, they can simply say so and abstain from voting. It's what we usually do already: there are 150+ core developers and only a few of them vote when a new core developer is proposed. So this is not a problem in practice. > == Step 2: Bug Triage Permission == > > Once a contributor becomes active enough, a core developer can propose > to give the bug triage permission to the contributor. It sounds like you are not taking into account what was said by various people during the previous discussion. > == Step 3: Getting a mentor == > > Python project is big and has a long history. Contributors need a > referrer to guide them in this wild and dangerous (!) project, and in > the development workflow. Perhaps you are overdoing this? :-) > Required mentor skills: > > * Be a core contributor. > * Be available at least during one whole month. > * Follow the contributor: must get an update at least once a week, > especially if the contributor doesn't show up. I'm afraid these requirements may make the process actually harder than it currently is. What if there is no potential mentor available? This reminds of the Google Summer of Code... Regards Antoine. ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] RFC: Process to become a core developer
On 12/07/2017 10:01 AM, Victor Stinner wrote: Note: I'm trying to avoid gender to be inclusive when mentioning a contributor by using "they" or "their". I'm not sure that it's correct in english, since english is not my first language. Is "they" acceptable to identify a single contributor, or is it restricted to the plural form (contributors)? "They" and "their" have been used as gender-neutral, singular pronouns for centuries. It can sound odd to those of us not accustomed to hearing it, but it is correct. -- ~Ethan~ ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Official python-dev docker images
On Dec 7, 2017, at 13:00, Barry Warsaw wrote: > He’s an amazing amount of work to improve the quality of this image! Um, let me rephrase :) He’s done an amazing amount of work to improve the quality of this image! -Barry signature.asc Description: Message signed with OpenPGP ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
[python-committers] RFC: Process to become a core developer
Hi, I'm working on a process to describe how a contributor becomes a core developer. The purpose is to be transparent, list "requirements" and responsabilities to the contributor, and have written rules to help to take a fair decision. This document is a draft. I chose to post it on python-committers. I expect that we would have to iterate on it multiple times until we can reach a consensus to agree on the process. While the process has many details, it must be seen more as a guideline than strict rules. Note: I'm trying to avoid gender to be inclusive when mentioning a contributor by using "they" or "their". I'm not sure that it's correct in english, since english is not my first language. Is "they" acceptable to identify a single contributor, or is it restricted to the plural form (contributors)? == Introduction == The overall goal is to get more active developers working on Python to better scale horizontally: get more reviews to get better changes. The code quality is expected to be enhanced: more eyes on reviews should help to catch bugs earlier. Another less important goal is to speed up the Python development IMHO the current blocker issue is that it is too hard to become a core developer. While becoming a core developer is not required to contribute, in my experience, core developers feel more involved and better recognized for their work. Core developer first means becoming responsible of a change: maintain the code/documentation and handle any potential regression. Long term commitment and good quality reviews are also expected from core developers. The blocker issue can be explained by the very high step that should be climed at once to become a core developer. The contributor responsibilities changes at once from "no power" to "can do anything on any part of the project". A promotion is decided with a vote. If a voter doesn't know the contributor, it can be very stressful to take a decision. Building a trust relationship takes time and is not currently formalized by a process. This process is trying to address these issues. I propose to formalize a process to promote a contributor from the early newcomer step to the final core developer step. The process is made of multiple steps to help the contributor to estimate their own progress. Mentoring becomes required by the process and is a major part of the whole process. While the process explains how to "clim" steps, going backward now becomes part of the process, it is not seen as a failure but as a normal and expected change under certain conditions. The final vote to promote a contributor as a core developer is expected to become more natural and simpler. The voters are expected to know better the future candidate. == Process Steps == I propose the following steps to become a core developer: * Step 0: Newcomer * Step 1: Contributor * Step 2: Bug triage permission * Step 3: Mentoree. * Step 4: Core developer == Step 0: Newcomer == The first step is to start as a newcomer. Usually, newcomers are following the Python development without actively contributing. == Step 1: Contributor == I consider that newcomers become automatically contributors as soon as they post their first comment on the bug tracker, comment on a pull request, or a pull request. Their is no manual validation, nor additional privilege. It's just a thin distinction with a newcomer. At this step, it becomes interesting to start reading the Python Developer Guide: http://devguide.python.org/ == Step 2: Bug Triage Permission == Once a contributor becomes active enough, a core developer can propose to give the bug triage permission to the contributor. The contributors may ask themself to give this permission. The level of activity is not strictly defined, since it depends on the kind of contributions and their quality. The core developer is responsabile to estimate this. There is no formal vote to give the bug triage permission. The core developer becomes responsible of the promotion. In practice, core developers are free to discuss together ;-) Getting the bug triage permission gives more responsabilities to the contributor: the bug tracker should not be misused to not lost useful information. Taking a decision on an issue requires a certain level of knowledege of the Python development. I propose that the contributor gets a mentor during one month. The role of the mentor is to answer to any question of the mentoree, and help them to take decisions if needed. The mentor is not expected to watch closely what the contributor does on the bug tracker. If the contributor misuses the bug tracker, the mentor (or another core developer) should help the contributor to adjust their behaviour. If the contributor continue to abuse the bug tracker or misbehaves, the permission is removed and the contributor moves back to the previous step. This step is the opportunity to know each other, begin to create a trust relationship. Required skills for the contributor: *
[python-committers] Official python-dev docker images
As part of the importlib_resources skunkworks project Brett and I have been working on (just announced), we’ve also put together a nice Docker image that we’re using for our automated testing. This image is based on Ubuntu 16.04 and provides the latest stable releases of Python 2.7, and 3.4-3.6, along with a mostly up-to-date git checkout of master, currently Python 3.7 of course. Once 3.7 is released to beta, we intend to track its release tarballs too. We also install a few other commonly needed tools, like pip, git, unzip, wget, mypy, and tox. Here’s the project repo: https://gitlab.com/python-devs/ci-images Huge shout out to Abhilash Raj who helped us clean up and compactify the image, and also for setting up automated publishing to quay.io. In case you weren’t aware, Abhilash is who I passed GNU Mailman project leadership to, so he has a lot of Python experience, and a ton of expertise in the image space. He’s an amazing amount of work to improve the quality of this image! Brett and I want to promote this more widely within the Python community as the “official Python Docker image” that projects can use in their own testing environments, or base their own images on it. We wanted to give you guys a heads up first to get your feedback, and maybe thoughts on the best places to promote this, e.g. on the python.org website or other places. We welcome your participation too of course! I’m happy to give write access to the project to any Python committer who wants to help. Cheers, -Barry, Brett, Abhilash signature.asc Description: Message signed with OpenPGP ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Sanyam Khurana has been promoted to get bug triage permission
Congrats Sanyam! Thanks for your continued contributions :) Mariatta Wijaya On Wed, Dec 6, 2017 at 3:25 PM, Senthil Kumaran wrote: > Congratulations, and Welcome Sanyam!. > > Thank you, and keep up with your good work. > > > > On Wed, Dec 6, 2017 at 1:43 PM, Victor Stinner > wrote: > >> Hi, >> >> To recognize the good contributions of Sanyam Khurana, I gave him the >> bug triage permission on bugs.python.org. (In practice, Ezio gave him >> the permission.) >> >> He already commited 9 changes into the master branch since April, 2017. >> >> Congrats Sanyam! >> >> Victor >> ___ >> python-committers mailing list >> python-committers@python.org >> https://mail.python.org/mailman/listinfo/python-committers >> Code of Conduct: https://www.python.org/psf/codeofconduct/ >> > > > ___ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > > ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Promote Julien Palard as core developer
Agree. +1! Mariatta Wijaya On Thu, Dec 7, 2017 at 8:29 AM, Ethan Furman wrote: > On 12/06/2017 04:48 PM, Victor Stinner wrote: > > I propose to promote Julien Palard as a core developer. >> > > I know that Julien doesn't have the typical profile of core >> developers, only or mostly contribute to the code: Julien is currently >> focused on the doculmentation. >> > > Good documentation is hard. +1 to bring Julien Palard in! > > -- > ~Ethan~ > > > ___ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers > Code of Conduct: https://www.python.org/psf/codeofconduct/ > ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Promote Julien Palard as core developer
On 12/06/2017 04:48 PM, Victor Stinner wrote: I propose to promote Julien Palard as a core developer. I know that Julien doesn't have the typical profile of core developers, only or mostly contribute to the code: Julien is currently focused on the doculmentation. Good documentation is hard. +1 to bring Julien Palard in! -- ~Ethan~ ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Promote Julien Palard as core developer
On Thu, Dec 7, 2017 at 2:48 AM, Nick Coghlan wrote: > On 7 December 2017 at 10:48, Victor Stinner wrote: >> Promoting Julien is part of my global idea/project of trying to >> recognize more contributions which are not strictly code, but as >> useful or even more useful than code! Python documentation is part of >> Python's success. I was told many times that Python has a good >> documentation, it's nice to hear that ! IMHO reducing CPython to its C >> and Python code is wrong and nor fair, CPython made of much more >> "sub-projects". > > +1 from me for giving docs-focused folks commit access! As the saying > goes, "For most users, if it isn't documented, it may as well not > exist" :) +1 here too, for the same reasons. Also, I've worked with Julien on a couple of issues and had nothing but good experience with him. -- Zach ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
Re: [python-committers] Promote Julien Palard as core developer
On 7 December 2017 at 10:48, Victor Stinner wrote: > Promoting Julien is part of my global idea/project of trying to > recognize more contributions which are not strictly code, but as > useful or even more useful than code! Python documentation is part of > Python's success. I was told many times that Python has a good > documentation, it's nice to hear that ! IMHO reducing CPython to its C > and Python code is wrong and nor fair, CPython made of much more > "sub-projects". +1 from me for giving docs-focused folks commit access! As the saying goes, "For most users, if it isn't documented, it may as well not exist" :) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers Code of Conduct: https://www.python.org/psf/codeofconduct/
