"Fossies" - the Fresh Open Source Software Archive

Member "PowerShell-7.2.5/docs/community/governance.md" (21 Jun 2022, 10029 Bytes) of package /linux/misc/PowerShell-7.2.5.tar.gz:

As a special service "Fossies" has tried to format the requested source page into HTML format (assuming markdown format). Alternatively you can here view or download the uninterpreted source code file. A member file download can also be achieved by clicking within a package contents listing on the according byte size field.

PowerShell Governance


PowerShell Committee

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

Committee Member Responsibilities

Committee Members are responsible for reviewing and approving PowerShell RFCs proposing new features or design changes.

Changes that require an RFC

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:

Changes that don't require an RFC

In some cases, a new feature or behavior may be deemed small enough to forgo the RFC process (e.g. changing the default PSReadline EditMode to Emacs on Mac/Linux). In these cases, issues marked as 1 - Planning require only a simple majority of Committee Members to sign off. After that, a Repository Maintainer should relabel the issue as 2 - Ready so that a contributor can begin working on it.

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.

Committee Member DOs and DON'Ts

As a PowerShell Committee Member:

  1. DO reply to issues and pull requests with design opinions (this could include offering support for good work or exciting new features)

  2. DO encourage healthy discussion about the direction of PowerShell

  3. DO raise "red flags" on PRs that haven't followed the proper RFC process when applicable

  4. DO contribute to documentation and best practices

  5. DO maintain a presence in the PowerShell community outside of GitHub (Twitter, blogs, StackOverflow, Reddit, Hacker News, etc.)

  6. DO heavily incorporate community feedback into the weight of your decisions

  7. DO be polite and respectful to a wide variety of opinions and perspectives

  8. DO make sure contributors are following the contributor guidelines

  9. DON'T constantly raise "red flags" for unimportant or minor problems to the point that the progress of the project is being slowed

  10. DON'T offer up your opinions as the absolute opinion of the PowerShell Committee. Members are encouraged to share their opinions, but they should be presented as such.

PowerShell Committee Membership

The initial PowerShell Committee consists of Microsoft employees. 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.

At any point in time, a Committee Member can nominate a strong community member to join the Committee. 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 will be required for the new Committee Member to be confirmed.

Repository Maintainers

Repository Maintainers are trusted stewards of the PowerShell community/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.

For more information on Repository Maintainers--their responsibilities, who they are, and how one becomes a Maintainer--see the README for Repository Maintainers.

Working Groups (WGs)

Working Groups (WGs) are collections of contributors with knowledge of specific components or technologies in the PowerShell domain. They are responsible for issue triage/acceptance, code reviews, and providing their expertise to others in issues, PRs, and RFC discussions, as well as to the Committee when said expertise is helpful in broader discussions.

They have write access to the PowerShell repository which gives them the power to:

  1. git push to all branches except master.
  2. Merge pull requests to all branches except master (though this should not be common given that masteris the only long-living branch).
  3. Assign labels, milestones, and people to issues.

Working Group Responsibilities

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, 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

  2. DO regularly communicate with other members of your WG to coordinate decisions about whether issues should move forward

  3. DO make decisions on whether or not issues should proceed forward with implementations or RFCs

  4. DO assign the correct labels to issues

  5. DO assign yourself to issues and PRs labeled with your area of expertise only when you are actively working on or implementing them

  6. 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).

  7. DO ensure that contributors are following the contributor guidelines and Code of Conduct

  8. DO ensure that contributions include Pester tests for all new/changed functionality

  9. DO ensure that contributions include documentation for all new-/changed functionality

  10. DO encourage contributions to refer to issues in their pull request description (e.g. Resolves issue #123)

  11. DO encourage contributions to have meaningful titles for all PRs, editing their title if necessary to ensure that changelogs convey useful and accurate information

  12. DO verify that all contributions are following the Coding Guidelines

  13. DON'T create new features, new designs, or change behaviors without following the RFC or approval process

Issue Management Process

See our Issue Management Process

Pull Request Process

See our Pull Request Process