From 580c7b78529c88ab39c6fa11b6a8655cfd864789 Mon Sep 17 00:00:00 2001 From: joeyaiello Date: Tue, 9 Aug 2016 16:42:34 -0700 Subject: [PATCH] address final PR/offline feedback for governance --- .github/CONTRIBUTING.md | 2 +- docs/community/governance.md | 4 ++-- docs/maintainers/README.md | 6 ++++-- docs/maintainers/pull-request-process.md | 10 +++++----- 4 files changed, 12 insertions(+), 10 deletions(-) diff --git a/.github/CONTRIBUTING.md b/.github/CONTRIBUTING.md index 3d888b5a0f..59db52bb88 100644 --- a/.github/CONTRIBUTING.md +++ b/.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". diff --git a/docs/community/governance.md b/docs/community/governance.md index 480dbdae5b..07f5e44bf5 100644 --- a/docs/community/governance.md +++ b/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). diff --git a/docs/maintainers/README.md b/docs/maintainers/README.md index c7a0968b3a..16d7a6ca79 100644 --- a/docs/maintainers/README.md +++ b/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 \ No newline at end of file +[CONTRIBUTING]: ../../.github/CONTRIBUTING.md \ No newline at end of file diff --git a/docs/maintainers/pull-request-process.md b/docs/maintainers/pull-request-process.md index 63fb7ead8a..82799e9f02 100644 --- a/docs/maintainers/pull-request-process.md +++ b/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: