These fails do affect your Kwalitee scores. This distribution may not be installed cleanly, or may have some issues in license or documentation. Please consider fixing them, or tell us if they are false.
|metayml conforms to known spec||
META.yml does not conform to any recognised META.yml Spec.
Take a look at the META.yml Spec at http://module-build.sourceforge.net/META-spec-v1.4.html (for version 1.4) or http://search.cpan.org/perldoc?CPAN::Meta::Spec (for version 2), and change your META.yml accordingly.
The file "README" is missing from this distribution. The README provides some basic information to users prior to downloading and unpacking the distribution.
Add a README to the distribution. It should contain a quick description of your module and how to install it.
|no mymeta files||
This distribution contains MYMETA.* files which should be used only locally. This metric should be integrated into 'no_generated_files' eventually, but as MYMETA.* files are recent inventions, you might need to take special care if MANIFEST.SKIP exists in your distribution. Hence this metric.
Update MANIFEST.SKIP to exclude MYMETA files. If you are lazy, add "#!install_default" in your MANIFEST.SKIP and update your ExtUtils::Manifest if necessary, then some of the most common files will be excluded.
|no broken module install||
This distribution uses an obsolete version of Module::Install. Versions of Module::Install prior to 0.61 might not work on some systems at all. Additionally if your Makefile.PL uses the 'auto_install()' feature, you need at least version 0.64. Also, 1.04 is known to be broken.
Upgrade the bundled version of Module::Install to the most current release. Alternatively, you can switch to another build system / installer that does not suffer from this problem. (ExtUtils::MakeMaker, Module::Build both of which have their own set of problems.)
|has license in source file||
Does not have license information in any of its source files
Add =head1 LICENSE and the text of the license to the main module in your code.
This distribution does not 'use strict;' (or its equivalents) in all of its modules. Note that this is not about the actual strictness of the modules. It's bad if nobody can tell whether the modules are strictly written or not, without reading the source code of your favorite clever module that actually enforces strictness. In other words, it's bad if someone feels the need to add 'use strict' to your modules.
Add 'use strict' (or its equivalents) to all modules, or convince us that your favorite module is well-known enough and people can easily see the modules are strictly written.
|no pod errors||
The documentation for this distribution contains syntactic errors in its POD. Note that this metric tests all .pl, .pm and .pod files, even if they are in t/. See 'pod_message' in the dist error view for more info.
Remove the POD errors. You can check for POD errors automatically by including Test::Pod to your test suite.
This dist failed its Module::Signature verification and does not to install automatically through the CPAN client if Module::Signature is installed. Note: unsigned dists will automatically pass this kwalitee check.
Sign the dist as the last step before creating the archive. Take care not to modify/regenerate dist meta files or the manifest.
These fails affect your total Kwalitee score, but don't affect the one for the Game. Some of them should be fixed by all means. Others are just matters of taste.
There is more than one .pm file in the base dir, or the .pm files are not in lib/ directory.
Move your *.pm files in a directory named 'lib'. The directory structure should look like 'lib/Your/Module.pm' for a module named 'Your::Module'.
|has known license in source file||
Does not have license information in any of its source files, or the information is not recognized by Software::License
Add =head1 LICENSE and/or the proper text of the well-known license to the main module in your code.
This distribution does not 'use warnings;' (or its equivalents) in all of its modules. Note that this is not about that your modules actually warn when something bad happens. It's bad if nobody can tell if a module warns or not, without reading the source code of your favorite module that actually enforces warnings. In other words, it's bad if someone feels the need to add 'use warnings' to your modules.
Add 'use warnings' (or its equivalents) to all modules (this will require perl > 5.6), or convince us that your favorite module is well-known enough and people can easily see the modules warn when something bad happens.
These fails are not serious and don't affect your Kwalitee scores at all.
|metayml has provides||
This distribution does not have a list of provided modules defined in META.yml.
Add all modules contained in this distribution to the META.yml field 'provides'. Module::Build does this automatically for you.