I think the other way to help is to really lean into automation so reviewing is even lighterweight than it is now. Now this can be as simple as to remind people when they need to regenerate a file like 'configure' via a status check, simply telling people when their PR failed a status check, or go as far as try to automate PEP 7/8 stuff.

Or another way to put it is to try and use automation to help make PRs more self-service so that there's less required from a human being to do.

On Fri, Oct 16, 2020 at 3:31 PM Tal Einat <taleinat@gmail.com> wrote:
(Context: Continuing to prepare for the core dev sprint next week. Since the sprint is near, I'd greatly appreciate any quick comments, feedback and ideas!)

Following up my collection of past beginning contributor experiences, I've collected these experiences in a dedicated GitHub repo[1] and written a (subjective!) summary of main themes that I recognize in the stories, which I've also included in the repo[2].

A "TL;DR" bullet list of those main themes:
* Slow/no responsiveness
* Long, slow process
* Hard to find where to contribute
* Mentorship helps a lot, but is scarce
* A lot to learn to get started
* It's intimidating

More specifically, something that has come up often is that maintaining momentum for new contributors is crucial for them to become long-term contributors. Most often, this comes up in relation to the first two points: Suggestions or PRs are completely receive no attention at all ("ignored") or stop receiving attention at some point ("lost to the void"). Unfortunately, the probability of this is pretty high for any issue/PR, so for a new contributor this is almost guaranteed to happen while working on one of their first few contributions. I've seen this happen many times, and have found that I have to personally follow promising contributors' work to ensure that this doesn't happen to them. I've also seen contributors learn to actively seek out core devs when these situations arise, which is often a successful tactic, but shouldn't be necessary so often.

Now, this is in large part a result of the fact that us core devs are not a very large group, made up almost entirely of volunteers working on this in their spare time. Last I checked, the total amount of paid development time dedicated to developing Python is less than 3 full-time (i.e. ~100 hours a week).

The situation being problematic is clear enough that the PSF had concrete plans to hire paid developers to review issues and PRs. However, those plans have been put on hold indefinitely, since the PSF's funding has shrunk dramatically since the COVID-19 outbreak (no PyCon!).

So, what can be done? Besides raising more funds (see a note on this below), I think we can find ways to reduce how often issues/PRs become "stalled". Here are some ideas:

1. Generate reminders for reviewers when an issue or PR becomes "stalled' due to them. Personally, I've found that both b.p.o. and GitHub make it relatively hard to remember to follow up on all of the many issues/PRs you've taken part in reviewing. It takes considerable attention and discipline to do so consistently, and reminders like these would have helped me. Many (many!) times, all it took to get an issue/PR moving forward (or closed) was a simple "ping?" comment.

2. Generate reminders for contributors when an issue or PR becomes "stalled" due to them. Similar to the above, but I consider these separate.

3. Advertise something like a "2-for-1" standing offer for reviews. This would give contributors an "official", acceptable way to get attention for their issue/PR, other than "begging" for attention on a mailing list. There are good ways for new contributors to be of significant help despite being new to the project, such as checking whether old bugs are still relevant, searching for duplicate issues, or applying old patches to the current code and creating a PR. (This would be similar to Martin v. Löwis's 5-for-1 offer in 2012[3], which had little success but lead to some interesting followup discussion[4]).

4. Encourage core devs to dedicate some of their time to working through issues/PRs which are "ignored" or "stalled". This would require first generating reliable lists of issues/PRs in such states. This could be in various forms, such as predefined GitHub/b.p.o. queries, a dedicated web-page, a periodic message similar to b.p.o.'s "weekly summary" email, or dedicated tags/labels for issues/PRs. (Perhaps prioritize "stalled" over "ignored".)

- Tal Einat


[1]: https://github.com/taleinat/python-contribution-feedback
[2]: https://github.com/taleinat/python-contribution-feedback/blob/master/Takeaways%20-%20October%202020.md
[3]: https://mail.python.org/archives/list/python-dev@python.org/message/7DLUN4Y7P77BSDW5YRWQQGVB3KVOY2M3/
[4]: https://mail.python.org/archives/list/python-dev@python.org/thread/N4MMHXXOAL77UJLO264PCTCRJLAIKBC6/#N4MMHXXOAL77UJLO264PCTCRJLAIKBC6
_______________________________________________
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/AYSE65DUJFMFY5F7GJZSZDD252UWQENE/
Code of Conduct: http://python.org/psf/codeofconduct/