Updated governance: Working Groups (WGs)

[joeyaiello]

PR Summary

This PR introduces the concept of PowerShell Working Groups (WGs), a governance body that makes decision with feature areas of PowerShell.

PR Context

As have been discussed by the Committee and PowerShell engineering teams over the course of the last year, and as we introduced in this blog post, this PR introduces the concept of PowerShell Working Groups (WGs).

We're still very much open to feedback with regards to these docs, so please let us know what you think about this proposal. As such, I've marked the PR as WIP for the time being.

I'm certain that, given the number of documents involved with these changes, that some of the older language is probably hanging around in some doc where it no longer makes sense. Please comment if you see any of these (or just any typos in general).

Note that this PR has a sibling PR in the PowerShell-RFC repo at PowerShell/PowerShell-RFC#274

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• Breaking changes
  • None
  • OR
  • Experimental feature(s) needed
    • Experimental feature name(s):
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed
• Tooling
  • I have considered the user experience from a tooling perspective and don't believe tooling will be impacted.
  • OR
  • I have considered the user experience from a tooling perspective and enumerated concerns in the summary. This may include:
    • Impact on PowerShell Editor Services which is used in the PowerShell extension for VSCode (which runs in a different PS Host).
    • Impact on Completions (both in the console and in editors) - one of PowerShell's most powerful features.
    • Impact on PSScriptAnalyzer (which provides linting & formatting in the editor extensions).
    • Impact on EditorSyntax (which provides syntax highlighting with in VSCode, GitHub, and many other editors).

[iSazonov]

The only doubt about group members is that we see the activity of some members never or very rarely.

[vexx32]

Small spelling error:

Suggested change

	# Working Group Defintions
	# Working Group Definitions

[vexx32]

I have additional thoughts about memberships -- I'm on the fence about whether it's a good idea to have PS team members as working group members directly. Points of contact are likely going to be crucial, so ideally that is kind of a minimum bar here.

However, a lot of the wording here refers to consensus, which essentially means that regardless of the number of community members in a working group, the powershell team member(s) that are part of that group can also unilaterally veto pretty much anything. On the surface, maybe that sounds useful, but I think in practice it would simply neuter the effectiveness and potential of working groups as a whole. If PS team members have a concern about a working group's decision, I think elevating it to committee review is a better process than just being able to veto it as a working group member.

Reading between the lines, it also seems fairly safe to presume that powershell team members that are also part of a working group likely cannot be removed from the group at any point, which means that it's not equal standing within the working group for community members and powershell team members, despite a lot of the language here seeming to suggest that equal standing amongs members is more or less the intention (correct me if I'm wrong, of course).

Community members tend to give deference to PowerShell team members in general, which I think may unavoidably affect the dynamic of working groups which have powershell team members. Perhaps it would be preferable in some or all cases for WGs to have defined points of contact on the team when context or detail from team members is required, rather than having them be full team members themselves.

Additionally, if PowerShell team members are also going to be WG members, is that in a "fellow community member" capacity or in a "that is part of their job description" capacity? Perhaps that distinction has been made internally already, but whether it has or not I think it needs to be made clear here. There is already a fairly significant problem of maintainers not having sufficient time to triage PRs and do code review; if this is intended to alleviate that, having them also required to interface as critical parts of multiple WGs seems counterproductive to me.

[iSazonov]

Are there already community candidates for these groups? If not, why start all this?

I'm amazed surprised that MSFT won't bring its partners here in any way.

[joeyaiello]

@mklement0: you raise a lot of really good points, did my best to address them all below, but let me know if there are still some lingering.

First, regarding whether PS Team members would ever be removed from WGs: obviously, if someone leaves the company or the PowerShell Team, they would probably not want to spend time as a WG member anymore. But even in other cases, I don't think it should be entirely ruled out: folks shuffle around their interests and roles within the team somewhat fluidly, and based on other time commitments, folks may need to leave WGs.

(However, given the nature of certain internal requirements, I do think we'll need all WGs to have at least some Microsoft representation.)

But a lot of the language here is intended to convey that being a WG member is a time commitment. WG members are expected to be actively contributing on a regular basis, and should not be occasional passive advisors. In that sense, and in the sense that WGs have formal authority, everyone on the WG should be more than a traditional "fellow community member", and may constitute the equivalent of "job responsibilities" for folks even outside of Microsoft.

Part of the motivation behind not adding community members on day one is that we would like to experiment with different engagement models. We don't yet know how engagement scales, how WGs want to reach consensus, etc., and we'd rather not add a bunch of folks to WGs only to realize that they're making ultimately undesirable decisions that need to be rolled back. Similarly, we want WGs to use this experimental timeframe to establish principles and criteria by which future decisions get made.

As for driving towards consensus: the language there is intended to specifically discourage blanket "vetos" or voting that traipses over the concerns of a minority of members. In other words, folks shouldn't just be saying "the 4 of us think you're wrong, so no", but rather convincing other members that their position is the correct one.

From those perspectives, WGs are not really supposed to be a sum of individuals with completely random interests and opinions, but rather a body that generally represents the overall project direction and philosophy. For example, we don't expect WGs to suddenly want to make breaking changes that wouldn't have historically been accepted so far.

I hope that clarifies some of your concerns. I'm not sure that all of this necessarily belongs in this set of docs, but I'm perfectly happy to make targeted clarifications or flesh out more of the specifics where you think it makes sense.

[mklement0]

@joeyaiello, I think you meant to direct your comment to @vexx32.

[vexx32]

Thanks, @mklement0 😁

Thanks @joeyaiello! I think that all makes sense. I'm not sure whether some of that should be in this doc either, to be honest, but the additional clarity is nonetheless appreciated. 💖 😊

[iSazonov]

I have never understood this. The only thing you might think is that MSFT PowerShell team has an internal KPI for the number of supported repositories. :-)
The team always says that it is too small and has limited resources, but each additional repository requires additional resources. Even much larger projects (dotnet) prefer a minimum of repositories.

[joeyaiello]

Our biggest reasoning is that we ultimately want those modules to be decoupled such that they can deployed to older supported versions of PS7. Similarly, we may want to create distributions of PowerShell in the future that don't contain certain modules.

This is certainly all possible within a single repo, but there are tradeoffs.

Regardless, I'm deferring that conversation as out-of-scope for the creation of WGs.

[SteveL-MSFT]

We tried to mitigate the additional cost of maintaining many module repos with the single module repo, but that proved untenable for the practical matter that CI/CD couldn't be done on a per module basis vs the entire repo as well as additional cost of triaging issues to mark areas for appropriate experts to review.

[iSazonov]

I have never put pressure on the team in view of the special status of the project, but here I see some confusion.

Regardless, I'm deferring that conversation as out-of-scope for the creation of WGs.

If we are talking about reducing overhead costs, then it is strongly related areas.
Creating new repositories obviously increases the overhead. Let's look at the .Net team again. They are 10 times larger, but put all the code in one repository. And they publish dozens of independent packages. They use a bot to assign tags.
Can't we do the same?
We already have some (10?) labels for modules including DSC, PowerShellGet and PSReadline. Add a few more is this really a problem?
Today only one person is working on the vault module. The same for PSReadline module. Don't you want working groups for them? More likely to make them real in a large repository.

we ultimately want those modules to be decoupled

This does not contradict in any way placing them in one repository. See again the experience of the .Net team. The maintenance and publishing process, policies, conventions, CIs are the same for all modules. This will significantly reduce overhead costs.

Based on my experience, I would advise MSFT team to go this way if there are no internal restrictions.

[joeyaiello]

Updated language to remove future intent

[vexx32]

Small spelling error:

Suggested change

	# Working Group Defintions
	# Working Group Definitions

[vexx32]

I have additional thoughts about memberships -- I'm on the fence about whether it's a good idea to have PS team members as working group members directly. Points of contact are likely going to be crucial, so ideally that is kind of a minimum bar here.

However, a lot of the wording here refers to consensus, which essentially means that regardless of the number of community members in a working group, the powershell team member(s) that are part of that group can also unilaterally veto pretty much anything. On the surface, maybe that sounds useful, but I think in practice it would simply neuter the effectiveness and potential of working groups as a whole. If PS team members have a concern about a working group's decision, I think elevating it to committee review is a better process than just being able to veto it as a working group member.

Reading between the lines, it also seems fairly safe to presume that powershell team members that are also part of a working group likely cannot be removed from the group at any point, which means that it's not equal standing within the working group for community members and powershell team members, despite a lot of the language here seeming to suggest that equal standing amongs members is more or less the intention (correct me if I'm wrong, of course).

Community members tend to give deference to PowerShell team members in general, which I think may unavoidably affect the dynamic of working groups which have powershell team members. Perhaps it would be preferable in some or all cases for WGs to have defined points of contact on the team when context or detail from team members is required, rather than having them be full team members themselves.

Additionally, if PowerShell team members are also going to be WG members, is that in a "fellow community member" capacity or in a "that is part of their job description" capacity? Perhaps that distinction has been made internally already, but whether it has or not I think it needs to be made clear here. There is already a fairly significant problem of maintainers not having sufficient time to triage PRs and do code review; if this is intended to alleviate that, having them also required to interface as critical parts of multiple WGs seems counterproductive to me.

[vexx32]

In my own opinion, I think these comments are unnecessary or would be better served worded differently.

Note that the Committee has thus far tended to agree with Maintainers.

This just reads more like "it's not worth debating a point with maintainers, because the committee generally has their back and won't consider community POVs as much as they will maintainer POVs". This puts folks on uneven ground from the start and is overly discouraging in my opinion. I don't think this note has any real reason to be part of a process doc, as this is more a judgement on balance of historical decisions, which may or may not still be a true statement in a few years' time.

Contributors are discouraged from launching unfounded appeals.

I think this is overly aggressive and doesn't really clarify what it seems to be intended to. The point appears to be moreso "Please don't launch an appeal without due cause", right? I feel that may be better conveyed with something more like "Be sure to enumerate your reasons for appeal, as unfounded appeals may be rejected for consideration by committee members until reasons are given."

[iSazonov]

I think this can be removed altogether.

[joeyaiello]

We talked extensively about this clause. I recognize that it's a very pointy statement (and I may take some of your wording suggestions, @vexx32), but I think something like it ultimately needs to stay.

Historically, there have been folks who contribute to the project that are very verbose in expressing highly contrarian views. While it's been rarer, some have also struggled with having their views formally rejected by the Committee.

So the intent here is to say: WGs should not act in a manner or with principles contrary to how the project has historically been run. In other words, WGs should not be a vector to 180 on existing Committee decisions. Additionally, if you throw a veto every time you're told "no", and after sound reasoning from WGs, we're going to stop reviewing your vetos.

[vexx32]

Yeah, I've seen enough to know that can happen from time to time. I do still think this current wording is a bit prone to being misread, but I agree that something along these lines probably needs to be mentioned here. 👍

[joeyaiello]

I want to rework this, but given the amount of discussion we had on it the past, I want to seek input from @JamesWTruher and others first.

[joeyaiello]

After some discussion with the @PowerShell/powershell-committee, we decided to borrow your language as it was a bit softer. :)

[iSazonov]

While we discuss the community process I want say about PowerShell Committee. It does not still contain a community members. I want nominate @mklement0 (if he agree) who have already done a tremendous work of analyzing PowerShell and continue to do so. I think this is a great candidate.

[joeyaiello]

While we discuss the community process I want say about PowerShell Committee. It does not still contain a community members. I want nominate @mklement0 (if he agree) who have already done a tremendous work of analyzing PowerShell and continue to do so. I think this is a great candidate.

Without commenting on any individual in particular, I'd ultimately still love to take external folks into the Committee. It was difficult for us given the sheer breadth of knowledge required, which was part of the motivation for creating WGs in the first place: to sub-divide and reduce the expertise needed to contribute to the project in a meaningful way.

Without committing to anything, I personally expect for WGs to eventually act as a pipeline into the Committee.

[SteveL-MSFT]

Should we make clear that contributors don't have to be members of a WG to participate in a WG area, but WG members are empowered to make approval and rejection decisions

[andyleejordan]

I second this.

[joeyaiello]

This seems out of scope for this document, better handled in https://github.com/PowerShell/PowerShell/blob/master/.github/CONTRIBUTING.md.

Happy to merge a suggestion here though if you feel it fits cleanly somewhere.

[daxian-dbw]

@joeyaiello I think we should have @iSazonov included in some of the WGs. He is a maintainer and, more importantly, he has been doing the WG work for the PowerShell repo for a long time already.

[daxian-dbw]

@iSazonov can you please comment on what WGs you'd like to be part of?

[iSazonov]

I think we don't need to mix maintenance and expertise.
Today I do really full pre-moderation all issues and PR so that MSFT team gets clean issues and clean code and tests in PRs.
For issues the pre-moderation is I set right area/WG label and adjust a level label (I usually use Issue-Question as an entry point because the automatically set label does not match the content of the request.)

I would be happy if the working groups did this work. :-)
If not. I can continue the pre-moderation leaving Needs-Triage label to the working groups.

Today I suggest to set Needs-Triage label to all open issues by a script.

[daxian-dbw]

You participated in a lot discussions in various issues/PRs and also did a lot work in many aspects of PowerShell already, so I don't doubt you have certain level of expertise in some areas of PowerShell that you feel comforatble with. But of course, it's not mandatory for mantianer to join any WGs, so it's totally up to you :)

The Needs-Triage label should have been applied to new in-coming issues since I have merged the updates to the issue template. Do you notice any new issue not marked with needs-triage label?

[iSazonov]

I don't mind participating in working groups if they include me.

Do you notice any new issue not marked with needs-triage label?

No, this works. I mean we could use a script and assign the label to all old issues - today it is not clear whether they was already triaged or no.

[ghost]

This pull request has been automatically marked as Review Needed because it has been there has not been any activity for 7 days.
Maintainer, please provide feedback and/or mark it as Waiting on Author

[andyleejordan]

Overall I am super pleased that PowerShell intends to setup Working Groups, as they're a proven method for collectively developing open-source software.

[andyleejordan]

I second this.

[andyleejordan]

Should we spell out how we believe this WG process will achieve these goals (and do we have a planned means to measure that)?

[andyleejordan]

@joeyaiello we should probably explicitly ask that this set of processes be re-reviewed, as being last in a long PR it seems to have been given the least attention (I say this guilty of it myself).

[joeyaiello]

Fair. To be honest, it probably received the least attention from my writing for the same reason.

I'll have some folks go over the verbiage tomorrow.

[joeyaiello]

Made a bunch of edits that I'd like to review with @PowerShell/powershell-committee tomorrow

[joeyaiello]

@PowerShell/powershell-committee reviewed this today with these final round of commits, and we're ready for @PowerShell/powershell-maintainers to merge this as our current process

[TravisEz13]

@joeyaiello Please fix the spelling issue.

[TravisEz13]

@joeyaiello Please remove WIP from the title if you are ready for review.

[joeyaiello]

@TravisEz13: this should be ready to review and merge now.

[ghost]

🎉v7.2.0-preview.7 has been released which incorporates this pull request.:tada:

Handy links:

• Release Notes