New and one-time contributors

Making my first patch to a Python library locally, was very satisfying. After discovering the cpython git repository, it seemed that the library hadn’t been touched in 6 years. Feeling comfortable that the patch wouldn’t break other code, it seemed time to contribute this small stupid feature. A roller-coaster of feelings started.

Over the course of many days, I was reading the dev-guide, trying out anything that wouldn’t bother the python developers, changing the few lines of code constantly to be conform the PEPs, other bpo’s and other people’s code and even prepared a todo-list for the big moment of adding bpo and pr.

Reviewing and double checking everything over and over again just before hitting the submit buttons and the git push, and then in a rush of adrenaline going through the submit steps. Of course, the todo-list was missing a lot of steps that was overlooked in the huge dev-guide. But ok. With not too much hope, it was added to the 6987 bpo’s and 945 pr’s. Now patience. But to my surprise, there was fast response of Karthikeyan Singaravelan with very good instructions. Thank you. That gave hope again.

Now for weeks I’ve been following IRC, mailing lists, discuss, bugs and git. Thinking maybe I could contribute something more. But the list of bpo’s is so big, and the list of pr’s is growing also. It gives a feeling that small features, adjustments and documentation adjustments first get a triage, but then get forgotten. Giving a small poke felt wrong as I didn’t want to disturb. The fun is probably working on future features deep in the core, what I understand, and other features are much more important and bigger and needed.

Probably a big amount of the bpo/pr’s can get a closed status with ‘out of date’/‘duplicate’/‘won’t fix’ resolution. What if each week, each core developer finds 5 to just set to close status, that doesn’t need work or is out-dated or got irrelevant or the contributor didn’t sign the Contributor Agreement. 75 core devs x 5 closes is 375 a week. Within 3 months it would be much more breathable to go through the bpo/pr’s.

Still, this experience is great. A good source to bump into libraries and ideas to try out. Even tried out cpython and cyton for the first time and won’t be last time. Even thinking of adding some PR’s about the dev-guide issues I ran into. But as said, I don’t want to pollute the long list much more for now.

If I would have more knowledge and find time to help, but I need many more years following all these forums, mailing lists and read much more code to feel comfortable.

2 Likes

Hi @aldwinaldwin,

Thanks for taking time to contribute back. I hope some one gets to cmd.py PR you have raised https://github.com/python/cpython/pull/13536

The dev document is available in GitHub at http://github.com/python/devguide in case you want to propose a change. There is also https://discuss.python.org/c/core-workflow to discuss workflow related questions.

Since it’s all unpaid volunteer time it’s hard for everyone to close out 5 issues a week. The beta release got a lot of PRs merged bringing open PR count to below 1000. Also some of the issues don’t get a straightforward resolution since it depends on agreement during the discussion, module maintainer’s availability, language design etc. Any attribute that is added and documented as part of stable release has to be supported till EoL for the release which is 5 years. Adding and removing a public API requires a deprecation period of one stable release to be removed in the next cycle so any addition would remain in use for next 10 years for the two cycles and has to be supported too. So even if there is a small change and it’s on a part of standard library untouched for many years it would require more attention and some one has to volunteer to commit. This is not to imply modules don’t accept improvement but that rate of change/acceptance to a module unless there is a maintainer to it could be low.

@xtreak
Again you pointed me to more interesting information (pep581), discussions (triage team) and workflows. The workflow is good, but so much to be aware of and old discussions to catch up with.

What I meant, is to change issues to a close status without any development. They could be always reopened again by the creators if they still want it. Situations like these:

‘open’ since 2008: https://bugs.python.org/issue2628
=> 4000 issues didn’t had any activity in last 15 months. around 5200 not in last 6 months. will they ever get attention again?

‘awaiting changes’: User posted a pr but didn’t come back for the changes like:
https://github.com/python/cpython/pull/1210 : awaiting changes since Oct 2017. (multiple pr’s of this user louisom it seems)
=> difficult to check how many of the ‘awaiting changes’ don’t have activity. It seems brettcannon went through many of them already.

So, suggestion:
=> if no activity for 3 months then send message like brettcannon does (“Try to help move older pull requests forward, …”) with a bot and set status ‘awaiting changes little more’.
=> if no activity for other 3 months then set status closed due to no activity with message they are always welcome to reopen.

Result? One time/new contributors would stay little more alert and get triggered faster to make the needed changes or restart their discussion if they are really interested in a fix or feature. Also bringing the bugs list to actually relevant 2000 recent issues would be nicer to go through to find ‘easy’ issues and improve the result of the ‘random issue’ function.

‘open’ since 2008: https://bugs.python.org/issue2628

You know what would be helpful for an eleven year old patch like
that?

For somebody to check that the patch still applies to the current
version without breaking anything, that the tests are sufficient, write
a “What’s New” blurb, etc. If it doesn’t apply, to patch the patch or
write a new patch. You don’t have to have commit privileges to
(unofficially) review a patch or to bring it up to date.

Of course a core dev still has to give it a final check before
committing, but unprivileged users can help restart stalled tasks.

[…]

So, suggestion:
=> if no activity for 3 months then send message like brettcannon does (“Try to help move older pull requests forward, …”) with a bot and set status ‘awaiting changes little more’.
=> if no activity for other 3 months then set status closed due to no activity with message they are always welcome to reopen.

Result? One time/new contributors would stay little more alert and get
triggered faster to make the needed changes or restart their
discussion if they are really interested in a fix or feature.

Often the bottle neck is the core devs, not the new contributor. In my
opinion, closing tickets written by new contributors because the core
devs don’t have time to review them is going to discourage new
contributors even more badly than having a ticket stay dormant.

1 Like