Flow/Editing comments

Background
Using the current talkpage interface, it is possible for users to edit the posts of others, up to and including interleaving. From a user experience point of view, this is irrational (and, frankly, insane): a discussion medium does not work without the certainty that the comment you are replying to is genuine, and that your comment will not itself be tweaked or corrupted by others. Accordingly, the argument is for Flow to not permit modification of posts, with the exception of a user trying to modify their own contribution.

The problem with this is that the community has developed various workflows in discussions and in the talk namespaces that are dependent on that kind of editing and interleaving: a list of examples can be found here, although it's not canonical. Removing the ability to edit the comments of others undermines these workflows. My task is to assess which of these workflows and examples are not handled by Flow itself, through a comparative analysis, and then look at occurrences of those that aren't (through hand-coding).

Use cases
A partial list of use cases can be found here, and is gratuitously copied across. If there are use-cases that aren't mentioned, please add them!


 * If you have their permission.
 * Collaborative text proposals
 * Personal talk page cleanup: On your own user talk page, you may archive threads at your discretion. Simply deleting others' comments on your talk page is permitted, but most editors prefer archiving. Many new users believe they can hide critical comments by deleting them. This is not true: Such comments can always be retrieved from the page history. Removal of a comment is taken as proof that the user has read it.
 * Removing prohibited material such as libel, personal details, or violations of copyright, living persons or banning policies.
 * Removing harmful posts, including personal attacks, trolling and vandalism. This generally does not extend to messages that are merely uncivil; deletions of simple invective are controversial.  Posts that may be considered disruptive in various ways are another borderline case and are usually best left as-is or archived.
 * Off-topic posts: If a discussion goes off-topic, the general practice is to hide it by using the templates collapse top and collapse bottom or similar templates. This normally stops the off-topic discussion, while allowing people to read it by pressing the "show" link. At times, it may make sense to move off-topic posts to a more appropriate talk page. It is still common to simply delete gibberish, rants about the article subject (as opposed to its treatment in the article) and test edits, as well as harmful or prohibited material as described above. Another form of refactoring is to move a thread of entirely personal commentary between two editors to the talk page of the editor who started the off-topic discussion. Your idea of what is off topic may be at variance with what others think is off topic; be sure to err on the side of caution.
 * Attributing unsigned comments: You are allowed to append attribution (which can be retrieved from the page history) to the end of someone's comment if they have failed to sign it.
 * Signature cleanup: If a signature violates the guidelines for signatures, or is an attempt to fake a signature, you may edit the signature to the standard form with correct information. Do not modify others' signatures for any other reason. If the user's signature has a coding error in it, you will need to contact the editor to fix this in their preferences.
 * Fixing format errors that render material difficult to read. In this case, restrict the edits to formatting changes only and preserve the content as much as possible. Examples include fixing indentation levels, removing bullets from discussions that are not consensus polls or requests for comment (RfC), fixing list markup, using o and other technical markup to fix code samples, and providing wikilinks if it helps in better navigation.
 * Fixing layout errors: This could include moving a new comment from the top of a page to the bottom, adding a header to a comment not having one, repairing accidental damage by one party to another's comments, correcting unclosed markup tags that mess up the entire page's formatting, accurately replacing HTML table code with a wikitable, etc.
 * Sectioning: If a thread has developed new subjects, it may be desirable to split it into separate discussions with their own headings or subheadings. When a topic is split into two topics, rather than sub-sectioned, it is often useful for there to be a link from the new topic to the original and vice versa. A common way of doing this is noting the change at the [then-]end of the original thread, and adding an unobtrusive note under the new heading. Some reformatting may be necessary to maintain the sense of the discussion to date and to preserve attribution. It is essential that splitting does not inadvertently alter the meaning of any comments. very long discussions may also be divided into sub-sections.
 * IDs Where sectioning is not appropriate, adding anchors for deep linking.
 * Section headings: Because threads are shared by multiple editors (regardless how many have posted so far), no one, including the original poster, "owns" a talk page discussion or its heading. It is generally acceptable to change headings when a better header is appropriate, e.g., one more descriptive of the content of the discussion or the issue discussed, less one-sided, more appropriate for accessibility reasons, etc. To avoid disputes it is best to discuss a heading change with the editor who started the thread, if possible, when a change is likely to be controversial. It can also sometimes be appropriate to merge entire sections under one heading (often preserving the later one as a subheading) if their discussions are redundant. In order to ensure links to the previous section heading (including automatically generated links in watchlists and histories) continue to work, one should anchor the old title.
 * Disambiguating or fixing links, if the linked-to page has moved, a talk page section has been archived, the link is simply broken by a typographical error, etc. Do not change links in others' posts to go to entirely different pages. If in doubt, ask the editor in question to update their own post, or add a follow-up comment of your own suggesting the alternative link. Only fix a link to a template that has been replaced or deprecated if the effect of the new template is essentially the same as what the poster used (otherwise, simply allow the post to red link to the old template, as a broken post is preferable to one with altered meaning). Internal links made using full URLs may be converted to wikilinks or protocol-relative URLs (by dropping the part before the "//"), so that they will work across protocols ( http:// vs. https:// ) and between our desktop and mobile sites.
 * Hiding or resizing images: You may hide an image (e.g., change  to   by adding a colon) once discussion of it has ended. This is especially appropriate for "warning" and "alert" icons included in bot-posted notices which are usually quickly resolved.  Another common and acceptable image-related edit is re-sizing images that were posted in full size and take up too much room on the talk page.
 * Deactivating templates and categories: You may prevent templates from being transcluded (e.g., change to Template:template name ) if the poster clearly intended to discuss the template rather than use it. You may deactivate category links (e.g., change   to   by inserting a colon) to prevent the page being inappropriately added to a discussed category.
 * Hiding old code samples: You may redact (replace with a note, or collapse) large code samples once discussion of the sample has ended; for instance fulfilled editprotected requests.
 * Discussions where interleaving is expected such as GAN/FAC, or talkpage-based peer reviews.
 * Manual archiving. It may be desirable to archive a thread that is not old, but is very long and has come to a conclusion.

Why and How often – Example diffs and feedback

 * I fix links about once a week (eg. [//en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_Disambiguation&diff=prev&oldid=566753402], [//en.wikipedia.org/w/index.php?title=Wikipedia_talk:VisualEditor&diff=prev&oldid=564952208]), I remove personal attacks about once every 6 months (eg. wp oldid 573194736), and I make pedantic changes erratically (twice a month?) if I'm well-acquainted with the editor (eg. [//en.wikipedia.org/w/index.php?title=Wikipedia_talk:Flow&diff=575333902&oldid=575329378] yesterday!). Quiddity (WMF) (talk) 00:02, 4 October 2013 (UTC)

Conclusion
There are a lot of situations in which comment editing by people other than the original author is necessary. Of particular concern are circumstances where process dictates comment interleaving, such as peer reviews or article evaluation processes. One proposed way around that is a "scratchpad" system, but relying on scratchpads would both slow down the development and deployment process (we're effectively blocked on wide-scale deployments until that can be solved for) and be worse than existing functionality in some ways (when it comes to dealing with interleaved comments embedded in an existing page, for example).

Obviously, the ideal is "not needing comment editing", and so we'll be testing the use cases above in production: the first release version of Flow will not have comment editing. Having said that, we're going into that release considering the absence of comment editing to be an experimental feature. It's trivial to enable comment editing, for admins, all users, or anything in-between, and if situations appear where comment editing is a needed feature, we'll happily modify the system.