"Fossies" - the Fresh Open Source Software Archive

Member "PowerShell-7.2.5/docs/community/working-group-definitions.md" (21 Jun 2022, 5873 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.

Working Group Definitions

This document maintains a list of the current PowerShell Working Groups (WG), 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

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.


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



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):

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.


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):



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.



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.


Cmdlets and Modules

The Cmdlet WG should focus on core/inbox modules whose source code lives within the PowerShell/PowerShell repository, including the proposal of new cmdlets and parameters, improvements and bug fixes to existing cmdlets/parameters, and 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:



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.


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


Similar to the topic of building PowerShell, quality (including test code, test infrastructure, and code coverage) should be managed by the PowerShell Maintainers.