I’ve been looking at CPAN distributions that have 10k+ downstream dependent distributions. There are currently just 45 such distributions:
http://neilb.org/2016/01/26/river-head-quality.html I think that in general these heavyweight dists should be good examples for people to look at. Sometimes there will be special reasons why they not following all best practices, no doubt, but in general I reckon they should. But before I start sending pull requests and blead patches for core modules, given I know that opinions on kwalitee vary, I figured I should raise the topic somewhere. For example, picking one module, base, I would look at: - adding license to the doc and dist metadata - adding min perl version - add a basic README - use warnings - add links to parent and superclass in SEE ALSO - changes mentions of fields and parent in first para to L<fields> and L<parent> - update doc to include discussion of RT#28580, and suggest it’s closed (https://rt.cpan.org/Public/Bug/Display.html?id=28580) - RT#98621 can be closed (https://rt.cpan.org/Public/Bug/Display.html?id=98621) - For RT#98360 see below - I’m not familiar enough with fields for RT#68763 (https://rt.cpan.org/Public/Bug/Display.html?id=68763) - Similarly for 28399 Is there an agreed policy for whether blead upstream modules should have the perl git repo in the dist metadata or not? Some do and some don’t. Personally it’s of questionable value, since I can’t submit a PR, but seeing the perl repo URL does at least tell me that it’s blead upstream. Neil