{"id":18658,"date":"2020-10-12T13:41:41","date_gmt":"2020-10-12T21:41:41","guid":{"rendered":"https:\/\/devblogs.microsoft.com\/powershell\/?p=18658"},"modified":"2020-10-14T16:55:07","modified_gmt":"2020-10-15T00:55:07","slug":"powershell-working-groups","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/powershell\/powershell-working-groups\/","title":{"rendered":"PowerShell Working Groups"},"content":{"rendered":"
\n

Since we open sourced PowerShell in 2016, PowerShell has been an immensely popular project on GitHub.\nEvery year<\/a>,\n700-1000 PRs and 1300-1500 issues are submitted to the PowerShell repo,\nwith roughly half of the PRs and 90% of the issues filed from the community.<\/p>\n

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

We set out with a couple of goals:<\/p>\n

First, we wanted to increase the velocity of innovation in PowerShell,\nbut without compromising the stability of the engine and language that so many depend upon\nwithin their critical infrastructure and automation environments.\nIt’s critical that anything we do in changing the management of the PowerShell project not jeopardize this.<\/p>\n

We also noticed that a lot of contributor time is being spent on contributions and discussions that\nare ultimately rejected by Maintainers or the Committee.\nDespite being rejected for legitimate reasons (e.g. risky breaking changes),\nwe recognize that the rejection could happen before the contributor spends considerable time and effort.<\/p>\n

To that end, we want to:<\/p>\n

    \n
  1. increase the number of people who can make approve or reject proposals,\nespecially where those people have domain-specific knowledge about a topic<\/li>\n
  2. make those approvals and rejections more explicit, giving contributors confidence in moving forward<\/li>\n
  3. make approvals and rejections earlier in the process to avoid unnecessary work for contributors and maintainers<\/li>\n<\/ol>\n

    \n<\/span><\/a>Working Groups<\/h2>\n

    To meet these goals, we are introducing the concept of Working Groups (WGs) within the PowerShell project\n(including those repositories that contribute their modules into the PowerShell package).\nYou can think of WGs as subcommittees for specific areas within the PowerShell project.\nSome of their responsibilities include:<\/p>\n

      \n
    1. Fostering discussions in issues and pull requests<\/li>\n
    2. Deciding whether feature proposals need request-for-comment (RFC) docs to be approved by the Committee<\/li>\n
    3. Approving or rejecting feature proposals in issues<\/li>\n
    4. Offering guidance and expertise in RFC discussions<\/li>\n
    5. Triaging bugs filed as issues<\/li>\n
    6. Reviewing code in pull requests<\/li>\n<\/ol>\n

      Initially, working groups will only consist of PowerShell Team members,\nbut we will be reaching out to high-impact community contributors over the next few months\nto gauge their interest in joining WGs.<\/p>\n

      \n<\/span><\/a>Issue Flow<\/h2>\n

      There are two primary categories of issues that get filed in the PowerShell repository:\nbugs and feature proposals.\nBugs and features will each be handled differently going forward.<\/p>\n

      \n<\/span><\/a>Bugs<\/h3>\n

      Bugs are the easy case. At a high-level, when a bug gets filed:<\/p>\n

        \n
      1. A Maintainer will label the issue with the appropriate Working Group(s)<\/li>\n
      2. Working Group members for those labels will review the bug to determine if it is a legitimate bug,\nby-design, external to the project, and\/or worth spending time to fix\n(based on the value, complexity, risk, etc.)<\/li>\n
      3. When a bug has been established as legitimate, Working Group members will establish the severity of the bug\n(i.e. the importance of fixing it)<\/li>\n
      4. If and when a PowerShell Team member or contributor files a PR to fix the bug,\nat least one Working Group member will be responsible for reviewing the PR.<\/li>\n<\/ol>\n

        In practice, this is similar to how bugs are already handled today.\nHowever, we’re hopeful that the addition of Working Group members outside of the PowerShell Team\nwill enable a greater number of bugs to be triaged and resolved appropriately,\nas well as to unblock a number of bug fixes in PR that are of a lower priority.<\/p>\n

        \n<\/span><\/a>Feature Proposals<\/h3>\n

        Feature proposals are a little more complicated.<\/p>\n

        First and foremost, any new feature proposals should initially be filed\nas issues, specifically using the issue template for feature\nrequests<\/a>\n(subject to some ongoing changes). This issue must include:<\/p>\n