From af0e53a515dfa0c29094d0109ac5f9c2302bd0e9 Mon Sep 17 00:00:00 2001
From: Mountain Man <43313373+MountainMan1312@users.noreply.github.com>
Date: Fri, 14 Apr 2023 17:32:41 -0400
Subject: Modify `CONTRIBUTING.md` to be more informative and instructive

---
 CONTRIBUTING.md | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++++----
 1 file changed, 83 insertions(+), 5 deletions(-)

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index 42ae6d8..2594ed3 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -24,7 +24,7 @@ I will reject all contributions from:
 
 Furthermore, individual items will be rejected because of:
 - exceptionally vulgar language.
-- ignorance or disregard of the `STYLE_GUIDE.md`
+- ignorance or disregard of the `STYLE_GUIDE.md` or Issue templates.
 
 
 ## How to Contribute
@@ -36,9 +36,9 @@ on the [GitHub Issues page](https://github.com/MountainMan1312/MMOSMacs/Issues).
 You can comment on topics that already have an existing Issue, or you
 can submit your own if it does not already exist. Issues can take the
 form of:
-- **Feedback**: share your thoughts about MMOSMacs.
-- **Bug Report**: discusion about a problem with the MMOSMacs code.
 - **RFC**: discussion about making a change to MMOSMacs.
+- **Bug Report**: discusion about a problem with the MMOSMacs code.
+- **Feedback**: share your thoughts about MMOSMacs.
 
 Before submitting a new issue, search for existing duplicate issues. If
 it already exists, comment on the existing Issue instead of making a new
@@ -49,5 +49,83 @@ it's just for organization's sake.
 To contribute code:
 1. Make an RFC or find an existing one
 2. Discuss your proposed changes
-3. Make your changes
-4. Submit a Pull Request
+3. Create a branch
+4. Make your changes
+5. Submit a Pull Request
+
+
+### RFC Issues, branches, commits, & Pull Requests
+
+#### Writing an RFC
+
+RFCs are the main form of project management for this repository. All
+major changes to MMOSMacs should have an associated RFC. RFC Issues
+should be named in the format `RFC: TITLE`, where title is a short
+description of the proposed changes. For example, the RFC to modify a
+few default Emacs things as a starting point for MMOSMacs is called
+`RFC: Start with sensible defaults`.
+
+The following template should be used when writing an RFC.
+
+```markdown
+# Summary
+
+Provide a one-paragraph summary of the proposed changes
+
+
+# Rationale and motivation
+
+Explain why this change is necessary or desirable. Relate to any other
+relevant RFCs, Bug Reports, or Feedback. Feel free to link to Issues
+from other repositories as well.
+
+
+# Details
+
+Provide an in-depth description of your proposed changes. This should
+get into specifics and corner-cases.
+
+
+# Drawbacks and Alternatives (optional)
+
+Why should these changes NOT be implemented? What other options are
+there, and why are these changes better than the alternatives?
+
+
+# Additional resources (optional)
+
+Link to external resources such as research papers, images, etc.
+
+
+# Unresolved questions (optional)
+
+Ask any further questions you have.
+```
+
+
+#### Creating branches & committing changes
+
+All changes made as part of an RFC should be made in an associated
+branch. The branch should be named in the format `TYPE/#/TITLE`, where
+TYPE is one of `RFC, BUG`, X is the Issue number, and TITLE is a short
+summary of the RFC title. For example the branch for
+`RFC: Start with sensible defaults` is named `RFC/2/sensible-defaults`.
+Branch names should be short, with an absolute maximum of 72 characters
+(preferrably shorter).
+
+Commits should be small and nuclear. They should each do "one thing".
+That said, multiple files could theoretically be affected by a single
+commit. Commit messages should be brief, but not omit any necessary
+detail.
+
+
+#### Writing a Pull Request
+
+Like RFCs, all major changes to MMOSMacs must have an associated Pull
+Reqest, which explains in detail the changes that were made. Pull
+Requests are reviewed before the changes are accepted into the stable
+branch, and it is likely that the reviewer will reject your changes with
+notes on what needs to be fixed.
+
+Pull Requests should explain the specifics and nuances of the changes
+contained therein.
-- 
cgit v1.2.3