in reply to PM Guide to editing nodes.

Personally, I don’t want to see the edits that were made to a post:   this is not a version-control system.   However, it should be stressed (and, it is ...) that a completed thread lives on as a source of future knowledge that will be re-discovered each time it is Super Searched.   Therefore, consider what the Gentle Reader™ will see at that time.   Try to leave the thread as informative as you reasonably can, for someone who will encounter it for the first time (and will be able to read it, start to finish), many years in the future.

For instance, don’t remove the original question ... even if you’re embarrassed by it now.   Instead, <strike>strike out the misleading or incorrect bits</strike>, and add a summary explanation.   When you discover/fix the problem, add a short summary post that’s more informative and useful than just “Sorry I fixed it thanks,” and consider also adding a short note to the original-post.

IMHO,™ even though a site like PerlMonks is “a mostly-fun substitute for The Water Cooler,” its real purpose and business-value is as an information archive, which today contains a rather vast number of posts.   Every thread adds to that knowledge-base.   Therefore:   “Please do your part.   Your Gentle Reader™ will someday thank you.”   (Even if you have (oops!) been smooshed by a bread-truck by that time . . .)

Replies are listed 'Best First'.
Re^2: PM Guide to editing nodes.
by Your Mother (Archbishop) on Mar 11, 2015 at 03:56 UTC

    I’m on the fence about this…

    I have given a lot of advice here I would not give today. I would not recommend Class::DBI, Path::Class, IO::All, Starman, or quite a few other things I have before. This is one of the reasons I find StackOverlfow generally odious in spite of its many otherwise merits; Vote to close: questions are answered and never shall they be revisited.

    Some advice I’ve given was good advice at one point but better exists now. Some advice I’ve given was because I didn’t know any better and no one realized or knew the need to step up to show better, so some of it stands as potentially authoritative in some degree.

    There are algorithmic and design discussions here that will be valid for years or decades. Many of the code answers are stale in a year and it’s a great strength of this site that so many monks are willing to entertain revisiting and refining even basic questions.

    And as far as edits: U WOT M8?! There is also nothing wrong with gracious edits that accept responsibility for poorly chosen words, technical or otherwise.

[reply]

      I have given a lot of advice here I would not give today.

      The other case is just as bad. That is, to go back and change the old posts. History is doomed to repeat itself; if you don't leave the posts there, someone else will "discover" the trick and give out the "new advice." Instead, i would reply to the old post, pointing to what has been learnt. Knowing what used to be thought of as good, and what was learnt over time is best for all.

      Well, except for people who look so quickly they don't read the rest of the thread. For them, an "override" post of some sort would be better. Strike-through does do that, but doesn't usually look that great and a quick reader may skip the message entirely. There are ways to finagle this idea, but posting a reply seems to be what most people do.

[reply]

        Well, I have actually fixed a couple in recent weeks but generally what you say is nonsense. You go back and give me edit notes on my 2,000+ nodes and I’ll gladly address anything particularly egregious that you find. This place is a journal of Perl more than a wiki. As I said, this broken attitude of time is a fixed point in relation to technical knowledge is part of why I find SO generally repugnant.

        If someone isn’t clever enough to realize that advice from 2005 is all but guaranteed to be out of date in the tech world, he has no business working in the tech world. If someone doesn’t think advice from two years ago might possibly be dated, he will lose jobs to those who are more cautious, ambitious, and curious.

[reply]

In Section Perl Monks Discussion