* [**Repository maintainer**](#repository-maintainers): An individual responsible for merging pull requests (PRs) into `master` when all requirements are met (code review, tests, docs, and RFC approval as applicable).
The PowerShell Committee and its members (aka Committee Members) are the primary caretakers of the PowerShell experience, including the PowerShell language, design, and project.
### Current Committee Members
* Bruce Payette ([BrucePay](https://github.com/BrucePay))
The following types of decisions require a written RFC and ample time for the community to respond with their feedback before a contributor begins work on the issue:
* new features or capabilities in PowerShell (e.g. PowerShell classes, PSRP over SSH, etc.)
* the addition of new PowerShell Committee Members or Repository Maintainers
* any changes to the process of maintaining the PowerShell repository (including the responsibilities of Committee Members, Repository Maintainers, and Area Experts)
If any Committee Members feels like this behavior is large enough to warrant an RFC, they can add the label `RFC-required` and the issue owner is expected to follow the RFC process.
It is expected that over time, PowerShell experts in the community will be made Committee Members.
Membership is heavily dependent on the level of contribution and expertise: individuals who contribute in meaningful ways to the project will be recognized accordingly.
Repository Maintainers are trusted stewards of the PowerShell community/repository responsible for maintaining consistency and quality of PowerShell code.
For more information on Repository Maintainers--their responsibilities, who they are, and how one becomes a Maintainer--see the [README for Repository Maintainers][maintainers].
They have [write access](https://docs.github.com/en/free-pro-team@latest/github/setting-up-and-managing-organizations-and-teams/repository-permission-levels-for-an-organization) to the PowerShell repository which gives them the power to:
1. Merge pull requests to all branches *except*`master` (though this should not be common given that [`master`is the only long-living branch](../git/README.md#understand-branches)).
If you are a member of a Working Group, you are expected to be actively involved in any development, design, or contributions in the focus area of the WG.
More information on the responsibilities of Working Groups can be found [here][wg],
while current WG definitions and membership can be found [here][wg-definitions].
If you are a Working Group member:
1.**DO** triage and contribute to discussions in issues and PRs that have `WG-*` labels assigned
1.**DO** regularly communicate with other members of your WG to coordinate decisions about
whether issues should move forward
1.**DO** make decisions on whether or not issues should proceed forward with implementations or RFCs
1.**DO** assign the [correct labels][issue-process] to issues
1.**DO** assign yourself to issues and PRs labeled with your area of expertise only when you are actively
working on or implementing them
1.**DO** code reviews for PRs where you're assigned or in your WG
(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** ensure that contributors are following the [contributor guidelines](../../.github/CONTRIBUTING.md)
and [Code of Conduct](https://github.com/PowerShell/PowerShell/blob/master/CODE_OF_CONDUCT.md)
1.**DO** ensure that contributions [include Pester tests][pester] for all new/changed functionality
1.**DO** ensure that contributions [include documentation][docs-contributing] for all new-/changed functionality
1.**DO** encourage contributions to refer to issues in their pull request description (e.g. `Resolves issue #123`)
1.**DO** encourage contributions to have meaningful titles for all PRs,
editing their title if necessary to ensure that changelogs convey useful and accurate information
1.**DO** verify that all contributions are following the [Coding Guidelines](../dev-process/coding-guidelines.md)