PowerShell / PowerShell/PSScriptAnalyzer
Help generate a report card for modules
まだ誰も着手していません。
- 主要言語
- C#
- スター
- 2.2k
- フォーク
- 415
- 平均マージ
- 13時間 1分
- マージ済み PR(30日)
- 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 にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
ファイル、テスト、エントリーポイントは指定されていません。まず提案を、レポートカードの生成と PowerShell Gallery への公開に関する検討事項に分け、次にプロジェクトの境界と必要なメンテナーの判断を特定してください。モジュールのスコアリングと、結果の提示または適用に関するスコープと設計について合意できれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- powershell
- 領域
- release, tooling
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- 説明が足りない
- 初心者へのやさしさ
- 15/100