13.06.18 19:43, Terry Reedy пише:

On 6/13/2018 12:16 PM, Victor Stinner wrote:

...

I propose to promote Pablo Salingo Salgado as a core developer and so open a vote during one week. If there is no strong opposition, I will promote him but also continue to mentor him for a least one month.

Pablo is contributing frequently to Python since almost one year. He added os.preadv()/pwritev() to Python 3.7 and os.posix_spawn() to Python 3.8. I am now waiting for his os.copy_file_range() function! x (Others are working on it.) https://bugs.python.org/issue26826

I am mentoring Pablo Salingo Salgado since January. I am watching his hard work since last September. He made many non trivial and useful contributions to Python.

I think that he understands well how Python is developed, is respectful, try to find answers alone before asking, and is eager to learn. In case of doubt, he ask others before doing something, like closing an issue. I trust that Pablo will respect opinions of others, like not merging a PR if someone disagree.

Pablo's merged PR: https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+

This includes closed without merging.

And reverted PRs. Adding ensure_disabled() (bpo-31356) was reverted because the implementation caused crash and core developers have doubts about usefulness of this feature at all. Adding posix_spawn() (bpo-20104) was reverted in 3.7 because it was incomplete and had many bugs. It was left in 3.8, and the work of completing and fixing it in process. PR 4003 has long review history, the final merged version is very different from the initial one. Many of other PRs are documentation fixes.

I think Pablo will be good core developer and agree with the description given by Victor. But it seems that he still needs to learn something about what changes are good for Python.

+1 With Victor's mentoring (1 or 2 months), I believe that it is reasonable to promote Pablo to a core developer either now or after 3 months of coaching.

I would also like to see Cheryl Sabella who has been very active on the bug tracker to also be promoted to a core developer as well as Emily Morehouse who has been at the Language Summit for several years.

I'm happy to trust Victor's perspective as well as Pablo being respectful of the merge process.

FWIW, I also believe that triaging issues, writing documentation, and contributing code are all valuable to the success of CPython. Without issue triage and quality documentation being valued, the users and contributors suffer a lack of information and efficiency as well as demotivating potential developers.

On Jun 13, 2018, at 1:46 PM, Victor Stinner mailto:vstinner@redhat.com> wrote:

Pablo proved its steady involvment in Python for almost one year with multiple significant contributions (new os functions). IMHO you are pushing the bar too high.

I think Pablo will be good core developer and agree with the description given by Victor.But it seems that he still needs to learn something about what changes are good for Python

On Jun 13, 2018, at 7:30 PM, Terry Reedy tjreedy@udel.edu wrote:

On 6/13/2018 7:03 PM, Carol Willing wrote:

...

+1 With Victor's mentoring (1 or 2 months), I believe that it is reasonable to promote Pablo to a core developer either now or after 3 months of coaching. I would also like to see Cheryl Sabella who has been very active on the bug tracker to also be promoted to a core developer.

A bit off topic, but I would too, as she has been extremely helpful with IDLE. We have discussed it privately and I offered to sponsor her here whenever she wants me to. At the moment, she is happy doing what she does with the time she has.

Terry Jan Reedy

Thanks Terry for discussing with her and mentoring her on IDLE :-)

---

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/

On Mon, 18 Jun 2018 at 11:17 Antoine Pitrou antoine@python.org wrote:

Le 14/06/2018 à 04:30, Terry Reedy a écrit :

...

On 6/13/2018 7:03 PM, Carol Willing wrote:

...

+1 With Victor's mentoring (1 or 2 months), I believe that it is reasonable to promote Pablo to a core developer either now or after 3 months of coaching.

I would also like to see Cheryl Sabella who has been very active on the bug tracker to also be promoted to a core developer.

A bit off topic, but I would too, as she has been extremely helpful with IDLE.

It's very nice that we're getting new active contributors. OTOH if Cheryl is mostly active on the bug tracker, does she need commit rights in order to participate properly? Or did she also review PRs or submit some of her own?

Cheryl is actually the 6th most active contributor by commits over the past year: https://github.com/python/cpython/graphs/contributors?from=2017-06-18&to=2018-06-18&type=c (IOW only Victor, you, Yury, Terry, and Ned have more commits since 2017-06-18).

On 6/18/2018 2:37 PM, Brett Cannon wrote:

On Mon, 18 Jun 2018 at 11:17 Antoine Pitrou mailto:antoine@python.org> wrote:

Le 14/06/2018 à 04:30, Terry Reedy a écrit :
 > On 6/13/2018 7:03 PM, Carol Willing wrote:
 >> +1 With Victor's mentoring (1 or 2 months), I believe that it is
 >> reasonable to promote Pablo to a core developer either now or
after 3
 >> months of coaching.
 >>
 >> I would also like to see Cheryl Sabella who has been very active
on the
 >> bug tracker to also be promoted to a core developer.
 >
 > A bit off topic, but I would too, as she has been extremely
helpful with
 > IDLE.

It's very nice that we're getting new active contributors.
OTOH if Cheryl is mostly active on the bug tracker, does she need commit
rights in order to participate properly?

On the tracker, ordinary commit rights add the little symbol after your name and add your name to the drop down lists for Assigned and Nosy. (The latter, by the way, would be a reason to de-activate people inactive after several years.)

  Or did she also review PRs or submit some of her own?

In the last year, she has submitted roughly 70 PRs, about half for IDLE, and perhaps 2/3 have been merged. I still need to review her remaining IDLE PRs. The last few I merged with little or no changed. She has done some reviews, especially when asked, but obviously prefers writing.

On Github, the main effects of commits rights are addition to the list of possible reviewers, more weight to reviews (as far as github is concerned), and the possibility of pushing changes to both the PR branch and cpython.

Cheryl is actually the 6th most active contributor by commits over the past year: https://github.com/python/cpython/graphs/contributors?from=2017-06-18&to=2018-06-18&type=c (IOW only Victor, you, Yury, Terry, and Ned have more commits since 2017-06-18).

13.06.18 23:46, Victor Stinner пише:

It's not like Pablo proposed the idea himself and force to get this feature merged. Pablo just implemented an idea proposed by two other core developers.

It looks like Pablo implements ideas for which he does not fully understand the consequences and the drawbacks. Well, his skills are not bad, but we don't need more half-baken features in the stdlib, it is better to have less but more qualitative features that fit well with the rest of the stdlib.

I don't see anything wrong here. It's not uncommon that a newly merged feature is still discussed, and I don't see anything wrong with Pablo's behaviour here. I don't see how we could prevent such further discussions on posix_spawn(). At least, I don't see how Pablo could prevent these issues.

My point was that if you count the number of merged PRs, you should exclude reverted and unfinished works.

At the end, I really like the final commit: https://github.com/python/cpython/commit/2c15b29aea5d6b9c61aa42d2c24a07ff1ed...

It adds a new rounding mode (_PyTime_ROUND_UP), write a non-trivial function test for negative timeout, has a good NEWS entry, etc.

Pablo showed that he is able to implement large change and fix all cases, not a single case. IMHO it's a good example, rather than a bad example :-)

It is just that more than a half of this work was made by you.

...

Many of other PRs are documentation fixes. Is it an issue?

No, but these PRs are much easier. And some of them just add the documentation for features added in other PRs and should not be count separately.

...

I think Pablo will be good core developer and agree with the description given by Victor. But it seems that he still needs to learn something about what changes are good for Python. Ok, I account your -1 vote.

Actually just -0. After dropping reverted PRs I have no enough information still for having a strong opinion. But I have no strong objections if you hold on to him.

In private, I told Pablo that I consider that the main difference between a core developer and a contributor is that core developers are expected to spend more time on reviews and mentoring.

The main difference is that the core developer constantly make decisions about his own and foreign patches. It is responsible for quality of merged code.

IMHO the purpose of adding a new core developer is reducing the burden for other core developers. He/she can take a part of the work, make qualified reviews and merge PRs without involving attention of BDFL or other core developers. For now, Pablo's PRs add the work for core developers.

2018-06-14 0:26 GMT+02:00 Berker Peksağ berker.peksag@gmail.com:

I don't care about total number of commits to be honest. It's not so hard to get 50 PRs merged into master in a month or so.

Wait, what? No developer got more than 50 commits merged into master in less than one month.

Stats between May, 1st and today (one month and a half, longer than one month), top 5

39 Serhiy Storchaka storchaka@gmail.com 31 Victor Stinner vstinner@redhat.com 24 Yury Selivanov yury@magic.io 18 Andrés Delfino adelfino@gmail.com 16 Ned Deily nad@python.org

Statistics on the master branch between September 1st, 2017 and today, developers with at least 20 commits:

221 Serhiy Storchaka 221 Victor Stinner 89 Yury Selivanov 67 Ned Deily 60 Benjamin Peterson 56 Terry Jan Reedy 51 Christian Heimes 41 Eric V. Smith 41 INADA Naoki 37 Antoine Pitrou 36 Raymond Hettinger 35 Steve Dower 34 Cheryl Sabella 34 Andrew Svetlov 31 Oren Milman 29 Barry Warsaw 26 xdegaye 24 Andrés Delfino 22 Eric Snow 21 Pablo Galindo 20 Berker Peksag

But if you ignore core developers, here is the top 6 most active contributors:

34 Cheryl Sabella 31 Oren Milman 24 Andrés Delfino 21 Pablo Galindo 18 Zackery Spytz 9 Paul Ganssle

I let you look at each commit to estimate how much time each contributor has spent on Python.

Note: Oh, it seems like Pablo got one commit as a different name but with same email ("Author: Dargor Pablogsal@gmail.com"). The correct number for Pablo is 22.

Note2: Pablo got 2 more commits merged into master (22) than Berker (20) ;-)

[1] According to bpo, Pablo has been active in 38 issues:

It seems that he is active, if not very active, on the bug tracker, no? But how can I compare this number to other core developers or other contributors?

Writing high quality code is not the only requirement to become a core developer. IMO, being active on bugs.p.o [1] and reviewing pull requests on GitHub [2] are more important than writing code or documentation.

I'm not sure that it works in this direction. I expect that once a developer is promoted as a core dev, they become more active on reviews and bug triage. It's my (personal) definition of the additional responsibilities of a core developer. I don't see why a contributor will spend time on reviews and bug triage before becoming a core. Writing pull requests is a good way to learn how to produce good reviews.

There are 90 core developers in the GitHub team: how many of them are regularly doing reviews and bug triage? Don't expect that a new core developer will be at least as active, if not more, than existing core developers. I'm happy if I review 5 pull requests per week. It takes a lot of time to review properly a PR.

As I wrote to Serhiy, IMHO you are putting the bar too high.

Our role is to mentor and guide contributors to make them feel part of a team and feel useful by recognizing the value of their work.

Please remind that they are very few contributors with available free time and ready to be invested in the long term.

In my experience, naturally, when a contributor is promoted, they become more active in different areas of Python: bug tracker, mailing list, devguide, etc.

My script to compute stats:

import collections import subprocess proc = subprocess.run(['git', 'log', '--after=2017-09-01', 'master'], stdout=subprocess.PIPE, universal_newlines=True) authors = collections.Counter() for line in proc.stdout.splitlines(): if line.startswith('Author: '): line = line[8:] name = line.split(' <')[0] authors[name] += 1 for name, commits in authors.most_common(): if commits < 5: break print(commits, name)

Victor

On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksağ berker.peksag@gmail.com wrote:

This isn't about my or someone else's high standards. We keep saying we need more triagers and reviewers, and we keep promoting people who didn't do any issue triaging and code review. It's not fair to contributors who have spent so much time working on these areas.

Surely the solution is to promote more people who do those things, not to turn away people making other contributions? We need more contributors of all kinds.

+1 from me.

-n

-- Nathaniel J. Smith -- https://vorpus.org

On Thu, Jun 14, 2018 at 8:06 PM Nathaniel Smith njs@pobox.com wrote:

On Thu, Jun 14, 2018 at 4:40 AM, Berker Peksağ berker.peksag@gmail.com wrote:

...

This isn't about my or someone else's high standards. We keep saying we need more triagers and reviewers, and we keep promoting people who didn't do any issue triaging and code review. It's not fair to contributors who have spent so much time working on these areas.

Just to be clear, Berker, I really appreciate the time folks (including you) put into the more thankless (and often tedious) tasks like bug triage and code review (and triaging buildbot failures). I for one need to spend more of my open-source time on that. No one should ever feel like they have to do more than their fair share.

Surely the solution is to promote more people who do those things, not to turn away people making other contributions? We need more contributors of all kinds.

I agree completely. However, Berker's concern is a real (and honest) one, regardless of its bearing on accepting new core developers. It also reflects a real, continuing problem: a shortage of folks doing bug triage/curation and code review. Unfortunately, this has a chain reaction effect by discouraging people from pursuing more involvement in core development. For instance, if someone creates a PR but it sits there for a year they eventually give up. On the other hand, sometimes aspiring core contributors question the value of giving a PR a review if a core committer is going to review it themself before possibly merging. (I realize there are good reasons for any code review, but that is the reaction I've gotten from people on occasion.)

The consequent question is how to get more people resolving open tracker issues and giving PR reviews? Off-hand, I'm not sure. :/ We've discussed this before and it's probably time to discuss it again. Any ideas?

-eric

2018-06-13 18:43 GMT+02:00 Terry Reedy tjreedy@udel.edu:

...

Pablo's merged PR:

https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+

This includes closed without merging.

...

He got 22 commits merged into master between September 2017 and June 2018.

https://github.com/python/cpython/pulls?page=2&q=is%3Amerged+is%3Apr+author%3Apablogsal&utf8=%E2%9C%93

shows 27 merged, 1 a backport. Merges were by several different people. +1

I computed the number of patches merged into master using:

$ git log master --author=Pablogsal@gmail.com|grep ^commit -c 22

Oh sorry, I posted the wrong link. I wanted to post this link: https://github.com/python/cpython/commits?author=pablogsal

I counted manually and I see again 22 changes.

Victor

Quick response:

+0.5

My first reaction was "really?" given the amount of iteration required due to lack of CPython extension module API experience demonstrated in the os.posix_spawn PRs. (I am not surprised to see Serhiy's negative reaction) But Pablo shows drive and desire to do good things and an ability to eventually do it even if there are learning bumps along the way. With mentoring and PR reviews (which I'm assuming Victor is signing up for) I believe Pablo would make a fine core developer.

So +0.5 from me. I wouldn't give Pablo free reign to make changes yet - mentoring required - but that is exactly how most of us start off while we learn. I know I started that way.

-gps

On Thu, Jun 14, 2018 at 5:06 AM Victor Stinner vstinner@redhat.com wrote:

Oh, I forgot to mention that Pablo is already helping me on triagging buildbot failures since 1 month.See my email to python-dev for the context:

"[Python-Dev] How to watch buildbots?" https://mail.python.org/pipermail/python-dev/2018-May/153754.html

You can see his emails on the buildbot-status mailing list: https://mail.python.org/mm3/mailman3/lists/buildbot-status.python.org/

Victor

2018-06-13 18:16 GMT+02:00 Victor Stinner vstinner@redhat.com:

...

Hi,

I propose to promote Pablo Salingo Salgado as a core developer and so open a vote during one week. If there is no strong opposition, I will promote him but also continue to mentor him for a least one month.

Pablo is contributing frequently to Python since almost one year. He added os.preadv()/pwritev() to Python 3.7 and os.posix_spawn() to Python 3.8. I am now waiting for his os.copy_file_range() function! (Others are working on it.) https://bugs.python.org/issue26826

I am mentoring Pablo Salingo Salgado since January. I am watching his hard work since last September. He made many non trivial and useful contributions to Python.

I think that he understands well how Python is developed, is respectful, try to find answers alone before asking, and is eager to learn. In case of doubt, he ask others before doing something, like closing an issue. I trust that Pablo will respect opinions of others, like not merging a PR if someone disagree.

Pablo's merged PR:

https://github.com/python/cpython/pulls?utf8=%E2%9C%93&q=is%3Aclosed+is%3Apr+author%3Apablogsal+

...

He got 22 commits merged into master between September 2017 and June

...

If Pablo is promoted as a core developer, I propose to continue to be his mentor for at least one month, and ask him before merging any PR.

Note: Pablo already has the bug triage permission for 5 months:

https://mail.python.org/pipermail/python-committers/2018-January/005133.html

...

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/