PowerShell/docs/maintainers

Repository Maintainers

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 to the PowerShell repositories which gives them the power to:

1. git push to the official PowerShell repository
2. Merge pull requests
3. Assign labels, milestones, and people to issues

Table of Contents

• Current Repository Maintainers
• Repository Maintainer Responsibilities
• Issue Management Process
• Pull Request Workflow
  • Abandoned Pull Requests
• Becoming a Repository Maintainer

Current Repository Maintainers

• Sergei Vorobev (vors)
• Jason Shirk (lzybkr)
• Dongbo Wang (daxian-dbw)
• Travis Plunk (TravisEz13)
• Mike Richmond (mirichmo)
• Andy Schwartzmeyer (andschwa)

Repository Maintainer Responsibilities

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)
2. MUST verify compliance with any third party code license terms (e.g., requiring attribution, etc.) if the contribution contains third party code.
3. MUST make sure that any change requiring approval from the PowerShell Committee has gone through the proper RFC or approval process
4. MUST validate that code reviews have been conducted before merging a pull request when no code is written
5. MUST validate that tests and documentation have been written before merging a pull request that contains new functionality
6. SHOULD add the correct labels to issues and pull requests
7. SHOULD make sure the correct 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)
8. SHOULD validate that the names and email addresses in the git commits reasonably match identity of the person submitting the pull request
9. SHOULD make sure contributors are following the contributor guidelines
10. SHOULD ask people to resend a pull request, if it doesn't target master
11. SHOULD wait for the CI system build to pass for pull requests (unless, for instance, the pull request is being submitted to fix broken CI)
12. SHOULD encourage contributors to refer to issues in their pull request description (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.
13. SHOULD encourage contributors to create meaningful titles for all PRs. Edit the title if necessary to provide clarity on the problem
14. SHOULD encourage contributes to write meaningful, descriptive git commits
15. SHOULD NOT merge pull requests with a failed CI build (unless, for instance, the pull request is being submitted to fix broken CI)
16. 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)
17. 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)
18. 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

Pull Request Workflow

1. A contributor opens a pull request.
2. The contributor ensures that their pull request passes the 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.

1. Once the build passes, the maintainer either reviews the pull request immediately or adds the need review label.
2. 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.
• 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:

• 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 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.