First of all: does it give me a/the solution to the problem I have.
- It has a recent release
Depends on the reason. A proven well-behaving module might not need a regular release.
Way more important is a good ChangeLog with the release.
- The newest release passes all its tests
Depends on the coverage (sorry BrowserUK, this *does* matter). It is easy to make a module to pass all tests if there is only one test that tests nothing: ok (1, "Make it PASS!"); is a legal but useless test
I certainly prefer the release to pass all tests, but if the only FAIL'ing test is an ill-written test that depends on floating points being rounded to 12 digits instead of 32 on a system with long long long doubles, I do not really care. Likewise fir 1 nanosecond differences in speedtests.
- Its tests have good coverage
Yes, but with well-defined tests. It is not hard to write a test suite that covers all of the code, without testing its functionality.
- It is of high kwalitee
Prefered, as that shows that the author is aware of possible issues, but in the end it doesn't say a thing about the functionality, the usability or the correctness of the code.
- It has many MetaCPAN ++s
Depends if the ++'s are recent. ++'s on version 0.12 from 2001 are not useful at all if the current version is 2.34 from 2019.
And ++'s do not have to be for the part of the code I am interested in.
- There are no long-standing open bugs
Depends. If I am working on Linux and the open bugs only affect Windows or vice-versa, I do not care at all.
- It is pure perl (ie. no XS)
Preferably the other way around :) Most XS modules are way faster than the PP counterparts.
- It has no/few non-core dependencies
CORE deps are fine: they will be there. Period.
Non-core deps depend. There is no use in writing a DBD module without using DBI.
I *hate* authors depending on useless non-core modules (however useful for them) like Modern::Perl, sanity, and common::sense. Depending on those are a red flag to me.
- Many other modules use it
I agree here with BrowserUK: a useless metric if all those are from the same author. That would be an indication of reinventing a wheel.
- The author is prolific
That is a void option. Way more important is if the author is responsible and acts/reacts in a mannered way to bug reports and/or questions. Check (recent) issues and tickets for questions and answers to see if the level of support is meeting your needs.
- It is as generic as possible
Non-issue. Why would this be a reason to use/reject a module?
- The licence is acceptable (Artistic/GPL/BSD - delete as appropriate)
*I* don't care, as long as I am licensed top use it for free.
- It has good reviews*
Where? By whom? Do the reviews talk about the functionality I want to use or just about how well the GUI looks that I do not plan to use?
- It has extensive and clear documentation
Very important. It must be up-to-date, complete and easy to read (not full of typos or words that only someone with a native tongue will recognize).
- It is recommended by a Monk
That might help, though it of course depends on how well I trust that monk (agreeing with BrowserUK again).
- A well defined minimum version of perl (with a reason)
- A complete META file
- A location for tickets (RT/GitHub)
- A location for help (IRC/MailingList/GitHub)
- An examples section in the docs or an examples folder in the dist with easy to understand code chunks
- Consistent code style. At least in the documentation
- A README and/or INSTALL doc if make install is not enough
- Conforms to standards (when applicable)
Enjoy, Have FUN! H.Merijn