Question re. Governance

[Jaykul]

I'm concerned that the current governance document is not being viewed as a set of rules, or a contract with the community, but merely as suggestions. It appears that the document is being regularly revised --without discussion via RFC-- and yet also routinely ignored.

I'm not just talking about minor problems, either, but about the big issues of governance like changes to:

• membership in the committee
• repository maintainers
• the governance process

In my reading of the document, I believed that all three of those would "require a written RFC and ample time for the community to respond with their feedback" -- in particular, "the addition of new PowerShell Committee Members or Repository Maintainers" is spelled out in black and white as always requiring this. Additionally, "changes to the process of maintaining the PowerShell repository (including the responsibilities of Committee Members, Repository Maintainers, and Area Experts)" are also spelled out as requiring RFCs and comment periods -- and I have assumed this obviously encompasses the governance document itself.

To be explicit:

One need only look at the commit history of the maintainers document or the governance document to see that these documents are regularly altered -- and new maintainers and new committee members are being added.

In fact, the maintainers document was changed last july to remove mention of RFCs as the mechanism for adding maintainers. Of course, immediately after that, new maintainers were added without fanfare or comment. The actual governance document still requires an RFC for such changes, but that's been ignored.

The same thing is happening with committee members, who have not only been added without an RFC, but as far as I can tell, without even a committee vote. As a side note: it's been disappointing to watch as each committee member who has left the PowerShell team has subsequently quit the committee -- even when they are still active maintainers of projects.

I understand that the need for transparency and following your documented change processes is a new constraint -- but this needs to be addressed and remedied ASAP if you want to maintain the faith of the community.

Additionally, I would propose that

1. Committee meeting minutes (or recordings) need to be published
2. Those meetings should be held electronically, since it currently appears it's not possible for "community members" to actually be a part of the committee

[kilasuit]

I 100% agree with @Jaykul in that the actions here seem a little averse to being truly transparent, even if accidental in nature.

Take as an example the committee notes that concern the following PR PowerShell/PowerShell#4311 that inevitably changed the mention of RFC's aren't currently (as far as I am aware) available to be seen publicly, this leads to the prior Black box scenario where the community aren't able to see all the decision points that lead to the point where we are currently, that and the @PowerShell/powershell-committee tag shows as private in PowerShell/PowerShell#6323 - this could be easily just be a simple Github settings issue but even this little thing could be perceived as being less than fully transparent in nature,

One thing that I expected to see with the open sourcing of PowerShell was that the community of experts, which you've dubbed Area Experts would have a much more triage focused role as it was written up, which I suppose I expected that this grouping would have been more closely aligned to the including many of the MVP's as they'd always been the gap between Microsoft and the real world, something that I feel has become a bit jaded over time.

Whilst I can also understand that there's been some of movement in the members of the team over the course of the open source lifetime of PowerShell, including members leaving not just the PowerShell team but also leaving Microsoft, which adds some further internal & external complexity to managing the project. There have also been some "lessons learnt" along the way, including what works and what doesn't, which includes the RFC process and whether the process helps or hinders the actual main goals of the and whilst I could echo pretty much everything that Joel has said above, I don't think that this something that can't be pulled back and gotten control under the details mentioned in the Governance Document.

But in all, sharing Committee notes, Enforcing the Governance Processes, ensuring that it's as open and transparent as possible AND expanding roles to the community would be good points to take to the next committee meeting 😉

[Jaykul]

Please, file an RFC ...

[vexx32]

@SteveL-MSFT @joeyaiello

I'm in agreement with many of @Jaykul's comments here. The RFC process seems to have a few holes that need patching up. The governance processes outlined on the PowerShell repository proper are not being followed as they seem to have been intended.

I am sure there were no ill-intentioned changes, but I'm not sure it's feasible to let it by the wayside. At the very least, the documents detailing the processes need to be updated to reflect the actual policy, since it seems fairly evident that the process may be too cumbersome for constant use and could use some revising.

And, ultimately, it appears many portions of this RFC repo are being left in the dust. There are some documents that have gone through the process as expected in recent weeks, which is great! But for those that do not, for whatever reason (whether it be due to lack of time on the author's part, lack of interest by the community, etc.) should probably be relegated to a Rejected or Abandoned folder as necessary. Leaving them in the Draft stage for months or years on end seems to be a bit of a hindrance for new RFCs, if anything at all.

Perhaps the RFC repo needs a bot to keep track of RFCs and their linked issues (perhaps mandate that RFCs link to their relevant issues as part of that) and be flagged by the bot as Stale similar to how PRs are in the main PowerShell repo and eventually moved to an Abandoned folder or other appropriate location to leave room for new ideas and continued growth and change?

It doesn't seem right for things to sit here for months and years on end with no clear resolution. 🙂

Perhaps a topic the Committee ought to consider and take a vote on?

[SteveL-MSFT]

We've discussed revisiting the process as well as putting more resources on reviewing RFCs and helping to move them along. However, other urgencies tend to come up. Will discuss this with @PowerShell/powershell-committee next week.

[joeyaiello]

We think we've been slowly addressing this over the course of the last few months with the addition of a weekly 1.5 hour meeting for us to make progress on RFCs (from which I'm typing right now). We know it's still an uphill battle, but we'll continue to set "plan to implement" RFCs (where the author plans to do the code work to make it happen) as a higher priority.