lisandi
commented
3 years ago Very good suggestions
Some themes/plugins use i.e. "No License - All Rights Reserved" and those get listed in the plugin list in the backend. Installing such a theme or plugin could cause serious legal issues!
Some plugins have an empty repository as listed here
A Readme with only the title but without any description is useless. So I would test that it contains at least a description or 50 + signs "The Plugin is Doing this and That for That purpose" In many plugins, the folder "languages are missing and they have not added the translation labels accordingly - This belongs in the Contribution Guidelines actually
i.e. Add a Plugin Name that describes its purpose Add a Description to your plugin of at least 50 letters. Add a "locales" folder and the language file "en.json" or one of your mother tongue "...json" Add a "static" folder with subfolders for i.e. css, html, js Add a "templates" folder i.e. ep_workspaces has only a static folder and all template files are in "static" Add a LICENSE.MD file (as that could then be parsed) similar to the pop-ups you have in WP Backend for Plugins Add a README.MD file (also that info could be shown in a modal popup)
JohnMcLear
Things Etherpad admins might care about when deciding on a plugin:
checkPlugins.jschecks these things, we could bastardize/port that logic and let admins know about these things in the future.The issue of course is that we need to download the plugin to check some things, alternatively we find a way to push this information to travis log output and we just review that. Although this does make travis a hard requirement for some checks.
Perhaps
parse npm result > has github repo? > try readme location in github repo. try .travis location in github repo. try i18n location in github repo.
But this assumes that the repo is the same as the npm version published.... I actually expect npm will offer this functionality soon to public (it's already available for private / commercial repos) so we could just time it around that 👍