address final PR/offline feedback for governance

.github/CONTRIBUTING.md

@@ -44,7 +44,7 @@ Contributing to Documentation
 
 Please see the [Contributor Guide in `PowerShell/PowerShell-Docs`](https://github.com/PowerShell/PowerShell-Docs/blob/staging/CONTRIBUTING.md).
 
-### Contributing to documentation related to contributing or maintaining the PowerShell Project
+### Contributing to documentation related to maintaining or contributing to the PowerShell project
 
 * When writing Markdown documentation, use [semantic linefeeds][].
   In most cases, it means "once clause / idea per line".

docs/community/governance.md

@@ -105,14 +105,14 @@ If you are an Area Expert:
 
 1. **DO** assign the [correct labels][issue-process]
 1. **DO** assign yourself to issues labeled with your area of expertise
-1. **DO** [code reviews][TODO] for issues where you're assigned or in your areas of expertise
+1. **DO** code reviews for issues where you're assigned or in your areas of expertise.
 1. **DO** reply to new issues and pull requests that are related to your area of expertise 
 (while reviewing PRs, leave your comment even if everything looks good - a simple "Looks good to me" or "LGTM" will suffice, so that we know someone has already taken a look at it).
 1. **DO** make sure contributors are following the [contributor guidelines](../../.github/CONTRIBUTING.md).
 1. **DO** ask people to resend a pull request, if it [doesn't target `master`](../../.github/CONTRIBUTING.md#lifecycle-of-a-pull-request).
 1. **DO** ensure that contributors [write Pester tests][pester] for all new/changed functionality
 1. **DO** ensure that contributors [write documentation][docs-contributing] for all new-/changed functionality
-1. **DO** encourage contributors to refer to issues in their pull request description per the [issue template](../../.github/ISSUE_TEMPLATE.md) (e.g. `Resolves issue #123`)
+1. **DO** encourage contributors to refer to issues in their pull request description per the [pull request template](../../.github/PULL_REQUEST_TEMPLATE.md) (e.g. `Resolves issue #123`)
 1. **DO** encourage contributors to create meaningful titles for all PRs. Edit title if necessary.
 1. **DO** verify that all contributors are following the [Coding Guidelines](../dev-process/coding-guidelines.md).
 

docs/maintainers/README.md

@@ -46,7 +46,9 @@ This includes adding extra reviewers when it makes sense
 1. **SHOULD** ask people to resend a pull request, if it [doesn't target `master`](../../.github/CONTRIBUTING.md#lifecycle-of-a-pull-request)
 1. **SHOULD** wait for the [CI system][ci-system] build to pass for pull requests 
 (unless, for instance, the pull request is being submitted to fix broken CI)
-1. **SHOULD** encourage contributors to refer to issues in their pull request description per the [issue template](../../.github/ISSUE_TEMPLATE) (e.g. `Resolves issue #123`) 
+1. **SHOULD** encourage contributors to refer to issues in their pull request description per the [pull request template](../../.github/PULL_REQUEST_TEMPLATE.md) (e.g. `Resolves issue #123`).
+If a user did not create an issue prior to submitting their pull request, their pull request should not be rejected.
+However, they should be reminded to create an issue in the future to frontload any potential problems with the work and to minimize duplication of efforts. 
 1. **SHOULD** encourage contributors to create meaningful titles for all PRs.
 Edit the title if necessary to provide clarity on the problem
 1. **SHOULD** encourage contributes to write meaningful, descriptive git commits
@@ -105,4 +107,4 @@ After the RFC has been discussed, a unanimous vote by the PowerShell Committee w
 [RFC-repo]: https://github.com/PowerShell/PowerShell-RFC
 [ci-system]: ../testing-guidelines/testing-guidelines.md#ci-system
 [issue-management]: issue-management.md
-[CONTRIBUTING]: ../../.github/CONTRIBUTING.MD
+[CONTRIBUTING]: ../../.github/CONTRIBUTING.md

docs/maintainers/pull-request-process.md

@@ -10,16 +10,16 @@ Our [pull request template][pr-template] includes the bare minimum requirements
 
 1. A contributor opens a pull request.
 1. The contributor ensures that their pull request passes the [CI system][ci-system] build.
-  - If the build fails, a [Repository Maintainer][repository-maintainer] adds the ```waiting for author``` label to the pull request. 
+  - If the build fails, a [Repository Maintainer][repository-maintainer] adds the `Review - waiting on author` label to the pull request. 
   The contributor can then continue to update the pull request until the build passes.
-1. Once the build passes, the maintainer either reviews the pull request immediately or adds the ```need review``` label.
+1. Once the build passes, the maintainer either reviews the pull request immediately or adds the `Review - needed` label.
 1. An [Area Expert][area-expert] reviews the pull request code.
-  - If the contributor does not meet the reviewer's standards, the reviewer makes comments. A maintainer then removes the ```need review``` label and adds the ```waiting for author``` label. The contributor must address the comments and repeat from step 2.
-  - If the contributor meets the reviewer's standards, the reviewer comments that they are satisfied. A maintainer then removes the ```need review``` label.
+  - If the contributor does not meet the reviewer's standards, the reviewer makes comments. A maintainer then removes the `Review - needed` label and adds the `Review - waiting on author` label. The contributor must address the comments and repeat from step 2.
+  - If the contributor meets the reviewer's standards, the reviewer comments that they are satisfied. A maintainer then removes the `need review` label.
 1. Once the code review is completed, a maintainer merges the pull request.
 
 ### Abandoned Pull Requests
-A pull request with the label ```waiting for the author``` for **more than two weeks** without a word from the author is considered abandoned.
+A pull request with the label `Review - waiting on author` for **more than two weeks** without a word from the author is considered abandoned.
 
 In these cases: