in reply to Perldocs and peer reviews

I agree that perldoc feedback is a good thing, but I'm not sure that a formal framework is necessary. If I find an error or some slight ambiguity in the documentation of a module, I email the author or put a bug report on the bug tracker. But if a module's documentation just stinks in the first place and shows little concern for the needs of users, it doesn't make me very hopeful that a documentation review is going to make any difference unless I'm actually sending a full patch for the pod.

(Maybe some authors hope that other people will like the module so much that they'll document it for him/her. That might explain the proliferation of real documentation showing up on wikis for several major frameworks. But I don't think that's very good practice if its intentional.)

-xdg

Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Replies are listed 'Best First'.
Re^2: Perldocs and peer reviews
by dragonchild (Archbishop) on Jan 31, 2005 at 13:54 UTC
    It's not intentional. When I wrote Excel::Template, I was writing it for an employer. I put it on CPAN to demonstrate ownership, but didn't have the time to document it. Later, and thankfully so, others have provided documentation questions and/or patches. Otherwise, I would always be waiting for those magical tuits to appear ...

    Being right, does not endow the right to be rude; politeness costs nothing.
    Being unknowing, is not the same as being stupid.
    Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
    Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.