Help generate a report card for modules

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.

Aucun fichier, test ou point d’entrée n’est nommé. Commencez par diviser la proposition entre les aspects de génération de fiches d’évaluation et de publication dans PowerShell Gallery, puis identifiez les limites du projet et les décisions des mainteneurs nécessaires. La tâche serait terminée lorsqu’un périmètre et une conception convenus pour l’évaluation des modules ainsi que pour la présentation ou l’application du résultat seraient définis.