in reply to Private module organisation

Smoothhound, you potentially have a big task on your hands.

Version Control

If you are not using a version control system, start using one. Check in the current version of all modules, and use this for progress. Even if you are working solo, it's still worth doing.

use strict and warnings

If this were me, I would start with a review of code quality in general. Do the modules use strict and warnings? If the answer is no, this would provide a starting point. Aim to get all the modules passing strict and not emitting warnings. See Thoughts on revisiting old code for my musings on this subject.

Review module interfaces

This may be a question of looking at documentation rather than code. In the worst case, there may be no documentation, not even comments in the code; if this is the case, write a POD section for each module describing its interface.

Module deployment

Just because a module is not going onto CPAN is no reason not to follow the standard guidelines for delivering a module. Most of the modules you are looking at were probably not generated with h2xs and friends (ExtUtils::ModuleMaker, Module::Starter). Make kits for each module or collection of modules.

Module tests

The CPAN style install mechanism has a provision for including unit tests. Write a suite of tests for each module kit.

--
I'm Not Just Another Perl Hacker