Content updates based on review.

Author: kgodey

content/community/community-team/project-roles/contents.lr

@@ -19,9 +19,9 @@ As a Project Maintainer, your responsibilities are as follows:
 * **Review pull requests (PRs):** You are expected to review incoming pull requests regularly (we aim to review all pull requests within [within three business days][pullrequestguidelines]).
 * **Recognize work as "Great Contribution":**You are expected to pay attention to contributions to your repositories, and apply “Great Contribution” labels as needed. For more information about this, see the “Great Contributions” section below.
 * **Decide on Community Team applications:** You are expected to make the final decision on Community Team applications for your project.
-* **Communicate with the applicant and the OSCC promptly:** You are expected to reach out to applicants for Community Team directly and let them know the status of their application.
+* **Communicate with the applicant and the Open Source Community Coordinator (OSCC) promptly:** You are expected to reach out to applicants for Community Team directly and let them know the status of their application.
    * We want to get back to applicants within seven business days of application, if possible. If this is not possible, you should reach out to the applicant just letting them know that it’s taking a little longer than usual (could be due to internal discussion taking a while, other things taking precedent, etc.), and that we’re working on it.
-   * You are expected to communicate with the Open Source Community Coordinator promptly (within three business days) when they reach out to you about a new Community Team application or other related matter.
+   * You are expected to communicate with the OSCC promptly (within three business days) when they reach out to you about a new Community Team application or other related matter.
    * You should also notify the OSCC of your decision about the Community Team application.
 * **Let contributors know about Community Team:** If you notice a strong contributor, you should notify them of the existence of Community Team, provide them with the link to the Community Team page on the CC Open Source site, and encourage them to apply.
 
@@ -34,7 +34,7 @@ Great Contributions
 “Great Contributions” are evaluated subjectively. If you notice that a contribution was of particularly high quality, you should mark it as a “Great Contribution”.
 
 Guidelines for what to mark as a “Great Contribution”:
-* A substantial PR (e.g. not fixing two links in a README. work should reasonably take an hour or more (assuming they’re not familiar with the project)
+* A substantial PR (e.g. not fixing two links in a README; work should reasonably take an hour or more, assuming they’re not familiar with the project)
 * Shows hard work
 * Responsive to feedback
 
@@ -45,9 +45,9 @@ How to label “Great Contributions”:
 
 
 ### Reviewing Applications
-Applications for Community Teams roles will be sent to you individually by the Open Source Community Coordinator. The OSCC has ensured that the bare requirements for the position are met. If bare requirements are not met, you will be notified how so when you receive the application from the OSCC.
+Applications for Community Teams roles will be sent to you individually by the  Open Source Community Coordinator (OSCC). The OSCC has ensured that the bare requirements for the position are met. If bare requirements are not met, you will be notified how so when you receive the application from the OSCC.
 
-From here, you should review the application and the applicant’s contributions based on the evaluation criteria. As a maintainer, you have lots of discretion here. If an applicant meets the requirements, but you do not think they are ready for the role they’ve applied for, you can choose to grant a role with fewer privileges, or not grant a role at all.
+From here, you should review the application and the applicant’s contributions based on the evaluation criteria. As a maintainer, you have a significant amount of discretion here. If an applicant meets the requirements, but you do not think they are ready for the role they’ve applied for, you can choose to grant a role with fewer privileges, or not grant a role at all.
 
 No matter the decision, you should do the following things:
 * Notify the OSCC of your decision. Please include the applicant’s name, the role they applied for, and if they applied for a project based role, the project they applied to. From here, the OSCC will help coordinate permissions and role management.
@@ -63,7 +63,7 @@ You have a big license for discretion within the Community Team. All applicants
 Here are some other miscellaneous things:
 * Issue submission requirements are org-wide, but PR requirements are not. Applicants should be submitting PRs for the repo they are aiming to get privileges for.
 * If two repos are closely related to each other (ex. catalog and catalog api), or if work in repo X also regularly includes work in repo Y, project maintainers can collaborate to grant roles to a contributor in both repos at once.
-* Repositories may opt out of granting roles depending on the nature of the repository.
+* Project Maintainers may opt out of granting roles depending on the nature of the repository.
 
 As a maintainer, you have the ability to make some repository-specific allowances. These include the following:
 * Issue and PR requirements can vary by repository depending on traffic. If a maintainer wants to mandate different numbers for their repository, they should state these requirements in the repo’s README.