Updated governance: Working Groups (WGs) (#14603)
This commit is contained in:
Joey Aiello
GitHub
parent
303cf518a0
commit
1ba2960f5c
13
.spelling
13
.spelling
|
|
@ -1068,6 +1068,19 @@ MultipleServiceCommandBase.AllServices
|
|||
JustinGrote
|
||||
Newtonsoft.Json
|
||||
minSize
|
||||
WGs
|
||||
wg-definitions
|
||||
thejasonhelmick
|
||||
winps
|
||||
componentization
|
||||
CimCmdlets
|
||||
Microsoft.PowerShell.Host
|
||||
PSDiagnostics
|
||||
nightlies
|
||||
wg
|
||||
Visio
|
||||
triaged
|
||||
lifecycle
|
||||
- CHANGELOG.md
|
||||
aavdberg
|
||||
asrosent
|
||||
|
|
|
|||
|
|
@ -5,10 +5,10 @@
|
|||
* [**PowerShell Committee**](#powershell-committee): A committee of project owners who are responsible for design decisions,
|
||||
approving [RFCs][RFC-repo], and approving new maintainers/committee members
|
||||
* [**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).
|
||||
|
||||
Repository Maintainers are the only people with write permissions for the `master` branch.
|
||||
* [**Area experts**](#area-experts): People who are experts for specific components (e.g. PSReadline, the parser) or technologies (e.g. security, performance).
|
||||
Area experts are responsible for code reviews, issue triage, and providing their expertise to others.
|
||||
* [**Working Groups (WGs)**](#working-groups-(wgs)) are collections of contributors responsible for
|
||||
providing expertise on a specific area of PowerShell in order to help establish consensus within
|
||||
the community and Committee.
|
||||
* **Corporation**: The Corporation owns the PowerShell repository and, under extreme circumstances,
|
||||
reserves the right to dissolve or reform the PowerShell Committee, the Project Leads, and the Corporate Maintainer.
|
||||
The Corporation for PowerShell is Microsoft.
|
||||
|
|
@ -90,9 +90,13 @@ One of their primary responsibilities is merging pull requests after all require
|
|||
|
||||
For more information on Repository Maintainers--their responsibilities, who they are, and how one becomes a Maintainer--see the [README for Repository Maintainers][maintainers].
|
||||
|
||||
## Area Experts
|
||||
## Working Groups (WGs)
|
||||
|
||||
Area Experts are people with knowledge of specific components or technologies in the PowerShell domain. They are responsible for code reviews, issue triage, and providing their expertise to others.
|
||||
[Working Groups (WGs)][wg] 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](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:
|
||||
|
||||
|
|
@ -100,26 +104,31 @@ They have [write access](https://docs.github.com/en/free-pro-team@latest/github/
|
|||
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)).
|
||||
1. Assign labels, milestones, and people to [issues](https://guides.github.com/features/issues/).
|
||||
|
||||
A list of Area Experts can be found [here][experts].
|
||||
### Working Group Responsibilities
|
||||
|
||||
### Area Expert 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][wg],
|
||||
while current WG definitions and membership can be found [here][wg-definitions].
|
||||
|
||||
If you are an Area Expert, you are expected to be actively involved in any development, design, or contributions in your area of expertise.
|
||||
If you are a Working Group member:
|
||||
|
||||
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 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 (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).
|
||||
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)
|
||||
|
||||
1. **DON'T** create new features, new designs, or change behaviors without following the [RFC][RFC-repo] or approval process
|
||||
|
||||
|
|
@ -138,4 +147,5 @@ See our [Pull Request Process][pull-request-process]
|
|||
[pull-request-process]: ../../.github/CONTRIBUTING.md#lifecycle-of-a-pull-request
|
||||
[docs-contributing]: https://github.com/PowerShell/PowerShell-Docs/blob/staging/CONTRIBUTING.md
|
||||
[maintainers]: ../maintainers/README.md
|
||||
[experts]: ../../.github/CODEOWNERS
|
||||
[wg]: ./working-group.md
|
||||
[wg-defintions]: ./working-group-definitions.md
|
||||
|
|
|
|||
1413
docs/community/process_diagram.svg
Normal file
1413
docs/community/process_diagram.svg
Normal file
File diff suppressed because it is too large
Load diff
|
After Width: | Height: | Size: 95 KiB |
BIN
docs/community/process_diagram.vsdx
Normal file
BIN
docs/community/process_diagram.vsdx
Normal file
Binary file not shown.
188
docs/community/working-group-definitions.md
Normal file
188
docs/community/working-group-definitions.md
Normal file
|
|
@ -0,0 +1,188 @@
|
|||
# Working Group Definitions
|
||||
|
||||
This document maintains a list of the current PowerShell [Working Groups (WG)](working-group.md),
|
||||
as well as their definitions, membership, and a non-exhaustive set of examples of topics that fall
|
||||
within the purview of that WG.
|
||||
|
||||
For an up-to-date list of the issue/PR labels associated with these WGs,
|
||||
see [Issue Management](../maintainers/issue-management.md)
|
||||
|
||||
## Desired State Configuration (DSC)
|
||||
|
||||
The Desired State Configuration (DSC) WG manages all facets of DSC in PowerShell 7,
|
||||
including language features (like the `Configuration` keyword)
|
||||
and the `PSDesiredStateConfiguration` module.
|
||||
|
||||
Today, DSC is integrated into the PowerShell language, and we need to manage it as such.
|
||||
|
||||
### Members
|
||||
|
||||
* @TravisEz13
|
||||
* @theJasonHelmick
|
||||
* @joeyaiello
|
||||
* @anmenaga
|
||||
|
||||
## Developer Experience
|
||||
|
||||
The PowerShell developer experience includes the **development of modules** (in C#, PowerShell script, etc.),
|
||||
as well as the experience of **hosting PowerShell and its APIs** in other applications and language runtimes.
|
||||
Special consideration should be given to topics like **backwards compatibility** with Windows PowerShell
|
||||
(e.g. with **PowerShell Standard**) and **integration with related developer tools**
|
||||
(e.g. .NET CLI or the PowerShell extension for VS Code).
|
||||
|
||||
### Members
|
||||
|
||||
* @JamesWTruher (PS Standard, module authoring)
|
||||
* @adityapatwardhan (SDK)
|
||||
* @rjmholt (hosting, WinPS compatibility)
|
||||
|
||||
## Engine
|
||||
|
||||
The PowerShell engine is one of the largest and most complex aspects of the codebase.
|
||||
The Engine WG should be focused on the
|
||||
**implementation and maintenance of core PowerShell engine code**.
|
||||
This includes (but is not limited to):
|
||||
|
||||
* The language parser
|
||||
* The command and parameter binders
|
||||
* The module and provider systems
|
||||
* `*-Item` cmdlets
|
||||
* Providers
|
||||
* Performance
|
||||
* Componentization
|
||||
* AssemblyLoadContext
|
||||
|
||||
It's worth noting that the Engine WG is not responsible for the definition of the PowerShell language.
|
||||
This should be handled by the Language WG instead.
|
||||
However, it's expected that many issues will require input from both WGs.
|
||||
|
||||
### Members
|
||||
|
||||
* @daxian-dbw
|
||||
* @rjmholt
|
||||
* @BrucePay
|
||||
|
||||
## Interactive UX
|
||||
|
||||
While much of PowerShell can be used through both interactive and non-interactive means,
|
||||
some of the PowerShell user experience is exclusively interactive.
|
||||
These topics include (but are not limited to):
|
||||
|
||||
* Console
|
||||
* Help System
|
||||
* Tab completion / IntelliSense
|
||||
* Markdown rendering
|
||||
* PSReadLine
|
||||
* Debugging
|
||||
|
||||
### Members
|
||||
|
||||
* @daxian-dbw (PSReadline / IntelliSense)
|
||||
* @adityapatwardhan (Markdown / help system)
|
||||
* @JamesWTruher (cmdlet design)
|
||||
|
||||
## Language
|
||||
|
||||
The Language WG is distinct from the Engine WG in that they deal with the abstract definition
|
||||
of the PowerShell language itself.
|
||||
While all WGs will be working closely with the PowerShell Committee (and may share members),
|
||||
it's likely that the Language WG will work especially close with them,
|
||||
particularly given the long-lasting effects of language decisions.
|
||||
|
||||
### Members
|
||||
|
||||
* @JamesWTruher
|
||||
* @rjmholt
|
||||
* @daxian-dbw
|
||||
* @BrucePay
|
||||
|
||||
## Remoting
|
||||
|
||||
The Remoting WG should focus on topics like the **PowerShell Remoting Protocol (PSRP)**,
|
||||
the **protocols implemented under PSRP** (e.g. WinRM and SSH),
|
||||
and **other protocols used for remoting** (e.g. "pure SSH" as opposed to SSH over PSRP).
|
||||
Given the commonality of serialization boundaries, the Remoting WG should also focus on
|
||||
**the PowerShell job system**.
|
||||
|
||||
### Members
|
||||
|
||||
* @PaulHigin
|
||||
* @SteveL-MSFT
|
||||
* @TravisEz13
|
||||
* @anmenaga
|
||||
|
||||
## Modules
|
||||
|
||||
For those core/inbox modules whose source code lives within the `PowerShell/PowerShell` repository,
|
||||
we may have some set of WGs responsible for their cmdlet design guidelines and enforcement,
|
||||
as well as to manage the proposal of new cmdlets or breaking changes.
|
||||
|
||||
However, some modules that ship as part of the PowerShell package are managed in other source repositories.
|
||||
These modules are owned by the maintainers of those individual repositories.
|
||||
These modules include:
|
||||
|
||||
* [`Microsoft.PowerShell.Archive`](https://github.com/PowerShell/Microsoft.PowerShell.Archive)
|
||||
* [`PackageManagement` (formerly `OneGet`)](https://github.com/OneGet/oneget)
|
||||
* [`PowerShellGet`](https://github.com/PowerShell/PowerShellGet)
|
||||
* [`PSDesiredStateConfiguration`](https://github.com/PowerShell/xPSDesiredStateConfiguration)
|
||||
(Note: this community repository maintains a slightly different version of this module on the Gallery,
|
||||
but should be used for future development of `PSDesiredStateConfiguration`.)
|
||||
* [`PSReadLine`](https://github.com/PowerShell/PSReadLine)
|
||||
* [`ThreadJob`](https://github.com/PowerShell/Modules/tree/master/Modules/Microsoft.PowerShell.ThreadJob)
|
||||
|
||||
Until it is determined how best to handle the remainder of modules that ship as part of PowerShell,
|
||||
the following modules will be owned by the Committee and Maintainers:
|
||||
|
||||
* CimCmdlets
|
||||
* Microsoft.PowerShell.Diagnostics
|
||||
* Microsoft.PowerShell.Host
|
||||
* Microsoft.PowerShell.Management
|
||||
* Microsoft.PowerShell.Security
|
||||
* Microsoft.PowerShell.Utility
|
||||
* Microsoft.WSMan.Management
|
||||
* PSDiagnostics
|
||||
* Web/JSON Cmdlets
|
||||
|
||||
## Security
|
||||
|
||||
The Security WG should be brought into any issues or pull requests which may have security implications
|
||||
in order to provide their expertise, concerns, and guidance.
|
||||
|
||||
### Members
|
||||
|
||||
* @TravisEz13
|
||||
* @PaulHigin
|
||||
|
||||
## Explicitly not Working Groups
|
||||
|
||||
Some areas of ownership in PowerShell specifically do not have Working Groups.
|
||||
For the sake of completeness, these are listed below:
|
||||
|
||||
### Build
|
||||
|
||||
Build includes everything that is needed to build, compile, and package PowerShell.
|
||||
This bucket is also not oriented a customer-facing deliverable and is already something handled by Maintainers,
|
||||
so we don't need to address it as part of the WGs.
|
||||
|
||||
* Build
|
||||
* `build.psm1`
|
||||
* `install-powershell.ps1`
|
||||
* Build infrastructure and automation
|
||||
* Packaging
|
||||
* Scripts
|
||||
* Infrastructure
|
||||
|
||||
### Quality
|
||||
|
||||
Similar to the topic of building PowerShell, quality
|
||||
(including **test code**, **test infrastructure**, and **code coverage**)
|
||||
should be managed by the PowerShell Maintainers.
|
||||
|
||||
* Test code
|
||||
* Pester unit tests
|
||||
* xUnit unit tests
|
||||
* Test infrastructure
|
||||
* Nightlies
|
||||
* CI
|
||||
* Code coverage
|
||||
* Pester
|
||||
190
docs/community/working-group.md
Normal file
190
docs/community/working-group.md
Normal file
|
|
@ -0,0 +1,190 @@
|
|||
# Working Groups
|
||||
|
||||
[Working Groups (WGs)][wg] 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.
|
||||
|
||||
The list, description, and membership of the existing Working Groups is available
|
||||
[here](working-group-definitions.md).
|
||||
|
||||
## Terms
|
||||
|
||||
* **Contributor** is used interchangeably within this doc as anyone participating in issues or
|
||||
contributing code, RFCs, documentations, tests, bug reports, etc.,
|
||||
regardless of their status with the PowerShell project.
|
||||
* **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.
|
||||
(Learn more about the Repository Maintainers [here](https://github.com/PowerShell/PowerShell/tree/master/docs/maintainers).)
|
||||
* The **PowerShell Committee** is responsible for the design and governance of the PowerShell project,
|
||||
primarily by voting to accept or reject review-for-comment (RFC) documents.
|
||||
(Learn more about the PowerShell Committee [here](https://github.com/PowerShell/PowerShell/blob/master/docs/community/governance.md#powershell-committee).)
|
||||
* A **Working Group** is a collection of people responsible for providing expertise on a specific
|
||||
area of PowerShell in order to help establish consensus within the community and Committee.
|
||||
The responsibilities of Working Groups are outlined below.
|
||||
(Note: while some experts within Working Groups may have more specific expertise in a sub-topic
|
||||
of the team,
|
||||
the intent is that each team is holistically and collectively responsible for making decisions
|
||||
within the larger topic space.)
|
||||
|
||||
## Goals
|
||||
|
||||
In designing the WG process, the Committee had a few goals:
|
||||
|
||||
1. Increase the velocity of innovation without compromising the stability of PowerShell
|
||||
1. Reduce the time spent by contributors on writing/reviewing PRs and RFCs that are not feasible
|
||||
1. Increase the formal authority of subject matter experts (SMEs) inside and outside of Microsoft
|
||||
1. Decrease the volume of required technical discussions held by the Committee
|
||||
|
||||
## Process
|
||||
|
||||
This process is represented within the [`process_diagram.vsdx` Visio diagram](process_diagram.vsdx):
|
||||
|
||||
|
||||
|
||||
1. A contributor has an idea for PowerShell
|
||||
1. The contributor files an issue informally describing the idea,
|
||||
including some rationale as to why it should happen and a few use cases to show how it could work,
|
||||
as well as to determine viability and value to the community.
|
||||
This should include examples of expected input and output so that others understand how the feature would function in the real world.
|
||||
1. The issue gets triaged into an [Area label](https://github.com/PowerShell/PowerShell/blob/master/docs/maintainers/issue-management.md#feature-areas)
|
||||
by Maintainers.
|
||||
This area label maps to one or more Working Groups.
|
||||
1. If the Working Group determines that an idea can be prototyped or built outside of the PowerShell repo
|
||||
(e.g. as a module),
|
||||
contributors should start that idea outside of the PowerShell project.
|
||||
Given that the issue is no longer directly relevant to the PowerShell project, it should be closed
|
||||
(with a link to the new project, if available).
|
||||
If the implementation turns out to be successful and particularly popular,
|
||||
and a contributor believes that it would be overwhelmingly valuable to include in the primary PowerShell package,
|
||||
they can restart the process in a new issue proposing that the functionality be
|
||||
incorporated directly into the primary PowerShell package.
|
||||
1. After the issue is filed, interested contributors should discuss the
|
||||
feasibility and approach of the idea in the issue.
|
||||
The Working Group that owns that Area is expected to contribute to this discussion.
|
||||
Working groups may have their own criteria to consider in their areas.
|
||||
1. After an appropriately exhaustive discussion/conversation
|
||||
(i.e. the Working Group has determined that no new arguments are being made),
|
||||
the Working Group makes a call on whether they believe the idea should continue through this process.
|
||||
Note: this should be done via a best effort of consensus among the Working Group.
|
||||
We don't currently have hard requirements for how this should be done,
|
||||
but some ideas include:
|
||||
|
||||
* a single member of the Working Group makes a proposal as a comment and other members should
|
||||
"react" on GitHub with up/down thumbs
|
||||
* Working Groups communicate privately through their own established channel to reach consensus
|
||||
|
||||
It's worth noting that Working Group members who repeatedly speak on behalf of the Working Group without
|
||||
consensus, they may be censured or removed from the team.
|
||||
|
||||
### Working Groups reject the proposal
|
||||
|
||||
If the Working Group says the idea should not pursued, the process stops.
|
||||
Some reasons for rejection include (but are not limited to):
|
||||
|
||||
* the idea can be implemented and validated for usefulness and popularity outside of the primary PowerShell repo/package
|
||||
* the idea is difficult/impossible to implement
|
||||
* the implementation would introduce undesirable (and possibly breaking) changes to PowerShell
|
||||
* other reasons specific to individual Working Groups
|
||||
|
||||
In the instance that the contributor feels they have compelling arguments showing that the
|
||||
Working Group is incorrect in their rejection,
|
||||
they can appeal to the PowerShell Committee by mentioning `@PowerShell/PowerShell-Committee`,
|
||||
upon which a maintainer will add the `Review-Committee` label to the issue and reopen it.
|
||||
Then, the PS Committee will discuss further with the Working Group and others to make a final call on
|
||||
whether or not the issue should be pursued further.
|
||||
|
||||
Be sure to enumerate your reasons for appeal, as unfounded appeals may be rejected for consideration
|
||||
by the Committee until reasons are given.
|
||||
|
||||
### Working groups believe the proposal has merit and/or potential
|
||||
|
||||
If the idea passes the preliminary acceptance criteria for the Working Group,
|
||||
the process proceeds on one of a few different paths:
|
||||
|
||||
#### "RFC Not Required"
|
||||
|
||||
In some cases, a proposed idea is determined by the Working Group to be small, uncontroversial, or simple,
|
||||
such that an RFC is not required (to be determined by the Working Group).
|
||||
In these circumstances, the Working Group should mark the issue as "RFC not required",
|
||||
upon which it can move directly to the code PR phase to be reviewed by Working Groups and Maintainers.
|
||||
|
||||
The Committee still holds the authority to require an RFC if they see an "RFC Not Required" issue
|
||||
that they feel needs more exposition before merging.
|
||||
|
||||
In cases of minor breaking changes, Maintainers or Working Groups can add the `Review - Committee` label to get
|
||||
additional opinions from the Committee.
|
||||
|
||||
#### RFC/Prototype Process
|
||||
|
||||
If an idea has any significant design or ecosystem implications,
|
||||
*cannot* be prototyped or built outside of the PowerShell repo,
|
||||
and the community and Working Groups agree that the idea is worth pursuing,
|
||||
a contributor (who may or may not be the original issue filer) must do two things:
|
||||
|
||||
* Write an RFC as a [Draft PR](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests)
|
||||
into `PowerShell/PowerShell-RFC`
|
||||
* Prototype the implementation as a [Draft PR](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests)
|
||||
into `PowerShell/PowerShell`
|
||||
|
||||
In both cases, the intention is to provide Working Groups and other contributors who care about the
|
||||
idea an opportunity to provide feedback on the design and implementation.
|
||||
|
||||
Either of these two steps can be done first, but both are required in order to have code accepted
|
||||
into the PowerShell repository, including experimental features.
|
||||
|
||||
Note: When "Draft" is capitalized in this document, I'm referring to the
|
||||
[Draft pull request](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/about-pull-requests#draft-pull-requests)
|
||||
feature on GitHub.
|
||||
We intend to use this feature liberally to mark the lifecycle of an idea through to implementation.
|
||||
|
||||
#### RFCs
|
||||
|
||||
The existing RFC process uses folders as a way to move an RFC through a multi-stage process
|
||||
(Draft -> Experimental -> Accepted/Final).
|
||||
However, it was difficult to reconcile this process with the benefits of PR reviews.
|
||||
|
||||
With the introduction of Draft PRs on GitHub, we are reorienting the acceptance process around the PR itself.
|
||||
Going forward, an RFC will have three stages:
|
||||
|
||||
1. A Draft PR, denoting that the RFC is still in the review period, openly soliciting comments,
|
||||
and that it may continue to be significantly iterated upon with revisions, edits, and responses to
|
||||
community feedback or concerns.
|
||||
1. After a minimum of two months of discussion, the RFC/PR author marks the PR as
|
||||
[ready for review](https://help.github.com/en/github/collaborating-with-issues-and-pull-requests/changing-the-stage-of-a-pull-request),
|
||||
upon which the RFC will enter the Committee's review queue to discuss the RFC contents and comments,
|
||||
and make a decision on whether it is reasonable to pursue.
|
||||
If after this review, the Committee determines that the intent of the RFC is not reasonable
|
||||
(e.g. there may be irreconcilable issues with the design,
|
||||
or the intent may not fit with the principles of PowerShell),
|
||||
they will reject the PR and the process terminates.
|
||||
1. In most cases, the Committee will choose to wait for the code PR to be merged as experimental,
|
||||
and leverage user feedback or telemetry to determine if the RFC PR should be merged.
|
||||
1. Finally, the Committee will choose to either merge or close the RFC PR,
|
||||
marking the RFC as either accepted or rejected, respectively.
|
||||
|
||||
#### Experiments
|
||||
|
||||
Often times, implementing an idea can demonstrate opportunities or challenges that were not well
|
||||
understood when the idea was formulated.
|
||||
Similarly, a "simple" code change can have far reaching effects that are not well understood
|
||||
until you're able to experiment with an idea within working code.
|
||||
|
||||
To that end, it's required that *some* implementation exist before the Committee will consider an
|
||||
RFC for acceptance.
|
||||
That way, contributors can compile the PR branch to play with a working iteration of the idea
|
||||
as a way to understand whether the feature is working as expected and valuable.
|
||||
|
||||
In most cases, as long as an RFC has already been written and published as a draft,
|
||||
Working Groups or the Committee will approve the feature for incorporation as an experimental feature,
|
||||
so that it can be trialed with greater usage as part of a preview release.
|
||||
In addition to increasing the scope of those who can provide real-world feedback on the feature,
|
||||
this enables us to use telemetry to understand if users are turning off the feature in large numbers.
|
||||
|
||||
Note: today, this will be done on a case-by-case basis, but over time, the Committee will establish
|
||||
firmer guidelines around when PRs should be merged as experimental.
|
||||
|
||||
Experiments should be complete to the extent that they serve as reasonable indicators of the user experience.
|
||||
In the case that breaking changes are required of the feature, the break should be made in the prototype
|
||||
so that users can experiment with whether or not the break has a significant negative effect.
|
||||
|
|
@ -7,6 +7,8 @@ first follow the [vulnerability issue reporting policy](../../.github/SECURITY.m
|
|||
|
||||
## Long-living issue labels
|
||||
|
||||
Issue labels for PowerShell/PowerShell can be found [here](https://github.com/powershell/powershell/labels).
|
||||
|
||||
### Issue and PR Labels
|
||||
|
||||
Issues are opened for many different reasons.
|
||||
|
|
@ -37,32 +39,35 @@ When an issue is resolved, the following labels are used to describe the resolut
|
|||
|
||||
### Feature areas
|
||||
|
||||
These labels describe what feature area of PowerShell that an issue affects:
|
||||
These labels describe what feature area of PowerShell that an issue affects.
|
||||
Those labels denoted by `WG-*` are owned by a Working Group (WG) defined
|
||||
[here](../community/working-group-definitions.md):
|
||||
|
||||
* `Area-Build`: build issues
|
||||
* `Area-Maintainers-Build`: build issues
|
||||
* `Area-Cmdlets-Core`: cmdlets in the Microsoft.PowerShell.Core module
|
||||
* `Area-Cmdlets-Utility`: cmdlets in the Microsoft.PowerShell.Utility module
|
||||
* `Area-Cmdlets-Management`: cmdlets in the Microsoft.PowerShell.Management module
|
||||
* `Area-Console`: the console experience
|
||||
* `Area-Debugging`: debugging PowerShell script
|
||||
* `Area-Demo`: a demo or sample
|
||||
* `Area-Documentation`: PowerShell *repo* documentation issues, general PowerShell doc issues go [here](https://github.com/PowerShell/PowerShell-Docs/issues)
|
||||
* `Area-DSC`: DSC related issues
|
||||
* `Area-Engine`: core PowerShell engine, interpreter, runtime
|
||||
* `Area-HelpSystem`: anything related to the help infrastructure and formatting of help
|
||||
* `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-PowerShellGet`: PowerShellGet related issues
|
||||
* `Area-Providers`: PowerShell providers such as FileSystem, Certificates, Registry, etc...
|
||||
* `Area-PSReadline`: PSReadline related issues
|
||||
* `Area-Remoting`: PSRP issues with any transport layer
|
||||
* `Area-Security`: security related areas such as [JEA](https://github.com/powershell/JEA)
|
||||
* `Area-SideBySide`: side by side support
|
||||
* `Area-Test`: issues in a test or in test infrastructure
|
||||
* `WG-DevEx-Portability`: anything related to authoring cross-platform or cross-architecture
|
||||
modules, cmdlets, and scripts
|
||||
* `WG-DevEx-SDK`: anything related to hosting PowerShell as a runtime, PowerShell's APIs,
|
||||
PowerShell Standard, or the development of modules and cmdlets
|
||||
* `WG-Engine`: core PowerShell engine, interpreter, and runtime
|
||||
* `WG-Engine-Performance`: core PowerShell engine, interpreter, and runtime performance
|
||||
* `WG-Engine-Providers`: built-in PowerShell providers such as FileSystem, Certificates,
|
||||
Registry, etc. (or anything returned by `Get-PSProvider`)
|
||||
* `WG-Interactive-Console`: the console experience
|
||||
* `WG-Interactive-Debugging`: debugging PowerShell script
|
||||
* `WG-Interactive-HelpSystem`: anything related to the help infrastructure and formatting of help
|
||||
* `WG-Interactive-IntelliSense`: tab completion
|
||||
* `WG-Interactive-PSReadline`: PSReadline related issues
|
||||
* `WG-Language`: parser, language semantics
|
||||
* `WG-Quality-Test`: issues in a test or in test infrastructure
|
||||
* `WG-Remoting`: PSRP issues with any transport layer
|
||||
* `WG-Security`: security related areas such as [JEA](https://github.com/powershell/JEA)
|
||||
|
||||
### Operating Systems
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue