small note about onboarding for future

Author: nazunalika

docs/special_interest_groups/index.md

@@ -45,11 +45,11 @@ This section goes over the current SIGs that may have sponsors and are active or
 
 We expect SIGs to satisfy some basic requirements, such as:
 
-* The group should be related to Rocky, a use-case for Rocky or Enterprise Linux, or related to Enterprise Linux as a whole
-* There must be feedback and control into the Rocky community
+* The group should be related to Rocky Linux, a use-case for Rocky Linux or Enterprise Linux, or related to Enterprise Linux as a whole
+* There must be feedback and control into the Rocky Linux community
 * All communication as to the work of the SIG should be public - Some matters may have to be private, and as such should be out of band
     * It is expected that each SIG will have a public channel as `SIG/name` in mattermost. Optionally an IRC or Matrix channel can also be assigned.
-* Code produced within the SIG must be compatible with a FOSS license presently used by Rocky - If a new license is wanted, consult with Release Engineering/Core or the `~Legal` channel in mattermost.
+* Code produced within the SIG must be compatible with a FOSS license presently used by Rocky Linux - If a new license is wanted, consult with Release Engineering/Core or the `~Legal` channel in mattermost.
 * All documentation and information of the SIG should be on a wiki produced in the [RESF Git Service](https://git.resf.org).
 * All documentation produced within the SIG must be a compatible documentation license
 * Groups should be aware/watchful of the direction from the Release Engineering team/Core as it can affect how SIGs operate if they are producing compiled software.
@@ -60,7 +60,7 @@ Each SIG should have a wiki that will have documentation for their particular gr
 
 * An "about" section on the index that explains what the group does/a group description
 * Mission Statement
-* How to Contribute
+* How to Contribute / Onboarding Process
 * Meeting Information (time, location, other information that they feel is important)
 * Policies and Resources, if applicable
 

docs/special_interest_groups/sig_guide/proposal.md

@@ -2,26 +2,26 @@
 title: Proposing a SIG
 ---
 
-This page goes over proposing a Special Interest Group for the Rocky ecosystem.
+This page goes over proposing a Special Interest Group for the Rocky Linux ecosystem.
 Anyone can propose or participate in a Special Interest Group.
 
 ## Proposal
 
-Creating a new Special Interest Group requires participation from a member of the Rocky teams or a member of the Rocky Linux project board. A SIG must meet these requirements:
+Creating a new Special Interest Group requires participation from a member of the Rocky Linux teams or a member of the Rocky Linux project board. A SIG must meet these requirements:
 
-* The group should be related to Rocky or a use-case for Rocky or Enterprise Linux as a whole
+* The group should be related to Rocky Linux or a use-case for Rocky Linux or Enterprise Linux as a whole
 * There must be feedback and control into the Rocky community
 * All communication as to the work of the SIG should be public - Some matters may have to be private, and as such should be out of band
 
     * It is expected that each SIG will have a public channel as `SIG/name` in mattermost. Optionally an IRC channel can also be assigned.
 
-* Code produced within the SIG must be compatible with a FOSS license presently used by Rocky and [upstream](https://docs.fedoraproject.org/en-US/legal/) - If a new license is wanted and is not available in the upstream list, consult with Release Engineering/Core or `~Legal` in Mattermost.
+* Code produced within the SIG must be compatible with a FOSS license presently used by Rocky Linux and [upstream](https://docs.fedoraproject.org/en-US/legal/) - If a new license is wanted and is not available in the upstream list, consult with Release Engineering/Core or `~Legal` in Mattermost.
 * All documentation produced within the SIG must be a compatible documentation license.
 
     * The group will receive a wiki that they can manage their documentation and group information on the RESF Git Service (using `sig-X.rocky.page` domain)
 
 * Groups should be aware/watchful of the direction from the Release Engineering team/Core as it can affect how SIGs operate if they are producing compiled software.
-* A member of the SIG should also come from the Core/RelEng team, in the case that the SIG produces packages for use on a Rocky system.
+* A member of the SIG should also come from the Core/RelEng team, in the case that the SIG produces packages for use on a Rocky Linux system.
 * General reports, requests, and communication, on at least a quarterly basis, will be required with the Rocky Linux project board
 
 It is also highly recommended to have packaged software (if applicable) to present in the proposal, e.g. on a Fedora Copr project or another setting.
@@ -30,7 +30,7 @@ It is also highly recommended to have packaged software (if applicable) to prese
 
 It is up to the requestor to:
 
-* Check and verify that the topic of interest is already covered by an existing Special Interest Group within Rocky or CentOS Stream
+* Check and verify that the topic of interest is already covered by an existing Special Interest Group within Rocky Linux or CentOS Stream
 * Post an introductory RFC message:
 
     * As an email to the rocky-devel mailing list and ask for comments or...