Flow/Functional Specifications/Moderation, Protection, and Refactoring

This document describes a set of functional requirements regarding moderation, suppression, and other access control systems for Flow.

This document should not be taken as a final descriptor for any one specific release of the software, though recommendations regarding inclusion in the "Minimum Viable Product".

Moderation and Suppression
Topics, Posts, and Boards must be subject to moderation and suppression. There are three primary classes of this, listed from "lightest" to "heaviest". Moderation and suppression is an absolute must have for the Flow MVP.


 * Hide - The content in question is hidden from view. However, a marker of some kind is left to indicate that the content is there and can be restored. All users will see the markers, which remain within the Board or Topic.
 * Delete - The content in question is hidden from view. Only those with the rights to delete the objects will see the markers that are left behind, view the content, and restore it. Markers remain within the Board or Topic.
 * Suppress - The content in question is hidden from view. There are no markers left within the Board or Topic, but they appear in the history logs for the Board (for suppressed Topics) or Topic (for suppressed Posts).

Markers
When content is hidden or deleted, a "marker" is left to indicate that there was once content. This is required in order to:


 * 1) Reduce user confusion when encountering discussion chains where Posts have been hidden or deleted;
 * 2) Allow other users to undo/revert "Hide" and "Delete" actions easily
 * 3) Provide culpability to the user who performed the action.

The marker should be simple and indicate the name of the User who performed the action as well as a timestamp as to when the moderation action occurred. This timestamp should not be displayed as time-relative to the viewer ("Jorm hid this post 4 hours ago") but instead relative to the time of action ("Jorm hid this post 4 minutes after it was created").

Users with the appropriate user rights will be given controls to undo the action.

Activity Chaining
Moderation activity must be allowed to "chain" through Topic Branches. That is, a suppression action on a Post must also be allowed to easily be applied to all "child" Posts as a single action.

Consider the following discussion (threaded):


 * A) by Jorm - Something something something.
 * B) by Timmy - Hi, I'm Timmy, I'm 12, here's my phone number
 * C) by Maryana - Timmy, you shouldn't tell us that you're 12 years old!

Clearly, both comments B and C must be suppressed. The action to suppress comment B must also ask if all replies to it also be suppressed (or deleted) in one action.

This functionality may not be required for the MVP.

Special:Nuke
Special:Nuke should be modified to handle Flow, though this is not necessarily required for the MVP release. The functionality should allow for deletion/suppression of all Topics and Posts created by the target user as well as handling all replies to those comments as well (see above).

Complications
Flow discussions are trans-wiki. Because of this, users may see Topics that are "owned" by a different wiki than one they have rights on. Since moderation priviliges may be granted to different user rights on different wikis, and users have different rights on those wikis, moderation tools may or may not be available.

Associated User Rights
The following user rights must be created and associated with user groups. Recommendations are listed.


 * Hide Topic - Autoconfirmed users
 * Hide Post - All users
 * Delete Topic - Sysop
 * Delete Post - Sysop
 * Suppress Topic - Oversight
 * Suppress Post - Oversight

Protection
Boards and Topics are subject to protection levels. Protection is inherited (protection applied to a Board is also applied to child Topics "owned" by that Board).

There are two primary protection levels:


 * 1) Semi-Protected - only auto-confirmed users may interact with the Board or Topic
 * 2) Fully Protected - only priviliged users may interact with the Board or Topic

And a secondary protection level (not considered for the MVP):


 * 1) Whitelist Restricted - only users who are on the Board or Topic's whitelist (see below) or have elevated privileges or are members of a specific user group (technology does not exist yet) may interact with the Board or Topic. More details on whitelisting are below.

Activity Restrictions
Under protection, the following actions are disallowed if the user fails to meet the requirements:

Boards

 * Create new Topic
 * Merge Topics
 * Hide Topic
 * Reply to Topic or Post
 * Edit Topic title
 * Close Topic (move to final workflow state)
 * Change Topic workflow state
 * Move Topic (unattach Topic from the Board)
 * Attach Topic to Board

Topics

 * Reply to Topic or Post
 * Edit Topic title
 * Hide Topic
 * Hide Post
 * Split Topic
 * Merge another Topic into a protected Topic
 * Move Topic (unattach Topic from any Board it is attached to)

Use Cases
Reasons why Boards may require protection are:


 * Harrassment - a user's board is targeted for harrassement by another user (or group of users) with multiple throw-away accounts.
 * Deceased User - a user's board may be "closed" if they have died.

Complications
As with moderation and suppression, protection levels are set by the "owner" wiki.

Open Questions

 * Not sure that Topics themselves require protection. This may be overcomplication.
 * Protection must happen at the "owning" Board level.

Blacklisting
Blacklisting is a technique by which individual users (or eventually, groups of users) may be denied the ability to interact with Topics or Posts on a specific Board. Blacklisting may be a way to enforce interaction or topic bans.

While the technology involved in blacklisting could be applied to any Topic or Board, it is probably less useful on mainspace Boards (Article talk) or other discussion spaces (e.g., Village Pumps).

Blacklisting is not considered for the MVP.

Complications
Normal users should probably not be allowed to create blacklist entries. Consider: a new user is given a warning by another user and simply decides to blacklist the user who gave the warning. This is especially problematic with regards to blacklisting administrators or other functionaries (though elevated privileges should override any blacklist entry).

Further, normal users should not be allowed to blacklist other users from general discussion fora. Blacklist technology is clearly a dangerous object, and should be handled carefully.

Whitelisting
Boards or Topics which are given a protection of "Whitelist restricted" may benefit from allowing Posts and Topics created by those in the "Whitelist". An example of such a scenario is a functionary discussion space, such as case files used by the English Wikipedia's Arbitration Committee. A case could be opened by a functionary and then the case participants whitelisted into the Topic, thus allowing them to participate as needed.

Whitelisting is not considered for the MVP.

Complications
Normal users should probably not be allowed to create whitelist entries. Whitelisting, in general, should have zero effect (99.999% of Boards should not have whitelist protection), so providing tools for it to most users will be confusing.

Refactoring
Topics will, from time to time, require "refactoring". Typically these actions surround splitting off or "closing" thread branches or merging multiple Topics into a single Topic.

Split Topic
Splitting a Topic allows a user to take one or more Posts from an existing Topic (typically a single Branch), remove them from that Topic, and create a new Topic (with a new name).

Splitting a topic should leave a marker (with a link) that points to the new Topic that was split out (one idea here is to have a "zoom in" control that will include the split Topic in situ).

When a Topic is split, the history is modified thus:
 * 1) The "new" Topic will be given the histories of all Posts that were split into it
 * 2) The "old" Topic will retain the histories of the split Posts but a note will be included indicating that they were split, with a pointer to the new Topic.

For the MVP, splitting multiple Branches from a Topic in one go is probably not necessary, though the process of splitting and merging several Topics may leave a lot of detritus.

Only users who have participated in the split Branch will be subscribed to the new Topic.

Merge Topics
Two or more Topics may be merged into a single Topic. Merged topics should be called out as such, with links to the original Topics that they belonged to (if they still exist).

When two Topics are merged, only one Topic will remain as the "real" Topic. The histories of the Topics will also be merged, with a new entry indicating that the Topics were merged.

Subscribers and participants in the "dead" Topic will be informed of the Topic merge and will be automatically subscribed to the new, master Topic. Typically, the "ghost" Topic will be deleted, but the merging user should be given the opportunity to leave a "ghost" redirect notice.

Merging Topics creates an interesting (though non-fatal) state in a conversation in that there will be two "top-level" Posts. This should not be overly confusing.

All users who have participated in both Topics will then be subscribed to the "real" Topic.

Merged Topic Redirection
Topics should be able to be redirected, both within the "local" Board and between foreign Boards. Whenever two or more Topics are merged, the "ghost" Topics will be pointers to the newly merged Topic.

Use Cases

 * A Topic ends up with a Branch that has gone off-topic but is still useful. A user then splits that Branch out, creating a new Topic.  Discussion continues in that Topic. * A Topic ends up with a Branch that has gone off-topic but is not useful (devolved into personal attacks, for instance).  A user then splits that Branch out and closes the new Topic, including a summary as to why.
 * Two separate users create Topics on the same Board about similar (if not the same) subjects. A User then decides to merge the two topics into a single Topic.
 * Two similar Topics are created by different users on different Boards. One of the Topics is clearly located in the wrong place.  A user then chooses to merge the two Topics into one - the Topic on the "correct" Board.  The Topic left on the "incorrect" Board is then redirected to the new, merged Topic.

Blocked Users
Blocked users (who are still granted the ability to edit their own Boards) will be restricted to doing just that. They will be able to create Topics on their own Boards and will be able to reply to Topics - but only Topics that are "owned" by their personal Boards.

The complication here is that Topics can be attached to multiple Boards. In such cases, the blocked user's responses will appear in the "foreign" Board.

This is not a bad thing. Consider the following (theoretical) "unblock request" scenario:


 * 1) Ankit blocks Barbara.  The block notice workflow Topic is started on Barbara's board.
 * 2) Barbara requests an unblock.  The block notice workflow Topic advances its stage and the Topic becomes attached to a second board, one called, say, "Unblock Requests"
 * 3) Admins who subscribe the "Unblock Request" board can now interact with Barbara (asking her questions, etc.) without having to visit her Board directly.

This clearly gets more complicated when dealing with inter-wiki conversations. Barbara is blocked on enwiki but not on commons, and can continue to be involved in discussions on commons. Users who read commons-owned Topics on enwiki will continue to see her posts - but Barbara is not interacting on enwiki; she is interacting on commons.