http://qs321.pair.com?node_id=593070

Surprisingly, this request is not prompted by any specific problem I encountered. It's more from my uneasiness with updating my own nodes seconds after I post them (yes, I do preview first. Fingers still much faster than brain.)

Suggestion: in the database, label every reply with an id/timestamp/version/whatever of its parent. When rendering out nodes, mark them as "this reply was to an earlier version of a post" if that id does not match the current id of the parent node.

The problem it addresses is when an author updates a node with replies such that the replies are invalid or don't make sense. This way, at least readers would be warned that they should think before assuming that the replier is an idiot, and perhaps wonder instead about the original poster.

I suppose you could also allow repliers to update their posts to "certify" them with the latest version of the parent node, thereby removing the warning label. Not that they need bother.

I have no idea what the performance implications of this might be, although it seems like the parent node is already getting retrieved at the very least to print out its title. I'm also not sure if the problem it is addressing is big enough to bother with. But it popped into my head, so I thought I'd mention it.

Update: I could have just changed the entire contents of node to "anybody who replies to this node is a poopy head."

But I didn't.

Replies are listed 'Best First'.
Re: Marking replies to updated nodes
by jdporter (Paladin) on Jan 05, 2007 at 07:00 UTC

    One succinct way to achieve what you want is to compare the 'lastedit' date/time field of the reply and its parent. Unfortunately, we're not using that field; in the current PerlMonks implementation, it is never altered from its initial setting. However, even if pmdev fix this, it will only be meaningful going forward; the thousands of old threads will continue to suffer from the problem you describe.

    A word spoken in Mind will reach its own level, in the objective world, by its own weight
      But that should not be a reason to don't do this, if you ask me. I mean, there are also still many nodes that are name-tagged, and no-one cares about that. It's a good and interesting idea...

      No, that says what revision of the node was in place when I finished my reply. It says much less about what revision of the parent node was in place when I started my reply (or, more accurately, what revision was in place when I loaded the page from which I later started my reply). And I can envision some members objecting if we started publishing how long it took them to reply, so I don't think publishing the start date would be an unmixed blessing.

      But I agree with others that the important thing is that people should not make non-trivial updates to their nodes without 1) making it obvious that an update took place, and 2) making it clear what (at least mostly) the node looked like before the update. It is also important that people be discouraged from making major updates to nodes at all. There are too many features that don't work well in the face of major updates so it is more important to discourage those than to publish details about how long (even just in terms of count of revisions to the parent node) it takes people to reply.

      This way, at least readers would be warned that they should think before assuming that the replier is an idiot

      I'd rather people think before assuming a replier is an idiot even if there has been no update made.

      - tye        

        No, not currently, because the lastedit field is never updated; it's always the same as the creation date/time.

        They should, especially if a change is implemented to keep lastedit up to date.

        Right on!

        A word spoken in Mind will reach its own level, in the objective world, by its own weight

        I don't know about everyone else, but I don't see much value in a "Most recent spelling and typo corrections in nodes" page.

        The site was built around the idea that new content goes into new nodes. Trying to change features of the site to work around ideas like "/msg me if someone updates a reply to one of my nodes" and "show me the most recently updated nodes" etc. just isn't going to scale. Most updates are currently (and should continue to be) quite minor updates, and as such should be of little interest to the majority of visitors. We could add a "this is a significant update" checkbox like we have for homenodes but the one we already have doesn't work well at all.

        So the better route is to continue to discourage major updates to nodes, that is, to encourage major updates to happen via a new node (or at least be accompanied by a new node).

        - tye        

Re: Marking replies to updated nodes
by g0n (Priest) on Jan 05, 2007 at 12:03 UTC
    On the relatively rare occasions that this happens, it's usually fairly obvious to the reader that it has happened.

    If the changes to the parent are drastic enough and mess up reply context badly, the original content of the node can be and sometimes is restored by the janitors.

    IMHO, the best thing to do is to probably to update your reply to the effect that the OP of the parent has changed their node, and if the changes are really drastic, consider for restoration of original content.

    Update: As wfsp just pointed out to me, these actions are dependent on noticing that changes have been made. FWIW I think the key point is that we as PM users shouldn't change nodes drastically without making it clear that changes have been made - perhaps with an "Update" marker like this one. That doesn't stop new users doing it, but gradually people get to know the conventions.

    (for my part, I consider this another reason to be light handed with the downvotes).

    --------------------------------------------------------------

    "If there is such a phenomenon as absolute evil, it consists in treating another human being as a thing."
    John Brunner, "The Shockwave Rider".

Re: Marking replies to updated nodes
by bassplayer (Monsignor) on Jan 05, 2007 at 16:09 UTC
    The problem it addresses is when an author updates a node with replies such that the replies are invalid or don't make sense. This way, at least readers would be warned that they should think before assuming that the replier is an idiot, and perhaps wonder instead about the original poster.
    One way to CYA is to include the text you are replying to in indented italics. This serves to document what you were commenting on. Could be annoying if overdone, but I thought I'd mention it here anyway.

    bassplayer

      Update: removed the actual quoting of the what bassplayer said about what g0n said, because it was far too silly.

      This idea could very quickly get out of controll, particularly for people who may end up with the whole thread in <blockquote> tags in each of their posts in an attempt to make it clear what exactly it was that they're commenting on.

      ...ofcourse, I'm fairly sure that nobody will take it beyond one level of quoting, unless they're being deliberately silly. (not that I'd know anything about that)

      Another option would be to track revisions of posts... and stash a rcs file in the database, and allow people to browse the patches to the node (and have the replies patch up/down to match the time).Even though the infrastructure would kill this, I thought I'd mention it here anyway.

      but then again, a commit message on a forum post may be just a tad over the top...

      Revision Controll is a serious thing to play with, and you really have to do all, or nothing...

      @_=qw; ask f00li5h to appear and remain for a moment of pretend better than a lifetime;;s;;@_[map hex,split'',B204316D8C2A4516DE];;y/05/os/&print;