PowerShell / PowerShell/PSScriptAnalyzer
Help generate a report card for modules
還沒有人認領這個 Issue。
- 主要語言
- C#
- 星號
- 2.2k
- 分支
- 414
- 平均合併
- 13 小時 1 分鐘
- 30 天內合併 PR
- 2
描述
I wasn't quite sure where to post this suggestion, but since I feel the work starts with PSScriptAnalyzer I decided to post it here.
The quality of many modules published into the PowerShell Gallery is quite poor, including modules coming from teams inside of Microsoft (not to point fingers, but cough Azure *cough). There are plenty of community modules that are of poor quality also, and scripts published into the Gallery will no doubt follow suit.
PSScriptAnalyzer is being used on publish to notify authors about issues, but authors can choose to simply ignore the issues and every user who discovers a module in the Gallery has to review it themselves. The review step is necessary, and I don't think that should go away, but I think that review should be focused on security and technical issues, not module design issues that can be corrected automatically. We were chatting on Twitter about having moderators in the mix, but really moderation should be about serious technical problems that can have adverse side effects on infrastructure, not about pluralized nouns, lack of documentation, or many other issues that can be automatically detected. PSScriptAnalyzer should be used as a tool to not only identify issues for script/module authors, but to identify issues to end users looking at community content. Helping authors is necessary, but helping end users is even more necessary so that they can identify the cruft more easily. I'm thinking a report card of sorts, for script files and for modules, that ranks them according to how well they pass (or fail) tests. Authors should be able to pragma-out rules that are actually inaccurate for their work, but such a tool would be highly useful for the community, and I think it would give authors much more incentive to do it right the first time.
Case in point: AzureAD was just added to the Gallery very recently, and it is just full of design problems that can be identified by anyone with a bit of PowerShell experience in a matter of a few minutes. The issues are egregious enough that several MVPs feel they should never have released the module in this state, and since it's release and the issues have been raised via numerous channels trying to get their attention, it appears that the authors are summarily ignoring the feedback and the requests to pull the module until its design issues are fixed, before there are many dependencies on the bad design issues. This is one prime example of a module from a very influential and highly visible group that influences the PowerShell Community in a shockingly bad direction.
Having a report card sent back to the author when the module is published and shared on the PowerShell Gallery would go much further towards keeping problem modules like this in line, I think. You could even have the PowerShellGallery refuse to publish modules that fall below a certain grade, so that people wanting to share their content are forced to learn how to do it the right way. Then, after all of that is in place, moderators and/or the community could also review a module for other issues that are less obvious, provide feedback into PSScriptAnalyzer for things that could/should be auto-detected that are being missed, contacting module authors about general technical issues, and providing feedback to the Gallery administrators for other more serious problems that may warrant a module being unlisted for one reason or another.
I would love PSScriptAnalyzer to get to this point (maybe with the help of the OneGet team because this directly impacts them) so that I wouldn't feel like getting module authors to follow best practices is such a hopeless task. That seems to be the only way to get certain people to raise the quality of PowerShell product that they produce, inside Microsoft and out.
貢獻指南
從這裡開始
- 先讀完整個 Issue,再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫,在一個分支上完成修改。
- 送出 Pull Request,並在描述裡引用這個 Issue 編號。
研究方向
沒有指定檔案、測試或進入點。首先將提案拆分為報告卡產生和發佈至 PowerShell Gallery 兩個面向,然後確認專案邊界以及所需的維護者決策。只有就模組評分以及結果的呈現或強制執行達成範圍和設計共識,才算完成。
由索引模型根據 Issue 內容生成。
評估
- 技術堆疊
- powershell
- 領域
- release, tooling
- Issue 類型
- 功能
- 難度
- 5/5
- 預估耗時
- 一週以上
- 活躍度
- 停滯
- 描述清晰度
- 需要釐清
- 新手友好度
- 15/100