docs: draft contribution guide

Author: lewisakura

CONTRIBUTING.md

@@ -0,0 +1,57 @@
+# Contribution Guide
+
+So, you wanna contribute to Bright? My oh my! You are very welcome to, just read the guide below to make sure what you're
+doing is a-okay.
+
+## Bug Reporting
+
+Before bug reporting, please check the following:
+
+- Is this a security issue? **STOP!** Do not open a public issue! Please report the vulnerability via GitHub's advisory
+  system. You are prompted with this option when you create a new issue.
+
+- Is this a duplicate? Please add your information (if applicable) to that issue instead of making a new one.
+
+- Is your problem easy to reproduce? Please provide a minimal reproduction with your issue. If a reproduction is not
+  possible, please detail in the clearest way you can on how to reproduce the issue, otherwise it may be closed with
+  "cannot reproduce".
+
+## Code/Documentation Contributions
+
+### AI Generation Policy
+
+Bright will not accept pull requests that are written completely with AI. These sorts of contributions signify that effort
+was not put in to the pull request, and do not inspire any confidence that what is being contributed is functional. Please
+put in human work to your contributions, rather than relying on an AI tool to do the work for you.
+
+For tools such as Copilot, make sure that the generated code works and has been modified to fit with the project's
+codestyle. Do not blindly trust generated code to be functional.
+
+### Code
+
+[to be done]
+
+### Documentation
+
+Bright's documentation is written to be a mix of serious and whimsy. Bright itself is not taken overly serious, as that
+would make it a boring tool, and my personal opinion is that a little sprinkle of humor and general unseriousness in
+documentation makes it more engaging for a developer to read through, but too much leads to it becoming annoying and
+repetitive.
+
+The current documentation has a few humorous descriptions and bits that don't take itself serious, but when it comes to
+the main information, it should be considered as a more serious subject, and humor should be reduced or eliminated. The
+[Transformer Basics](https://brightluau.dev/developer-guide/tutorials/transformer-basics/) guide is not really a guideline
+per se, but is a good reference for what we're going for. Unserious parts are mixed in where appropriate, but the key
+information is kept serious so that developers aren't deciphering jokes and whatnot to work out what to do. Essentially,
+add whimsy in areas that can be ignored easier, and reduce it during key information.
+
+Page descriptions are probably a massive exception to this rule, as they are almost exclusively written with humor in
+mind. These descriptions only show in social cards, rather than on the page themselves, so it's okay to make them silly
+since it won't affect the content of the page.
+
+Most importantly though, documentation should be informal. Bright is not a company of any kind; it is a community ran thing.
+Formal English tends to give an impression that something is very uptight, and that is not the vibe that we should be
+going for.
+
+The only exception to all of the above is the API documentation. It should be written in a relatively deadpan way as it's
+meant to describe code, rather than be a general piece of writing.