Windows 10: Microsoft introducing Working Groups within PowerShell

Brink · Oct 14, 2020

Since we open sourced PowerShell in 2016, PowerShell has been an immensely popular project on GitHub. Every year, 700-1000 PRs and 1300-1500 issues are submitted to the PowerShell repo, with roughly half of the PRs and 90% of the issues filed from the community.

We realize that some of these issues and PRs have been piling up and, as the project has grown in popularity and community activity, we sometimes struggle with the sheer volume of them. Those of us on the PowerShell Committee have been discussing some ways that we think we might be able to improve the efficiency of our decision-making process, and to reduce bottlenecks that may be causing the increase in our overall backlog.

We set out with a couple of goals:

First, we wanted to increase the velocity of innovation in PowerShell, but without compromising the stability of the engine and language that so many depend upon within their critical infrastructure and automation environments. Itâs critical that anything we do in changing the management of the PowerShell project not jeopardize this.

We also noticed that a lot of contributor time is being spent on contributions and discussions that are ultimately rejected by Maintainers or the Committee. Despite being rejected for legitimate reasons (e.g. risky breaking changes), we recognize that the rejection could happen before the contributor spends considerable time and effort.

To that end, we want to:

increase the number of people who can make approve or reject proposals, especially where those people have domain-specific knowledge about a topic

make those approvals and rejections more explicit, giving contributors confidence in moving forward

make approvals and rejections earlier in the process to avoid unnecessary work for contributors and maintainers

Working Groups

To meet these goals, we are introducing the concept of Working Groups (WGs) within the PowerShell project (including those repositories that contribute their modules into the PowerShell package). You can think of WGs as subcommittees for specific areas within the PowerShell project. Some of their responsibilities include:

Fostering discussions in issues and pull requests

Deciding whether feature proposals need request-for-comment (RFC) docs to be approved by the Committee

Approving or rejecting feature proposals in issues

Offering guidance and expertise in RFC discussions

Triaging bugs filed as issues

Reviewing code in pull requests

Initially, working groups will only consist of PowerShell Team members, but we will be reaching out to high-impact community contributors over the next few months to gauge their interest in joining WGs.

Issue Flow

There are two primary categories of issues that get filed in the PowerShell repository: bugs and feature proposals. Bugs and features will each be handled differently going forward.

Bugs

Bugs are the easy case. At a high-level, when a bug gets filed:

A Maintainer will label the issue with the appropriate Working Group(s)

Working Group members for those labels will review the bug to determine if it is a legitimate bug, by-design, external to the project, and/or worth spending time to fix (based on the value, complexity, risk, etc.)

When a bug has been established as legitimate, Working Group members will establish the severity of the bug (i.e. the importance of fixing it)

If and when a PowerShell Team member or contributor files a PR to fix the bug, at least one Working Group member will be responsible for reviewing the PR.

In practice, this is similar to how bugs are already handled today. However, weâre hopeful that the addition of Working Group members outside of the PowerShell Team will enable a greater number of bugs to be triaged and resolved appropriately, as well as to unblock a number of bug fixes in PR that are of a lower priority.

Feature Proposals

Feature proposals are a little more complicated.

First and foremost, any new feature proposals should initially be filed as issues, specifically using the issue template for feature requests (subject to some ongoing changes). This issue must include:

a description of the feature being proposed

the scenario for using the feature (i.e. why is the feature useful in the real world)

examples of how the feature might work in practice (including mandatory example script blocks and output)

Again, Maintainers will label the issue for the appropriate WGs in order to bring them into the issue for discussion. Working Group members will facilitate a discussion with the community around the utility and design of the proposal, as well as contributing their expertise on the feasibility and design consistency of implementing the proposal.

One pattern that we are noticing within the PowerShell repo today is the large number of proposals that could be implemented outside of PowerShell itself (usually via external modules). In keeping with our goal of maintaining stability in PowerShell, weâd prefer that this experimentation happens via the PowerShell Gallery, where modules can be published as prerelease, and where semantic versioning can be used to communicate breaking changes. Therefore, WGs will aggressively reject any feature proposals that can be implemented externally from the repo.

WGs will also decide whether they believe the feature proposal requires an RFC, based on the complexity, size, and potential impact of the proposal. Where RFCs are not required, WGs will approve the proposal and then will review the eventual PR to implement it. Where RFCs are required, contributors will be asked to submit RFCs. Working Group members will participate heavily in the RFC discussion, contributing their expertise to help the Committee make decisions on whether to accept the proposal.

Experimental Features

Experimental features are features shipped in PowerShell that are not officially supported as they may be unstable or subject to change in the future. (Theyâre turned on by default in preview branches and off by default in officially supported versions, including release candidates.)

We introduced experimental features as a way to accelerate development and gather feedback in situations where weâre unsure whether a specific approach is best, and where we may want to change the behavior before users start depending on it in production.

In the past, weâve largely used experimental features for new behavior that we already have a strong intent to eventually merge. While weâve caught certain issues that have prevented experimental features from being accepted as stable, we believe the current perception is that these features will eventually become stable.

In the future, weâd like to use experimental features for experimenting and gathering user feedback on whether a feature should exist at all, with a more explicit assertion that many of them will never find their way to a supported GA release. This means that we may be accepting more PRs into PowerShell as experimental features, but that this acceptance is not necessarily long-term acceptance into PowerShell.

Instead, the RFC process will be used to convey full acceptance, something that may happen long after code has been accepted as experimental. And in fact, the feedback received around the experimental will be used by the Committee to inform the RFC decision.

Whatâs next?

Similar to the way we roll out functionality in PowerShell, weâll be taking a staged approach to rolling out these governance changes, taking feedback along the way.

In the near term, members of the PowerShell Team have been added to preliminary WGs, and youâll see Area issue labels change to reflect these WGs as weâve defined them. Members of these WGs will be responsible for triaging new issues under those labels, reviewing PRs under those labels, and (eventually) working through the backlog of existing issues. WGs will also be experimenting with various ways of organizing themselves, including how they divvy up issues/PRs and how much consensus amongst themselves to make a decision.

Over the next couple months, weâll introduce more of this process as official governance proposals within the RFC repo, and update our existing governance language to reflect the new changes. These changes may continue to evolve as we learn more about what does and doesnât work.

The Committee will address existing RFCs on a case-by-case basis. Some have already been extensively discussed as issues and/or RFC discussions, and we may choose to move forward with experimental implementations or reject them altogether.

If folks feel that issues, pull requests, or RFCs arenât being adequately addressed by WGs, they should still feel free to mention @PowerShell/powershell-committee or to request that a Review-Committee label be added. In the future, weâll have more guidance on how escalations and Committee reviews will work.

Eventually, weâll reach out to contributors who may be interested in joining these Working Groups, completing our original goal of increasing the number of people who can make decisions about specific areas of PowerShell.

Thank you!

Thanks to our contributors and users for continuing to submit issues, pull requests, and RFCs to the PowerShell repo. We appreicate your patience as we work towards this new model, and we encourage you to provide feedback as issues in the PowerShell-RFC repo as we continue on this journey.

Joey Aiello
Click to expand...

Source: https://devblogs.microsoft.com/powershell/18658-2/

Tweet

— Twitter API (@user) View on Twitter
Click to expand...

:)

Radney Dri · Oct 14, 2020

Microsoft Solitaire is not working

Hi,

I need more information about your concern. Is there any error message/code after Microsoft Solitaire fails to launch? Since the steps you have tried did not work, I suggest that you reinstall it instead. Follow the steps below:

Open Windows PowerShell as an administrator. (Type PowerShell in Start menu search box, right-click and select Run as administrator)

Type the following command and press Enter "Get-AppxPackage *solitairecollection* | Remove-AppxPackage"

You can close the PowerShell window and restart your device.

Open Store app and search for Microsoft Solitaire Collection and download the game.

Looking forward to your response.

lvgandhi · Oct 14, 2020

powershell help does not seem to work

Hi, did you do the first part of what @Bree asked?

Try this to fix Powershell:
Press Windows key + R
Type: optionalfeatures.exe
Hit Enter

Scroll down and locate the Windows PowerShell entry.
Uncheck the PowerShell feature.
Save and apply your changes.
Restart your Windows 10 computer.
Afterwards, repeat the steps from above and re-enable the Windows PowerShell feature.
Click to expand...

Thanks for response.
I have done chkdsk C: /f also.
still not working. I tried your suggestion also. That also does not work.
But as I said get-help dir works. Please see below

KeithM · Oct 14, 2020

How to change the WinX menu, including Powershell/Powershell (Admin)

2. I know how to toggle WIN-X between command prompt and powershell. But after I selected powershell and click I get a message that Powershell can not be used due to restrictions. From there i get lost. No idea what to do. And could not find it in the suggested answers and links. Or did I miss something?
Click to expand...

This part intrigues me. As suggested earler, please post a screenshot of the error message. Also, please clarify/test the follwoing:

Can you start PowerShell from the Start Menu?

If you navigate to %localappdata%\Microsoft\Windows\WinX\Group3, does PowerShell launch from the shortcuts there?

If #1 works & #2 doesn't, compare (& post) the target text from each shortcuts properties. For the Start Menu shortcut, right-click & select Open file location to navigate to the Start Menu folder.

Keith

Windows 10: Microsoft introducing Working Groups within PowerShell

Microsoft introducing Working Groups within PowerShell

Microsoft introducing Working Groups within PowerShell

Microsoft introducing Working Groups within PowerShell

Microsoft introducing Working Groups within PowerShell - Similar Threads - Microsoft introducing Working

Powershell modules to work on MIM groups

Powershell modules to work on MIM groups

Group Policy for Powershell Execution

Group Policy for Powershell Execution

Group Policy for Powershell Execution

Microsoft powershell not working

Powershell - Local group creation

Introducing Microsoft Editor

Sharing purchases within family group