mirror of
https://github.com/aphrody-labs/PowerShell.git
synced 2026-10-17 04:36:39 +00:00
refactor maintainer and governance docs
Now that we've gotten enough of a sign-off from everyone involved in the governance process, the docs need to be reworked to use a consistent terminology set, links, and directory structure.
This commit is contained in:
joeyaiello committed
1 parent
d9b1093a1c
commit
42019e511e
7 files changed
+90
-137
No files matched your search
+73
-34
@@ -1,59 +1,86 @@
|
||||
# Repository Maintainers
|
||||
|
||||
Repository maintainers are trusted people with knowledge in the PowerShell domain.
|
||||
Repository Maintainers are trusted stewards of the PowerShell repository responsible for maintaining consistency and quality of PowerShell code.
|
||||
One of their primary responsibilities is merging pull requests after all requirements have been fulfilled.
|
||||
|
||||
They have [write access](https://help.github.com/articles/permission-levels-for-an-organization-repository/) to the PowerShell repositories which gives them the power to:
|
||||
|
||||
1. `push`.
|
||||
2. Merge pull requests.
|
||||
3. Assign labels, milestones, and people to [issues](https://guides.github.com/features/issues/).
|
||||
1. `git push` to the official PowerShell repository
|
||||
2. Merge pull requests
|
||||
3. Assign labels, milestones, and people to [issues](https://guides.github.com/features/issues/)
|
||||
|
||||
## Table of Contents
|
||||
- [Rules](#rules)
|
||||
- [Current Repository Maintainers](#current-repository-maintainers)
|
||||
- [Repository Maintainer Responsibilities](#repository-maintainer-responsibilities)
|
||||
- [Issue Management Process](#issue-management-process)
|
||||
- [Pull Request Workflow](#pull-management-process)
|
||||
- [Abandoned Pull Requests](#abandoned-pull-requests)
|
||||
- [Becoming a Repository Maintainer](#becoming-a-repository-maintainer)
|
||||
|
||||
## Rules
|
||||
## Current Repository Maintainers
|
||||
|
||||
If you are a maintainer, please follow these rules:
|
||||
* Sergei Vorobev ([vors](https://github.com/vors))
|
||||
* Jason Shirk ([lzybkr](https://github.com/lzybkr))
|
||||
* Dongbo Wang ([daxian-dbw](https://github.com/daxian-dbw))
|
||||
* Travis Plunk ([TravisEz123](https://github.com/TravisEz123))
|
||||
* Mike Richmond ([mirichmo](https://github.com/mirichmo))
|
||||
* Andy Schwartzmeyer ([andschwa](https://github.com/andschwa))
|
||||
|
||||
1. **DO** reply to new issues and pull requests (while reviewing PRs, leave your comment even if everything looks good - 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 targets [the wrong branch](../../.github/CONTRIBUTING.md#lifecycle-of-a-pull-request).
|
||||
1. **DO** encourage people to write Pester tests for all new/changed functionality.
|
||||
1. **DO** wait for the [CI system][ci-system] build to pass for pull requests.
|
||||
1. **DO** encourage contributors to refer to issues in PR title/description (e.g. ```Closes #11```). Edit title if necessary.
|
||||
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).
|
||||
1. **DO** ensure that each contributor has signed a valid Contributor License Agreement (CLA).
|
||||
1. **DO** verify compliance with any third party code license terms (e.g., requiring attribution, etc.) if the contribution contains third party code.
|
||||
## Repository Maintainer Responsibilities
|
||||
|
||||
1. **DON'T** merge pull requests with a failed CI build.
|
||||
1. **DON'T** merge pull requests without the label `cla-signed` or `cla-not-required` from the Microsoft CLA bot.
|
||||
1. **DON'T** merge pull requests that do not [include all meaningful changes](../../.github/CONTRIBUTING.md#lifecycle-of-a-pull-request) under the **Unreleased** section in the repository's `CHANGELOG.md`.
|
||||
1. **DON'T** merge your own pull requests before they are reviewed by someone else.
|
||||
- If there is **no one** else to review your pull request, please wait **24** hours to merge it in case anyone comes along and has a comment.
|
||||
Repository Maintainers enable rapid contributions while maintaining a high level of quality in PowerShell by ensuring that all development processes are being followed correctly.
|
||||
|
||||
If you are a Repository Maintainer, you:
|
||||
|
||||
1. **MUST** ensure that each contributor has signed a valid Contributor License Agreement (CLA)
|
||||
1. **MUST** verify compliance with any third party code license terms (e.g., requiring attribution, etc.) if the contribution contains third party code.
|
||||
1. **MUST** make sure that [any change requiring approval from the PowerShell Committee](#changes-that-require-an-rfc) has gone through the proper [RFC][RFC-repo] or approval process
|
||||
1. **MUST** validate that code reviews have been conducted before merging a pull request when no code is written
|
||||
1. **MUST** validate that tests and documentation have been written before merging a pull request that contains new functionality
|
||||
1. **SHOULD** add [the correct labels][issue-management] to issues and pull requests
|
||||
1. **SHOULD** make sure the correct [Area Experts](#area-experts) are assigned to relevant pull requests and issues.
|
||||
This includes adding extra reviewers when it makes sense
|
||||
(e.g. a pull request that adds remoting capabilities might require a security expert)
|
||||
1. **SHOULD** validate that the names and email addresses in the git commits reasonably match identity of the person submitting the pull request
|
||||
1. **SHOULD** make sure contributors are following the [contributor guidelines][CONTRIBUTING]
|
||||
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 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
|
||||
1. **SHOULD NOT** merge pull requests with a failed CI build
|
||||
(unless, for instance, the pull request is being submitted to fix broken CI)
|
||||
1. **SHOULD NOT** merge pull requests without the label `cla-signed` or `cla-not-required` from the Microsoft CLA bot
|
||||
(unless the CLA bot is broken, and CLA signing can be confirmed through other means)
|
||||
1. **SHOULD NOT** merge pull requests too quickly after they're submitted.
|
||||
Even if the pull request meets all the requirements, people should have time to give their input
|
||||
(unless the pull request is particularly urgent for some reason)
|
||||
1. **SHOULD NOT** merge your own pull requests.
|
||||
If a Repository Maintainer opens a pull request, another Maintainer should merge it unless there are extreme, short-term circumstances requiring a merge or another Maintainer has given explicit sign-off without merging
|
||||
|
||||
## Issue Management Process
|
||||
|
||||
Please see [Issue Management Process](./issue-management-process.md)
|
||||
Please see [Issue Management][issue-management]
|
||||
|
||||
## Pull Request Workflow
|
||||
|
||||
1. A contributor opens a pull request.
|
||||
2. The contributor ensures that their pull request passes the [CI system][ci-system] build.
|
||||
1. The contributor ensures that their pull request passes the [CI system][ci-system] build.
|
||||
- If the build fails, a maintainer adds the ```waiting for author``` label to the pull request.
|
||||
The contributor can then continue to update the pull request until the build passes.
|
||||
2. Once the build passes, the maintainer either reviews the pull request immediately or adds the ```need review``` label.
|
||||
3. A maintainer or trusted contributor reviews the pull request code.
|
||||
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. A maintainer or trusted contributor 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.
|
||||
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.
|
||||
3. Once the code review is completed, a maintainer merges the pull request.
|
||||
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.
|
||||
|
||||
In these cases:
|
||||
@@ -61,9 +88,21 @@ In these cases:
|
||||
1. Ping the author of PR to remind him of pending changes.
|
||||
- If the contributor responds, it's no longer an abandoned pull request, proceed as normal.
|
||||
2. If the contributor does not respond **within a week**:
|
||||
- If the reviewer's comments are very minor, merge the change, fix the code immediately, and create a new PR with the fixes addressing the minor comments.
|
||||
- If the changes required to merge the pull request are significant but needed, create a new branch with the changes and open an issue to merge the code into the dev branch.
|
||||
Mention the original pull request ID in the description of the new issue and close the abandoned pull request.
|
||||
- Create a new branch with the changes and open an issue to merge the code into the dev branch.
|
||||
Mention the original pull request ID in the description of the new issue and close the abandoned pull request.
|
||||
- If the changes in an abandoned pull request are no longer needed (e.g. due to refactoring of the code base or a design change), simply close the pull request.
|
||||
|
||||
## Becoming a Repository Maintainer
|
||||
|
||||
Repository Maintainers currently consist entirely of Microsoft employees
|
||||
It is expected that over time, regular trusted contributors to the PowerShell repository will be made Repository Maintainers.
|
||||
Eligibility is heavily dependent on the level of contribution and expertise: individuals who contribute in meaningful ways to the project will be recognized accordingly.
|
||||
|
||||
At any point in time, a Repository Maintainers can nominate a strong community member to become a Repository Maintainer.
|
||||
Nominations should be submitted in the form of [RFCs][RFC-repo] detailing why that individual is qualified and how they will contribute.
|
||||
After the RFC has been discussed, a unanimous vote by the PowerShell Committee will be required for the new Repository Maintainer to be confirmed.
|
||||
|
||||
[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
|
||||
@@ -1,12 +0,0 @@
|
||||
author: Jason/Andy
|
||||
|
||||
|
||||
> meaning of label, assignees, etc.
|
||||
> triage process
|
||||
> requirements for resolving (timing), closing...
|
||||
|
||||
# Maintainer - Issue Management Process
|
||||
|
||||
## Issue Label Descriptions
|
||||
|
||||
See [Issue Label Descriptions](../dev-process/issue-label-descriptions)
|
||||
@@ -0,0 +1,46 @@
|
||||
# Issue Management
|
||||
|
||||
## Long-living issue labels
|
||||
|
||||
### Feature areas
|
||||
|
||||
These labels describe what feature area of PowerShell that an issue addresses.
|
||||
|
||||
* `Area-Build`: build issues
|
||||
* `Area-Cmdlets`: cmdlets in any module
|
||||
* `Area-Console`: the console experience
|
||||
* `Area-Debugging`: debugging PowerShell script
|
||||
* `Area-Documentation`: PowerShell *repo* documentation issues, general PowerShell doc issues go [here](https://github.com/PowerShell/PowerShell-Docs/issues)
|
||||
* `Area-Engine`: core PowerShell engine, interpreter, runtime
|
||||
* `Area-Intellisense`: tab completion
|
||||
* `Area-Language`: parser, language semantics
|
||||
* `Area-OMI`: omi
|
||||
* `Area-PackageManagement`: PackageManagement related issues
|
||||
* `Area-Performance`: a performance issue
|
||||
* `Area-Portability`: anything affecting script portability
|
||||
* `Area-PSReadline`: PSReadLine
|
||||
* `Area-SideBySide`: Side by side support
|
||||
* `Area-Test`: tests or test infrastructure
|
||||
|
||||
### Operating systems
|
||||
|
||||
These are for issues that are specific to certain operating systems:
|
||||
* `OS-Linux`
|
||||
* `OS-OS X`
|
||||
* `OS-Windows`
|
||||
|
||||
### Process Tags
|
||||
|
||||
Issues can be in one of the following states:
|
||||
* `0 - Backlog` : We've acknowledged the issue but have no immediate plans to address it.
|
||||
* `1 - Planning` : The issue requires some design or discussion before coding can begin.
|
||||
* `2 - Ready` : Any design or discussion is essentially done, coding has not yet begun though.
|
||||
* `3 - Working` : The assignee(s) are actively working on the issue.
|
||||
* `4 - In Review` : The issue is being reviewed.
|
||||
The assignee(s) are responsible for signing off before the PR will be merged.
|
||||
|
||||
* `help wanted` : We are looking for someone to work on this issue.
|
||||
* `need review` : This pull request is being reviewed. Please see [Pull Request - Code Review](../../.github/CONTRIBUTING.md#pull-request-code-review)
|
||||
* `waiting for author`: The issue or pull request needs
|
||||
* `add to changelog`: The PR requires an addition to the changelog.
|
||||
Should be removed when it has been added.
|
||||
@@ -0,0 +1,37 @@
|
||||
# Pull Request Process
|
||||
|
||||
Our [pull request template][pr-template] includes the bare minimum requirements for a pull request to be accepted into PowerShell. This includes:
|
||||
* Writing tests
|
||||
* Writing documentation (where does thie one live already? is it where this guidance should exist all up?)
|
||||
* Our [code review process][code-review]
|
||||
* Repository maintainer sign-off, per our [governance model][governance]
|
||||
|
||||
## Pull Request Workflow
|
||||
|
||||
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.
|
||||
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. 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.
|
||||
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.
|
||||
|
||||
In these cases:
|
||||
|
||||
1. Ping the author of PR to remind him of pending changes.
|
||||
- If the contributor responds, it's no longer an abandoned pull request, proceed as normal.
|
||||
2. If the contributor does not respond **within a week**:
|
||||
- If the reviewer's comments are very minor, merge the change, fix the code immediately, and create a new PR with the fixes addressing the minor comments.
|
||||
- If the changes required to merge the pull request are significant but needed, create a new branch with the changes and open an issue to merge the code into the dev branch. Mention the original pull request ID in the description of the new issue and close the abandoned pull request.
|
||||
- If the changes in an abandoned pull request are no longer needed (e.g. due to refactoring of the code base or a design change), simply close the pull request.
|
||||
|
||||
[pr-template]: ../.github/PULL_REQUEST_TEMPLATE.md
|
||||
[code-review]: code-review-guidelines.md
|
||||
[governance]: ../community/governance.md
|
||||
[repository-maintainer]: ../community/governance.md#repository-maintainers
|
||||
[area-expert]: ../community/governance.md#area-experts#area-experts
|
||||
@@ -1,18 +0,0 @@
|
||||
author: Hemant
|
||||
> Hemant: "SLAs" for pull requests
|
||||
> ALWAYS point to documents when critiquing PRs
|
||||
> this should also include the blackbox of Windows/STEX testing
|
||||
> time can totally be wishy-washy here
|
||||
> "some tests we can only run internally"
|
||||
> exact timeline not need for Aug17
|
||||
> Windows quality gates
|
||||
|
||||
## Minimum gates (TODO)
|
||||
|
||||
Our [pull request template][pr-template] includes the bare minimum requirements for a pull request to be accepted into PowerShell. This includes:
|
||||
* Writing tests
|
||||
* Writing documentation (where does thie one live already? is it where this guidance should exist all up?)
|
||||
* Repository maintainer sign-off, per our [governance model][governance]
|
||||
|
||||
[pr-template]: ../../.github/PULL_REQUEST_TEMPLATE.md
|
||||
[governance]: ../community/governance.md
|
||||
Reference in new issue
Block a user