This should also state this will become a requirement on specified date. We need to have a date in mind for that.

I'm thinking Q1 2016.

WebClient / HttpRequest... Invoke-WebRequest / iwr

Will become required later (put the date into suggestion)

https://github.com/chocolatey/choco/wiki/HelpersReference

These are taken in part from here:

https://github.com/chocolatey/choco/wiki/Moderation

The following is a list of rules that need to be added, and these will be updated as they are implemented. New rules can be added here as they are thought of.

Requirements

• Copyright Word Count Minimum
• Description
• Install Automation Script Named Correctly
• License Url Missing When License Acceptance True
• Package Internal Files Are Not Packaged
• Portable Package Scripts Do Not Use Program Files
• Project Url
• Scripts Do Not Contain Choco Commands
• Scripts Do Not Contain Internal Variables
• Source Control Internal Files Are Not Packaged
• Tags Are Spaced Separated
• Tags Do Not Contain Chocolatey
• Uninstall Automation Script Named Correctly
• Install and Uninstall Scripts work with PowerShell V2, see #1
• Templated Comments have been removed
• UTF-8 Encoding is being used
• Correct BOM at start of file - NOTE - not a fan of this one, we actually want this to be UTF-8 w/out BOM

Guidelines

• Description Word Count Minimum 30
• License Url Does Not Match Project Url
• License Url Missing
• Package Source Url Missing
• Project source Url Does Not Match Project Url
• Project Source Url Missing
• Summary Not Empty
• Tags Not Empty
• Title Not Empty
• Title Not Same As Package Id
• Does the download include both x86 and x64 urls if available? - see #17
• Icon Url Missing
• Release Notes Not Empty
• Write-ChocolateySuccess / Write-ChocolateyFailure
• request admin tag if it calls Install-ChocolateyPackage (or uses another admin script)

Suggestions

• Bug Tracker Url Missing
• Docs Url Missing
• Mailing List Url Missing
• With Get-BinRoot, ask if the user should move to a simpler approach

Notes

• Binaries are included
• Package Id Uses Dots
• Author Field Is Not Used For Maintainer

Things that require more thought

• check package name - flag if first version based on the naming convention (doesn't matter if prerelease or not)
• suggest the name split if over 25 chars with no -
• flag on "."" in name (unless .portable/.install)

Things that can't be automated - These have now been covered in the moderation instructions https://github.com/chocolatey/choco/wiki/Moderation

• Verify description contains Trial information, when required
• Trial software should include #trial tag
• Licensed software should include #license
• Does the download version match the package version?
• Does the package try to do anything that an existing Chocolatey function already covers? The maintainers would need a really good reason for diverging from that.
• Not a package duplicating another existing package

Implements https://github.com/chocolatey/chocolatey.org/issues/181

Nothing should have a need to copy to program files without a really good reason. The native installer should make the changes required.

However if someone is just deciding that is where their portable application goes, that is an anti-pattern.

When a rule that requires more explanation fails, we can point to it to give folks more information on why it failed, what's wrong with what they are doing and how they can fix it up.

I'd like this for first release as well, I think it will help if folks have a place to go to understand why certain things are flagged and why they are required to be changed. That means it is less likely that they will use the contact administrators.

And as we expand on things, information for folks is automatically updated without requiring a new release of the validator.

Suggest using package parameters instead.

Had a package once that removed install args and put them back once it was done.

https://chocolatey.org/packages/ServiceControl.install/1.6.3.20151029

Or the boundary is not strict enough.

The version dependency from a meta package should be either exact "[version]" or bounded based on the version of the meta package, e.g. 1.2.0 ~= "[1.2.0, 1.21)" - it allows for fixes up to the next version.

To ensure correct result. Use mocked IPackage to return some dependencies, and ensure Chocolatey isn't one of them.

We need to followup to see what the user is attempting to do.

$url64 = $url is a good check.

If a user has implemented at least one of these, then they probably know about all of them. No reason for there to be 3 checks.

• docsUrl
• mailingListUrl
• bugTrackerUrl

Maybe also include projectSourceUrl in this one check. packageSourceUrl is a guideline so it should continue to remain separate.

[Deprecated]ServiceControl.install

http://stackoverflow.com/questions/10812843/is-there-a-way-of-validating-a-powershell-script
https://msdn.microsoft.com/en-us/library/system.management.automation.psparser%28v=vs.85%29.aspx?f=255&MSPPError=-2147217396

To do this, one must download the icon first.

I’ve noticed that almost all of the wiki pages are empty stubs at this point. I also noticed that editing for the package validator wiki is disabled. Is it possible to set up a separate wiki repo like this one? If one is set up, I might be interested in supplying some preliminary documentation for the validator messages. Thanks!

Note this will become a requirement

I'm less concerned about the opposite.

Too much logic in packages is not a good thing.

https://chocolatey.org/packages/sbt/0.13.9

And note that the package should be added to test exempted status if it hasn't already been.

https://github.com/chocolatey/choco/wiki/CreatePackages#package-icon-guidelines

Usually related to creating shortcuts directly instead of using the helper.

i.e. don't lead to a 404.

Unless a package needs a specific version of Chocolatey in order to function, a dependency on the Chocolatey Package is not required.

Add this as a note so that a human can verify.

Follow up from: #55

Point them to this gist as an alternative - https://gist.github.com/ferventcoder/c593d222b07d4f95b388