Document MCP process and add issue template (#80)

Author: XAMPPRocky

.github/ISSUE_TEMPLATE/mcp.md

@@ -0,0 +1,20 @@
+---
+name: Major change proposal (MCP)
+about: Propose a major change to the project.
+title: "(My major change proposal)"
+labels: "mcp: proposed"
+---
+
+<!--
+Thank you for your interest in proposing a new feature for the `rust-gpu`
+project. Please try to provide a short high level overview of what you would
+like you to add. Also be sure to check the existing and closed MCPs to see
+if it's already been proposed before posting.
+
+Existing Proposals: https://github.com/EmbarkStudios/rust-gpu/issues?q=is%3Aopen+is%3Aissue+label%3A%22mcp%3A+proposed%22
+Closed Proposals: https://github.com/EmbarkStudios/rust-gpu/issues?q=is%3Aclosed+is%3Aissue+label%3A%22mcp%3A+proposed%22
+
+-->
+
+# Proposal
+

.github/workflows/ISSUE_TEMPLATE/bug_report.md

@@ -18,14 +18,23 @@ Feature requests will be tagged as `enhancement` and their status will be update
 
 ### Bugs
 
-When reporting a bug or unexpected behaviour in a project, make sure your issue descibes steps to reproduce the behaviour, including the platform you were using, what steps you took, and any error messages.
+When reporting a bug or unexpected behaviour in a project, make sure your issue describes steps to reproduce the behaviour, including the platform you were using, what steps you took, and any error messages.
 
 Reproducible bugs will be tagged as `bug` and their status will be updated in the comments of the issue.
 
 ### Wontfix
 
 Issues will be closed and tagged as `wontfix` if we decide that we do not wish to implement it, usually due to being misaligned with the project vision or out of scope. We will comment on the issue with more detailed reasoning.
 
+### Labels
+The labels for this repository are divided into the following categories;
+
+- **`c:` Crate** Issues specific a single crate in the repository.
+- **`g:` GPU** Issues specific a GPU vendor.
+- **`p:` Platform** Issues specific a single operating system or platform.
+- **`s:` Status** The current status of a PR or issue.
+- **`t:` Type** The general type of the issue. (E.g. `t: bug` for bugs.)
+
 ## Contribution Workflow
 
 ### Open Issues
@@ -34,31 +43,65 @@ If you're ready to contribute, start by looking at our open issues tagged as [`h
 
 You can comment on the issue to let others know you're interested in working on it or to ask questions.
 
-### Making Changes
+### Major Change Process
+Most bug fixes can be implemented directly by opening a PR, however for larger design decisions and major changes to the compiler's architecture, this repository uses a two stage "Major Change Proposal" and "Request For Comments" process. If you're unsure about what's required for a specific change you should always start with [**opening an issue**][open-issue] or asking the team over on the `#rust-gpu` channel in the [Embark Discord][dis].
 
-1. Fork the repository.
+[dis]: https://discord.gg/8TW9nfF
+[open-issue]: https://github.com/EmbarkStudios/rust-gpu/issues/new
 
-2. Create a new feature branch.
+#### Definitions
 
-3. Make your changes. Ensure that there are no build errors by running the project with your changes locally.
+##### **Major Change Proposal (MCP)**
+A proposal to make a significant internal changes or small public facing changes to the compiler. An MCP is opened as an issue on `rust-gpu` the repository. An MCP typically only requires one member's approval. Though if the change is significantly big enough it may require the full team's sign off or require an RFC.
 
-4. Open a pull request with a name and description of what you did. You can read more about working with pull requests on GitHub [here](https://help.github.com/en/articles/creating-a-pull-request-from-a-fork).
+  An MCP should generally be a short (1-2 paragraphs) high level overview of the change you would want to make, the motivation behind the change, and potential solutions. There is a [major change issue template][mcp-template] you can use for convenience.
 
-5. A maintainer will review your pull request and may ask you to make changes.
+[mcp-template]: https://github.com/rust-lang/rust/issues/new?labels=mcp%3A%20proposed&template=mcp.md
 
-## Code Guidelines
+  Examples of what would require an MCP:
 
-### Rust
+  - Changing the compiler architecture.
+  - Adding support for an existing Rust language or feature.
+  - Small additions (e.g. new methods) to `spirv-std` types.
+  - Proposing an RFC.
 
-You can read about our standards and recommendations for working with Rust [here](https://github.com/EmbarkStudios/rust-ecosystem/blob/master/guidelines.md).
+  Examples of what would **not** require an MCP:
+
+  - Updating documentation
+  - Fixing existing bugs
+  - Performance improvements
+
+##### **Request For Comments (RFC)**
+A proposal to make significant public facing changes to the compiler or standard library. RFCs are opened as pull requests to the `rust-gpu` repository. RFCs require full sign off by the team, before being approved or implemented. Check out the [RFC `000-template.md` document][rfc-template] for details on the structure.
+
+[rfc-template]: https://github.com/EmbarkStudios/rust-gpu/blob/main/rfcs/000-template.md
 
-### Python
+Examples of what would require an RFC:
 
-We recommend following [PEP8 conventions](https://www.python.org/dev/peps/pep-0008/) when working with Python modules.
+- Major additions to `spirv-std`, such as new APIs, or breaking changes to existing ones.
 
-### JavaScript
+#### Life-cycle
 
-We follow the [AirBnB JavaScript style guide](https://github.com/airbnb/javascript). You can find the ESLint configuration in relevant repositories.
+1. You file a [major change proposal][mcp-template] outlining the changes and the motivation for it.
+2. A member of the team will review the proposal and tag it with the appropiate label.
+  2.1. `mcp: accepted` means that the MCP has been accepted and is ready for a pull request implementing it.
+  2.2. `mcp: rfc needed` means that the MCP has been accepted as something the team would like but needs a full RFC before the implementation.
+  2.3 Closing an issue means that the MCP has rejected.
+3. If the proposal has been accepted then the implementation can begin.
+
+### Pull Request Process
+
+1. Fork the repository.
+2. Create a new feature branch.
+3. Make your changes. Ensure that there are no build errors by running the project with your changes locally.
+4. Open a pull request with a name and description of what you did. You can read more about working with pull requests on GitHub [here](https://help.github.com/en/articles/creating-a-pull-request-from-a-fork).
+5. A maintainer will review your pull request and may ask you to make changes.
+
+## Code Guidelines
+
+### Rust
+
+You can read about our standards and recommendations for working with Rust [here](https://github.com/EmbarkStudios/rust-ecosystem/blob/master/guidelines.md).
 
 ## Licensing