A recent proposal showed that a majority support a feature that allows editing of posts. Here’s my suggestion for how this would work. I’m mainly opening this thread up for discussion of implementation, though, so everybody can kick ideas around and hopefully come up with something that we all like.
My suggestion is: There will be some kind of indication that a post has been edited, e.g. a string at the top or bottom of the post that says “Edited at ______” with a timestamp. This string will not appear if the post was edited a brief period of time after it was posted (say, 60 seconds). This allows users to clean up small typos and punctuation without being “penalized”.
Note: This discussion was imported from Loomio. Click here to view the original discussion.
If we’re defining parameters, I’d go with five minutes before displaying an 'Edited…" message. I’m not sure I could correct a typo or markdown formatting issue in sixty seconds.
Perhaps offer a small free-text-type box so the author can add a reason for the edit too.
I think it would be nice if there was a revision-system on posts. So you can annotate on comments what revision the post had when the comment was submitted. You could then browse the revision-history of the post if you need to look up some references (if they would have been edited out).
Beeing a quite complete and transparent implementation, I think it would be not as hard to implement in the federation (send an “new revision” update on a post when it is edited, as well as annotate the revision on comments when they are saved and sent).
It will however introduce new impacts on performance: more messages that will be federated and there will be a bigger post-table for the revisions (or use an extra table for all outdated revisions, so the normal post-lookup is not slowed down).
Also there might be problems when a comment arrives, referring to a revision of a post that has not even arrived at the pod where the comment just arrived.
Just a few thoughts…
I think that having revision history for comments is an interesting idea. The issue I have with it isn’t implementation, though…it’s privacy. Imagine that I read somebody’s post, get upset, and write an angry reply. Well, 5 or 10 minutes later I’ve cooled down a bit, and I decide to edit the post to make it less angry. The post now shows that I’ve edited it, and the material that I’ve deleted is still in the revision history! There’s nothing I can do to stop people from looking at the previous comment that I wanted to remove.
Another scenario is that I’ve posted some sensitive information. Maybe I didn’t even know that the information was sensitive when I posted it. Later, I re-think what I’ve posted, or I find out that I’ve divulged information that I shouldn’t have (The party’s supposed to be a surprise!), so I go back to edit…but the sensitive information is still there in the history, available to anybody who wants to do a little digging.
Now, sure, knowing this, I could just copy the message, make the changes, delete the original, and re-post…but that defeats the whole purpose of having an editing feature in the first place. Also, if you don’t know this, or you edit in a hurry and forget, it could come back to haunt you later. It doesn’t seem like the possible benefits outweigh the possible nuisances.
Should notifications also be sent after an edit?
So perhaps I Liked a post, I should be informed if that post has changed.
I don’t like the period thing, I think that the best choice is that we could edit the posts when we wanted.
@rich1, why not an option for that in the settings?
That what happens on Pump (or fb).
Hey Alberto. The time limit would only be to control whether the “Edited at…” would be displayed. You could edit it at any time you like, even years later. But if you edit it within say 5 minutes of posting, then no “Edited at…” message would be displayed.
I like the Loomio timestamp better. Instead of giving a date and time, it gives a length of time, like “30 minutes ago” or “2 hours ago”.
@brentbartlett I think the sensitive information scenario you mention is the reason why “edit” hasn’t been implemented so far – as I understand it, because of federation (which is “pull”), it is basically impossible to delete something efficiently. So the idea was that it would lull users into a false sense of security if they thought all they had to do was press “edit” and their sensitive information would disappear. In fact, all the other pods that their message had already been forwarded to would possess that sensitive information, and there may well be a significant lag before those pods realise they should delete it.
(Maybe someone more knowledgeable will correct me.)
To me, the primary reason people seem to want the edit function (and I keep seeing calls for it!) is to correct typos and such like. It’s a feature people have come to expect from a social network/comment system. I don’t think we need a revision-system for this, though I don’t see why not. But I think this task will be conceptually simpler if we see typo-correction as the reason we’re implementing this, rather than getting lost down the rabbit-hole of sensitive-information-hiding, which may well be impossible to solve securely.
On the amount of time before a timestamp (of whatever sort) gets attached, 5 minutes seems appropriate to me.
@alexb I think you make a very good point. Federation might make editing not quite as smooth as on other systems. I think that once all the kinks get worked out of federation, though, it will be just as smooth and error-free as any other social network.
For example, I have an account on diasp.org and JoinDiaspora. I make a comment on JD, and it pops up on diasp.org. Then, I delete it on JD, and it disappears from diasp.org. Edits would work the same way: I make a change on JD, and the comment changes on diasp.org.
Good point – if we offer post-deletion, then my explanation as to why we don’t offer post-editing doesn’t quite work.
I suppose my main point is that we should see this feature as offering aesthetic editing rather than privacy-preserving editing, because the latter can’t actually be offered properly (i.e. we’ll never be able to change the fact that “once the information is out there it’s out there”).
Implementing for aesthetic editing should be relatively straightforward, while it would be impossible to try to achieve the ability to recall information that has already been sent out.
In essence, I agree with your original proposal, with the 5-minute amendment, and I’m agnostic about revision-history.
For example, I have an account on diasp.org and JoinDiaspora. I make a comment on JD, and it pops up on diasp.org. Then, I delete it on JD, and it disappears from diasp.org.
This still doesn’t happen in many cases - both in posting and deletion. Also, comments sometimes don’t get federated on posts which have been federated. Until federation is far more reliable across all pods, there is no way to guarantee, or even to expect, that people on different pods will be seeing (and commenting on/liking) the same version of a post. Therefore time-stamping of edits is not a solution until federation is both instant and reliable.
I think that would be good too. Or a preview system as the original post. This allows to read before publishing.
BTW, the actual preview system for new posts is buggy. It sometimes doesn’t display the one being currently written but only highlights the most recent one in the flow.
I think we need more than a preview function – people just write, post, and then re-read their post. Even with a preview function available, typos etc still make it to the first actual post. I don’t think we do ourselves any good if we expect people to be ultra-careful – we have to build in some leeway for carelessness!
To me, a simple edit-post function, with some sort of timestamp after five minutes, would sort out this issue for a lot of people. As long as it is clear that we’re not guaranteeing that people on other pods will see the edits immediately, I don’t see the problem posed by the federation-induced lag.
This feature (as I see it) is just so that people can fix typos – not a grand motive, but something that I’ve seen asked for several times by newcomers. And something simple to achieve, I believe.
“Pas Faux” ! AlexB is right !
AlexB is on the right track.
There is something about re-reading your own “actually published” post that makes you notice errors you didn’t notice in a preview.
I always like systems that say something like “edit (for another 15 minutes)” and the number goes down dynamically. This gives you a nice clear indication that you still have a chance to change it before it goes “permanent”, and how much of a chance you actually have. I dunno that it needs to be 15 minutes, maybe 5 is fine. Either way, the tricky part is probably making sure that the post doesn’t propagate anywhere until the clock hits zero. But once it does it’s pretty obvious that you’ve now “put it out there” and there’s no going back. Which is, you know, the Internet.
+1 for AlexB
Maybe the pod can prevent publication during a short delay when you post (à la Gmail).
It avoids dealing with the federation and solve incrementaly the problem.
Then another increment would be “how to extend this with federation handling”.
But only if the users still complain a lot about edit.
Proposal: Pending post proposal
As a user,
When I post,
Then the post is not really posted, it is pending.
And it appears in my stream as if it was really posted but is editable
And a countdown indicate the remain pending time
As a user,
When I edit a pending post,
Then the client advertise the the pod of the edit so it is not posted for good during the edit,
And the pending time is reseted when I confirm my edit.
The default pending time 1min, adjustable in settings: 0s 10s 30s 1min 10min 30min
As a user,
When I click on the countdow of a pending post (or a sendnow button?),
Then the pendind is canceled and the post is posted for good
Note: This proposal was imported from Loomio. Vote details, some comments and metadata were not imported. Click here to view the proposal with all details on Loomio.
Lets say 3min? and remove the sendnow option.