Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
Cpanratings does not even have the module author's right of reply. I have an issue with this with one of my modules, but I digress.

There is nothing to stop you from reviewing your own module if you want, merlyn did it. Personally, I am not so sure about that practice though.

Fortunately though, module reviews are editable by their original authors. I faced a similar issue as you when I got my first module review (see the bottom most one), and I decided to include information in the POD docs about why I felt my module was not redundant. The review author saw the update and changed his review and rating (course I am not sure if he ever actually used the module or not though).

As for changing Tutorials, and your extreme case:

My issue concerns updating reviews I have written in the past. An extreme hypothetical case is a module which I have written a review of X::Y praising it as the best thing since sliced bread. But I now want to replace it with a review saying that the module X::Y sucks and you should really be using X::Z instead
I think the easiest way to handle this is to simply write a new review for X::Z and provide a link from the old tutorial to the new one. If you feel really strongly then edit the tutorial and include a UPDATE at the top of it suggesting the user go to the new tutorial.

For the less extreme cases, where say the module has been updated and the tutorial is maybe giving outdated or wrong information, I think editing is perfectly acceptable. After all, what good is it if it is outdated? However, I would recommend that if the information you are removing still possibly has some value, copy and paste it into a child node of the tutorial and mark it as such.

While I like the 2D Wiki idea, it seems like an extreme solution for a relatively simple problem. I very much agree that editing comment nodes can be an annoying practice, and think your guidelines are good. I don't think those same guidelines need to apply to Tutorials. If what you edit out is possibly still valuable to someone, make sure it is still there (again, as a child node) or note it somehow, but I would really think Tutorials loose their value if they are not kept up to date.


In reply to Re: Maintaining module reviews by stvn
in thread Maintaining module reviews by rinceWind

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others lurking in the Monastery: (7)
As of 2023-12-06 17:09 GMT
Find Nodes?
    Voting Booth?
    What's your preferred 'use VERSION' for new CPAN modules in 2023?

    Results (31 votes). Check out past polls.