my notes from the review at PTS 2018 Oslo

[karenetheridge]

in prereqs:

• do not list EUMM as a build prereq
• do not list Test::* as a runtime prereq
• Test::Prereq is a helpful developer tool, but do not ship this test!
• do not put author tests (pod syntax, perl critic, spelling etc) in t/: keep them in xt/. and do not add their prereqs to the metadata.

legal: the perl/perl_5 licence is a reasonable default if you don't have a preferred licence.

multiple perl versions: travis can help with this - I'm not sure if we have a good document for perl travis testing yet but we ought to.

META: people shouldn't be editing their META.* by hand: this is generated by authoring tools (either EUMM directly, or Dist::Zilla, App::ModuleBuildTiny etc). should link to the document(s) that describe how to declare metadata using those tools.

Changelog:

• "Changes" is the preferred filename
• every release should have an entry
• put most recent release first (therefore, sort in descending order by date/version)

as discussed in the meeting (2018-04-21, PTS 2018 Oslo):

• some of this is in the Berlin Consensus (https://github.com/Perl-Toolchain-Gang/toolchain-site/blob/master/berlin-consensus.md#recommended-practices-for-cpan-authors) -- we could explain in more detail what some of these points need
• the really basic stuff should be in perlnewmod.pod - link to that
• put a section at the top listing the things that are most important for beginners to pay attention to (metadata, declaring prereqs, Changes file, licence..)
• include directory trees containing templates for basic distributions using each of the major authoring tools (bare EUMM, Minilla, App::ModuleBuildTiny, Dist::Zilla, ...) -- or if this is already available in Module::Starter, link to that (okay this should be in perlnewmod instead)
• Test::Kwalitee exists, but https://cpants.cpanauthors.org/ has many more metrics, and lots of documentation about these best practices
• CPANTS as a service would be awesome - to upload works in progress to get critique

[exodist]

I will point out that Test:: can go into the regular prereq's if the dist is itself a testing module and therefore does require Test:: at run-time. The wording above implies there is no correct time ot put Test:: modules into prereqs.

[Tux]

I've merged most of that now. Sorry for the huge delay. I do not think template folders are appropriate, but I'll take PR's :)