Flow/Closing discussions

An essential part of any discussion system is the ability to deliberately close discussions - whether that be by fixing their form or removing them completely. For the context of this document, "closing" refers to two classes of action:

1. The deliberate removal of a conversational thread, through any means, due to misbehaviour on the part of the author(s);
2. The deliberate fixing of a conversational thread's form - be that due to consensus being reached, conversations stalling, or minor misbehaviour that does not justify removing the discussion entirely from view.

Talkpages are, essentially, a sandbox: there is no structure. Because of that there are a vast number of different implementations of the above actions. The task with this document is to identify the common components of each, and the common information presented, with the idea of being able to make informed design decisions about what data is needed in Flow's discussion-closing mechanisms.

Closing discussions

Removal

Rollback/undo

Rollback and undo are two ways of removing an edit from Wikipedia, while keeping the edit in the revision history, allowing it to be accessed and viewed by any user if they want to see it. These mechanisms, in the talk namespace, are mostly used to handle comments that are problematic but not problematic enough to justify revision-deletion/suppression. An analogue in Flow would be flagging/hiding a comment; it removes it from immediate view, but leaves it visible if a user really wants to read it.

Rollback and undo are both roughly analogous (the difference is speed and simplicity) so we'll treat them as the same thing for the purposes of this document. The actions can be triggered in one of two ways.

From the history page, both rollback and undo functionality is available via a link next to each entry;(1) rollback only appears for the newest edit.

From a diff, both appear via links - rollback next to the user link,(1) and undo next to "edit".(2)

Clicking "rollback" in either place removes all successive edits made by the same user to that page - this is probably not functionality we need to replicate. A confirmation message is then displayed, along with a diff of the change you made.(1)

Clicking "undo" presents you with a diff of what change you will make, and requires you to enter an edit summary.(1) You then click "save changes",(2) undoing the edit you selected.

In both cases the edit remains viewable in the history of the page, and the removal of the edit itself registers as an edit/log entry, allowing for users to see who took the action and what their rationale was.

Interface element	Description	Necessary?	Handled by Flow?	Comments
Rationales	The ability to explain why the content was flagged	Yes	No	If flagging hides comments from the view of all users, this is necessary; if it's just from the user taking the action, it's not (although we should discuss that decision).
Logging	The logging of these rationales, and the ability for a user to easily see who flagged a comment and why	Yes	No	See above
Un-undo	The ability to undo the removal/flagging of a comment	Yes	No	Logging is necessary for this, too.

Revision deletion and suppression

Revision deletion and suppression are two different mechanisms for removing content. In both cases, they make the content invisible to most users - unlike rollback. The primary difference is that "revision delete" is only accessible to admins (and the deleted content can only be seen by admins), while suppression is only available to oversighters, and hides content from all but oversighters. Revision deletion and oversight are used for removing different classes of the most inappropriate content - copyright violations, defamation, child pornography, privacy violations, so on and so forth.

Both processes are identical in UI terms, except for a single checkbox, and can be triggered in one of two ways. Both begin by removing the content from the latest revision to the page. After that:

From the "history" tab of a page, an administrator or oversighter is presented with a checkbox next to every revision (1) that allows them to select multiple edits. When they have selected the edits they want to remove, they press the "del/undel selected revision" button (2).

From the "diff" view, an administrator or oversighter is presented merely with a "show/hide" button (1). This only allows for the selection of that particular edit.

Whichever view (history or diff) is chosen, the admin/oversighter will end up at the deletion screen. This contains several important elements. Users are first presented with a confirmation of which revisions they have selected;(1) this allows for double-checking before hitting the big red button. In Flow, this is probably unnecessary - the fact that everything happens through interstitials rather than in a totally different interface means the user can see the revision they're trying to select. They are then shown extensive guidelines and warnings,(2) the intention of which is to warn against making mistakes: poor judgment with such powerful tools is usually responded to very strongly. This can probably be simplified to a link to the relevant policy, and a caution about using the tool, which is what's found in tools such as AFT5.

Below these warnings is the actual interface for suppressing or revision-deleting edits.(3) This permits various permutations of suppression and revision-deletion, with options to eliminate any permutation of username, edit summary and actual edit contents. The rationale here is that different types of user misbehaviour have different minimal responses: sometimes it will only be the edit summary that is inappropriate. Sometimes it will be a user accidentally editing logged-out, revealing their IP address. And sometimes everything will be a problem. These sets of options are all available for both revision-deletion and suppression - the only interaction difference being that suppression requires the users to check the "suppress data from administrators as well as others" button.

The interface also features the logs of previous revision-deletion/suppression actions on (that/those) edit(s),(4) allowing for the user to see if there is anything contentious about the content, and identify the deletion circumstances if they are using the interface to undelete content.

When the administrator/oversighter has filled out the options they want, they provide a rationale for the removal of material - selecting from a set of pre-set options in a dropdown box, and/or filling out their own explanation. They then click "apply to selected revision", which applies revision-deleted/suppressed status to the edit(s). This reloads the screen and confirms that the action was successful.

A user who tries to view a diff of the deleted revision will be presented with a notification that it is unavailable,(1) and - if they are the right class of user - a notification that they can still access a diff of the revision if they want.(2)

Interface element	Description	Necessary?	Handled by Flow?	Comments
Ability to select multiple contributions	The existing revisiondelete/OS structure allows for selecting multiple revisions for removal within the same page. I (Oliver) have spoken to the current OSers and they confirm that, even with Flow's more-sensible structure of pages, this will still be necessary - it is not unusual to have people post multiple inappropriate and distinct edits to a talkpage.	Yes	No	This should be high-priority. Presumably, for Flow, it means thread-level obliteration controls as well as post-level.
Ability to select individual contributions	Sometimes you just want to murderlate a single edit.	Yes	Yes	N/A
Confirmation of selected edits	A part of the deletion screen that confirms which edits you've selected for removal	Yes	Yes	The existence of suppression/revision deletion in Flow as an interstitial rather than an entirely new page that obscures the original content means that the user can visually refer back to what they're deleting.
Warnings and policy links	Explanations as to how to use the tool, a link to policies governing its usage, and warnings as to not to misuse it	Yes	No	These are necessary elements, but can be drastically simplified.
Different permutations of deletion type	The challenge with OS/Revdel is to achieve the aim while removing the smallest possible amount of information. This is achieved by offering different types of deletion (remove edit summary, remove username from history, remove text, any/all of the above).	Yes	No	This can probably be dramatically simplified; edit summary, for example, will no longer necessarily be an attribute that posts to the talk namespaces have.
Summary	The ability to provide a summary/explanation of why an edit is being removed.	Yes	No	N/A
Logging	The ability to access logs of previous actions taken on that post/thread	Yes	No	N/A
View deleted content	The ability for users who fit into permitted usergroups to view the content, even after its deletion	Yes	No	N/A
Undo the above	The ability to un-suppress and un-delete	Yes	No	N/A

Fixing form

Consensus decision

Outside of direct removal of content, content is often closed because consensus has been reached - or not. Many Wikipedia processes have set times for closing discussions, with the decision being community agreement, disagreement or ambivalence to the original premise (whether that premise is the deletion of an article, the blocking of a user, or the granting of rights to a user). Other discussions are simply closed in this fashion because it becomes clear, at an early stage, what outcome will result. Different processes involve different workflows, but all share common elements. As an example, we'll use a discussion on the Administrators' Noticeboard. Such discussions are closed by wrapping the thread in a template, which generates various colour changes and spaces for notes.

The three crucial elements appear either at the top of the thread - where they are most visible - or uniformly. They are the background colour change,(1) the note that the discussion has been closed,(2) and the space provided for the closing user's rationale.(3) The background colour change is commonly a neutral shade, such as blue, to make the template more generalisable - there are other examples in which positive or negative colouration is used to indicate "did/did not reach consensus", and we probably want the ability to visually indicate this to be available. The rationale is twofold; first, it provides a visual indication that the thread is closed. Second, it provides an easy point of reference (if positive colouration is used) to which direction the conversation was closed in.

The note is, well, fairly self-explanatory; it has greater importance in a freeform wiki page where it is always possible to edit content, and a note is needed to point out that doing so is ill-advised. Restricting the ability to contribute to a thread after it has been closed is probably something we want to build in technically - but, in the interest of avoiding making editors put in unnecessary effort, this should be visually indicated too. The space provided for a rationale allows the closing administrator (or closing non-administrator) to explain why they reached the decision they did, which promotes open dialogues about decisions and is pretty much required by the community.

Misc

Other types of form-fixing are...miscellaneous. Usually they're the result of "informal" closes; a user deciding that a thread is simply going nowhere, or that a discussion is mildly inappropriate but not enough to warrant anything stronger. There are a lot of templates used for this; all share common elements, however.

The important things to recognise here are the compression,(1) the ability to trivially undo that compression on a per-user basis,(2) and the space for an explanation, rationale or summary.(3) Compression is important visually: it means that once it has been decided something is off-topic/inappropriate, users are not forced to scroll through or read it. The ability to undo ensures they can refer back to it if they want - it's not that inappropriate, and might be useful context for subsequent discussions. The rationale, as with admin closes (see above), allows for an explanation of why the discussion was found inappropriate/off-topic/a dead-end, or a summary, or both.

Visibility matrix

Action	interface	Joe Bloggs	Administrator	Oversighter
Hide	Board	Collapsed, even after thread expansion, with a header line reading "This post was hidden by $user on $timestamp" and a link to expand it and see the full thing. The username and timestamp of the post(er) are available in the usual places. On expansion, the content is visibly distinct from non-hidden posts, and a button to un-hide it is made available - as are suppress/revdel link(s).	Same	Same
	History	Offending post visible in the same way non-hidden posts are	Same	Same
	Link to specific post	Post appears collapsed, with the same header line and interactions as above	Same	Same
Revision deletion	Board	Invisible	Collapsed, even after thread expansion, with a header line reading "This post was deleted by $user on $timestamp: $rationale". Collapsed header line would have the author's username visible iff the person revdelling the edit didn't choose to also revdel the username. If they did, the username appears on expansion. Expanded content visible distinct from non-hidden posts, and a button to un-revdel...you get the picture	Same
	History	Invisible	Visible, but with a line struck through it	Same
	Link to specific post	Notice informing the reader that the post in question was deleted by an administrator	Same as for "Board	Same as for "Board"
Suppression	Board	Invisible	Invisible	Same as for "Revision deletion/board" above.
	History	Invisible	Invisible	Visible, but with a line struck through it.
	Link to specific post	Notice informing the reader that the post in question was suppressed by an oversighter	Same	Same as for "Board".
Closed	Board	Collapsed, with the line "Discussion closed by $user at $timestamp: $explanation"	Same	Same