Lemmy bug: notification not given when a previously read msg is edited
Lemmy bug: notification not given when a previously read msg is edited
cross-posted from: https://lemmy.dbzer0.com/post/1702086
So Bob replies to Alice, who then reads the msg and marks it as read. Then Bob makes some significant changes to the msg like adding lots of useful information that further answers Alice’s question. Alice gets no notification that the reply was updated.
You're viewing a single thread.
Most discussion forums doesn’t do this; Reddit doesn’t do this; I don’t see why Lemmy should do this. Best practice is to post a new reply, and that’s kind of how things have been since pretty much early 2000s if not earlier.
Heh.. the funny irony here is that you actually missed my update to the OP, which says:
“For comparison, note that Mastodon (at least some versions) notify you upon edits of msgs that you were previously notified on.”
That’s of course a different scenario since crossposts don’t update (which could be a separate interesting discussion). But funny nonetheless because you missed an update while saying that tools should not be improved in favor of social / cultural change. I guess you should have thought to read the OP and compare it for changes (the social solution) :)
that’s kind of how things have been since pretty much early 2000s if not earlier.
We can dispense any sort of “conventional wisdom” in the course of moving forward with improvements.
Very specifically the comment that inspired my post was someone posting misinformation, then going back and adding a s̶t̶r̶i̶k̶e̶t̶h̶r̶o̶u̶g̶h̶ and highlighting their
correction in red text. No correction would be more readable than that. The problem with your proposal is that misinformation is left there persistently misinforming. That can then be taken out of context (e.g. someone screensnaps the misinfo & uses it against the author). There’s also the problem that readers often do not read a whole thread top to bottom. This is proven by the number of votes (up or down), which appear in high numbers on high comments and drop dramatically after ~3 or so replies. You might argue that the post can be deleted, but that then creates a problem of responses not having context. And it creates confusion as people wonder “didn’t person X say Y?”So let me get this straight… Bob does something no one else does — edit messages on somewhere no one else goes, adding significant content to something no one sees — and then Bob wants to spam the world about the update with notification? Why would the world care when everyone else expect Bob to post an actual update?
Also, in this context, this wouldn’t be a bug, but rather a feature request … a feature that no one is asking for, and doesn’t make the software better except to those that doesn’t follow social norms yet still demands to get into others’ inboxes.
Instead, the appropriate behaviour is to not allow Bob to make edits after sometime (which many softwares have such feature for), and/or make edit logs visible (also a common feature), such that people who doesn’t follow expected norms cannot create mass confusion by doing things no one else does, against the grains of expected norms.
So let me get this straight… Bob does something no one else does
Straight away you don’t have it straight. Edits happen. The mere possibility of edits in fact encourages authors to produce ½-baked drafts in the 1st place knowing that they can always edit.
edit messages on somewhere no one else goes, adding significant content to something no one sees
Not sure what drives this logic. If no one goes there, the post/comment is unlikely to happen in the 1st place. And with no interaction in the thread, refinements are even less likely. If you don’t have at least two people participating in a thread, there are no notifications to speak of.
and then Bob wants to spam the world about the update with notification?
Bob wants to take no action at all and let a smart system handle notifications as needed. So your attempt to “get this straight” got everything crooked. Furthermore, your proposed solution is moreso aligned with Bob pushing “spam”, as Bob’s new & separate msg forces a notification as the platform has no way of distinguishing an update from a new msg. Thus it would be treated like a new msg and a notice would be sent.
Also, in this context, this wouldn’t be a bug, but rather a feature request
One man’s bug is another man’s feature. Luckily bugs and feature requests are handled in the same venue so it’s a red herring.
a feature that no one is asking for
Certainly not true anymore.
and doesn’t make the software better
One man’s bug is another man’s feature.
except to those that doesn’t follow social norms yet still demands to get into others’ inboxes.
You’ve misunderstood where the demand is coming from. It’s not the author; it’s the recipient. Someone posted a useful reply to Alice, Alice read it, marked it as read, & then Bob made a useful update. Alice did not receive the notice of the update. This “demand” comes from the recipient (Alice), not Bob the author. The update was for the recipient’s benefit not the author’s. It’s purely incidental that Alice discovered that an update happened because #Lemmy was not smart enough to notify me of the update (unlike Mastodon which is quite a bit more mature).
Instead, the appropriate behaviour is to not allow Bob to make edits after sometime (which many softwares have such feature for)
That’d be fair enough, but it would not have helped in this case where the edit happened the same day.
and/or make edit logs visible (also a common feature)
You’re imposing too much manual labor on humans. Machines are here to work for us not the other way around.
such that people who doesn’t follow expected norms
The norms adapt to the software. When the software does an extra service for people, they abandon norms that attempt to compensate for a feature poor system. And rightly so.