Codeowners Policy

src/SUMMARY.md

@@ -356,6 +356,7 @@ Staff
   - [Useful Maintainer Tools](en/wizden-staff/maintainer/maintainer-tools.md)
   - [Maintainer Policy](en/wizden-staff/maintainer/maintainer-policy.md)
   - [Workgroup Policy](en/wizden-staff/maintainer/maintainer-workgroup-policy.md)
+  - [Codeowners Policy](en/wizden-staff/maintainer/codeowners-policy.md)
   - [Reviewing Procedure](en/wizden-staff/maintainer/review-procedure.md)
   - [Review Whitelist](en/wizden-staff/maintainer/review-whitelist.md)
   - [Hotfix Procedure](en/wizden-staff/maintainer/hotfix-procedure.md)

src/en/wizden-staff/maintainer/codeowners-policy.md

@@ -0,0 +1,55 @@
+# Codeowners Policy
+This document outlines the Codeowners policy, a permission granted to Maintainers by Lead Maintainers.
+
+This permission allows them to process and merge pull requests on their own accord, including pull requests authored by the codeowner.
+
+## Goals
+The codeowners policy aims to achieve the following:
+1. **Increase velocity and turnaround time for pull requests that touch a system when no maintainer is available for review.**
+   1. Many abandoned/derelict systems have been adopted by a maintainer who now knows the system extensively. Oftentimes, work on a system is blocked by pull requests that would normally require another maintainer to re-learn the system in order to give a proper review. This results in work being stalled for months, as learning the system is often a great effort that is not feasible to exert.
+
+## Policy
+
+### Supervision
+Maintainers who perform codeowner actions are overseen by the Lead Maintainers.
+
+They are to make sure that the aforementioned policy is followed.
+
+### Formation
+Maintainers are granted codeowner permissions for their chosen system by a Lead Maintainer.
+Lead Maintainers can also deny the permissions if they do not deem the maintainer to be fit for the system, or if the requested system is undefinable in scope.
+
+A maintainer can request codeowner permissions in any format, but it should ideally be in a space where it is documented and the active maintainer team knows about it (ex. a maintainer meeting).
+
+Maintainers should only be granted codeowner permissions if it has been persistently demonstrated that there is no other maintainer available to review the other maintainer's pull requests in a reasonable timeframe.
+
+### Revocation
+Lead Maintainers may revoke codeowner permissions from a maintainer at any time.
+Revocation is usually due to the following reasons:
+- The maintainer has refused to implement tests or demonstrate performance improvements via benchmarks.
+- The maintainer is merging large swaths of undocumented code.
+- The maintainer exercises negligence in making sure that their code does not contain bugs.
+- The maintainer is present for submitting and merging pull requests, but largely absent when bugs caused by them need fixing.
+
+### Scope
+The system that the maintainer chooses to become a codeowner for must be definable in scope.
+Maintainers cannot simply request to claim all `EntitySystem`s, rather the request must be for a specific group of systems or mechanic that the maintainer is familiar with. Examples include:
+- Atmospherics
+- Solutions
+- Physics
+- Explosions
+- Pow3r
+
+### Permissions and Requirements
+Maintainers with codeowner permissions have greater power over their area, however they must furfill specific requirements before exercising it.
+1. **Codeowners can process pull requests targeting their scope by themselves.**
+   1. No second review is required for merging.
+   2. Codeowners can process their own pull requests (self-merging).
+   3. The pull request must have tests that properly cover the changes.
+   4. If the pull request targets performance improvements, the improvements must be demonstrated by a benchmark.
+   5. The pull request must be open for at least 3 days before merging.
+
+There is no restriction for regular maintainers processing pull requests that touch a scope claimed by a codeowner.
+However, it is recommended that maintainers, when doing so, defer to the codeowner in question.
+
+

src/en/wizden-staff/maintainer/review-procedure.md

@@ -92,6 +92,12 @@ There are some exceptions to the one-approval or two-approval system. They are l
 3. **Changes targeting a [Maintainer Workgroups](maintainer-workgroup-policy.md)'s game area must be approved by a member from the workgroup.**
    1. Workgroup members can self-approve changes targeting their own workgroup.
 4. **Rule or server configuration changes require the approval, either written or on GitHub, of the Head Game Admin or infrastructure team.**
+5. **Changes targeting a [codeowner](codeowners-policy.md)'s scope can be approved and processed by a single codeowner.**
+   1. The changes must have tests that fully cover the changes that the pull request makes.
+   2. If the changes are targeting performance improvements, the improvements in question must be demonstrated by a benchmark.
+   3. Codeowners can self-approve their own changes targeting the codeowner's scope; the above requirements must be met before merging.
+   4. The pull request must be open for at least 3 days before it is merged by a single codeowner.
+   5. The fact that a scope is owned by a codeowner does not prevent other maintainers from processing a pull request via the normal review procedure; it is recommended to defer to the codeowner.
 
 ### Closing PRs
 Pull requests can be closed in two ways: