Mailing List Archive

On 5/12/21 4:10 PM, Terry Reedy wrote:
> On 5/12/2021 5:14 PM, Antoine Pitrou wrote:
>> On Wed, 12 May 2021 17:05:03 -0400
>> Terry Reedy <tjreedy@udel.edu> wrote:
>
>>>> Yet you always see it: new people not knowing where to start,
>>>> highly skilled contributors drowning and
>>>> intermediate contributors moving slowly
>>>
>>> I have multiple times strongly recommended that people review issues and
>>> PRs, and sometimes given details, but most won't or don't.
>>
>> I don't know who "people" are in your sentence, but reviewing issues
>> and PRs generally requires a high familiarity with a project, and
>
> Much can be done without what I think you mean by 'high familiarity'.
>
> Bug issues:
>   bpo: "On macOS with 3.8.3 I see this buggy behavior" If not enough
> info to reproduce, ask for it.  If there is, try to reproduce on lastest
> release or even better, repository build.  Sometimes, trying on a
> different OS is helpful.
>   PR: make local PR branch and test whether proposed fix works.
>
> Enhancement issues:
>   bpo: if proposal is for core python or a module one has used, does
> proposal seem like an actual improvement?  enough to be worth the likely
> bother?
>   PR: does the PR work as promised?  Do you like it?
>
> PR Python code: read it.  See any possible improvements?

In addition, starting by working in other's issues and PRs will build a
degree of familiarity with how the Python development works - what sorts
of questions get asked, what changes to a PR tend to get asked for, etc.


_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/7TVT56IK54YZOACMD4LYERV3BW23RF7G/
Code of Conduct: http://python.org/psf/codeofconduct/

On Fri, 14 May 2021, 1:47 am Stéfane Fermigier, <sf@fermigier.com> wrote:

>
>
> On Thu, May 13, 2021 at 8:42 AM Abdur-Rahmaan Janhangeer <
> arj.python@gmail.com> wrote:
>
>> Actual quote by "a Python Software Foundation fellow and contrib-
>> utor to Python infrastructure projects"
>>
>
> Ah, this is what you were referring to. The document was published 5 years
> ago, so this may or may not reflect the current situation.
>
>
>> What frustrates me most is that we have an all-time high of
>> Python developers and an all-time low on high quality contri-
>> butions.[...] As soon as pivotal developers like Armin Ronacher
>> slow down their churn, the whole community feels it immedi-
>> ately.
>>
>
> That's true, but, AFAIK, Armin was never a direct contributor to CPython
> (confirmed by looking at
> https://github.com/python/cpython/graphs/contributors ) so I guess that's
> another issue.
>


The problems mentioned in the Ford Foundation report definitely aren't
solved, but one of the contributing factors that the PSF identified at the
time was that if core projects like CPython and pypi.org are underfunded,
that poor precedent severely hurts fund raising and other sustainability
efforts in the wider Python ecosystem.

Thus efforts like the "developer in residence" role that the PSF are
currently recruiting for, as well as the increased focus on (and investment
in) ecosystem sustainability from commercial users and redistributors.

Cheers,
Nick.



>
>
>

On Thu, May 13, 2021 at 10:03 PM Stephen J. Turnbull <
turnbull.stephen.fw@u.tsukuba.ac.jp> wrote:

> *Creating* plausible issues is hard work, I assure you as a university
> professor. Coming up with "exercises" that are not makework requires
> expertise in both the domain and in educational psychology. (Some
> people are "just good at it", of course, but it's quite clear from
> popular textbooks that most are not.) I think that would be a very
> unproductive use of developer time, especially since "git clone; git
> checkout some-tag-in-2017" is pretty much what you're asking for
> otherwise.


Maybe selecting already solved issues which theoretically takes
away the pain of mimicking real-world scenarios. Great to have the
insights from someone behind the scenes of exercises

The problem is not a lack of issues to practice on. It's that (1) the
> PR process itself is a barrier, or at least an annoyance, and (2) many
> new contributors need mentoring. (Or think they do. Some just need
> encouragment, others need help on technique, but both groups are more
> or less blocked without the mentoring.)
>

I think setting up is not that hard. VStinner contributed a great piece in
the
sense of https://cpython-core-tutorial.readthedocs.io/en/latest/ if someone
gets stuck, he can ping the list or something like that . Like once you set
the project running i guess what you need is contribute or explore and
understand, both theoretically solved using the educational repo. Like you
need to find something to do before the interest wanes away. As Terry Reedy
encourages, getting more and more people to contribute ensures that at least
a couple of people passes through the vital processes need to get people
going/becoming a regular contributor. This idea aims to make this process
easier.

And, of course, real contribution involves a lot of unfun work.
> Writing tests, writing documentation, explaining to other developers
> who start out -1 because they don't get it, overcoming your own mental
> blocks to changing your submission because *you* don't get it, and on
> and on. A lot of newcomers think "I'm not good at that, if I have to
> do it I can't contribute" (and a few selfishly think they can just do
> the fun parts and achieve fame and fortune), but you know, "if not
> you, then who? If you don't do it for Python, where are you going to
> be able to contribute?"
>

Having past solved issues picked out and documented some more in increasing
level of difficulty seems to iron out the issues.


> To be honest, although I'm not a specialist in organizational behavior
> and am operating with a small sample, I can say that from the point of
> view of identifying tasks, finding solutions, and implementing them,
> Python is the most effective non-hierarchical organization I've ever
> seen. I can't say I've seen more than one or two hierarchical
> organizations that are significantly better at implementing solutions
> and don't burn up their workers in the process -- and the ones I'm
> thinking of are way smaller than Python. (Yes, I know that there are
> people who have gotten burned up in Python, too. We can do better on
> that, but Python does not deliberately sacrifice people to the
> organization.)
>

I agree that the Python community is awesome, the different WGs act like
great departments, people do give a lot of time but being subscribed in
here for some years made me see some recurring patterns. Also, while
organising FlaskCon, we got some really great insights into the community.
The usergroup page where usergroups are listed is a big lie in the sense
that
though is lists all usergroups once initiated, the real picture is way
different.
We contacted a great deal of them. Here and there there is room for
improvement
in the machinery.


> I have to point out that there's a whole crew over on corementorship
> doing this work, and at least one Very Senior Developer with their own
> private mentoring program.[1] IMO, that is a big part of why Python
> is as successful as it is. If more senior developers would take on
> these tasks it would have a big effect downstream. But emotional work
> is hard, and it comes in big chunks. In many situations you have to
> follow through, on the mentee's schedule, or the mentee will "slip the
> hook and swim away." So it's a big ask. I'm willing to make that ask
> in the abstract, but there's not even one senior developer I'm able to
> point to and say "definitely that person would do more for Python by
> mentoring than by hacking". It's a very hard problem.
>

That's why i guess what i am proposing might seem simple but it's
fundamentally
putting CPython contribution mentoring in auto-pilot mode. I've seen as i
said VStinner's
initiative and initiatives like these pay off far more than just the docs
though it can be
included in the docs, but having some tidbit liberty addresses some on the
fly issues.
But not all people have time for that as juggling work, life and OpenSource
is a great
problem to solve.

Personally i intend to help setting up the basics of it but it requires me
to become a regular
contributor, in the meanwhile, sharing some obeservations, ticking off some
todos until
i resume interest in tackling issues.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius

A really awesome book, i was proposing a by the house training.
The community is awesome, just some more twerkings needed
as you always see the lost beginner wanting mentorship, the contributors
contributing and the core-devs having no time to cater for a whole community
of mentorship seekers.

Kind Regards,

Abdur-Rahmaan Janhangeer
about <https://compileralchemy.github.io/> | blog
<https://www.pythonkitchen.com>
github <https://github.com/Abdur-RahmaanJ>
Mauritius

Recently I found cinder on GitHub created by Instagram
<https://github.com/facebookincubator/cinder>, looks like they have the
same interest of yous (speed up cpython) and might be useful team up with
them.

```
We've made Cinder publicly available in order to facilitate conversation
about potentially upstreaming some of this work to CPython and to reduce
duplication of effort among people working on CPython performance.
```

Em seg., 17 de mai. de 2021 às 12:52, Abdur-Rahmaan Janhangeer <
arj.python@gmail.com> escreveu:

> A really awesome book, i was proposing a by the house training.
> The community is awesome, just some more twerkings needed
> as you always see the lost beginner wanting mentorship, the contributors
> contributing and the core-devs having no time to cater for a whole
> community
> of mentorship seekers.
>
> Kind Regards,
>
> Abdur-Rahmaan Janhangeer
> about <https://compileralchemy.github.io/> | blog
> <https://www.pythonkitchen.com>
> github <https://github.com/Abdur-RahmaanJ>
> Mauritius
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/MASJZFLZS7SHSYT27KMECPUMD7SSGZIH/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


--
Att,
Diego da Silva Péres.

Abdur-Rahmaan Janhangeer writes:

> That's why i guess what i am proposing might seem simple

I'm saying that we already have the simple version, spelled

git clone; git checkout main~5000

then

git log -U0 main~5000..main | grep -v '^[-+ ]'

which provides very nice hints for the diligent student, including
description, file, and even line numbers.[1] Variations on that theme
will provide less detailed hints or you can cheat just a little by
replacing the "| grep" with "; sleep 2; clear". The possibilities are
endless!

The curated version you propose is, in my "I do that for $DAYJOB"
opinion, very hard to do better than that.

Steve

Footnotes:
[1] git is, in my opinion, the 42 of software development. It is the
answer to life, the universe, and EVERYTHING. :-)

_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PFBJQ7I7SDIA225RLAVD6JZ35MNCNP3U/
Code of Conduct: http://python.org/psf/codeofconduct/