1 files changed, 21 insertions, 52 deletions
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index c331bf9..e7a3942 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,69 +1,55 @@
 # Contributing to MMOSMacs
-Howdy, and welcome to the MMOSMacs git repository. This document
+Howdy, and welcome to the MMOSMacs git repository. This document outlines the conventions and standards for contributing to the project.
-outlines the conventions and standards for the project.
 ## This is personal
-Please understand that this is my personal Emacs configuration. MMOSMacs
+Please understand that this is my personal Emacs configuration. MMOSMacs is designed to meet my personal needs. I welcome any and all contributions, and I will do my best to make MMOSMacs accessible to others, but my needs and preferences ultimately take priority.
-is designed to meet my personal needs. I welcome any and all
-contributions, and I will do my best to make MMOSMacs accessible to
-others, but my needs and preferences ultimately take priority.
-All contributors are listed at the end of this document. If you have
+All contributors are listed at the end of this document. If you have contributed and your name does not appear here, submit a PR or RFC Issue for it to be added.
-contributed and your name does not appear here, submit a PR or RFC Issue
-for it to be added.
 ## Code of Conduct
 I will reject all contributions from:
- people who abuse other contributors.
+- people who abuse me or other contributors.
 - people I know to be affiliated with any state agency.
 Furthermore, individual items will be rejected because of:
 - exceptionally vulgar language.
- ignorance or disregard of the `STYLE_GUIDE.md` or Issue templates.
+- ignorance or disregard of `STYLE_GUIDE.md`.
 ## How to Contribute
 There are several ways you can contribute.
-The easiest way you can contribute is by taking part in the discussions
+The easiest way you can contribute is by taking part in the discussions 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:
-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:
 - **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
+Before submitting a new issue, search for existing duplicate issues. If it already exists, comment on the existing Issue instead of making a new one. Duplicate issues will be removed and you will be asked to move your post to the comment section of the existing post. It's not to be rude, it's just for organization's sake.
-it already exists, comment on the existing Issue instead of making a new
-one. Duplicate issues will be removed and you will be asked to move your
-post to the comment section of the existing post. It's not to be rude,
-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. Create a branch
 4. Make your changes
 5. Submit a Pull Request
+6. Wait for feedback
 ### RFC Issues, branches, commits, & Pull Requests
 #### Writing an RFC
-RFCs are the main form of project management for this repository. All
+RFCs are the main way contributors can request or suggest changes. I do not use RFCs as project management, so there may be plans that haven't been discussed anywhere.
-major changes to MMOSMacs should have an associated RFC. RFC Issues
-should be named in the format `RFC: TITLE`, where title is a short
+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`.
-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.
@@ -75,21 +61,17 @@ Provide a one-paragraph summary of the proposed changes
 # Rationale and motivation
-Explain why this change is necessary or desirable. Relate to any other
+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.
-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
+Provide an in-depth description of your proposed changes. This should get into specifics and corner-cases.
-get into specifics and corner-cases.
 # Drawbacks and Alternatives (optional)
-Why should these changes NOT be implemented? What other options are
+Why should these changes NOT be implemented? What other options are there, and why are these changes better than the alternatives?
-there, and why are these changes better than the alternatives?
 # Additional resources (optional)
@@ -105,27 +87,14 @@ Ask any further questions you have.
 #### Creating branches & committing changes
-All changes made as part of an RFC should be made in an associated
+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
-branch. The branch should be named in the format `TYPE/#/TITLE`, where
+`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).
-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".
+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.
-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
+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.
-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
+Pull Requests should explain the specifics and nuances of the changes contained therein.
-contained therein.

diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index c331bf9..e7a3942 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md
@@ -1,69 +1,55 @@
1	# Contributing to MMOSMacs	1	# Contributing to MMOSMacs
2		2
3	Howdy, and welcome to the MMOSMacs git repository. This document	3	Howdy, and welcome to the MMOSMacs git repository. This document outlines the conventions and standards for contributing to the project.
4	outlines the conventions and standards for the project.
5		4
6		5
7	## This is personal	6	## This is personal
8		7
9	Please understand that this is my personal Emacs configuration. MMOSMacs	8	Please understand that this is my personal Emacs configuration. MMOSMacs is designed to meet my personal needs. I welcome any and all contributions, and I will do my best to make MMOSMacs accessible to others, but my needs and preferences ultimately take priority.
10	is designed to meet my personal needs. I welcome any and all
11	contributions, and I will do my best to make MMOSMacs accessible to
12	others, but my needs and preferences ultimately take priority.
13		9
14	All contributors are listed at the end of this document. If you have	10	All contributors are listed at the end of this document. If you have contributed and your name does not appear here, submit a PR or RFC Issue for it to be added.
15	contributed and your name does not appear here, submit a PR or RFC Issue
16	for it to be added.
17		11
18		12
19	## Code of Conduct	13	## Code of Conduct
20		14
21	I will reject all contributions from:	15	I will reject all contributions from:
22	- people who abuse other contributors.	16	- people who abuse me or other contributors.
23	- people I know to be affiliated with any state agency.	17	- people I know to be affiliated with any state agency.
24		18
25	Furthermore, individual items will be rejected because of:	19	Furthermore, individual items will be rejected because of:
26	- exceptionally vulgar language.	20	- exceptionally vulgar language.
27	- ignorance or disregard of the `STYLE_GUIDE.md` or Issue templates.	21	- ignorance or disregard of `STYLE_GUIDE.md`.
28		22
29		23
30	## How to Contribute	24	## How to Contribute
31		25
32	There are several ways you can contribute.	26	There are several ways you can contribute.
33		27
34	The easiest way you can contribute is by taking part in the discussions	28	The easiest way you can contribute is by taking part in the discussions 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:
35	on the [GitHub Issues page](https://github.com/MountainMan1312/MMOSMacs/issues).	29
36	You can comment on topics that already have an existing Issue, or you
37	can submit your own if it does not already exist. Issues can take the
38	form of:
39	- RFC: discussion about making a change to MMOSMacs.	30	- RFC: discussion about making a change to MMOSMacs.
40	- Bug Report: discusion about a problem with the MMOSMacs code.	31	- Bug Report: discusion about a problem with the MMOSMacs code.
41	- Feedback: share your thoughts about MMOSMacs.	32	- Feedback: share your thoughts about MMOSMacs.
42		33
43	Before submitting a new issue, search for existing duplicate issues. If	34	Before submitting a new issue, search for existing duplicate issues. If it already exists, comment on the existing Issue instead of making a new one. Duplicate issues will be removed and you will be asked to move your post to the comment section of the existing post. It's not to be rude, it's just for organization's sake.
44	it already exists, comment on the existing Issue instead of making a new
45	one. Duplicate issues will be removed and you will be asked to move your
46	post to the comment section of the existing post. It's not to be rude,
47	it's just for organization's sake.
48		35
49	To contribute code:	36	To contribute code:
		37
50	1. Make an RFC or find an existing one	38	1. Make an RFC or find an existing one
51	2. Discuss your proposed changes	39	2. Discuss your proposed changes
52	3. Create a branch	40	3. Create a branch
53	4. Make your changes	41	4. Make your changes
54	5. Submit a Pull Request	42	5. Submit a Pull Request
		43	6. Wait for feedback
55		44
56		45
57	### RFC Issues, branches, commits, & Pull Requests	46	### RFC Issues, branches, commits, & Pull Requests
58		47
59	#### Writing an RFC	48	#### Writing an RFC
60		49
61	RFCs are the main form of project management for this repository. All	50	RFCs are the main way contributors can request or suggest changes. I do not use RFCs as project management, so there may be plans that haven't been discussed anywhere.
62	major changes to MMOSMacs should have an associated RFC. RFC Issues	51
63	should be named in the format `RFC: TITLE`, where title is a short	52	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`.
64	description of the proposed changes. For example, the RFC to modify a
65	few default Emacs things as a starting point for MMOSMacs is called
66	`RFC: Start with sensible defaults`.
67		53
68	The following template should be used when writing an RFC.	54	The following template should be used when writing an RFC.
69		55
@@ -75,21 +61,17 @@ Provide a one-paragraph summary of the proposed changes
75		61
76	# Rationale and motivation	62	# Rationale and motivation
77		63
78	Explain why this change is necessary or desirable. Relate to any other	64	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.
79	relevant RFCs, Bug Reports, or Feedback. Feel free to link to Issues
80	from other repositories as well.
81		65
82		66
83	# Details	67	# Details
84		68
85	Provide an in-depth description of your proposed changes. This should	69	Provide an in-depth description of your proposed changes. This should get into specifics and corner-cases.
86	get into specifics and corner-cases.
87		70
88		71
89	# Drawbacks and Alternatives (optional)	72	# Drawbacks and Alternatives (optional)
90		73
91	Why should these changes NOT be implemented? What other options are	74	Why should these changes NOT be implemented? What other options are there, and why are these changes better than the alternatives?
92	there, and why are these changes better than the alternatives?
93		75
94		76
95	# Additional resources (optional)	77	# Additional resources (optional)
@@ -105,27 +87,14 @@ Ask any further questions you have.
105		87
106	#### Creating branches & committing changes	88	#### Creating branches & committing changes
107		89
108	All changes made as part of an RFC should be made in an associated	90	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
109	branch. The branch should be named in the format `TYPE/#/TITLE`, where	91	`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).
110	TYPE is one of `RFC, BUG`, X is the Issue number, and TITLE is a short
111	summary of the RFC title. For example the branch for
112	`RFC: Start with sensible defaults` is named `RFC/2/sensible-defaults`.
113	Branch names should be short, with an absolute maximum of 72 characters
114	(preferrably shorter).
115		92
116	Commits should be small and nuclear. They should each do "one thing".	93	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.
117	That said, multiple files could theoretically be affected by a single
118	commit. Commit messages should be brief, but not omit any necessary
119	detail.
120		94
121		95
122	#### Writing a Pull Request	96	#### Writing a Pull Request
123		97
124	Like RFCs, all major changes to MMOSMacs must have an associated Pull	98	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.
125	Reqest, which explains in detail the changes that were made. Pull
126	Requests are reviewed before the changes are accepted into the stable
127	branch, and it is likely that the reviewer will reject your changes with
128	notes on what needs to be fixed.
129		99
130	Pull Requests should explain the specifics and nuances of the changes	100	Pull Requests should explain the specifics and nuances of the changes contained therein.
131	contained therein.