Change: Maintainership update

docs/guidelines/content/achievement-set-revisions.md

@@ -240,34 +240,4 @@ Revision voting is currently dev-only. While voting is exclusive to Discord, ple
 - All revision types require you to contact active authors of the set and any developer with an active claim.
 - You may contact them in any manner in which you can be reasonably certain they will see it (DMs preferred)
 - If you believe you may be blocked by the user, send a message to [DevCompliance](https://retroachievements.org/createmessage.php?t=DevCompliance&s=Revision%20Contact%20Request%20-%20[Author%20Name]) asking them to contact the author on your behalf. The 72hr maximum wait time will begin upon sending the message to DevCompliance. When doing so, state the user's name, type of revision, and the brief description of what your revision entails as if you were contacting the author directly.
-- Some authors opt out of requiring contact. Check the [Public Opt-Out Sheet](https://docs.google.com/spreadsheets/d/e/2PACX-1vRRSNI9R-ezC0ma7x2BoU2JiZgMu26iht-sIPc56otfJa2sd_8QQCO-V4JXbfsfSUbrl54wib68-Pjp/pubhtml?gid=1195161231&single=true). If the author is listed as opting out of the revision type, they do not need to be contacted. To update your own Opt-Out information, use [this form](https://forms.gle/mgzv7RHbJEPCrxc77).
-
-## Maintainer Role Purpose and Qualification
-The achievement Maintainer role allows a developer to assume responsibility for an achievement. Future tickets and unlock credit will be assigned to achievement maintainers and maintainership is effectively a transfer of ownership. The original author does not lose authorship credit, ticket history, or unlock credit that occurred prior to the assignment of a new maintainer. If a maintainer loses or relinquishes the role, new tickets and unlocks will return to being given to the author. A maintainer can be assigned to an entire set or a portion of the achievements depending on which achievements were fixed. The maintainer role may only be approved and assigned by the DevCompliance team.
-
-Maintainership requests will be considered on a case by case basis for significant repairs. Correcting set-significant instability issues is the biggest factor when considering approval of the maintainer role. If a maintainer loses or leaves the role, new tickets and unlocks will return to being given to the original author until a new maintainer is assigned.
-
-### What May Qualify for Maintainership?
-A good candidate for maintainership will meet many of the following criteria:
-
-- Set demoted for necessary repairs by QA-Maintainers.
-- Existing logic was fundamentally flawed for the set or for a category of achievements and needed to be replaced in all of the affected achievements.
-- Problems in the set were causing regular tickets or other problematic quality issues.
-- Significant New RAM digging needed to be done to find replacement addresses or better addresses to use to accomplish the goals.
-- Significant logic re-work was necessary for proper functionality and stability.
-- Very few, if any logic conditions were retained in the new logic.
-- Any retained logic conditions were not the most important piece of data for functionality.
-- One-condition achievements where the final product is vastly changed.
-- Adding hash or language support requiring a rewrite that significantly changed the approach to logic.
-- Requestor has a history of fixing tickets in the set.
-- All tickets in the set have been resolved or closed.
-
-### What Shall Not Qualify for Maintainership?
-Writing new logic for previously stable achievements is not sufficient to warrant maintainership.  Poor candidates include, but are not limited to:
-
-- Logic reworked that did not exhibit any issues (i.e. not prone to tickets or exploits).
-- A main change was simply adding Delta checks.
-- A main change was simply adding an in-game/in-stage, or other similar guarding condition.
-- Only added protection such as save protection, demo protection, or cheat protection.
-- Updating outdated logic of otherwise functional achievements to be in line with modern toolkit features and standards.
-- Relatively simple "drive-by" ticket fixes.
+- Some authors opt out of requiring contact. Check the [Public Opt-Out Sheet](https://docs.google.com/spreadsheets/d/e/2PACX-1vRRSNI9R-ezC0ma7x2BoU2JiZgMu26iht-sIPc56otfJa2sd_8QQCO-V4JXbfsfSUbrl54wib68-Pjp/pubhtml?gid=1195161231&single=true). If the author is listed as opting out of the revision type, they do not need to be contacted. To update your own Opt-Out information, use [this form](https://forms.gle/mgzv7RHbJEPCrxc77).

docs/guidelines/developers/maintainership.md

@@ -0,0 +1,35 @@
+---
+title: Maintainership
+description: Description of maintainer role, role request, and approval process.
+---
+
+# Maintainer Role Purpose and Qualification
+The achievement Maintainer role allows a developer to assume responsibility for an achievement. Future tickets and unlock credit will be assigned to achievement maintainers and maintainership is effectively a transfer of ownership. The original author does not lose authorship credit, ticket history, or unlock credit that occurred prior to the assignment of a new maintainer. If a maintainer loses or relinquishes the role, new tickets and unlocks will return to being given to the author. A maintainer can be assigned to an entire set or a portion of the achievements depending on the scope of work that was done. The maintainer role may only be approved and assigned by the QA team.
+
+Maintainership requests will be considered for significant repairs on a case by case basis. Correcting set-significant instability issues is the primary factor when considering approval of the maintainer role. Because the Maintainer role grants future credit to the maintainer, the work done to receive the role must amount to fixing significant instability. Poorly coded, but otherwise stable achievements are not eligible for maintainership consideration.
+
+[[toc]]
+
+## What May Qualify for Maintainership?
+A good candidate for maintainership will meet many of the following criteria:
+
+- Set demoted for necessary repairs by QA-Maintainers.
+- Existing logic was fundamentally flawed for the set or for a category of achievements and needed to be replaced in all of the affected achievements.
+- Problems in the set were causing regular tickets or other problematic quality issues.
+- Significant New RAM digging needed to be done to find replacement addresses or better addresses to use to accomplish the goals.
+- Significant logic re-work was necessary for proper functionality and stability.
+- Very few, if any logic conditions were retained in the new logic.
+- Any retained logic conditions were not the most important piece of data for functionality.
+- One-condition achievements where the final product is vastly changed.
+- Requestor has a history of fixing tickets in the set.
+- All tickets in the set have been resolved or closed.
+
+## What Shall Not Qualify for Maintainership?
+Writing new logic for previously stable achievements is not sufficient to warrant maintainership.  Poor candidates include, but are not limited to:
+
+- Logic reworked that did not exhibit any issues (i.e. not prone to tickets or exploits).
+- A main change was simply adding Delta checks.
+- A main change was simply adding an in-game/in-stage, or other similar guarding condition.
+- Only added protection such as save protection, demo protection, or cheat protection.
+- Updating outdated logic of otherwise functional achievements to be in line with modern toolkit features and standards.
+- Relatively simple "drive-by" ticket fixes.