[DRAFT] Maintainer Deferral Policy

[Princess-Cheeseballs]

Overview

Adds a deferral policy to maintainer policy to let maintainers do partial reviews of specific segments of a PR relevant to their expertise.

This is to hopefully cut down on the workload of some maintainers and streamline review processes for large technical and blocking PRs such that those with expertise don't have to dedicate an entire review to these PRs.

Why

There's a lot of reasons why genuinely.

This is already kind of a soft policy but it doesn't work very well since it's not organized and extremely taxing. We have PRs we call "Sloth PRs" PRs only Slarti can review, PRs technical enough we need a wizard or lead maintainer to review them and right now the system of pinging and review begging doesn't work.

Stuff slips through the cracks, things get left behind, work piles up and eventually things get merged without proper review because that's the only option and all you can do is hope that it works based on the research, review, and testing you've done.

This Policy change aims to optimize and streamline a big undocumented part of the review process and limit it to hopefully make it go by faster.

This policy aims to do this by:

• Defining when a review should be deferred to another maintainer (Aka for important blocking PRs, important bugfixes, and otherwise unnamed important PRs such as experimental tags and in game feedback).

• Better organizing deferring so things don't get lost, by defining a deferred review a maintainer can know and should expect that what's being asked of them is important enough to another maintainer to not be just another review.

• Limiting the scope of deferrals so maintainers with a lot of codebase knowledge aren't overwhelmed. This is mostly for Slarti and PJB who have a lot of work already so that they can give their feedback and approval on a PR without having to leave a full review and have the expectations and oversight that comes with a full review.

• Facilitate learning. Deferred reviews also give an opportunity to teach and learn about parts of the codebase. Since you're no longer asking a maintainer to simply do the review for you but instead look at problem parts of code, it gives opportunity to share knowledge about the codebase and code in general that can improve code quality and review going forward.

[VerinSenpai]

should there be any clarification about what has been reviewed vs what hasn't?

[Princess-Cheeseballs]

should there be any clarification about what has been reviewed vs what hasn't?

As in if a deferral was part of a review? Probably yeah.

[K-Dynamic]

Should probably specify when and why a deferral exists.

e.g. the code/balance/licensing is too complicated to explain or understand but someone else knows

[K-Dynamic]

1. If there's a lot of deferrals to the same people for the same code/balance/licensing issue, that could indicate a lack of knowledge among staff; it might be worth trying to train or teach staff said missing knowledge so there are fewer deferrals.
2. Would deferrals share equal responsibility for a review or are they only responsible for the sections that have reviewed?