Core Contributor News for Sprint: Mar 29th – Apr 11th, 2025

[antoviaque (Xavier Antoviaque (OpenCraft) - opencraft.com/help)]

@itsjeyd

I don’t know the answer to that question, but what I can say is that on the repos that I’m responsible for as OSPR manager, I haven’t really been seeing CCs take action independently and assign themselves as reviewers without being prompted.

I wonder if that could be incentivized somehow? Or organized, so that the prompting is more systematic and allows to get the PRs assigned more quickly?

@itsjeyd

PR authors often don’t initiate the process themselves, and/or don’t stay as proactive as the process requires them to be.

Are there things we can do to facilitate the steps PR authors have to follow? Getting a PR merge will always require some level of proactivity, but if we can save them some steps or make them happen more quickly, that will likely help.

Also, often the motivation for an author to do work or reply on a MR is when they post it; it can quickly decrease with time, especially for new contributors - this could be a factor to take into account when trying to get better responses from authors.

Maybe there is a need to accommodate relatively small changes, so they can have a product review without requiring large budgets - otherwise we are missing on small features which don’t go all the way to have product/UX/etc resources? Maybe there could be a light version of the product review for those cases?

@Michelle_Philbrick

For edx-platform, I can check in on those more regularly if needed, that’s not an issue. The issue is getting the number of stalled PRs down. With edx-platform, there’s lots of PRs stuck needing review, some have been waiting for 6-12 months (and may not even be relevant anymore). The CCs do get occasional reminders to peek at the ones needing review, and we’re highlighting this issue more in the CC comms (like @Cassie is working on), so maybe this will start to improve a bit. I will also check internally with the Axim Eng team to get their thoughts on how to handle PRs that have beens stuck with no reviewers (regardless of repo).

These PRs that are stuck, is it because of lack of skills/experience of reviewers for the parts of the code being affected? If nobody feels they have the expertise, nobody feels they can review, then in turn nobody gets stuff merged, so nobody builds experience.

So maybe we could have a kind of roster of core contributors who volunteer to take on MRs in a part of the codebase without good reviewers, giving them explicitly permission to merge code there, since nobody else will review anyway? This way the code can live again - and maybe people contributing to it will in term become maintainers?