Added the necessary tooling for github

.github/CONTRIBUTING.md

@@ -0,0 +1,167 @@
+# CONTRIBUTING TO CM-SS13
+
+- [CONTRIBUTING TO CM-SS13](#contributing-to-cm-ss13)
+	- [Reporting Issues](#reporting-issues)
+	- [Introduction](#introduction)
+	- [Getting Started](#getting-started)
+	- [Meet the Team](#meet-the-team)
+		- [Head Developer and Project Manager](#head-developer-and-project-manager)
+		- [Maintainers](#maintainers)
+		- [Issue Managers](#issue-managers)
+	- [Issues Tracker](#issues-tracker)
+	- [Development Guides](#development-guides)
+			- [Writing readable code](#writing-readable-code)
+			- [Writing sane code](#writing-sane-code)
+			- [Writing understandable code](#writing-understandable-code)
+			- [Misc](#misc)
+	- [Pull Request Process](#pull-request-process)
+	- [Good Boy Points](#good-boy-points)
+	- [Porting features/sprites/sounds/tools from other codebases](#porting-featuresspritessoundstools-from-other-codebases)
+	- [Banned content](#banned-content)
+
+## Reporting Issues
+
+If you ever encounter a bug in-game, the best way to let a coder know about it is with our GitHub Issue Tracker. Please make sure you use the supplied issue template.
+
+(If you don't have an account, making a new one takes only one minute.)
+
+If you have difficulty, ask for help in the #development channel on our discord.
+
+## Introduction
+
+Hello and welcome to CM-SS13's contributing page. You are here because you are curious or interested in contributing - thank you! Everyone is free to contribute to this project as long as they follow the simple guidelines and specifications below; at CM-SS13, we strive to maintain code stability and maintainability, and to do that, we need all pull requests to hold up to those specifications. It's in everyone's best interests - including yours! - if the same bug doesn't have to be fixed twice because of duplicated code.
+
+First things first, we want to make it clear how you can contribute (if you've never contributed before), as well as the kinds of powers the team has over your additions, to avoid any unpleasant surprises if your pull request is closed for a reason you didn't foresee.
+
+## Getting Started
+
+CM-SS13 doesn't have a list of goals and features to add; we instead allow freedom for contributors to suggest and create their ideas for the game. That doesn't mean we aren't determined to squash bugs, which unfortunately pop up a lot due to the deep complexity of the game. Here are some useful starting guides, if you want to contribute or if you want to know what challenges you can tackle with zero knowledge about the game's code structure.
+
+There is an open list of approachable issues for [your inspiration here](https://github.com/cmss13-devs/cmss13/issues?q=is%3Aopen+is%3Aissue+label%3A%22Good+First+Issue%22).
+
+You can of course, as always, ask for help on the Discord channels or the forums. We're just here to have fun and help out, so please don't expect professional support.
+
+## Meet the Team
+
+### Head Developer and Project Manager
+
+The Head Developer and Project Manager are responsible for controlling, adding, and removing maintainers from the project. In addition to filling the role of a normal maintainer, they have sole authority on who becomes a maintainer, as well as who remains a maintainer and who does not.
+
+### Maintainers
+
+Maintainers are quality control. If a proposed pull request doesn't meet the following specifications, they can request you to change it, or simply just close the pull request. Maintainers are required to give a reason for closing the pull request.
+
+Maintainers can revert your changes if they feel they are not worth maintaining or if they did not live up to the quality specifications.
+
+<details>
+<summary>Maintainer Guidelines</summary>
+
+These are the few directives we have for project maintainers.
+
+- Do not merge PRs you create.
+- Do not merge PRs until 24 hours have passed since it was opened. Exceptions include:
+  - Emergency fixes.
+    - Try to get secondary maintainer approval before merging if you are able to.
+  - PRs with empty commits intended to generate a changelog.
+- Do not merge PRs that contain content from the [banned content list](./CONTRIBUTING.md#banned-content).
+
+These are not steadfast rules as maintainers are expected to use their best judgement when operating.
+
+Our team is entirely voluntary, as such we extend our thanks to maintainers, issue managers, and contributors alike for helping keep the project alive.
+
+</details>
+
+### Issue Managers
+
+Issue Managers help out the project by labelling bug reports and PRs and closing bug reports which are duplicates or are no longer applicable.
+
+<details>
+<summary>What You Can and Can't Do as an Issue Manager</summary>
+
+This should help you understand what you can and can't do with your newfound github permissions.
+
+Things you **CAN** do:
+* Label issues appropriately
+* Close issues when appropriate
+
+Things you **CAN'T** do:
+* [Close PRs](https://imgur.com/w2RqpX8.png): Only maintainers are allowed to close PRs. Do not hit that button.
+* Label PRs, leave that for maintainers to handle.
+
+</details>
+
+## Issues Tracker
+Potential bugs can be submitted to the project issue tracker on GitLab. While we appreciate suggestions, they should **not** be posted here to make triaging technical issues and fixing bugs easier.
+
+When submitting an issue, use the provided template. A few things to keep in mind for a good issue report maximizing the chance of finding and fixing it:
+
+ * Search quickly for existing related issues - add info there if applicable rather than duplicating them
+ * Stay factual and as concise as possible
+ * If possible, attempt to reproduce and confirm the issue, and detail steps
+
+The tracker is a powerful tool - it might look pointless, but ensures what's there can be known by anyone, team members and contributors alike, and won't be forgotten. This maximizes chances of issues being resolved. Don't be afraid to use it.
+
+## Development Guides
+
+#### Writing readable code
+[Style guidelines](./guides/STYLES.md)
+
+#### Writing sane code
+[Code standards](./guides/STANDARDS.md)
+
+#### Writing understandable code
+[Autodocumenting code](./guides/AUTODOC.md)
+
+#### Misc
+[UI Development](../tgui/README.md)
+
+[Embedding tgui components in chat](../tgui/docs/chat-embedded-components.md)
+
+## Pull Request Process
+
+There is no strict process when it comes to merging pull requests. Pull requests will sometimes take a while before they are looked at by a maintainer; the bigger the change, the more time it will take before they are accepted into the code. Every team member is a volunteer who is giving up their own time to help maintain and contribute, so please be courteous and respectful. Here are some helpful ways to make it easier for you and for the maintainers when making a pull request.
+
+* Make sure your pull request complies to the requirements outlined here
+
+* You are expected to have tested your pull requests if it is anything that would warrant testing. Text only changes, single number balance changes, and similar generally don't need testing, but anything else does. This means by extension web edits are disallowed for larger changes.
+
+* You are going to be expected to document all your changes in the pull request. Failing to do so will mean delaying it as we will have to question why you made the change. On the other hand, you can speed up the process by making the pull request readable and easy to understand, with diagrams or before/after data. Should you be optimizing a routine you must provide proof by way of profiling that your changes are faster.
+
+* We ask that you use the changelog system to document your player facing changes, which prevents our players from being caught unaware by said changes - you can find more information about this [on this wiki page](http://tgstation13.org/wiki/Guide_to_Changelogs).
+
+* If you are proposing multiple changes, which change many different aspects of the code, you are expected to section them off into different pull requests in order to make it easier to review them and to deny/accept the changes that are deemed acceptable.
+
+* If your pull request is accepted, the code you add no longer belongs exclusively to you but to everyone; everyone is free to work on it, but you are also free to support or object to any changes being made, which will likely hold more weight, as you're the one who added the feature. It is a shame this has to be explicitly said, but there have been cases where this would've saved some trouble.
+
+* Please explain why you are submitting the pull request, and how you think your change will be beneficial to the game. Failure to do so will be grounds for rejecting the PR.
+
+* If your pull request is not finished, you may open it as a draft for potential review. If you open it as a full-fledged PR make sure it is at least testable in a live environment. Pull requests that do not at least meet this requirement will be closed. You may request a maintainer reopen the pull request when you're ready, or make a new one.
+
+* While we have no issue helping contributors (and especially new contributors) bring reasonably sized contributions up to standards via the pull request review process, larger contributions are expected to pass a higher bar of completeness and code quality *before* you open a pull request. Maintainers may close such pull requests that are deemed to be substantially flawed. You should take some time to discuss with maintainers or other contributors on how to improve the changes.
+
+* After leaving reviews on an open pull request, maintainers may convert it to a draft. Once you have addressed all their comments to the best of your ability, feel free to mark the pull as `Ready for Review` again.
+
+## Good Boy Points
+
+Each GitHub account has a score known as Good Boy Points, or GBP. This is a system we use to ensure that the codebase stays maintained and that contributors fix bugs as well as add features.
+
+The GBP gain or loss for a PR depends on the type of changes the PR makes, represented by the tags assigned to the PR by the CM-SS13 github bot or maintainers. Generally speaking, fixing bugs, updating sprites, or improving maps increases your GBP score, while adding mechanics, or rebalancing things will cost you GBP.
+
+The GBP change of a PR is the sum of greatest positive and lowest negative values it has. For example, a PR that has tags worth +10, +4, -1, -7, will net 3 GBP (10 - 7).
+
+Negative GBP increases the likelihood of a maintainer closing your PR. With that chance being higher the lower your GBP is. Be sure to use the proper tags in the changelog to prevent unnecessary GBP loss. Maintainers reserve the right to change tags as they deem appropriate.
+
+There is no benefit to having a higher positive GBP score, since GBP only comes into consideration when it is negative.
+
+You can see each tag and their GBP values [Here](https://github.com/cmss13-devs/cmss13/blob/master/.github/gbp.toml).
+
+## Porting features/sprites/sounds/tools from other codebases
+
+If you are porting features/tools from other codebases, you must give them credit where it's due. Typically, crediting them in your pull request and the changelog is the recommended way of doing it. Take note of what license they use though, porting stuff from AGPLv3 and GPLv3 codebases are allowed.
+
+Regarding sprites & sounds, you must credit the artist and possibly the codebase.
+
+
+## Banned content
+Do not add any of the following in a Pull Request or risk getting the PR closed:
+* Code which violates GitHub's [terms of service](https://github.com/site/terms).

.github/ISSUE_TEMPLATE/bug_report.md

@@ -1,33 +1,13 @@
-#### Description
-<!-- a quick, 1-2 sentence summary -->
+---
+name: Bug report
+about: Create a report to help reproduce and fix the issue
+---
+## Testmerges:
 
+<!-- If you're certain the issue is to be caused by a test merge, report it in the pull request's comment section rather than on the tracker(If you're unsure you can refer to the issue number by prefixing said number with #. The issue number can be found beside the title after submitting it to the tracker).If no testmerges are active, feel free to remove this section. -->
 
-#### Difference between expected and actual behavior
-<!-- what does it do, what it should do... -->
+## Reproduction:
 
+<!-- Explain your issue in detail, including the steps to reproduce it. Issues without proper reproduction steps or explanation are open to being ignored/closed by maintainers.-->
 
-#### Steps to reproduce
-<!-- step by step on how we can reproduce this issue, as detailed as possible -->
-
-
-#### Specific information for locating
-<!-- e.g. an object name, paste specific message outputs... -->
-
-
-#### Length of time in which bug has been known to occur
-<!--
-	Be specific if you approximately know the time it's been occurring
-	for—this can speed up finding the source. If you're not sure
-	about it, tell us too!
--->
-
-
-#### Issue bingo
-<!-- Check these by writing an x inside the [ ] (like this: [x])-->
-<!-- Don't forget to remove the space between the brackets, or it won't work! -->
-- [ ] Issue could be reproduced at least once
-- [ ] Issue could be reproduced by different players
-- [ ] Issue could be reproduced in multiple rounds
-- [ ] Issue happened in a recent (less than 7 days ago) round
-- [ ] [Couldn't find an existing issue about this](https://gitlab.com/cmdevs/colonial-warfare/issues)
-
+<!-- **For Admins:** Oddities induced by var-edits and other admin tools are not necessarily bugs. Verify that your issues occur under regular circumstances before reporting them. -->

.github/PULL_REQUEST_TEMPLATE.md

@@ -1,34 +1,36 @@
-## Changelog
-<!--
-	Remember that the name can NOT contain spaces
--->
+<!-- Write **BELOW** The Headers and **ABOVE** The comments else it may not be viewable. -->
+
+## About The Pull Request
 
-:cl: JohnTitor
+<!-- Describe The Pull Request. Please be sure every change is documented or this can delay review and even discourage maintainers from merging your PR! -->
 
-rscadd: Added a broken changelog that wasn't filled out.
+## Why It's Good For The Game
 
-tweak: Probably tweaked something.
+<!-- Please add a short description of why you think these changes would benefit the game. If you can't justify it in words, it might not be worth adding. -->
 
-bugfix: Jones is now a cat again.
+## Changelog
 
+<!-- If your PR modifies aspects of the game that can be concretely observed by players or admins you should add a changelog. If your change does NOT meet this description, remove this section. Be sure to properly mark your PRs to prevent unnecessary GBP loss. Please note that maintainers freely reserve the right to remove and add tags should they deem it appropriate. You can attempt to finagle the system all you want, but it's best to shoot for clear communication right off the bat. -->
+
+:cl:
+add: Added new mechanics or gameplay changes
+add: Added more things
+tweak: Tweaks to existing mechanics or gameplay
+del: Removed old things
+qol: made something easier to use
+balance: rebalanced something
+fix: fixed a few things
+soundadd: added a new sound thingy
+sounddel: removed an old sound thingy
+imageadd: added some icons and images
+imagedel: deleted some icons and images
+spellcheck: fixed a few typos
+code: changed some code
+refactor: refactored some code
+config: changed some config setting
+admin: messed with admin stuff
+server: something server ops should know
 /:cl:
 
-<!-- Valid Prefixes:
-bugfix tweak
-rscadd rscdel
-imageadd imagedel
-maptweak spellcheck
-soundadd sounddel
-experiment wip
--->
-
-## Details
-<!--
-	Put more details about your changes below as needed or just anything you don't want in the changelog.
--->
-
-
-## Related Issues
-<!--
-	 Mention the issue(s) this MR closes or is related to
--->
+<!-- Both :cl:'s are required for the changelog to work! You can put your name to the right of the first :cl: if you want to overwrite your GitHub username as author ingame. -->
+<!-- You can use multiple of the same prefix (they're only used for the icon ingame) and delete the unneeded ones. Despite some of the tags, changelogs should generally represent how a player might be affected by the changes rather than a summary of the PR's contents. -->

.github/add_labels.py

@@ -0,0 +1,86 @@
+import os, re
+from github import Github
+
+# Format - Key: Array[Label, [StringsToIgnore]]
+changelogToPrefix = {
+	'fix': ["Fix", ["fixed a few things"]],
+	'qol': ["Quality of Life", ["made something easier to use"]],
+	'add': ["Feature", ["Added new mechanics or gameplay changes", "Added more things"]],
+	'del': ["Removal", ["Removed old things"]],
+	'tweak': ["Tweak", ["Tweaks to existing mechanics or gameplay"]],
+	'spellcheck': ["Grammar and Formatting", ["fixed a few typos"]],
+	'balance': ["Balance", ["rebalanced something"]],
+	'code': ["Code Improvement", ["changed some code"]],
+	'refactor': ["Refactor", ["refactored some code"]],
+	'config': ["Config", ["changed some config setting"]],
+	'admin': ["Admin", ["messed with admin stuff"]],
+	'server': ["Server", ["something server ops should know"]]
+}
+
+fileToPrefix = {
+	'wav': 'Sound',
+	'ogg': 'Sound',
+    'dmm': 'Mapping',
+
+	'js': 'UI',
+	'tsx': 'UI',
+	'ts': 'UI',
+	'jsx': 'UI',
+	'scss': 'UI',
+
+	'dmi': "Sprites",
+}
+
+def get_labels(pr):
+	labels = {}
+	changelog_match = re.search(r"🆑(.*)🆑", pr.body, re.S | re.M)
+	if changelog_match is None:
+		return
+	lines = changelog_match.group(1).split('\n')
+	for line in lines:
+		line = line.strip()
+		if not line:
+			continue
+
+		contentSplit = line.split(":")
+
+		key = contentSplit.pop(0).strip()
+		content = ":".join(contentSplit).strip()
+
+		if not key in changelogToPrefix:
+			continue
+
+		if content in changelogToPrefix[key][1]:
+			continue
+
+		labels[changelogToPrefix[key][0]] = True
+
+	files = pr.get_files()
+	for file in files:
+		prefix = file.filename.split(".")[-1]
+		if not prefix in fileToPrefix:
+			continue
+		labels[fileToPrefix[prefix]] = True
+	return list(labels)
+
+def main():
+	g = Github(os.environ["TOKEN"])
+	repo = g.get_repo(os.environ['REPO'])
+
+	pr = repo.get_pull(int(os.environ["PR_NUMBER"]))
+	if not pr:
+		print("Not a PR.")
+		return
+
+	labels = get_labels(pr)
+
+	if labels is None: # no labels to add
+		print("No labels to add.")
+		return
+
+	for label in labels:
+		pr.add_to_labels(label)
+
+
+if __name__ == '__main__':
+	main()

.github/gbp.toml

@@ -0,0 +1,22 @@
+no_balance_label = "GBP: No Update"
+reset_label = "GBP: Reset"
+
+[points]
+"Accessibility" = 3
+"Administration" = 2
+"Atomic" = 2
+"Balance" = -8
+"Code Improvement" = 2
+"Fix" = 3
+"Grammar and Formatting" = 1
+"Hard Deletes" = 12
+"Logging" = 1
+"Feature" = -10
+"Tweak" = -3
+"Performance" = 12
+"Priority: CRITICAL" = 20
+"Priority: High" = 15
+"Quality of Life" = 1
+"Refactor" = 10
+"Sound" = 3
+"Sprites" = 3