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.

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.

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, with the exception of 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)

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.