Re: [python-committers] RFC: Process to become a core developer

[Nick Coghlan]

On 8 December 2017 at 04:21, Antoine Pitrou  wrote:
>
> 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.

I'll note that one thing that *has* changed since then is that we've
been putting a lot more emphasis on software distribution via PyPI.

Part of that is the Python 2.7 feature freeze (so if you've wanted to
deliver new functionality to Python 2 users, you've *had* to use PyPI,
even if you're already a core developer), part of it has been improved
tooling and other enhancements (pip was first released in 2011, and
first bundled with CPython in early 2014), and part of it has simply
been recognition that CPython rollout cycles through the full
redistributor network are inherently slow (even 7 years after its
initial release, Python *2.7* is at less than 100% penetration, with
some infrastructure projects only just beginning to drop Python 2.6
support now).

So while better enabling folks to bypass us entirely may seem like a
weird thing to celebrate, I think it actually is worth celebrating,
since it takes both us and our redistributors out of the critical path
for the evolution of the Python ecosystem as a whole - we can serve
more as popularisers of concepts & techniques initially defined
elsewhere, rather than having to drive that exploration of the
available design space ourselves.

I think we've also had a lot of success in bringing the developer
experience for core devs and non-core-devs closer together - while
*technically* we can push directly to the main repository, very few of
us actually do so. Even when we end up self-reviewing a change, we'll
still typically run it through the PR process so Travis et al get a
chance to run their pre-merge checks. Changing from "I need someone
else to push the merge button for me" to "I push the merge button" is
now more a difference in level of responsibility than it is a marked
change in the contribution experience.

That said, I'm still happy that Victor is taking the initiative to
investigate our processes here, and look to make things a bit more
objectively data-driven - when volunteers are mentoring and managing
other volunteers, it's even easier for unconscious biases to come into
play than it is in a more explicitly professional setting.

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/

Re: [python-committers] Official python-dev docker images

[Nick Coghlan]

On 8 December 2017 at 13:14, Barry Warsaw  wrote:
> 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?

Yeah, I'd advise the same: the CPython compatibility testing images
should provide unpatched builds. That way, checking against the
upstream builds becomes a first step in triage for problems
encountered with redistributor builds: if a problem only shows up in
the distro version, then distro specific patches would be the first
place to look.

Cheers,
Nick.

P.S. This thread would probably be better located on python-dev :)

-- 
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/

[python-committers] Proposed schedule for next 3.4 and 3.5 releases - end of January / early February

[Larry Hastings]

Howdy howdy.  I know nobody's excited by the prospect of 3.4 and 3.5 
releases--I mean, fer gosh sakes, neither of those versions even has 
f-strings!   But we're about due.  I prefer to release roughly every six 
months, and the current releases came out in early August.


Here's my proposed schedule:

   Sun Jan 21 2017 - release 3.4.8rc1 and 3.5.5rc1
   Sun Feb 04 2017 - release 3.4.8 final and 3.5.5 final

Unless I'm presented with good reasons to change it, that'll be the 
schedule.  I'll update the PEPs with the final release dates in about a 
week.


Just for fun, I'll remind everybody here that 3.4 and 3.5 are both in 
security-fixes-only mode.  This means two things:


1. These will be source-code-only releases; the Python core dev team
   won't release any more binary installers for 3.4 or 3.5.
2. I'm the only person permitted to accept PRs for 3.4 and 3.5. If you
   have security fixes for either of those versions, please add me as a
   reviewer.


Happy holidays to you and yours,


//arry/
___
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

[Victor Stinner]

Ezio:
> Nowadays the situation is much better, Python is more stable and
> mature, and what's left is more difficult, obscure, or controversial.
> There are still new modules and features being added and ISTM that
> most of the new core devs are working on those (e.g.
> asyncio/typing/etc), but otherwise finding new easy issues is becoming
> increasingly more difficult.

Hey, I really like your very positive view on CPython ;-) You made my day!

Python is moving closer to perfection!

"Perfection is Achieved Not When There Is Nothing More to Add, But
When There Is Nothing Left to Take Away"

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?

[Ezio Melotti]

On Fri, Dec 8, 2017 at 5:32 PM, Victor Stinner  wrote:
> 2017-12-08 17:19 GMT+01:00 Ezio Melotti :
>>> Aha. Maybe we need some tooling, like statistics on contributions to the
>>> bug tracker, just to detect earlier active "bug triagers"?
>>>
>>
>> This can be done (e.g. the famous highscores page we have been talking 
>> about).
>
> My opinion on such statistics is that they must not be public. I don't
> want to reward the highest number of contributions. As I wrote in the
> process documentation, what matters is the quality and kind of the
> contributions, and also the commitment.
>
> But a private tool, only accessible to core dev for example, would
> easy the work of identifying active contributors.
>

It doesn't necessarily have to be based solely on number of
contribution.  Twisted uses a formula that rewards different kind of
contributions differently.  In theory there could also be different
leaderboards based on number of commits, lines of code, PR submitted,
reviews done, PR/issues closed, etc.  I trust that if we ever get
around implementing this, the contributors won't abuse it, and to
prevent that we can simply add a line saying something like "The
number of contribution doesn't take into account the quality or the
complexity of the contributions.".
I don't think it should be private, as one of its main purposes is to
recognize the work of the contributors, not only by us, but also by
themselves and other contributors.

>
>> There are however other triagers that just go through the issues and
>> adjust fields or comment, even if they have no intention of working on
>> the issue itself.
>> While it's technically true that there might be people that want to
>> triage but not contribute code, most of them do contribute, and triage
>> while going through the issues.
>
> Hum, as Ned Deily wrote, some people don't want to become core
> developers and are fine to contribute as regular contributors. I
> should clarify this in the document.
>
> By the way, since the migration to Git and GitHub, contributing
> without being a core dev became simpler IMHO.
>
>
>>> My hope is that many contributors are potential core developers but were
>>> stuck somewhere, and failed to get the right documentation or mentor to
>>> unblock them.
>>>
>>
>> This is a good point, but indeed, how many are contributing with the
>> goal and hope of becoming core devs?  How many are contributing
>> because they like the project, and would be happy to become core devs?
>>  How many are just scratching a itch but otherwise have no desire to
>> contribute to other aspects of the project?
>> Finding an answer to these questions might help understanding where
>> are the problems that need to be addressed.
>
> Ow, these are tricky questions! Maybe a poll sent to contributors, or
> to python-dev, would help?
>
> 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] Licences for PyCharm and other JetBrains products

[Vinay Sajip via python-committers]

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
___
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?

[Victor Stinner]

2017-12-08 17:19 GMT+01:00 Ezio Melotti :
>> Aha. Maybe we need some tooling, like statistics on contributions to the
>> bug tracker, just to detect earlier active "bug triagers"?
>>
>
> This can be done (e.g. the famous highscores page we have been talking about).

My opinion on such statistics is that they must not be public. I don't
want to reward the highest number of contributions. As I wrote in the
process documentation, what matters is the quality and kind of the
contributions, and also the commitment.

But a private tool, only accessible to core dev for example, would
easy the work of identifying active contributors.


> There are however other triagers that just go through the issues and
> adjust fields or comment, even if they have no intention of working on
> the issue itself.
> While it's technically true that there might be people that want to
> triage but not contribute code, most of them do contribute, and triage
> while going through the issues.

Hum, as Ned Deily wrote, some people don't want to become core
developers and are fine to contribute as regular contributors. I
should clarify this in the document.

By the way, since the migration to Git and GitHub, contributing
without being a core dev became simpler IMHO.


>> My hope is that many contributors are potential core developers but were
>> stuck somewhere, and failed to get the right documentation or mentor to
>> unblock them.
>>
>
> This is a good point, but indeed, how many are contributing with the
> goal and hope of becoming core devs?  How many are contributing
> because they like the project, and would be happy to become core devs?
>  How many are just scratching a itch but otherwise have no desire to
> contribute to other aspects of the project?
> Finding an answer to these questions might help understanding where
> are the problems that need to be addressed.

Ow, these are tricky questions! Maybe a poll sent to contributors, or
to python-dev, would help?

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] RFC: Process to become a core developer

[Victor Stinner]

2017-12-08 14:19 GMT+01:00 Ezio Melotti :
> In my opinion, the role of the mentor should boil down to:
> 1) be a reference for the new core dev and be available in case
> everything else fails (e.g. if no one else answers a question);
> 2) be responsible for the mistakes the new core dev might make (e.g.
> help fixing up a bad merge or a broken buildbot caused by the new core
> dev).
> The mentor shouldn't babysit the new core dev and be in the only point
> of contact.

I can only agree with you on these points :-)

> The new core dev should:
> 1) interact with the other core devs and the community in general;
> 2) reach to the mentor only when necessary (i.e. no one else replied,
> something import/urgent/"personal").

Hum, maybe the process document should give a few pointers to the
proper place to ask questions at each step? For example,
core-mentorship before coming a core, and then maybe more on
python-committers after becoming a core?

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?

[Ezio Melotti]

On Thu, Dec 7, 2017 at 11:20 PM, Victor Stinner
 wrote:
> (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.
>

While most of these suggestions seem to help define the process, ISTM
they are also making it more bureaucratic.

>
> 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"?
>

This can be done (e.g. the famous highscores page we have been talking about).

> 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".
>

With this I agree, and as I mentioned below, I think all core devs
should have the triage bit and know how to use it.

> 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?
>

All core devs should have the triage bit, even though many of them are
only interested in using it for the issues they are working on.
There are however other triagers that just go through the issues and
adjust fields or comment, even if they have no intention of working on
the issue itself.
While it's technically true that there might be people that want 

Re: [python-committers] Promote Julien Palard as core developer

[Victor Stinner]

2017-12-08 16:32 GMT+01:00 Victor Stinner :
> I declare the vote done and wish welcome to our new core developer,
> Julien Palard!  ✨    ✨

I added Julien to the Devguide:
https://github.com/python/devguide/commit/f414589365e8d3808eaef3cf9f2b7370314133a1

I will now see with him for the other steps (GitHub organization,
subscribe to python-committers).

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] Adding Ivan Levkivskyi as a core committer

[Ivan Levkivskyi]

Thank you, Victor!

--
Ivan



On 8 December 2017 at 16:47, Victor Stinner 
wrote:

> 2017-12-06 17:57 GMT+01:00 Mariatta Wijaya :
> > Please add Ivan to the Developer Log in Dev Guide, and he should
> subscribe
> > to python-committers mailing list :)
>
> I added Ivan to the Devguide:
> https://github.com/python/devguide/commit/f414589365e8d3808eaef3cf9f2b73
> 70314133a1
>
> 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/

Re: [python-committers] Statistics: growth of core dev number vs growth of the code size/complexity

[Ezio Melotti]

On Thu, Dec 7, 2017 at 8:43 PM, Brett Cannon  wrote:
>
>
> 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.
>

Here is a breakdown:
2443 behavior
2124 enhancements
224 crash
170 compile error
125 resource usage
104 performance
44 security


>>
>>
>> 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.
>

I think it also has to do with the maturity of the project.

When I started I remember I wanted to fix some issue and when I ran
the whole test suite I had at least a dozen failing on my machine, so
I went and fix those as well.  But to fix those I needed to add more
stuff to test.support and to regrtest, and so I did.  Then those
changes needed to be documented, but the documentation was missing.
So I started improving the documentation and even after all that was
done there were still plenty of low hanging fruits on the bug tracker
or other issues to work on.  Then Python 3 came, and there was more
work to be done.

Nowadays the situation is much better, Python is more stable and
mature, and what's left is more difficult, obscure, or controversial.
There are still new modules and features being added and ISTM that
most of the new core devs are working on those (e.g.
asyncio/typing/etc), but otherwise finding new easy issues is becoming
increasingly more difficult.

Best Regards,
Ezio Melotti
___
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] Adding Ivan Levkivskyi as a core committer

[Victor Stinner]

2017-12-06 17:57 GMT+01:00 Mariatta Wijaya :
> Please add Ivan to the Developer Log in Dev Guide, and he should subscribe
> to python-committers mailing list :)

I added Ivan to the Devguide:
https://github.com/python/devguide/commit/f414589365e8d3808eaef3cf9f2b7370314133a1

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] Promote Julien Palard as core developer

[Victor Stinner]

Wow, I didn't expect such warmly welcome for Julien Palard!

I counted 6 positive votes (Nick, Zachary, Ethan, Mariatta, Ned,
Carol), in addition to my implicit positive vote.

I declare the vote done and wish welcome to our new core developer,
Julien Palard!  ✨    ✨

I will now follow
https://devguide.python.org/coredev/#gaining-commit-privileges process
for the practical part.

Victor

2017-12-07 1:48 GMT+01:00 Victor Stinner :
> Hi,
>
> I propose to promote Julien Palard as a core developer.
>
> Julien Palard is leading the french translation of the Python
> documentation since 2 or 3 years. He spent a lot of time to try to get
> this translation online. Since he was unlucky on the python-ideas
> mailing list, I convinced him to write down a PEP. He wrote it with
> Naoki INADA (who is translated the documentation to Japanese) and me.
> It wasn't easy to write the PEP and get it approved: it took almost 1
> year and a half! The PEP 545 was approved and implemented in Python
> 3.7!
>
>https://www.python.org/dev/peps/pep-0545/
>
> Thanks to Julien (and others), translated documentations are now online at:
>
>   https://docs.python.org/fr/ -- French
>   https://docs.python.org/ja/ -- Japanese
>
> See also the What's New in Python 3.7 entry:
> https://docs.python.org/dev/whatsnew/3.7.html#documentation
>
> Julien spent a lot of time to fix a lot of various issues in the
> documentation, the docsbuild-scripts project used to build the CPython
> documentation, Sphinx, etc. to be able to translate properly the
> documentation.
>
> For me, the documentation and the docsbuild-scripts project are
> tightly coupled to the CPython project. Last june, I even asked to
> give the commit bit to Julien on the
> https://github.com/python/docsbuild-scripts/ project on this list,
> since I expected that this project was part of CPython (it isn't, it's
> another "team" on GitHub, if I understood correctly) :-) In the
> meanwhile, Julien became a "core developer" on this project as well.
>
> He also worked closely with the Python infra team to fix a few bugs
> when the translated documentation was published at python.org.
>
> To come back to CPython itself, Julien Palard already got 18 commits
> merged into the master branch since January 2016: 11 before GitHub
> ("patch by Julien Palard") + 7 since CPython migrated to GitHub
> ("Julien Palard" author). Most of his commits are related to the
> Python documentation content and tooling to build the documentation.
> He fixed "bugs" in the documentation, to clarify some documentation.
>
> Giving him the commit bit would ease his work, since too few people
> are looking at these areas of the code. When I reviewed his patches,
> they are usually good after one or two iterations, and Julien welcomes
> criticism.
>
> 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. But I believe (because he told me so
> ;-)) that Julien will slowly contribute to other areas of the code,
> once he will feel more confortable, and I may guide him in the code if
> needed. I think that many of us started to contribute to a project on
> its documentation ;-)
>
> I don't think that he needs an official menthor since he already knows
> well the CPython workflow, and he knows how to ask questions if needed
> ;-)
>
> 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".
>
> 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] RFC: Process to become a core developer

[Ezio Melotti]

On Thu, Dec 7, 2017 at 11:38 PM, Victor Stinner
 wrote:
> 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.
>

In my experience, contributors that get promoted to core devs are
usually already experienced, but they might not be familiar with all
the quirks of CPython development and they will likely have a few
CPython-specific questions.
When I became a core dev I don't remember having an official mentor. I
had several different questions (should I backport this to Python 2.3?
 how do I use svnmerge? how do I create a wide unicode debug build?
which rst role should I use to document X?) and always received a
timely reply from several different people, depending on who was
available and their main area of expertise (also note that there was
no devguide back then :).

In my opinion, the role of the mentor should boil down to:
1) be a reference for the new core dev and be available in case
everything else fails (e.g. if no one else answers a question);
2) be responsible for the mistakes the new core dev might make (e.g.
help fixing up a bad merge or a broken buildbot caused by the new core
dev).
The mentor shouldn't babysit the new core dev and be in the only point
of contact.

The new core dev should:
1) interact with the other core devs and the community in general;
2) reach to the mentor only when necessary (i.e. no one else replied,
something import/urgent/"personal").


For GSoC the situation is different:
1) GSoC students have to work on a specific project with specific
goals, requirements, and deadlines;
2) GSoC students are usually less experience and need to be followed,
guided, and sometimes pushed;
3) Given its breadth and maturity, CPython itself is not a
particularly good candidate for GSoC projects.

Best Regards,
Ezio Melotti

> 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
>