diff --git a/.github/CODEOWNERS b/.github/CODEOWNERS
index 50dd099a100..cbfc0fbe66d 100644
--- a/.github/CODEOWNERS
+++ b/.github/CODEOWNERS
@@ -2,6 +2,7 @@
 # This list is alphabetized by User -> Filename KEEP IT THAT WAY
 # In the event that multiple org members are to be informed of changes to the same file or dir, add them to the end under Multiple Owners
 # This is ONLY for taking ownership of server-critical code which must be written in a very specific way for the server to operate at all.
+# You cannot take ownership of a file/feature just because "I dont want people touching my stuff"
 
 ### AffectedArc07
 # Actual Code
@@ -23,9 +24,9 @@
 # Executables that need to be security-cleared
 dreamchecker.exe @AffectedArc07
 rust_g.dll @AffectedArc07
+librust_g.so @AffectedArc07
+
 
-### dearmochi
-/tgui/ @dearmochi
 
 ### Fox-McCloud
 /code/controllers/subsystem/air.dm @Fox-McCloud
diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md
index 697500553bd..b265be2abe1 100644
--- a/.github/CONTRIBUTING.md
+++ b/.github/CONTRIBUTING.md
@@ -666,32 +666,45 @@ There are a few other defines that do other things. `GLOBAL_REAL` shouldn't be u
 `GLOBAL_VAR_INIT` allows you to set an initial value on the var, like `GLOBAL_VAR_INIT(number_one, 1)`.
 `GLOBAL_LIST_INIT` allows you to define a list global var with an initial value. Etc.
 
-## Maintainers
-The only current official role for GitHub staff are the `Maintainers`. They share equal power. The `Maintainers` are
-responsible for properly tagging new pull requests and issues, moderating comments in
-pull requests/issues, and merging/closing pull requests.
+### GitHub Staff
 
-### Maintainer List
+There are 3 roles on the GitHub, these are:
+
+* Headcoder
+* Commit Access
+* Review Team
+
+Each role inherits the lower role's responsibilities (IE: Headcoders also have commit access, and members of commit access are also part of the review team)
+
+`Headcoders` are the overarching "administrators" of the repository. People included in this role are:
 
 * [AffectedArc07](https://github.com/AffectedArc07)
 * [Crazylemon](https://github.com/marlyn-x86)
-* [dearmochi](https://github.com/dearmochi)
 * [Fox P McCloud](https://github.com/Fox-McCloud)
 
-### Maintainer instructions
-* Do not "self-merge"; this refers to the practice of opening a pull request, then
-  merging it yourself. A different maintainer must review and merge your pull request, no
-  matter how trivial. This is to ensure quality.
-  * A subset of this instruction: Do not push directly to the repository, always make a
-  pull request.
-* Wait for the CI build to complete. If it fails, the pull request may only be
- merged if there is a very good reason (example: fixing the CI configuration).
-* Pull requests labeled as bugfixes and refactors may be merged as soon as they are
- reviewed.
-* The shortest waiting period for -any- feature or balancing altering pull request is 24
- hours, to allow other coders and the community time to discuss the proposed changes.
-* If the discussion is active, or the change is controversial, the pull request is to be
- put on hold until a consensus is reached.
-* To keep commit history easy to navigate for future contributors (e.g. Git Blame), squash merge
-is to be preferred to normal merge where suitable. Ensure that the squashed commit name is easy
-to understand and read. Modify it if needed.
+---
+
+`Commit Access` members have write access to the repository and can merge your PRs. People included in this role are:
+
+* [Charliminator](https://github.com/hal9000PR)
+* [farie82](https://github.com/farie82)
+* [SteelSlayer](https://github.com/SteelSlayer)
+
+---
+
+`Review Team` members are people who are denoted as having reviews which can affect mergeability status. People included in this role are:
+
+* [lewcc](https://github.com/lewcc)
+
+---
+
+Full information on the GitHub contribution workflow & policy can be found at [https://www.paradisestation.org/dev/policy/](https://www.paradisestation.org/dev/policy/)
+
+### PR Status
+
+Status of your pull request will be communicated via PR labels. This includes:
+
+* `Status: Awaiting type assignment` - This will be displayed when your PR is awaiting an internal type assignment (for Fix, Balance, Tweak, etc)
+* `Status: Awaiting approval` - This will be displayed if your PR is waiting for approval from the specific party, be it Balance or Design. Fixes & Refactors should never have this label
+* `Status: Awaiting review` - This will be displayed when your PR has passed the design vote and is now waiting for someone in the review team to approve it
+* `Status: Awaiting merge` - Your PR is done and is waiting for someone with commit access to merge it. **Note: Your PR may be delayed if it is pending testmerge or in the mapping queue**
diff --git a/.github/gbp.toml b/.github/gbp.toml
index 28e20d0ee12..63de7a7894c 100644
--- a/.github/gbp.toml
+++ b/.github/gbp.toml
@@ -3,15 +3,16 @@ reset_label = "GBP: Reset"
 
 [points]
 "Administration" = 2
-"Balance" = -8
+"Balance" = -5
 "Code Improvement" = 1
-"Feature" = -9
+"Feature" = -5
 "Fix" = 3
 "GC Related" = 12
 "Grammar and Formatting" = 1
 "High Priority" = 20
 "Infrastructure" = 5
 "Performance" = 12
+"Project Progression" = 10
 "Refactor" = 3
 "Sound" = 1
 "Sprites" = 1