While I generally agree with your post and criteria, there's one that most certainly isn't right:
Looking at the version number is not going to help much. You have to factor in the complexity of the module you're looking at, the experience of the author, etc. Similarly, just because there hasn't been a release in a year, the module isn't necessarily broken. It may just be stable and proven (and I don't mean "biologically stable").
Let me suggest a modified metric:
- Take a very close look at the release history and request tracker of the module as well as the release history of its maintainer.
- Has the maintainer uploaded any distributions (of this module or another) to CPAN within the past six months? If not, he may be unavailable to fix bugs you might find.
- Does the author/maintainer typically do many releases of a module or just one or two? Specifically if you're looking at something really ingenious or complicated, there must have been bugs to start with. The quality of maintenance is naturally related to how long it kept the attention of the author.
- How much time passed on average between a bug report in the request tracker and a reply from the maintainer?
- If you have questions, check the module documentation for contact info. Only if no explicit contact information can be found in the documentation should you try the mail address of the maintainer's search.cpan.org address.
Do not underestimate the last point. The average quality of support requests for PAR that goes to the mailing list is better than that of those which end up in my inbox regularly. Why? The former at least glanced at the docs. So for many authors, this may be a red herring and you start out on the wrong foot.
Cheers,
Steffen
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.