Paradise Station Development Team Structure

---

Section 1 - Roles & their purposes

The Paradise development structure is made up of a leading group (Headcoders), and a set of smaller groups. These are:

• Maintainers
• Review Team
• Design Team
• Balance Team
• Sprite Team
• Mapping Team
• Issue Managers

None of these roles are mutually exclusive, nor do they outrank eachother. For example, you can be a Maintainer, part of the Design Team and be an Issue Manager. However, being part of multiple teams does not grant you 2 votes if a PR concerns both groups. While being part of both the Design Team and Balance Team is not mutually exclusive, it is preferred that one person is only part of one of these teams.

None of these roles (with the exception of Headcoder) grant access to the staff discord or ingame rights (+VIEWRUNTIMES is now a case-by-case basis).

All of these subgroups will have access to a dedicated #development-discussion channel in the public discord. This channel will not be viewable to people outside the development branch. Each group will have their own separate roles to aid discusion in scenarios such as @Review Team could we get #12345 looked at?.

The Maintainers, Review Team and Issue Managers will get access to the servers Kibana server. They will only be granted access to the performance, runtime and qdel metrics. The data here can be shared to others if deemed safe by the development member. Avoid sharing sensitive/personal information from this view, use common sense to determine if it is safe to share. Individuals, who are not part of the above mentioned teams, can be granted this privilege on the discretion of the Headcoders and the Server Host.

All of these subgroups are subject to a biannual review. If the Headcoders deem you are no longer fit for a role, you may lose it.

---

A - Headcoders

• Repository rights: Admin.
• Amount: 3 at all times.
• See the main staff structure document for ingame rights.

i - Duties

• Coordinating all the groups below them to ensure PRs are handled efficiently and properly.
  • Add the voting groups to PRs when they are opened to ensure the teams know what they should vote on.
• Managing promotion/demotion of lower roles, in accordance with the Heads of Staff where necessary.
  • Promoting/demoting someone to/from Issue managers for example does not require a Head of Staff verdict.
• Handling disputes lower in the chain.
  • This includes having a vote in PRs, as well as handling 50/50 deadlocks.
    • If a PR vote is 50/50 deadlocked and you already have a vote in one side, you cannot add two votes as a "veto move".
  • Headcoders are allowed to override descisions made by lower groups if absolutely necessary, however:
    • This requires at least 2 Headcoders to sign off on this descision.
    • The descision must have sufficient reasoning. Reasoning such as I don't like it is not valid, you must explain why.
• Handling testmerge requests on the production server.
  • Maintainers do not get testmerge rights by default for security concerns. It may be granted on a case-by-case basis at the discretion of the Server Host.
• Taking a more technical role in PRs and reviews in the event that a refactor is made that is so specialised or complex (see: atmospherics) that the standard review team require another set of eyes.
• Assigning which teams can vote for PRs in the internal PR tracker.

ii - Hiring

1 - Requirements for eligibility

• No disciplinary action applied for at least twelve months.
• Already be a Maintainer, Review team member, or Issue managers for at least 6 months.
• Additional requirements may be added at the discretion of the existing Headcoders, or by the Heads of Staff.

2 - Selection

Unanimous approval by both the Heads of Staff and existing Headcoders.

---

B - Maintainers

• Repository rights: Write.
• Amount: Variable.
• Permission to delete messages in the coding_chat and pr_review channels on Discord.
  • These rights must only be used to follow exploit fix procedure. Failure to comply will result in the removal of the permission as well as other possible disciplinary actions.

i - Duties

• Handling PR merges after all other steps in the procedure have been carried out (See section 2A for information).
  • PR merges are to be handled in line with the Merge Procedure.
  • Under NO condition are you allowed to self-merge pull requests, create PRs from the main repository (forks must still be used), or merge PRs bypassing the procedure. Failure to comply with this will result in a swift removal of your rights.
• Handling exploit fix PRs as listed in Fixing exploits.
• Labeling PRs according to the Labeling procedure.

ii - Hiring

1 - Requirements for eligibility

• No disciplinary action applied for at least six months.
• Already be a part of the Review team.
• Have reviewed numerous PRs of different types, sizes, and subject matters.
• Have a good understanding of how changes might affect (seemingly) unrelated features.
• Have shown the ability to properly communicate through Github and Discord.
• Additional requirements may be added at the discretion of the existing Headcoders.
• Maintainers MUST have 2FA enabled on their GitHub account. This is non-negotiable.

2 - Selection

Unanimous approval by both the Headcoders and existing Maintainers.

---

C - Review Team

• Repository rights: None.
• Amount: Variable.

i - Duties

• Handling PR review for code quality and stability + GC concerns.

ii - Hiring

1 - Requirements for eligibility

• No disciplinary action applied for at least six months.
• Have the Github contributor role.
• Have a fair amount of merged PRs, including one bigger PR or a few moderate sized. Examples for bigger PRs include the surgery rework, datumizing clings or APC/machinery refactor. Examples for moderate PRs include Dantalion vampire, shield wall refactor or the admin economy manager.
• Have reviewed a range of PRs for our codebase.
• Have a good understanding of our coding standards.
• Have a basic understanding of how changes may affect (seemingly) unrelated features.
• Additional requirements may be added at the discretion of the existing Headcoders.

2 - Selection

Unanimous approval by the Headcoders.

---

D - Design Team

• Repository rights: None.
• Amount: Must be an odd number at all times to avoid 50/50 deadlocks.

i - Duties

• Voting on PRs within the design voting group. This team does not concern itself with balance changes.
  • Notifying Headcoders if the voting groups chosen seem incorrect. Include the reasoning why it should be another set of voting groups.
• Working as public outreach to gather community feedback. This includes but is not limited to:
  • Feedback on recent changes.
  • Feedback on testmerges.
  • Community thoughts on the design direction of the game.
  • Advising contributors to create design documents so their ideas can be fully fleshed out.

ii - Hiring

1 - Requirements for eligibility

• No disciplinary action applied for at least six months.
• Have at least played on our server for 9 months and have a minimum playtime of 400 hours.
• Play on our server regularly. About 6 hours a week on average.
• Have shown a good understanding of game design either through PRs or suggestions.
• Be able to view topics from multiple perspectives.
• Have shown the ability to properly communicate through Github and Discord.
• Additional requirements may be added at the discretion of the existing Headcoders or Heads of Staff.

2 - Selection

Unanimous approval by both the Headcoders and Heads of Staff.

---

E - Balance Team

• Repository rights: None.
• Amount: Must be an odd number at all times to avoid 50/50 deadlocks.

i - Duties

• Voting on PRs within the balance voting group. This team does not concern itself with design changes.
  • Notifying Headcoders if the voting groups chosen seem incorrect. Include the reasoning why it should be another set of voting groups.
• Actively playing the game in multiple roles to get a proper eye on current metas, balance scenarios and general game flow.

ii - Hiring

1 - Requirements for eligibility

• No disciplinary action applied for at least six months.
• Have at least played on our server for 9 months and have a minimum playtime of 400 hours.
• Play on our server regularly. About 6 hours a week on average.
• Be able to view topics from multiple perspectives.
• Have shown the ability to properly communicate through Github and Discord.
• Additional requirements may be added at the discretion of the existing Headcoders or Heads of Staff.

2 - Selection

Unanimous approval by both the Headcoders and Heads of Staff.

---

F - Sprite Team

• Repository rights: None.
• Amount: Must be an even number at all times so their votes + Design Team votes always add up to odd amounts.

i - Duties

• Reviewing PRs that add and/or edit sprites to ensure they meet the required standards.
  • Reviews should be conducted within a 30-day period of the PR being initially marked as ready for review, should a sprite PR be open for longer with no review from a sprite team member, it may be merged or closed at the discretion of the Headcoders.
• Helping spriters improve and conform to required standards by using the spriting channel on discord.
• Working with the design team to:
  • Ensure a standardised and consistent artstyle is maintained.
  • Create palettes for the community to use in their sprites.
• Voting on PRs within the sprite voting group.
  • If a PR adds a sprite, but the sprite is not the main focus of the PR (e.g. adding a new gun to the uplink), then any sprite team objections in such cases will NOT block merging.
  • Notifying Headcoders if the voting groups chosen seem incorrect. Include the reasoning why it should be another set of voting groups.

ii - Hiring

1 - Requirements for eligibility

• No disciplinary action applied for at least six months.
• Displayed a proficiency in spriting and a healthy attitude in the community, as determined by the Headcoders and Heads of Staff.
• Additional requirements may be added at the discretion of the existing Headcoders and Heads of Staff.

2 - Selection

Unanimous approval by both the Headcoders and Heads of Staff.

---

G - Issue Managers

• Repository rights: Triage.
• Amount: Variable.

i - Duties

• Handling the issues list on the GitHub repository. This involves:
  • Closing issues which are no longer relevant.
  • Appropriately tagging issues on the type they are.
  • Denoting simple-to-fix issues as Good First Issue.
  • If an issue is lacking information on how to reproduce it, speaking with the issue author to get more context.
• Labeling PRs according to the Labeling procedure is permitted but not required.
• Under no circumstances are Issue Managers to close PRs. You are only allowed to close issues.

ii - Hiring

1 - Requirements for eligibility

• No disciplinary action applied for at least six months.
• Have the Github contributor role.
• Being familiar with the codebase as a player. Know what created issues would be a feature request and what would be a bug.
• Have a reasonable understanding of how Byond/SS13 code works.
• Additional requirements may be added at the discretion of the existing Headcoders.

2 - Selection

Unanimous approval by the Headcoders.

---

H - Mapping Team

• Repository rights: None.
• Amount: Must be an odd number at all times to avoid 50/50 deadlocks.

i - Duties

• Reviewing PRs that edit maps to ensure they meet the required standards and are consistent with other elements of the map.
  • Reviews should be conducted within a 30-day period of the PR being marked as ready for review, should a mapping PR be open for longer with no review from a map team member, it may be merged or closed at the discretion of the Headcoders.
• Helping mappers improve and conform to required mapping standards by using the #mapping channel on discord.
• Setting and maintaining mapping standards for the codebase.
• Voting on PRs that contain map edits.
  • If a PR edits a map in a minor way (small changes within a room or a small number of rooms) and the mapping changes are not the main focus of the PR (e.g. adding a new gun and putting it in the armoury); then they are permitted to vote on it, however any map team objections in such cases will NOT block merging.
  • The aim of the mapping team is to vote and give a direction on subjective mapping merits, not technical mapping. While mapping team members can object to a map on technical grounds, this should mainly be the concern of the review team. Mapping team members should aim to vote primarily on map design choices.

ii - Hiring

1 - Requirements for eligibility

• No disciplinary action applied for at least six months.
• Displayed an understanding of good map design choices and has a healthy attitude in the community, as determined by the Headcoders and Heads of Staff.
• Additional requirements may be added at the discretion of the existing Headcoders and Heads of Staff.

2 - Selection

• Unanimous approval by both the Headcoders and Heads of Staff.

---

I - External Teams

i - Access and Responsibility

• External (non-development) teams, like Wiki Managers, play a vital role in our development efforts and have access to resources. They are required to strictly adhere to project policies and guidelines.

ii - Consequences of Misuse

• Misuse of privileges (i.e. Misuse of GitHub labelling commands or violating project rules) disrupts workflows and may result in loss of permissions or privileges.

iii - GitHub Labeling Protocol for Wiki Managers

• Wiki Managers can comment !wiki_label on a pull request to designate it as requiring documentation updates. Wiki Managers are responsible for ensuring that the label is applied to relevant PRs.
• Headcoders are responsible for granting and managing the permission to use this feature.

---

Section 2 - Procedure

This section outlines all procedure.

A - PR procedure

i - ALL PRs

• All PRs are subject to a 30-day timeout, unless:
  • It is pending testmerge.
  • It is waiting for the PR author to make requested changes.
    • If the PR author has not responded to the request for changes within 7 days, the PR is to be marked stale and closed.
  • No steps have been taken to communicate any objection reasons to the PR author.
• If a PR has passed design approval and is waiting on code review, the reviewers have 14 days to look at it before it is handed to a Headcoder.
  • This means 14 days for someone to even mention they are reviewing it. It does not mean that you must complete the PR review within 14 days.
• If a PR changes or adds a sprite, and is not solely a sprite PR, the sprite team have 30 days to review the sprite portion of the PR before it is handed to a Headcoder.
• If a PR edits or adds a map, and is not solely a mapping PR, the mapping team have 30 days to review the map edit portion of the PR before it is handed to a Headcoder.
• If a vote is sat at a 50/50 deadlock for whatever reason, a Headcoder must vote to override the deadlock.
  • The Headcoder may not vote twice to solve a deadlock if they have already voted in this matter.
• While voting on PRs, an objection will be considered invalid and ignored unless a genuine and/or relevant reason is provided. The Headcoders have the final say regarding what constitutes a "genuine and/or relevant reason".
  • Examples of reasons that might be considered invalid by the Headcoders:
    • If the reason is regarding PR author attitude on/off the github. "Objection: PR author has a terrible attitude when handling suggested changes." or "Objection: Player is banned for powergaming, they should not be allowed to make balance PRs."
    • If the reason provided is too vague or generic. "Objection: This PR is terrible I hate it."
    • If there is no provided reason.
• Self-voting (voting on your own PR) is permitted for the Design and Balance teams.
  • It is expected that team members discuss and refine ideas together first, so self-voting should rarely cause a split vote to pass.
  • Bigger changes will require at least one other approval for the PR to be mergeable. In this case, it is preferred to wait until another approval is given before self-voting.
    • Low impact tweaks or low impact features are considered small changes
    • Anything listed in our Code of Conduct as controversial or large changes will fall under this rule as a "bigger change".
    • Headcoders have the final say on whether a PR is considered a "bigger change" or not.
• Wherever possible, a Headcoder who closes any PR that either; has not had sufficient votes, has failed to pass a vote, or has been successfully vetoed, must provide all reasons given behind valid objections against the PR. These reasons should be included in the closing comment on the PR where possible, and should be anonymised by default. If the objectioner indicates so, their identity can be disclosed alongside the objection reason.
  • The Headcoders may use reasonable judgement in this process and should strive for overall transparency while not endangering the anonymity of those who choose not to disclose their identity when objecting.
  • The Headcoder who closes a PR can choose not to disclose objection reasons if the Headcoder team deems it necessary for that PR.

ii - Pure Fix/Refactor PR with no design implications

• PR is to be reviewed by the code Review Team then merged by a Maintainer in line with the Merge Procedure. No waiting period is necessary.

iii - Content expansion (Major feature PR)

• Design is first looked over by the Design Team, ensuring it reaches majority vote.
  • This preferably happens before the contributor puts hours of work in.
  • Because of this vote, the PR must stay open for at least 24 hours
• The Balance Team gives it a skim over for glaring balance issues, but they cannot throw a merge-blocking objection on it.
  • They can however, speak to the Design Team to try and make their point reasonably.
• Voting then occurs again after any design/balance changes have been requested to make sure its still agreed upon.
• Once the PR has passed the design vote, it is then handed to the Review Team to ensure the code is of sufficient quality.
• Once the review team has ensured quality, a Maintainer can merge the PR in line with the Merge Procedure.

iv - Minor balance change (Value tweaking)

• The PR is looked over by the Balance Team only, and voting occurs.
  • Because of this vote, the PR must stay open for at least 24 hours.
• Once the PR has passed the balance vote, it is then handed to the Review Team to ensure the code is of sufficient quality.
• Once the review team has ensured quality, a Maintainer can merge the PR in line with the Merge Procedure.

v - Major balance change (New weapon or ERT class or similar)

• The PR is looked over by the Balance Team first to refine the values, and voting occurs.
  • Because of this vote, the PR must stay open for at least 24 hours.
• The Design Team then looks at it to ensure it fits in with the game design.
  • In a similar fashion to before, the Design Team themselves cannot forcefully merge-block the PR, but they can speak to the Balance Team reasonably.
• Once the PR has passed the balance vote, it is then handed to the Review Team to ensure the code is of sufficient quality.
• Once the review team has ensured quality, a Maintainer can merge the PR in line with the Merge Procedure.

vi - Non-balance altering tweak

• The PR is looked over by the Design Team only, and voting occurs.
  • Because of this vote, the PR must stay open for at least 24 hours.
• Once the PR has passed the balance vote, it is then handed to the Review Team to ensure the code is of sufficient quality.
• Once the review team has ensured quality, a Maintainer can merge the PR in line with the Merge Procedure.

vii - Spriting PR

• A sprite PR cannot be merged without a review from the sprite team unless approved by a Headcoder.
• The PR is reviewed by the Sprite Team and voting occurs.
  • A PR that does not only resprites items, or is considered large (changes all jumpsuits, mass resprites guns, etc...) will also be subject to a Design Team vote.
  • Because of this vote, the PR must stay open for at least 24 hours.
• Once the PR has passed the combined team vote, it is then handed to the Review Team to ensure it is technically sound.
• Once the review team has ensured quality, a Maintainer can merge the PR in line with the Merge Procedure.

viii - Mapping PR

• A mapping PR cannot be merged without a review from the mapping team unless approved by a Headcoder.
• The PR is reviewed by the Mapping Team and Design Team, and voting occurs.
• Because of this vote, the PR must stay open for at least 24 hours.
• Once the PR has passed both teams’ independent vote, it is then handed to the Review Team to ensure it is technically sound.
  • “Both teams’ independent vote” means that the votes cast by the Mapping Team and Design Team are independent, and failing either vote will mean the overall vote has also failed.
• Once the review team has ensured quality, a Maintainer can merge the PR.

ix - Any PR that doesn't fit above criteria

• At the discretion of Headcoders.

B - Exploit Procedure

This section uses the term Exploit to mean any process, method, or actions that use an oversight, bug, or flaw either in the game code or game systems in order to perform unintended acts, gain an unfair advantage, harm the game experience, cause crashes, cause lag, or compromise server security.

i - Reporting exploits and the management of exploit reports

• Exploits should only be disclosed to or discussed with members of the Paradise Station development team, they should never be publically disclosed or privately shared with non-development team members. This includes in GitHub issue reports.

• Upon becoming aware of an exploit, a community member should file an exploit report on the Paradise Station forums at this link.

  • If an Issue manager notices that a community member has filed an exploit report on the GitHub issue section, a Headcoder should be informed so they can determine if the issue should be deleted or handled in another way.

• Issue managers are primarily responsible for the exploit report list, they are expected to sort through new reports and determine if they should be classed as either a bug or an exploit. Bug reports submitted to the exploit report list should be closed and the author directed to the GitHub issue section.

• If an Issue manager is unsure regarding the classification of a report as a bug or as an exploit, they should consult the Design Team or Balance Team for insight. If required, Headcoders have the final say on the classification of a report.

• If an exploit report details potential server security concerns, the Server Host should be contacted urgently to perform a systems audit and ensure that the exploit has not been used. The Server Host, although not subject to this development team structure document, is expected to liaise with staff and development team members on these matters to a reasonable degree.

ii - Fixing exploits

• Any development team member may prepare a fix for an exploit. Non-development team members may be permitted to fix exploits on a case-by-case basis if they are trusted. If in doubt, ask a Headcoder before assigning an exploit to a non-development team member.

  • The severity of any given exploit should guide the choice of who fixes an exploit (For example, do not assign exploits that involve severe server crashes to non-development team members).
  • If a team member intends to prepare a fix for an exploit, they should comment on the exploit report to make this known.
  • If a non-development team member is selected to prepare a fix for an exploit, whoever confirms with them should comment on the exploit report to make this known.

• Before opening an exploit fix PR, a Maintainer or a Headcoder must be contacted to discuss how the PR will be handled.

• In the case of a severe exploit or one that has server performance implications, the code diff should be provided beforehand to a Maintainer or a Headcoder to pre-review. This is to speed up the merge process.

• A Maintainer or Headcoder should be notified and be ready before posting the PR to GitHub, so the automatically posted links on Discord can be removed.

  • A Headcoder or Maintainer may determine that the exploit fix PR should be posted shortly before the current game round ends. Communication with a Game Admin may be required to arrange a brief delay to the current game round end for code deployment to occur.

• When posting an exploit fix PR, the title should always start with [s] to clearly indicate it fixes an exploit.

• Exploit reports/fixes should not be discussed until the current game round has fully ended, even if the fix PR has been merged.

  • Exploit reports/fixes that involve major lag, server crashes, or server security should never be publically discussed as they may affect other servers.

C - Labeling Procedure

i Label Usage

Labels on PRs are to be used to more easily identify what a PR is about and to look them up. Before, the labels were used to determine the voting groups, this is now separated from the Github labels.

The Headcoder, Maintainer, Review and Issue Manager teams can label PRs as they deem fit. The labels should reflect the main content of the PR as best they can while keeping it ordered and as compact as possible.

For example, a PR that adds a new feature but refactors a little to make this feature possible should get the Feature label and not the Refactor label as the feature part is overshadowing the refactor done.

ii Restricted Labels

The following categories of labels should not be added or removed from PRs, except when approved by a Headcoder on a case per case basis:

• Any label that is part of the automated processes we have, including the -Status:..., Merge Conflict, Testmerge Active or Testmerge Requested labels. These are used in automated processes and should therefore not be added or removed.
• The On Hold label, unless given specific permission from a Headcoder to manage these on Github.
• The Exploit label. Instead of labeling this PR yourself, you should notify a Maintainer or Headcoder unless one is already working on this PR. These PRs should be merged as fast as possible and require special attention, see Fixing exploits.
• High Priority unless approved by a Headcoder or Maintainer, as these indicate that the PR should be fast-tracked.

iii Special Labels

The following labels are special cases which can be added or removed but with special conditions:

• The Administration label. This label will notify admins when it is merged into the codebase.
• Any automatic informative labels such as map labels (like BoxStation), Dependencies, github_actions or NanoMaps. These are automatically added, but the bot doing it can break due to git weirdness. These labels can be adjusted if this occurs.
• The Configuration Change label. If the PR is in a non-draft state or ready for a TM, then notify the Server Host so they can do a configuration review.
• Any freeze related label should not be added if there is no freeze in place. They should also not be removed unless the freeze has ended or you have had explicit approval from a Headcoder.

D - Merge Procedure

The primary aim of the merge procedure is to make effective use of merge queues. The merge queue feature permits for each PR to be tested through CI against the updated master branch before merge. This allows PRs introducing stealth conflicts or with other compatibility issues to be filtered out before merge.

i Standard Procedure

All PRs have to be processed as described below unless they meet the criteria in the below Urgent PRs section, or at the discretion of a Headcoder or Maintainer.

• The merge queue function should be used wherever possible as opposed to directly merging into the master branch by any other method.
• If a PR is automatically removed from the merge queue due to failing status checks or merge conflicts, it is handed back to the Review Team to ensure it is technically sound.
  • Once any issues have been addressed and the pull request is again ready for merge, it may be re-added to the merge queue in the normal manner.
• PRs may be manually removed from the merge queue for any reason at the discretion of a Maintainer or Headcoder.
  • PRs manually removed from the merge queue are to be treated in the same manner as any other PR.

ii Urgent PRs

In the event of a PR requiring urgent attention, such as exploit fix PRs or server security PRs, a more streamlined process is to be used for merges. The designation of any PR as urgent is done at the discretion of a Maintainer or Headcoder.

• The use of merge queues is not required for an urgent PR, and these may be directly merged into the master branch once it is certain the PR is technically sound.
• Before merging an urgent PR, the merge queue should be inspected and any disruptions anticipated.
  • In the event of a disruption to the merge queue due to an urgent PR being directly merged, the authors of disrupted PRs should be made aware within a reasonable timeframe.

---

Section 3 - Closing notes

• This document is subject to change with little to no notice, however, the changelog below must be updated with timestamps

A - Changelog

• AffectedArc07@2022-05-29 - Initial document
• S34N@2022-06-10 - Added GitHub 2FA requirements for members of Commit Access at request of AA07.
• S34N@2022-12-12 - Added Sprite Team section, amended Section 2 - Procedure
• S34N@2023-03-19 - Added details regarding objection validity and disclosure of objection reasons.
• Farie82@2023-03-27 - Updated the hiring requirements to be more in line of what we expect from those team members
• Farie82@2023-05-01 - Added the Requires Wiki Update label exception for issue managers.
• S34N@2023-05-30 - Added Exploit Procedure section.
• Farie82@2023-10-10 - Added Kibana access to technical development members and chosen individuals.
• Farie82@2023-11-02 - Allow self-voting for the design and balance team in specific cases.
• Farie82@2023-11-04 - Grants Commit access members delete permission in the coding_chat and pr_review channels on Discord to handle exploit fixes
• Farie82@2024-02-07 - Adds the labeling procedure and allows Commit Access and Issue Managers to label PRs. Adds Assigning voting teams to PRs for HCs
• Farie82@2024-02-27 - Adds [MQL] --SKIP-- to special labels section
• Farie82@2024-03-06 - Add design and balance team exclusivity explanation
• DGamerL@2024-03-07 - Updated section 2A - PR procedure.
• S34N@2024-03-11 - Added Merge Procedure section.
• Farie82@2024-06-09 - Add the voting groups as a concept. The Design/Balance/Sprite team should notify HCs if a wrong voting group is assigned.
• Burzah@2024-07-02 - Added policy regarding External Teams including protocol for adding Requires Wiki Update by Wiki Managers.
• S34N@2024-07-31 - Added Mapping Team section, amended Section 1 - Roles & their purposes and Section 2 - Procedure
• Burzah@2024-09-26 - Renamed Commit Access to Maintainer where appropriate.
• DGamerL@2024-12-03 - Resprite-only PRs are now only a Sprite Team Responsibility.
• Warriorstar@2024-12-19 - Removed references to defunct map queue labels and procedure.
• Contrabang@2025-02-18 - Changed Headcoder requirements require being on only 1 and not all of the teams with a 6 month requirement.