Comment Editing, with abuse mitigation model.
Short, concise description of the idea
Allow editing of comments in a fashion similar to editing of posts. Idea has been suggested previously. I provide some ideas on how to handle the problems that (I am told) resulted in its rejection.
Full description of the idea
The basics of editing are obvious -- you have a page that's identical in design to the comment posting page, but have it pull the info about the comment fom the DB, and then update the original record when the new version is submitted.
- Allows users to correct errors, whether minor typos, or factual issues.
- Eliminates the "delete and repost" phenomenon, in which a short comment with errors gets immediately removed and reposted, leading to a greater server load than a single update, and multiple emails to the replyed-to user.
- Allows small corrections or "ETA" (edited to add) bits, without creating a [deleted post] block and messing up the flow of a thread.
- Brings usage of comments in line with top-level posts, making a more consistent interface.
- Brings LJ's "bulletin board" design more in line with standards for other web bulletin boards such as UBB, phpBB, etc, all of which offer comment-editing.
An ordered list of problems/issues involved
- Abuse: Malicious users might edit comments to add in or remove offensive material, or try to conceal what they have said. I will note that on boards where editing is available, users quickly adopt the practice of quoting "troll" type material when replying to it, so as to prevent cowardly redaction. Additionally, if a journal owner starts receiving comments from an unknown user, you'd expect he'd take the time to go glance at them, and perhaps reply to some. Either he or his regular readers would notice pretty fast if the new user were abusive, and said user would get banned.
- Server load: The availability of editing might lead users who would otherwise have let an error stand to edit instead. But then, depending on what portion of users are already using the delete/repost method on a regular basis, server load might go DOWN, rather than up. This is hard to predict.
- Complexity: Adds an additional checkbox or two to the journal settings page. (Though perhaps the whole set of features relating to comments -- whether to allow them, how to screen them, IP-logging, editing -- could be consolidated into one block of the page in a way that would make this less confusing.)
An organized list, or a few short paragraphs detailing suggestions for implementation
- Permitting edits would be a checkbox in journal setup, probably disabled by default (similar to the "mutual friends" feature).
- If server load and abuse are serious concerns, one way to mitigate both of these issues would be to start by making the feature available only to paid users, who are a) a much smaller group (less load), b) probably more committed to the well-being of LJ (less abuse), and c) more "trackable" (and hence punishable in case of abuse) since a paid account isn't going to be an anonymous throwaway, used for messing with people. Unpaid users might be allowed to permit edits to comments on their posts, but only their paid-user friends would actually be able to use the feature.
- Obviously, only the person who posted a comment should be able to edit it, not the journalist whose post was replied to. A journal owner who dislikes what you have to say can delete or ban you; but he should not be able to put words in your mouth. For reasons that should be obvious, it would be impossible to edit an anonymous comment.
- In keeping with widespread standards, editing should cause a small block to be inserted either in the "header" (next to the username and icon, along with the original date/time stamp) or at the bottom of the post, reporting the date/time that the post was edited. If the journal owner has IP logging enabled, the IP address from which the post was edited should be logged, if different from the IP address from which the post was originally made.
- As a general rule, we expect edits to result only in very small changes to the text of the comment, so a new notification email should be unnecessary. One might consider enhancing the feature so that a new notification is sent if the edit is made more than (say) a full hour after the comment was originally posted. But this doesn't seem like a high-priority enhancement.