Ideas for improving the contribution experience

(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 user experiences, as in my previous post, I’ve collected these experiences in a dedicated GitHub repo and written a (subjective!) summary of main themes that I recognize in the stories, which I’ve also included in the repo.

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, which had little success but lead to some interesting followup discussion).

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

2 Likes

Hi Tal,

Another thing that I think might help would be to tidy up the open issues. For example, if you partially resolve an issue, then either summarize in a comment where things currently stand and what’s left to do, or even better - close the issue and open a new one for the remaining work. New contributors are more likely to look at issues that don’t have a patch and a long discussion attached to them.

Also, perhaps there can be a way that a core dev can indicate “I am interested in this issue and I will review PRs submitted for it”. This can be a way to prioritize open issues with respect to what the core devs want to focus on.

I also noticed some issues and PRs staying open with negative comments from several people (along the lines of “I don’t like this, maybe someone else will”). Perhaps there needs to be a process for rejecting issues and PRs. I don’t know what that process should be like, but there seems to be some awkwardness about this. I think a clear, well argued rejection is often better for the new contributor who opened the PR or issue because it will make them feel that their suggestion was evaluated and a reasoned decision has been made about it, which is better than the appearance that nobody cares enough to make a call.

1 Like