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^{[citation needed]} (and, frankly, insane^{[citation needed]}): a discussion medium does not work^{[citation needed]} 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, except for 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 [[File:Foo.jpg|<var>...details...</var>]] to [[:File:Foo.jpg|<var>...details...</var>]] 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 {{template name}} 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 [[Category:Foobar]] to [[:Category:Foobar]] 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.

Comparative analysis

Use case	Handled by Flow?	Commmunity/Analysis notes	Engineering notes	Product notes
With permission	N/A	Not really a use-case.
Personal talkpage cleanup	Yes	Flow permits closing discussions.		Infinite scroll means that older discussions will naturally fall out of view, so there's no need to manually archive old discussions. Close/hide features could be used to ensure that off-topic discussions/flamewars don't take over the entire page.
Removing prohibited material	Yes(?)	Suppression, revision-delete and hide (equivalent to rollback) will be available for each individual post, and possibly entire threads at a time. Having said that, what happens to the good information in the post? With bad-faith users we don't care, but good-faith users bringing up evidence of wrongdoing, the evidence of which is deemed a violation of [something]? New users asking a perfectly legitimate question that accidentally includes Personally identifiable information (PII)?
Removing harmful posts	Yes	See immediately above
Off-topic posts	Yes	The two examples given are solved for by hiding and topic splitting.
Attributing unsigned comments	Yes	All comments will be signed automatically.
Signature cleanup	Yes(?)	Find out about custom sigs		Custom sigs aren't something we're considering in the first release, though we may add the ability to use a preferred name (in cases where a username doesn't match what a user calls him or herself onwiki).
Fix formatting errors	No	Discuss. Hopefully the stripped-down VE will reduce the number of issues here, but a lot of people are still going to prefer markup editing, and the VE is not perfect, even with the tiny number of features we're including.		This may be better solved for by providing a quick preview step in the posting process.
Fix layout errors	No	Needs discussion. A lot of the examples will be solved for (where to stick replies/new threads should be fairly intuitive, and the lack of a free-form structure means comment editing wouldn't help there anyway) but the example of misused HTML/wikimarkup tags is a good one and needs discussion – first with the engineers (can things overlap?) and also with users (even if things can't overlap, what if they obscure the rest of the comment? yuck).		This may be better solved for by providing a quick preview step in the posting process.
Sectioning	Yes	Flow allows user-directed sub-threading and splitting off into new topics.
IDs	Yes	Threads and even individual posts can be individually linked.
Section headings	Yes	I'll find out.		Section headings can be changed by any editor
Disambiguation/fixing links	No	This is a potential problem.		Again, preview could help here.
Hiding or resizing images	No	This is going to be less of a problem, insofar as closed discussions can be just that – closed, so people don't need to read them or view the contents unless they really want to. The problem is what happens with oversized/oddly-sized images in threads that are still going.		Preview in the short-term. In the long term, it will be easier to use the VE add media button.
Deactivating templates and categories	No	Again, this falls under 'it'd be easier with the VE, but a lot of people don't use the VE'
Hiding old code samples	Yes	Collapsing is easily done, particularly once a discussion is 'closed'.
Discussions where interleaving is expected	No	We've talked about a 'scratchpad' format that could be used, but this hasn't been fleshed out, and relying on it means delaying any widespread deployment until it's built. Moreover, it doesn't solve for this kind of discussion happening on an already-created page.

Why and How often – Example diffs and feedback

• I fix links about once a week (eg. [1], [2]), 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. [3] 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^{[citation needed]}, 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.