Split up Supplemental Info and touch up Contrib Guidelines

Created new pages:
* Linting
* Logging
* Writing Good Commit Messages

Moved Draft PR section to new pull requests guide
Moved type hinting section to style guide

7 files changed, 82 insertions, 128 deletions

diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines.md
index de1777f2..f13b05be 100644
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines.md
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines.md
@@ -4,22 +4,15 @@ description: Guidelines to adhere to when contributing to our projects.
 ---
 
 Thank you for your interest in our projects!
+This page contains the golden rules to follow when contributing. If you have questions about how to get started contributing, check out our [in-depth walkthrough](../../contributing/).
 
-If you are interested in contributing, **this page contains the golden rules to follow when contributing.**
-Supplemental information [can be found here](./supplemental-information/).
-Do note that failing to comply with our guidelines may lead to a rejection of the contribution.
-
-If you are confused by any of these rules, feel free to ask us in the `#dev-contrib` channel in our [Discord server.](https://discord.gg/python)
-
-# The Golden Rules of Contributing
-
-1. **Lint before you push.** We have simple but strict style rules that are enforced through linting.
-You must always lint your code before committing or pushing.
-[Using tools](./supplemental-information/#linting-and-pre-commit) such as `flake8` and `pre-commit` can make this easier.
-Make sure to follow our [style guide](../style-guide/) when contributing.
+1. **Lint before you push.**
+We have simple but strict style rules that are enforced through linting.
+[Set up a pre-commit hook](../linting/) to lint your code when you commit it.
+Not all of the style rules are enforced by linting, so make sure to read the [style guide](../style-guide/) as well.
 2. **Make great commits.**
 Great commits should be atomic, with a commit message explaining what and why.
-More on that can be found in [this section](./supplemental-information/#writing-good-commit-messages).
+Check out [Writing Good Commit Messages](/commit-messages) for details.
 3. **Do not open a pull request if you aren't assigned to the issue.**
 If someone is already working on it, consider offering to collaborate with that person.
 4. **Use assets licensed for public use.**
@@ -28,4 +21,8 @@ Whenever the assets are images, audio or even code, they must have a license com
 We aim to foster a welcoming and friendly environment on our open source projects.
 We take violations of our Code of Conduct very seriously, and may respond with moderator action.
 
-Welcome to our projects!
+<br/>
+
+Failing to comply with our guidelines may lead to a rejection of the contribution.
+If you have questions about any of the rules, feel free to ask us in the `#dev-contrib` channel in our [Discord server](https://discord.gg/python).
+{: .notification .is-warning }
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/commit-messages.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/commit-messages.md
new file mode 100644
index 00000000..ba476b65
--- /dev/null
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/commit-messages.md
@@ -0,0 +1,15 @@
+---
+title: Writing Good Commit Messages
+description: Information about logging in our projects.
+---
+
+A well-structured git log is key to a project's maintainability; it provides insight into when and *why* things were done for future maintainers of the project.
+
+Commits should be as narrow in scope as possible.
+Commits that span hundreds of lines across multiple unrelated functions and/or files are very hard for maintainers to follow.
+After about a week they'll probably be hard for you to follow, too.
+
+Please also avoid making minor commits for fixing typos or linting errors.
+[Don’t forget to lint before you push!](https://soundcloud.com/lemonsaurusrex/lint-before-you-push)
+
+A more in-depth guide to writing great commit messages can be found in Chris Beam's [How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/supplemental-information.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/supplemental-information.md
deleted file mode 100644
index e64e4fc6..00000000
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/contributing-guidelines/supplemental-information.md
+++ /dev/null
@@ -1,99 +0,0 @@
----
-title: Supplemental Information
-description: Additional information related to our contributing guidelines.
----
-
-This page contains additional information concerning a specific part of our development pipeline.
-
-## Writing Good Commit Messages
-
-A well-structured git log is key to a project's maintainability; it provides insight into when and *why* things were done for future maintainers of the project.
-
-Commits should be as narrow in scope as possible.
-Commits that span hundreds of lines across multiple unrelated functions and/or files are very hard for maintainers to follow.
-After about a week they'll probably be hard for you to follow, too.
-
-Please also avoid making minor commits for fixing typos or linting errors.
-*[Don’t forget to lint before you push!](https://soundcloud.com/lemonsaurusrex/lint-before-you-push)*
-
-A more in-depth guide to writing great commit messages can be found in Chris Beam's *[How to Write a Git Commit Message](https://chris.beams.io/posts/git-commit/).*
-
-## Code Style
-
-All of our projects have a certain project-wide style that contributions should attempt to maintain consistency with.
-During PR review, it's not unusual for style adjustments to be requested.
-
-[This page](../../style-guide/) will reference the differences between our projects and what is recommended by [PEP 8.](https://www.python.org/dev/peps/pep-0008/)
-
-## Linting and Pre-commit
-
-On most of our projects, we use `flake8` and `pre-commit` to ensure that the code style is consistent across the code base.
-
-Running `flake8` will warn you about any potential style errors in your contribution.
-You must always check it **before pushing**.
-Your commit will be rejected by the build server if it fails to lint.
-
-**Some style rules are not enforced by flake8. Make sure to read the [style guide](../../style-guide/).**
-
-`pre-commit` is a powerful tool that helps you automatically lint before you commit.
-If the linter complains, the commit is aborted so that you can fix the linting errors before committing again.
-That way, you never commit the problematic code in the first place!
-
-Please refer to the project-specific documentation to see how to setup and run those tools.
-In most cases, you can install pre-commit using `poetry run task precommit`, and lint using `poetry run task lint`.
-
-## Type Hinting
-
-[PEP 484](https://www.python.org/dev/peps/pep-0484/) formally specifies type hints for Python functions, added to the Python Standard Library in version 3.5.
-Type hints are recognized by most modern code editing tools and provide useful insight into both the input and output types of a function, preventing the user from having to go through the codebase to determine these types.
-
-For example:
-
-```python
-import typing
-
-def foo(input_1: int, input_2: typing.Dict[str, str]) -> bool:
-    ...
-```
-
-This tells us that `foo` accepts an `int` and a `dict`, with `str` keys and values, and returns a `bool`.
-
-If the project is running Python 3.9 or above, you can use `dict` instead of `typing.Dict`.
-See [PEP 585](https://www.python.org/dev/peps/pep-0585/) for more information.
-
-All function declarations should be type hinted in code contributed to the PyDis organization.
-
-## Logging
-
-Instead of using `print` statements for logging, we use the built-in [`logging`](https://docs.python.org/3/library/logging.html) module.
-Here is an example usage:
-
-```python
-import logging
-
-log = logging.getLogger(__name__) # Get a logger bound to the module name.
-# This line is usually placed under the import statements at the top of the file.
-
-log.trace("This is a trace log.")
-log.warning("BEEP! This is a warning.")
-log.critical("It is about to go down!")
-```
-
-Print statements should be avoided when possible.
-Our projects currently defines logging levels as follows, from lowest to highest severity:
-
-- **TRACE:** These events should be used to provide a *verbose* trace of every step of a complex process. This is essentially the `logging` equivalent of sprinkling `print` statements throughout the code.
-- **Note:** This is a PyDis-implemented logging level. It may not be available on every project.
-- **DEBUG:** These events should add context to what's happening in a development setup to make it easier to follow what's going while workig on a project. This is in the same vein as **TRACE** logging but at a much lower level of verbosity.
-- **INFO:** These events are normal and don't need direct attention but are worth keeping track of in production, like checking which cogs were loaded during a start-up.
-- **WARNING:** These events are out of the ordinary and should be fixed, but can cause a failure.
-- **ERROR:** These events can cause a failure in a specific part of the application and require urgent attention.
-- **CRITICAL:** These events can cause the whole application to fail and require immediate intervention.
-
-Any logging above the **INFO** level will trigger a [Sentry](https://sentry.io) issue and alert the Core Developer team.
-
-## Draft Pull Requests
-
-Github [provides a PR feature](https://github.blog/2019-02-14-introducing-draft-pull-requests/) that allows the PR author to mark it as a Draft when opening it. This provides both a visual and functional indicator that the contents of the PR are in a draft state and not yet ready for formal review.
-
-This feature should be utilized in place of the traditional method of prepending `[WIP]` to the PR title.
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/linting.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/linting.md
new file mode 100644
index 00000000..48f1cafc
--- /dev/null
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/linting.md
@@ -0,0 +1,14 @@
+---
+title: Linting
+description: A guide for linting and setting up pre-commit.
+---
+
+Your commit will be rejected by the build server if it fails to lint.
+On most of our projects, we use `flake8` and `pre-commit` to ensure that the code style is consistent across the code base.
+
+`pre-commit` is a powerful tool that helps you automatically lint before you commit.
+If the linter complains, the commit is aborted so that you can fix the linting errors before committing again.
+That way, you never commit the problematic code in the first place!
+
+Please refer to the project-specific documentation to see how to setup and run those tools.
+In most cases, you can install pre-commit using `poetry run task precommit`, and lint using `poetry run task lint`.
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/logging.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/logging.md
new file mode 100644
index 00000000..1291a7a4
--- /dev/null
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/logging.md
@@ -0,0 +1,31 @@
+---
+title: Logging
+description: Information about logging in our projects.
+---
+
+Instead of using `print` statements for logging, we use the built-in [`logging`](https://docs.python.org/3/library/logging.html) module.
+Here is an example usage:
+
+```python
+import logging
+
+log = logging.getLogger(__name__) # Get a logger bound to the module name.
+# This line is usually placed under the import statements at the top of the file.
+
+log.trace("This is a trace log.")
+log.warning("BEEP! This is a warning.")
+log.critical("It is about to go down!")
+```
+
+Print statements should be avoided when possible.
+Our projects currently defines logging levels as follows, from lowest to highest severity:
+
+- **TRACE:** These events should be used to provide a *verbose* trace of every step of a complex process. This is essentially the `logging` equivalent of sprinkling `print` statements throughout the code.
+- **Note:** This is a PyDis-implemented logging level. It may not be available on every project.
+- **DEBUG:** These events should add context to what's happening in a development setup to make it easier to follow what's going while workig on a project. This is in the same vein as **TRACE** logging but at a much lower level of verbosity.
+- **INFO:** These events are normal and don't need direct attention but are worth keeping track of in production, like checking which cogs were loaded during a start-up.
+- **WARNING:** These events are out of the ordinary and should be fixed, but can cause a failure.
+- **ERROR:** These events can cause a failure in a specific part of the application and require urgent attention.
+- **CRITICAL:** These events can cause the whole application to fail and require immediate intervention.
+
+Any logging above the **INFO** level will trigger a [Sentry](https://sentry.io) issue and alert the Core Developer team.
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/pull-requests.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/pull-requests.md
index f7dee491..a9b6385e 100644
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/pull-requests.md
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/pull-requests.md
@@ -10,7 +10,7 @@ As stated in our [Contributing Guidelines](../contributing-guidelines/), do not
 Before opening a pull request you should have:
 
 1. Committed your changes to your local repository
-2. [Linted](../contributing-guidelines/#linting-and-pre-commit) your code
+2. [Linted](../linting/) your code
 3. Tested your changes
 4. Pushed the branch to your fork of the project on GitHub
 
diff --git a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/style-guide.md b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/style-guide.md
index f9962990..4dba45c8 100644
--- a/pydis_site/apps/content/resources/guides/pydis-guides/contributing/style-guide.md
+++ b/pydis_site/apps/content/resources/guides/pydis-guides/contributing/style-guide.md
@@ -191,21 +191,17 @@ Present tense defines that the work being done is now, in the present, rather th
 **Use:** "Build an information embed."<br>
 **Don't use:** "Built an information embed." or "Will build an information embed."
 
-# Type Annotations
-Functions are required to have type annotations as per the style defined in [PEP 484](https://www.python.org/dev/peps/pep-0484/).
+# Type Hinting
+Functions are required to have type annotations as per the style defined in [PEP 484](https://www.python.org/dev/peps/pep-0484/). Type hints are recognized by most modern code editing tools and provide useful insight into both the input and output types of a function, preventing the user from having to go through the codebase to determine these types.
 
-A function without annotations might look like:
-```py
-def divide(a, b):
-    """Divide the two given arguments."""
-    return a / b
-```
-
-With annotations, the arguments and the function are annotated with their respective types:
-```py
-def divide(a: int, b: int) -> float:
-    """Divide the two given arguments."""
-    return a / b
+A function with type hints looks like:
+```python
+def foo(input_1: int, input_2: dict[str, int]) -> bool:
+    ...
 ```
+This tells us that `foo` accepts an `int` and a `dict`, with `str` keys and `int` values, and returns a `bool`.
 
 In previous examples, we have purposely omitted annotations to keep focus on the specific points they represent.
+
+> **Note:** if the project is running Python 3.8 or below you have to use `typing.Dict` instead of `dict`, but our three main projects are all >=3.9.
+> See [PEP 585](https://www.python.org/dev/peps/pep-0585/) for more information.