From a4a30217ee05006961d4ed2592150e0539b20844 Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:04:23 -0800 Subject: [PATCH 01/14] rename --- .../{review-procedure.md => code-review-procedure.md} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) rename src/en/wizden-staff/maintainer/{review-procedure.md => code-review-procedure.md} (99%) diff --git a/src/en/wizden-staff/maintainer/review-procedure.md b/src/en/wizden-staff/maintainer/code-review-procedure.md similarity index 99% rename from src/en/wizden-staff/maintainer/review-procedure.md rename to src/en/wizden-staff/maintainer/code-review-procedure.md index 6f4e06727f..c2bd6a5a41 100644 --- a/src/en/wizden-staff/maintainer/review-procedure.md +++ b/src/en/wizden-staff/maintainer/code-review-procedure.md @@ -185,4 +185,4 @@ Major game features usually follow the below dynamic: 2. Maintainers discuss the document in an informal discussion. If most agree, the document is marked with `S: Doc Approved`, and the contributor can start work on the actual feature. As the feature is developed, the document is updated if necessary. 3. Once the content-side implementation is ready to be merged, both the design document and the content pull request are merged in tandem. -The intention behind this is to ensure that contributors do not waste time implementing a feature that may not fit well into Upstream's intended gameplay. \ No newline at end of file +The intention behind this is to ensure that contributors do not waste time implementing a feature that may not fit well into Upstream's intended gameplay. From d135f1f44f15c8e75c58b062be6b916dbace4d46 Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:06:17 -0800 Subject: [PATCH 02/14] rename2 --- .../{code-review-procedure.md => content-review-procedure.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/en/wizden-staff/maintainer/{code-review-procedure.md => content-review-procedure.md} (100%) diff --git a/src/en/wizden-staff/maintainer/code-review-procedure.md b/src/en/wizden-staff/maintainer/content-review-procedure.md similarity index 100% rename from src/en/wizden-staff/maintainer/code-review-procedure.md rename to src/en/wizden-staff/maintainer/content-review-procedure.md From c031bc93a04a9134dd6d2d5e51d6879e4cd975d5 Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:09:45 -0800 Subject: [PATCH 03/14] cdontent --- src/en/wizden-staff/maintainer/content-review-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/maintainer/content-review-procedure.md b/src/en/wizden-staff/maintainer/content-review-procedure.md index c2bd6a5a41..d238fd3ab4 100644 --- a/src/en/wizden-staff/maintainer/content-review-procedure.md +++ b/src/en/wizden-staff/maintainer/content-review-procedure.md @@ -1,4 +1,4 @@ -# PR Review Procedure +# Content PR Review Procedure ## Abstract This document outlines the Maintainer procedure for reviewing and merging PRs to the [Space Station 14 repository](https://github.com/space-wizards/space-station-14) `master` branch (otherwise known as the Content repository). From 37defaecd1aa2706b372b3a5de543a21fdeb7d10 Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:18:51 -0800 Subject: [PATCH 04/14] asafasfafsa --- .../maintainer/doc-review-procedure | 24 +++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 src/en/wizden-staff/maintainer/doc-review-procedure diff --git a/src/en/wizden-staff/maintainer/doc-review-procedure b/src/en/wizden-staff/maintainer/doc-review-procedure new file mode 100644 index 0000000000..ddcd0d9251 --- /dev/null +++ b/src/en/wizden-staff/maintainer/doc-review-procedure @@ -0,0 +1,24 @@ +## Docs PR Review Procedure + +The Docs repo has a different review policy compared to the Content repository. +Since the Docs repo can be pushed to directly by maintainers, is mostly text-based, can be easily reverted/changed, and does not affect forks, most docs pull requests can be handled by a single maintainer. + +### Pushing to the Docs Repo +Maintainers have direct push access to the Docs repo and are encouraged to use it to update any outdated information, whether it's technical documentation, amending a design document, or just fixing grammar. + +### PR Reviews +PRs that update instructional or reference documentation (including but not limited to setup guides, style guides, system documentation) require only a single approval before it can be merged. +Likewise, only a single maintainer needs to express concern to close it. + +Note that this does not apply to changes to internal procedure or other modifications that require voting or group deliberation according to relevant policy. + +#### Design Documents +Major PRs that introduce or change a design document should require at least two maintainer approvals. +If the addition is large enough, a maintainer can call a vote on the design document; however, this should be done only when the scope of the pull request warrants it. + +Major game features usually follow the below dynamic: +1. A contributor creates a preliminary design document demonstrating what they would like to add, offering a high-level overview of how it fits into the game. +2. Maintainers discuss the document in an informal discussion. If most agree, the document is marked with `S: Doc Approved`, and the contributor can start work on the actual feature. As the feature is developed, the document is updated if necessary. +3. Once the content-side implementation is ready to be merged, both the design document and the content pull request are merged in tandem. + +The intention behind this is to ensure that contributors do not waste time implementing a feature that may not fit well into Upstream's intended gameplay. From 2025f469545baa750ba58eec848c2bdad4502f6e Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:18:59 -0800 Subject: [PATCH 05/14] trewrewerw --- .../maintainer/content-review-procedure.md | 24 ------------------- 1 file changed, 24 deletions(-) diff --git a/src/en/wizden-staff/maintainer/content-review-procedure.md b/src/en/wizden-staff/maintainer/content-review-procedure.md index d238fd3ab4..021a014647 100644 --- a/src/en/wizden-staff/maintainer/content-review-procedure.md +++ b/src/en/wizden-staff/maintainer/content-review-procedure.md @@ -162,27 +162,3 @@ Next: If the pull request gets kicked out of the merge queue due to failing tests, check if the test failure is related to the PR. If not, re-add the pull request to the merge queue. If the test is a Heisentest (a bug causing a rare, sporadic test fail), it should be logged in the [Heisentest bug tracker](https://github.com/space-wizards/space-station-14/issues/41081). - -## Reviewing Docs Pull Requests -The Docs repo has a different review policy compared to the Content repository. -Since the Docs repo can be pushed to directly by maintainers, is mostly text-based, can be easily reverted/changed, and does not affect forks, most docs pull requests can be handled by a single maintainer. - -### Pushing to the Docs Repo -Maintainers have direct push access to the Docs repo and are encouraged to use it to update any outdated information, whether it's technical documentation, amending a design document, or just fixing grammar. - -### PR Reviews -PRs that update instructional or reference documentation (including but not limited to setup guides, style guides, system documentation) require only a single approval before it can be merged. -Likewise, only a single maintainer needs to express concern to close it. - -Note that this does not apply to changes to internal procedure or other modifications that require voting or group deliberation according to relevant policy. - -#### Design Documents -Major PRs that introduce or change a design document should require at least two maintainer approvals. -If the addition is large enough, a maintainer can call a vote on the design document; however, this should be done only when the scope of the pull request warrants it. - -Major game features usually follow the below dynamic: -1. A contributor creates a preliminary design document demonstrating what they would like to add, offering a high-level overview of how it fits into the game. -2. Maintainers discuss the document in an informal discussion. If most agree, the document is marked with `S: Doc Approved`, and the contributor can start work on the actual feature. As the feature is developed, the document is updated if necessary. -3. Once the content-side implementation is ready to be merged, both the design document and the content pull request are merged in tandem. - -The intention behind this is to ensure that contributors do not waste time implementing a feature that may not fit well into Upstream's intended gameplay. From 91b25c55f1f730a8bfe41d8d09087a66ad2b595f Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:31:24 -0800 Subject: [PATCH 06/14] sfafsafa --- src/en/wizden-staff/maintainer.md | 30 +++++++++++++++++++++++++++++- 1 file changed, 29 insertions(+), 1 deletion(-) diff --git a/src/en/wizden-staff/maintainer.md b/src/en/wizden-staff/maintainer.md index ebc3ea2e6f..fccf338c5b 100644 --- a/src/en/wizden-staff/maintainer.md +++ b/src/en/wizden-staff/maintainer.md @@ -1,3 +1,31 @@ # Maintainer -This section contains information on Maintainer and PR-Review Policies, **as it pertains to Wizards Den servers, hosted by Space Wizards.** These policies do not apply to other servers, and may be waived in exceptional circumstances. \ No newline at end of file +This section contains information on Maintainer and PR-Review Policies, **as it pertains to Wizards Den servers, hosted by Space Wizards.** These policies do not apply to other servers, and may be waived in exceptional circumstances. + +## Maintainer + +A maintainer is a member of staff who is given authority and trust in reviewing and merging PRs. All maintainers regardless of specialization are expected to follow Maintainer Policy. + +### SS14 Maintainer + +A SS14 Maintainer maintains the content side of Space Station 14. This includes the docs repo, and content repo. + +### Documaintainer + +A Documaintainer is a SS14 Maintainer who only has Maintainer powers for the Docs Repo. Within the docs repo they have the same power and authority as an SS14 Maintainer. + +### Head Mapper + +A Head Mapper is a SS14 Maintainer who has exclusive power over content PRs with map changes and additions. These maintainers are expected to ensure mapping standards and their approval is required for any PRs which make mapping changes. + +### Art Lead + +An Art Lead is a SS14 Maintainer who has exclusive power over content PRs with sprite changes and additions. These maintainers are expected to ensure the game maintains its art style and their approval is required for any PRs which make significant changes to existing sprites, or add new sprites. + +### UI Lead + +A UI Lead is a SS14 Maintainer who has exclusive power over content PRs with UI changes and additions. These maintainers are expected to ensure the game retains usable, aesthetically pleasing UIs which fit the game's art style. + +### Robust Toolbox maintainer + +A Robust Toolbox Maintainer is a Maintainer for the game's engine Robust Toolbox. These are the only Maintainers who have merge powers for the engine. From 9865c07b3e13d1f9e8ec55a5bea26ca14874e511 Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:46:48 -0800 Subject: [PATCH 07/14] md!!!!!!!!! --- .../maintainer/{doc-review-procedure => doc-review-procedure.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename src/en/wizden-staff/maintainer/{doc-review-procedure => doc-review-procedure.md} (100%) diff --git a/src/en/wizden-staff/maintainer/doc-review-procedure b/src/en/wizden-staff/maintainer/doc-review-procedure.md similarity index 100% rename from src/en/wizden-staff/maintainer/doc-review-procedure rename to src/en/wizden-staff/maintainer/doc-review-procedure.md From f79160724b56e2158c7682c5dcdc46a83b7a39b2 Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:47:07 -0800 Subject: [PATCH 08/14] sfafsafsasfa --- src/SUMMARY.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/src/SUMMARY.md b/src/SUMMARY.md index c2dbd3a33a..602e0ce404 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -357,7 +357,8 @@ Staff - [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) + - [Content PR Review Procedure](en/wizden-staff/maintainer/content-review-procedure.md) + - [Docs PR Review Procedure](en/wizden-staff/maintainer/doc-review-procedure.md) - [Review Whitelist](en/wizden-staff/maintainer/review-whitelist.md) - [Hotfix Procedure](en/wizden-staff/maintainer/hotfix-procedure.md) - [Triage Procedure](en/wizden-staff/maintainer/triage-procedure.md) From 303fb21590b2878996f890162a51d2e23ae5833b Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:49:41 -0800 Subject: [PATCH 09/14] fix 1 --- src/en/general-development/codebase-info/releases.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/general-development/codebase-info/releases.md b/src/en/general-development/codebase-info/releases.md index d44d44b209..43cd4e1974 100644 --- a/src/en/general-development/codebase-info/releases.md +++ b/src/en/general-development/codebase-info/releases.md @@ -8,7 +8,7 @@ What does this mean for you? If you're a fork developer, this means that you now Updates are deployed every 14 days over the course of a weekend (Usually on a Saturday). 2 days prior to update day, "master" will be branched into "staging" and maintainers will perform a review of the upcoming changes. During this period, changes may be made or PRs may be reverted on the staging branch. Release day also coincides with the day of the regular maintainer meeting, half of which will be devoted to looking over the changes prepared for release. The outcome of this meeting determines if the update will be deployed as is, receive changes, or be delayed. The following 2 days after an update is deployed will allow for balance/minor gameplay fixes to be deployed under the normal Hotfix procedure. ### Review/PR Procedure -All PRs must be reviewed according to the PR review procedure [documented here](../../wizden-staff/maintainer/review-procedure.md), and may be merged to the development branch "master" at any point. PR's fixing code bugs or critical gameplay issues *may* be merged directly onto the "stable" branch but in that case must additionally follow the Hotfix procedure [documented here](../../wizden-staff/maintainer/hotfix-procedure.md). +All PRs must be reviewed according to the PR review procedure [documented here](../../wizden-staff/maintainer/content-review-procedure.md), and may be merged to the development branch "master" at any point. PR's fixing code bugs or critical gameplay issues *may* be merged directly onto the "stable" branch but in that case must additionally follow the Hotfix procedure [documented here](../../wizden-staff/maintainer/hotfix-procedure.md). ### What is Hotfixable? Any issue that directly impacts a player's ability to play the game in a largely negative way and can be considered by most to be a "bug" is eligable to be merged as a Hotfix. Critical gameplay issues may also fall into this category as well. "Critical" being an issue that is majorly disruptive to players **or admins**. *Outside of an emergency*, all **Hotfixes require 3 maintainers to sign-off** on merging (Ideally they should also review but giving approval is enough). Bugfixes may be applied to master following the regular review requirements. From 694e8af089a785b4a716bfaaf8bbfee7cf49732d Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:50:55 -0800 Subject: [PATCH 10/14] sfafs --- src/en/wizden-staff/maintainer/adding-new-maintainers.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/maintainer/adding-new-maintainers.md b/src/en/wizden-staff/maintainer/adding-new-maintainers.md index 9240e91061..4a2151d672 100644 --- a/src/en/wizden-staff/maintainer/adding-new-maintainers.md +++ b/src/en/wizden-staff/maintainer/adding-new-maintainers.md @@ -61,7 +61,7 @@ Once a new Maintainer has been accepted, they must be on-boarded. The pre-requis ### Additional Notes - Read the [maintainer tools](/en/wizden-staff/maintainer/maintainer-tools.html) page to see some useful tools that can help you as a maintainer. -- Read the [maintainer policy](/en/wizden-staff/maintainer/maintainer-policy.html) and [review procedure](/en/wizden-staff/maintainer/review-procedure.html) to see which rules you have to follow when merging PRs. +- Read the [maintainer policy](/en/wizden-staff/maintainer/maintainer-policy.html) and [review procedure](/en/wizden-staff/maintainer/content-review-procedure.html) to see which rules you have to follow when merging PRs. - Read the [doc page](/en/general-development/codebase-info/releases.html) on how our release model and maintainer meetings work. They happen every two weeks and the event schedule can be found on discord. - After being invited to the GitHub organization, go to the space-wizards org > People > Find yourself > and set your organization visibility to public. This allows people to more easily see you are a maintainer (you will have a “Member” attached to your comments) AND you get to flex the org on your github profile. - It is recommended to set up two-factor authentication for your Discord, SS14, and github accounts to ensure they cannot be compromised. From 0ff300281e3bb8a61dbf16ae63fb547fe0f6242d Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:51:13 -0800 Subject: [PATCH 11/14] asdsadsa --- src/en/wizden-staff/maintainer/maintainer-policy.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/maintainer/maintainer-policy.md b/src/en/wizden-staff/maintainer/maintainer-policy.md index 8e37cac343..2efa8c5321 100644 --- a/src/en/wizden-staff/maintainer/maintainer-policy.md +++ b/src/en/wizden-staff/maintainer/maintainer-policy.md @@ -5,7 +5,7 @@ This policy applies in addition to the [General Staff](../staff-policy.md) and [ **Breaking any of these rules will result in disiplinary action being taken** ## Reviews and Feedback -- All maintainers must follow the [PR Review](../maintainer/review-procedure.md) and [Hotfix Procedures](../maintainer/hotfix-procedure.md) when they apply. +- All maintainers must follow the [PR Review](../maintainer/content-review-procedure.md) and [Hotfix Procedures](../maintainer/hotfix-procedure.md) when they apply. - Maintainers should try to the best of their ability, to keep PR authors informed on the status of their PRs. - Maintainers should keep public criticism of code *constructive* and avoid making comments in regards to the authors of the code. **Harsh but fair** citicism of code is *acceptable*, but criticism of its author is not. - Maintainers should try to perform code reviews *whenever possible*, getting content into the game is everyone's responsibility. From c6dbab79f0f680b0578bdf90789115e85b707a85 Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Fri, 23 Jan 2026 15:51:34 -0800 Subject: [PATCH 12/14] sadasdsa --- src/en/wizden-staff/maintainer/hotfix-procedure.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/en/wizden-staff/maintainer/hotfix-procedure.md b/src/en/wizden-staff/maintainer/hotfix-procedure.md index 21721cd2f9..4ab78490c6 100644 --- a/src/en/wizden-staff/maintainer/hotfix-procedure.md +++ b/src/en/wizden-staff/maintainer/hotfix-procedure.md @@ -4,7 +4,7 @@ Not following this procedure/policy will result in disciplinary action being tak ## Requirements - **Three Maintainers must *sign-off*** (Approval is required, reviewing is recommended but optional) on a hotfix PR for it to be merged. - The Hotfix procedure only applies to PRs being merged straight to "stable" or "staging". **When merging bugfixes to master, this procedure does NOT apply, use the normal PR procedure instead!** -- All Hotfixes must adhere to the normal [PR Review Procedure](../maintainer/review-procedure.md) in addition to any requirements listed here. +- All Hotfixes must adhere to the normal [PR Review Procedure](../maintainer/content-review-procedure.md) in addition to any requirements listed here. - Hotfixes must be given the "Hotfix" label during triage. They will also automatically receive a label indicating their branch. - Stable Hotfixes are for fixing bugs only, not for adding new content or minor balance adjustments. *If a balance issue is bad enough to majorly impact game quality, it should be considered a bug and is eligible for a hotfix. This is up to Maintainer judgment, but if you are unsure, it's recommended to create a discussion thread prefixed with "HOTFIX-PRNumber". - Hotfixes to Staging may include any changes that are deemed necessary for the upcoming release, but are otherwise still referred to as Hotfixes and follow these procedures. From 862d97cb03760e98baee514161c583105fee16eb Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Sun, 25 Jan 2026 15:33:06 -0800 Subject: [PATCH 13/14] Apply suggestion from @RemFexxel Co-authored-by: Rem --- src/en/wizden-staff/maintainer/doc-review-procedure.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/src/en/wizden-staff/maintainer/doc-review-procedure.md b/src/en/wizden-staff/maintainer/doc-review-procedure.md index ddcd0d9251..3ea22eab6b 100644 --- a/src/en/wizden-staff/maintainer/doc-review-procedure.md +++ b/src/en/wizden-staff/maintainer/doc-review-procedure.md @@ -7,7 +7,7 @@ Since the Docs repo can be pushed to directly by maintainers, is mostly text-bas Maintainers have direct push access to the Docs repo and are encouraged to use it to update any outdated information, whether it's technical documentation, amending a design document, or just fixing grammar. ### PR Reviews -PRs that update instructional or reference documentation (including but not limited to setup guides, style guides, system documentation) require only a single approval before it can be merged. +PRs that update instructional or reference documentation (including, but not limited to, setup guides, style guides, and system documentation) require only a single approval before they can be merged. Likewise, only a single maintainer needs to express concern to close it. Note that this does not apply to changes to internal procedure or other modifications that require voting or group deliberation according to relevant policy. @@ -16,9 +16,9 @@ Note that this does not apply to changes to internal procedure or other modifica Major PRs that introduce or change a design document should require at least two maintainer approvals. If the addition is large enough, a maintainer can call a vote on the design document; however, this should be done only when the scope of the pull request warrants it. -Major game features usually follow the below dynamic: +Major game features usually follow the following dynamic: 1. A contributor creates a preliminary design document demonstrating what they would like to add, offering a high-level overview of how it fits into the game. 2. Maintainers discuss the document in an informal discussion. If most agree, the document is marked with `S: Doc Approved`, and the contributor can start work on the actual feature. As the feature is developed, the document is updated if necessary. 3. Once the content-side implementation is ready to be merged, both the design document and the content pull request are merged in tandem. -The intention behind this is to ensure that contributors do not waste time implementing a feature that may not fit well into Upstream's intended gameplay. +The intention is to ensure that contributors do not waste time implementing a feature that may not fit well with Upstream's intended gameplay. From 2aef5047ac26b0ee8848bb1e965bc22b969b7399 Mon Sep 17 00:00:00 2001 From: Princess Cheeseballs <66055347+Princess-Cheeseballs@users.noreply.github.com> Date: Sun, 25 Jan 2026 15:34:13 -0800 Subject: [PATCH 14/14] Apply suggestions from code review Co-authored-by: Rem --- src/en/wizden-staff/maintainer.md | 18 +++++++++--------- .../maintainer/hotfix-procedure.md | 2 +- 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/src/en/wizden-staff/maintainer.md b/src/en/wizden-staff/maintainer.md index fccf338c5b..0f7759526c 100644 --- a/src/en/wizden-staff/maintainer.md +++ b/src/en/wizden-staff/maintainer.md @@ -1,31 +1,31 @@ # Maintainer -This section contains information on Maintainer and PR-Review Policies, **as it pertains to Wizards Den servers, hosted by Space Wizards.** These policies do not apply to other servers, and may be waived in exceptional circumstances. +This section contains information on Maintainer and PR-Review Policies, **as it pertains to Wizards Den servers, hosted by Space Wizards.** These policies do not apply to other servers and may be waived in exceptional circumstances. ## Maintainer -A maintainer is a member of staff who is given authority and trust in reviewing and merging PRs. All maintainers regardless of specialization are expected to follow Maintainer Policy. +A maintainer is a member of staff who is given authority and trust to review and merge PRs. All maintainers, regardless of specialization, are expected to follow the Maintainer Policy. ### SS14 Maintainer -A SS14 Maintainer maintains the content side of Space Station 14. This includes the docs repo, and content repo. +A SS14 Maintainer maintains the content side of Space Station 14. This includes the docs repo and the content repo. ### Documaintainer -A Documaintainer is a SS14 Maintainer who only has Maintainer powers for the Docs Repo. Within the docs repo they have the same power and authority as an SS14 Maintainer. +A Documaintainer is an SS14 maintainer who only has maintainer powers for the Docs Repo. Within the docs repo, they have the same power and authority as an SS14 maintainer. ### Head Mapper -A Head Mapper is a SS14 Maintainer who has exclusive power over content PRs with map changes and additions. These maintainers are expected to ensure mapping standards and their approval is required for any PRs which make mapping changes. +A Head Mapper is an SS14 Maintainer who has exclusive power over content PRs with map changes and additions. These maintainers are expected to ensure mapping standards are met, and their approval is required for any PRs that make mapping changes. ### Art Lead -An Art Lead is a SS14 Maintainer who has exclusive power over content PRs with sprite changes and additions. These maintainers are expected to ensure the game maintains its art style and their approval is required for any PRs which make significant changes to existing sprites, or add new sprites. +An Art Lead is an SS14 Maintainer who has exclusive power over content PRs with sprite changes and additions. These maintainers are expected to ensure the game maintains its art style, and their approval is required for any PRs that make significant changes to existing sprites or add new sprites. ### UI Lead -A UI Lead is a SS14 Maintainer who has exclusive power over content PRs with UI changes and additions. These maintainers are expected to ensure the game retains usable, aesthetically pleasing UIs which fit the game's art style. +A UI Lead is an SS14 Maintainer who has exclusive power over content PRs with UI changes and additions. These maintainers are expected to ensure the game retains usable, aesthetically pleasing UIs which fit the game's art style. -### Robust Toolbox maintainer +### Robust Toolbox Maintainer -A Robust Toolbox Maintainer is a Maintainer for the game's engine Robust Toolbox. These are the only Maintainers who have merge powers for the engine. +A Robust Toolbox maintainer is a maintainer for the game's engine, Robust Toolbox. These are the only Maintainers who have merge powers for the engine. diff --git a/src/en/wizden-staff/maintainer/hotfix-procedure.md b/src/en/wizden-staff/maintainer/hotfix-procedure.md index 4ab78490c6..5b9d578a9d 100644 --- a/src/en/wizden-staff/maintainer/hotfix-procedure.md +++ b/src/en/wizden-staff/maintainer/hotfix-procedure.md @@ -4,7 +4,7 @@ Not following this procedure/policy will result in disciplinary action being tak ## Requirements - **Three Maintainers must *sign-off*** (Approval is required, reviewing is recommended but optional) on a hotfix PR for it to be merged. - The Hotfix procedure only applies to PRs being merged straight to "stable" or "staging". **When merging bugfixes to master, this procedure does NOT apply, use the normal PR procedure instead!** -- All Hotfixes must adhere to the normal [PR Review Procedure](../maintainer/content-review-procedure.md) in addition to any requirements listed here. +- All Hotfixes must adhere to the normal [PR review procedure](../maintainer/content-review-procedure.md) in addition to any requirements listed here. - Hotfixes must be given the "Hotfix" label during triage. They will also automatically receive a label indicating their branch. - Stable Hotfixes are for fixing bugs only, not for adding new content or minor balance adjustments. *If a balance issue is bad enough to majorly impact game quality, it should be considered a bug and is eligible for a hotfix. This is up to Maintainer judgment, but if you are unsure, it's recommended to create a discussion thread prefixed with "HOTFIX-PRNumber". - Hotfixes to Staging may include any changes that are deemed necessary for the upcoming release, but are otherwise still referred to as Hotfixes and follow these procedures.