RFC Author(s): Martin Shwalbe, Pierre-Emmanuel Manteau
- When you are looking for a module, you might want to know abotu the quality of the module, and not choose randomly.
- If we ever reach a point where we have thousands of modules, and several of them doing the same thing, you might want to be able to compare them.
- As a module provider, we want to ensure a certain level of quality in the module provided, or at least information about this quality to be judged by users. It is necessary to be deemed reliable.
- Evaluating ones code is not always an easy task and might be very subjective at times depending on the one evaluating.
- We need to rely on a set of informations, among them :
- reactivity (speed of issue resolving, speed of PR treatment).
- user ratings (documentation, ease of installation, quality of support, module is working as expected), with 4 stars, one for each, or something like that.
- nb of downloads. (int)
- are there any unit tests? (yes / no)
- is there any documentation? (yes / no)
- nb of open/closed issues
- nb of waiting/merged Pull Requests
- ...
- We consider that it is not our role to compile all these information into one note, as some factors may be wrongly influenced. For example, is a stable module with no update for 6 months better than an "unstable" module with a lot of issues and PR, but which solves both at a fast pace? We believe it is up to the final user to make the decision what he/she deems better for his/her context.
- Providing a set of informations that helps a user decide seems to be a better option than a global blackbox ranking.
- In order to allow users to search by their own criteria, own order of importance, we will provide filters and indexes on information subsets.
- It MUST have a module.php file in the root folder
- It MUST have a licence.md
- It MUST have a readme.md
- It can provide additional information in the readme.md such as :
- @zf-version : 2.x
- ...
You can see a running(?) example here : http://zf-modules.bigbrowser.net