Flow/User to User Discussions

This document describes the design of a user-to-user discussion module for Flow.

Note on Nomenclature

Nomenclature in this document (e.g., "Flow board") is product design facing and not user facing. User facing terms will very likely be different than those included herein.

In order to ease understanding, the following terms are defined:

Board: This is a user's "talk page" analog. It is low-velocity.
Feed: This is the feed that users have of discussions and other items. It is high-velocity.
Topic: This is a single discussion (analogous to a Talk page "section"). Topics have a title and associated metadata (including histories of splits/merges/summaries/locking).
Post or Comment: These are any elements provided by users to the topic. The first post (when the topic is created) is considered a "0 level" post for threading purposes. Replies to the post are threaded as in-reply to that post. Additional replies to the topic will also be "0 level".
Discussion: This is used interchangeably with topic where the language gets weird.
Element: Any atomic item that appears in a Flow board.
Thread: This refers to the ordering of comments in a topic (e.g., this comment is in reply to another comment).

Rationale

One of the most confusing issues faced by users of Wikipedia (and MediaWiki in general) is that of "User Talk Pages." It is beyond the scope of this document to describe in detail all the problems involved with them and the interaction model problems they pose; however, a simple list could contain:

Conventions regarding user talk pages are opaque (e.g., indentation with colons, requirements for signature code, etc).
It is not clear as to where one responds to messages left. On my talk page, or yours? (see "talkback" templates)
If a discussion is occurring on another user's talk page, there is no automated notification of replies.
- This is further compounded because watchlists for active editors on large wikis tend to quickly become useless
  - And you have to know what a watchlist is, in the first place
  - You can use your contributions list as a pseudo-watchlist, but that doesn't show changes by other users.

Since communication between users is of paramount importance in a collaborative system, it is therefore essential that communication tools be easy-to-use, intuitive, robust, and responsive.

Initially, the Flow discussion modules will be focused on user-to-user communication and not general discussion.

Hypotheses

An intuitive user-to-user discussion system will promote editor engagement and retention by eliminating several of the greater hurdles that new (and old) users face.

Feature Requirements

Flow discussions must allow for:

Automated posting, by bots or scripts.
Easy-to-use searching of posts
Multi-user interactions (e.g., 3 or more)
Addition of (possibly limited) wiki markup in postings
Ultimate integration with the VisualEditor.

Scope

The first iteration of the Flow discussion module will focus exclusively on a replacement for "User_talk". User-to-user discussions are typically different than discussions about articles, policies, or processes in that they typically are not deeply threaded and rarely contain "!votes" or polls.

Most user-to-user discussions are fairly short and easily read chronologically.

Basic Concepts

A process diagram illustrating a simple conversation with a "board and feed" model.

A process diagram illustrating a simple conversation with a "1st person vs. 3rd person" model.

Cognative Model

The Flow discussion system utilizes a "Board and Feed" model.

A user's Board is a low-velocity talk page analog. The Board is where a user will go to start a conversation with another user. It is the "home" for topics (though topics can be visited from other locations). It is a view into the discussions that involve the "owning" user.

A user's Feed is a high-velocity view into all discussions that a user is participating in (that they are subscribed to) as well as passive notifications about other activity that they may be interested in.

Topic and comment "homes"

Currently, each talk section (as well as each LiquidThreads thread) is stored on its individual page, although transclusion can be used to multi-home discussions (impossible with LiquidThreads). This is problematic because users don't necessarily know where to look for the conversation threads that they are engaged in. For prolific editors this can be a nightmare of open tabs and so forth.

Flow discussions seek to solve this problem by granting multiple "homes" for a given topic. Topics are "owned" by all users who have interacted (subscribed) with them; they can appear in multiple Feeds.

Topic Subscriptions

It should be possible to subscribe to topics without actively engaging in the topic (replying to a comment).

Users will be able to subscribe to all discussion activity on any user's Board. This would greatly improve the situation with regards to mentoring, for example, or watching possible editors who work in bad faith. This is analogous to "watching" someone's Talk page, though (hopefully) easier to use.

Active vs. Passive subscriptions

Flow will make a distiction between active and passive subscriptions to topics.

An active subscription is one on a topic that the user has directly subscribed to, either by intentionally subscribing to it or by commenting in it.

A passive subscription is one where the user is subscribed to another user but has not engaged in the specific topic.

These will display differently within the Feed.

Actively subscribed topics will display as "open" and will have interaction controls. They will also be subject to "staleness filtering" - when the topic has activity, it will bubble to the top of the Feed.

Passively subscribed topics will simply display as a line item in the Feed, with controls that will allow the user to view the topic (and possibly subscribe to it, promoting it to an "active" subscription).

Topic subject versus replies

Topics are analogous to talk page sections. They have a subject heading, an original author, last-modified dates, and additional metadata based on the manipulation history of the topic.

Topic summaries (hat notes) belong to the topic.

Topics may be replied to multiple times. The first posting (created when the topic is created) is considered to be "0 level" and will have no threading. Additional replies to the topic will also be "0 level".

Consider a template left for a user by WikiLove. The template is the original post (and is thus 0-level). If the user then replied to the 0 level post, this would be a comment and tied to the original post (which is the WikiLove template).

Minimal interface

Postings in Flow discussions must have a minimal interface. Commenting does not require the full weight of the editor, for instance (even if they are wikitext entries).

Activity notification

Flow will automatically keep track of comments that the user has seen. If a comment makes its way into the viewport, it will be marked as "read."

Topics that have unread comments will be called out to the user. Additionally, they will "bubble" to the surface according to last-modified chronology.

Controls will be provided to allow the user to mark all topics and replies as read.

Auto-Archiving

By its very nature, Flow Boards are auto-archiving. Elements in the board simply "fall off" the bottom visually but are still there and may be discovered through scrolling/pagination or simply searching for them.

Topic expansion and collapse

In order to reduce visual clutter, topics with multiple comments may need to be collapsed after a certain comment-count threshold is met (determined via user testing; ideally configurable on a per-installation basis).

It is entirely possible that this is not required, but it is something that should be accounted for in designs.

Comment privacy

Currently, any user may edit talk page postings by any other user. This is a behavior that is frankly alien to most users of discussion systems; they (rightfully) believe that their words are their own and do not expect others to "vandalize" them.

Accordingly, comments in Flow discussions are only able to be modified by the user who created them or an administrator (or other user-group) (unless specified as a collaborative posting - see below). When a comment has been modified, a notice will be included saying that the comment was modified, when this happened, and who did the modification.

Moderation controls

Flow topics and comments must be compliant with standard MediaWiki moderation controls. Administrators (or other user-groups) must be able to delete individual comments or entire topics.

Additionally, oversight functionality must be included.

Topics

A UML diagram of a Flow topic.

This section concerns itself with the mechanics of topics.

Topic elements

A topic consists of the following elements:

Title: The title of the topic
Original author: The user who originally started the topic
Start date: When the topic was created
Last-Modified date: When the topic last saw activity
Summary: A short summary of the topic. Not required except if the topic is locked
Lock status: Whether or not the topic has been locked
Activity history: A listing of replies, splits, merges, etc.
1+ Posts: A collection of threaded comments that are associated with the topic

Thread Depth Models

Jorm's Law, a corollary to Godwin's Law:

As the thread depth of a topic increases, the likelihood of the topic becoming uncivil approaches 1.

There are three basic modes for discussion "threading":

Flat. There is no visible threading; all conversation happens consecutively
Unlimited threading. Threading is visible and can expand to arbitrary depth.
Limited threading. Conversations allow for threading but only to a limited depth, after which they become "flat".

Comparison of Thread Depth Models
Thread Model	Pros	Cons	Examples
Flat	Easy to use and understand (a common blog pattern)	Context and nuance cues are lost Replying to specific comments is impossible without quoting mechanisms (increased complexity) or back links	Forums (phpbb, Discourse, 4chan) Most blog comment systems Twitter, Facebook Bugzilla
Unlimited Threading	Flexible Keeps full record of replies	Confusing to follow, especially for new users Can be overwhelming and difficult to digest (requires auto-collapsing of sections which may be undesirable) Do not display well in many resolutions Hard to contain Can quickly become incivil or useless, especially at depth	MediaWiki talk pages Reddit Livejournal
Limited Threading	Allows for nuance and context within a given topic Disincentivizes circular arguments	Somewhat more complex than flat Less flexible than unlimited threading	Techcrunch Quora (not well) CNN.com Facebook Comments (blog system)

It is recommended that Flow discussions utilize limited threading, with a target maximum depth of 4 or 5 degrees. Note that this is a limit set on display, not storage. From the data side, full threading will continue to exist (if only to support topic splitting, which will change the depth of comments).

Topic Locking and Archiving

The concepts of "locking" and "archiving" are often conflated due to the way that MediaWiki talk pages operate. For the sake of this discussion, we shall use the following definitions:

Topic Lock: Someone has decided to close the topic for discussion. Typically this means "hatting" the section.
Topic Archive: Someone has decided to move the topic from the talk page and onto a sub-page to reduce clutter. Often this is handled by bots.

There are several reasons for "locking" and "archiving" topics but mainly they serve to prevent discussions from being re-opened. This is often desirable with off-topic or argumentative topics (locking) and stale topics (archiving).

Flow should handle these use cases, with an additional twist:

Locked topics: A topic is just that: it locks the topic for additional comments. The locking user must supply a reason why the topic was locked (a "hat note"). Locked topics will remain stationary within the topic activity chronology and will fall off as normal.
Archived topics: A topic that is old and has fallen back in history. As the topic ages without activity, it will naturally fall off the stack.
Stale topics: A stale topics are topics that have not seen activity within a certain time period (say, two weeks). Stale topics may not have been archived (in the case of there being few topics). If a user attempts to re-awaken a stale topic (what some communities call "topic liching") a warning should be shown to the user saying that the topic is old and that they should probably not respond to it.

The software could be configured to automatically "lock" stale topics after additional time has passed (say, 3 months), and this may be configurable based on the type of dicussion.

Topic Splitting

There exists a need for topics to be split. The reasons for splitting a topic are easy to define but mainly fall into two basic use cases:

Parts of the topic have gone off topic. These comments are useful and should be kept but are clutter in the context of the current topic.
Parts of the topic have gone off topic and are not useful (e.g. uncivil). In normal Talk pages, these comments are "hatted" with templates.

In the first case, the off-topic comments are selected and a new topic title is chosen. These comments are then split off into their own topic which exists as normal.

In the second case, the exact same thing happens, except that the user who does the splitting would also lockthe topic immediately (thus "hatting" it).

Topics that have been created due to a split will have an indicator that they were split and a pointer to the original topic. Further, the topic depth levels for split topics will be reset (e.g., comments that may have been "flattened" may become "threaded").

Topic Merging

It should be possible to merge two or more topics into a single, unified topic. This is a more complex interaction than splitting topics.

When topics are merged, the user will be required to provide a new title for the topic (which, of course, may be the title of one of the existing topics). Merged topics will be called out as such, with information displaying the original topic titles.

The most difficult part of topic merging is the ordering of existing threads within the old topics. Threads will organize by depth, chronologically (oldest top-level first).

With merging, there will nearly always be at least two "0 level" postings.

VisualEditor Integration

The future advent of the VisualEditor creates significant problems regarding "free" wikitext posts and comments. While the VisualEditor is powerful software, it is likely that it may never be able to handle certain levels of wikitext complexity.

Users will expect a consistent experience between editing articles and attending to discussions. Accordingly, it is suggested that the VisualEditor also be used as the editor for comments and posts within the Flow discussion module.

If the VisualEditor is unable to be used at the time of launch, it is suggested that the Flow discussion module only accept a limited set of wikitext entries (so as to be foward-compatible).

Raw Wikitext Posts

However, from time to time a posting may require complex wikitext (such as that created by certain templates that have not been "Flow-ified"). In this case, a post may be marked as "Raw Wikitext" and require the standard editor to interact with it.

Collaborative Posts

There will be the ability for the user to mark any post that they create as collaborative. This will allow any user to make edits to the post.

Collaborative posts will be called out as such. No single user will be associated with the post but all editors who have contributed will be listed.

A user's discussion page, all threads collapsed
A user's discussion page, a thread opened
Starting a reply
Adding a reply
Reply successful