+ first contribution + 1000
+ moodle partner + 1000
+ app support + 500
+ gdpr support + 500
+ amount of databases supported * 100
+ amount of supported active Moodle versions * 100
+ amount of badges in plugins database * 10
+ amount of badges in Moodle.org * 100
+ current php versions supported * 10
+ phpunit coverage * 10
+ behat steps * 10
+ phpcbf steps * 10
+ days waiting to get approved
- non documented functions * 10
- phpmd errors * 10
- phpmd violations
- codesniffer errors * 10
- codesniffer warnings
- mustache lint warnings
- grunt errors * 50
- grunt warnings
- phpunit warnings
- phpunit errors * 50
- behat warnings
- behat errors * 50
- Accessibility errors * 50
- XMLDB errors * 500
= total
This calculation produces a first step to produce a more objective method to handle the plugins queue:
Total > XXXXX => semi authomatic approval within a week
YYYY < Total < XXXXX => plugin needs some work and needs review
ZZZZ < Total < YYYYY => plugin needs a lot of work before it can be reviewed
Total < YYYYY => do not bother to review
Total < ZZZZZ => do not bother to review
And perhaps the missing things could directly point the developer to the dedicated parts of the documentation so that he can improve the plugin.
Séverin
I have seen some good suggestions by others in this discussion and would like to add a few ideas:
1. Give developers the power to bump their plugin up in the approval queue. Automated testing should be the first level of approval process. The system already does automated pre-check testing and priority could be given to plugins with the lowest number of total issues, with security issues being a complete show stopper regardless of the number of other issues.
This would give developers the power to move their plugin up in the approval process queue while encouraging them to increases the quality of their plugin. Top priority goes to those with zero pre-check issues.
2. Wiki of pre-check issues and solutions: it would be very helpful to have a repository of knowledge on how to interpret the pre-check reports and what to do about reported issues. There are often cryptic errors and warnings that lots of people get but nobody knows how to fix. So, it becomes nearly impossible to fix the issue, especially for new developers. While one could write a course on this topic alone, a repository of knowledge that people could contribute to would be quite valuable. A link to this should be displayed at the top of every pre-check report. Either that or improve the clarity of messages - but that might not be as easy since they are often 3rd party tools.
3. Display place in approval queue: This has already been suggested this and I completely agree. This is extremely important to developers waiting for their plugin to be approved - to know that their plugin is moving up in the queue, not only over time but as they make efforts to improve their code as mentioned above.
4. Raise visibility: Plugins pending approval should be listed in the Plugins directory, but only for those who are already approved maintainers of other plugins. If a plugin seems potentially useful to them, they might be more inclined to do a review or maybe even fix issues and contribute pull requests back to the developer.
Of course unapproved plugins would need to be clearly marked in the listings and search results.
5. Make access to review process easier: It would be helpful if a link or button would be displayed in the unapproved plugin that would take potential reviewers to the approval process. The idea is to make it easier to get the approval process moving forward. Different parts of the check list could even be completed by a single or multiple people reducing the effort required by a single person.
6. Ratings and reviews: there is always the option of letting people rate plugins and submit reviews. In order to remain visible, a plugin would need to maintain a minimum public rating. Ratings would be specific to each release and start off with a neutral rating. A person could only submit one review per release but update their existing review. I haven't thought this idea through completely yet so it might need a little more thought on how to implement this fairly.
7. What is Good Enough: Something to consider is whether good enough to be publicly available means that it is secure and does what it says it does, or does it need to be coded and documented according to guidelines. It is really a balancing act. If you look at many of the plugins in the repository, you will notice that very few of them pass the pre-check. Many of the most popular ones have between dozens and hundreds of issues. What constitutes good enough?
8. New Premium Plugin Directory: I realize that implementing these ideas involves paying someone to do it. Funds for this could be raised by implementing a new directory of premium plugins and themes. Maintainers would subscribe and pay to have their premium plugin listed. This repository would not contain the plugin but rather just a link to where visitors could find more information and pay. Revenues from these listings could fund the development of the above-mentioned ideas and the resources to move plugins through the approval process. Personally, I think it would be great to see a complete list of most premium plugins in one place. They are currently hard to find unless you happen to trip across them. However, there are some great premium plugins for Moodle out there that most people don't know even exist.
In addition to the subscription fee, you could also make it a condition that each premium product also have a free version available that may have a reduced feature set. This would encourage premium developers to also contribute to the free directory thereby increasing the selection of free plugins. I believe that this could result in a scenario where everybody wins.
Hope you find these suggestions useful.
Best regards,
Michael Milette
