the only thing outside of the obvious would be perhaps to encourage the creation of a CPAN equivalent of a Tech Writer team;

About a decade ago I was part of a huge project that was responsible for overhauling, consolidating and unifying the IT systems of an entire country. 100,000 desktops and 5000+ servers across 23 different government depts.

As Senior System Architect for the server and desktop deployment; the single best decision I made was to bring a Technical Writer on board. With almost zero programming knowledge, but several years of taking programmers notes, comments and diagrams and turning them into properly structured documents; he paid for his not expensive salary every week in the time he saved the far more expensive programmers from expending their time trying to reprogram Word (the customers choice) to work like emacs or textpad or whatever other editor that particular programmer favored.

The second best decision was to give him the authority to demand full and timely answers from programmers, to any questions he had arising from their notes or code. That included me. Only by giving him the authority, to go with the responsibility we were all only to glad to pass to him, did we enable him to do the job we needed of him.

Programmers are nearly always too close to the code they write, to also do a good job of documenting it. Because they know the internal workings so well, they are apt to simply forget to mention stuff that is ingrained in their brains, but that will be completely opaque to users. On the other hand, they have the habit of going into excruciating detail about stuff that users simple have no need to know. However, you do need the input of someone with a seriously good knowledge of how to use the code. And that's where the non-programing technical author comes into his own.

By having them able to directly pick the brains of the programmers, but also stand apart from the code, they are able to act on behalf of the users to extract the salient information. And their authorship skills mean that they can structure the information in the way and form that the users need it; rather than the way the programmers prioritise it.

Finally, they need to be dogged, persistent, and thick-skinned. Programmers collectively have a tendency to prize their time above that of other people; and to be intolerant of those that don't get what they get. Tech.Auth is a tough gig, that requires a tough mindset in addition to all the other skills. The best ones are few and far between; but very worth seeking out and retaining.

All of that said, I do think there is some mileage in coming up with a template for module documentation. Not just a set of section names and keywords; but also a set of concrete suggestions and guidelines for what should appear in those sections.

Also, as unpopular a suggestion as it is likely to be, I happen to think that POD is just too limited and limiting to allow the creation of good documentation for complex (and even moderately complex) modules; much less frameworks and toolkits. IMO; html is far better suited to the task. People will probably point out that POD can be converted to html (amongst many other formats), but the only reason it can do that, is because it is the lowest common denominator amongst those other formats; and that makes it very limiting.