Single Responsible Person Principle (for bugs & PRs)

Topic

Indicate which topic your proposal falls under:

Overview

It’s often unclear what the next step is for a Pull Request or who is responsible for getting it reviewed/merged. This proposal says we should always have a single person clearly assigned in every case. (Same applies to bug reports / issues.)

Solution

1. A bot will manage the status of each incoming PR or issue (bug report etc.) so that it's always clear what its status is.

   1. Status is something like: waiting on author, waiting for triage, maintainer needs to assign reviewer, waiting for product review, waiting for reviewer, blocked on other work, blocked until release is cut, etc.

2. There is always a single person assigned responsibility for the next step, except for "blocked" statuses.

   1. The "waiting for" statuses always have a single person assigned to do the task. For example, when a PR is opened against frontend-app-learning, one of the maintainers (me or @farhaan) is randomly selected and the PR is assigned to, say, me to triage. The status would be “waiting for triage”, and then it’s my responsibility to prioritize the PR (e.g. low-normal-high) and assign it to a reviewer who will be able to do the review. (The maintainers are not expected to review all PRs themselves, but they are expected to be able to suggest who a good reviewer would be.) Once the maintainer assigns the priority and reviewer, it's now "waiting for review" from that assigned reviewer.

   2. The “blocked” status must always be something that the bot can monitor to know when it’s un-blocked - e.g. when an issue is resolved, another PR is merged, a release is cut, a dependency is upgraded, etc.

3. When a PR/issue is “waiting for” a specific person, the bot will post a reminder to the assigned person every ~two weeks (note: this would depend on the priority - e.g. 2 days for critical priority, 4 weeks for low priority). The assigned person can "opt out" if they aren't willing or able to do their task; in that case, the bot always re-assigns it to a new person.

4. If the assigned person doesn’t reply for ~six weeks, and/or opts out, the PR is escalated and re-assigned to a more senior person (e.g. for frontend-app-learning the escalation path would look like: assigned reviewer -> maintainer (Braden/Farhaan) -> Frontend Committer (Brian, Adolfo, Braden, Viktor) -> Super Committer (Dave, Feanil, etc.)

   1. These people can of course re-assign it as needed; they don’t have to definitely finish it themselves.

Exception 1: to reduce noise, every PR and issue will not go into this workflow automatically. Many PRs that are opened by 2U or by funded contribution partners do not need this process, and the developer already has a way to find their own reviewer. Instead, the bot will post something like “Thanks for the PR/report. Please click here if you need me to find a reviewer.” Only PRs where the author requests it in that way will become part of this “single responsible person“ OSPR workflow.

Exception 2: bug reports, once triaged, don’t need to have an assignee unless they’re high priority. In other words, low/normal priority bugs will be unassigned indefinitely until someone volunteers to take them on. Feature requests never require an assignee and will always wait until someone volunteers to take them on.

Exception 3: the bot should be aware of how many PRs/issues are assigned to each person overall, and avoid assigning each person too much work until they have cleared their queue. In some cases, this may mean that a new PR can’t be assigned to someone and instead of “waiting for [person]” it will get a “blocked on team capacity” status. This status, like all blocked status, will be automatically resolved once the queue of reviews is reduced.

Impact

Should be clearly measurable with our existing OSPR metrics like lead time Should result in a clear decrease in how long each PR spends waiting for attention and review.

Timeline

This will take some time. A guess follows:

1. Develop a prototype of the bot (1 month?) - I’m not sure if there is an existing open source bot like this or not. If so, we can start using it fairly quickly, needing only to configure it and perhaps write some plugin(s). If not, the bot should be designed in a way that it can be easily adopted and used by other open source communities.

2. Test out the bot on a few repos (3 months?), including retroactively on existing PRs.

3. Refine the bot and roll it out more widely (6-9 months)