There doesn't seem to be anything specific to a "Perl Shop" on the list.
Perl specific maturity items would be:
1) Do all packages have documentation (pod) stored in the package file(s), and is it up to date?
2) Are there tests built using TAP (e.g. Test::More), and is this built into some kind of continuous build/test server?
3) Have a set of perlcritic rules been set up for the shop? Are these checked as part of code-review or scm check-in?
4) Is there a consistent set of rules for how external packages are brought into the current build? How are local changes to CPAN-originated packages handled?
These are the kinds of policies I'd expect to see implemented in a mature Perl Shop. The policies listed in the original post are those which I'd expect to see implemented in a mature software firm.
Specs (do you write down how stuff works? ... how to troubleshoot at 3 AM?) would be a good addition. It's a good list, though I don't see it becoming any more or less relevant when using Perl.
Do you solicit and attempt to meet your employees' workstyle preference? Specifically, can those who benefit from or require a quiet work environment get one? (This is not anti-collaboration; it is simply anti-noise and physical distraction.)
As an admittedly anecdotal perspective, the majority of the best developers I've worked with have expressed a strong desire for this -- even as and because we have struggled with cubification, shrinking cubes, and other management "best practices".
A side-product of this was finding/accessing them online in the evening, after they'd driven home, had dinner, and ensconced themselves to achieve some real focus.
Perl specific maturity items would be:
1) Do all packages have documentation (pod) stored in the package file(s), and is it up to date?
2) Are there tests built using TAP (e.g. Test::More), and is this built into some kind of continuous build/test server?
3) Have a set of perlcritic rules been set up for the shop? Are these checked as part of code-review or scm check-in?
4) Is there a consistent set of rules for how external packages are brought into the current build? How are local changes to CPAN-originated packages handled?
These are the kinds of policies I'd expect to see implemented in a mature Perl Shop. The policies listed in the original post are those which I'd expect to see implemented in a mature software firm.