Flow/Archive

This document describes the design of a new interface for user-to-user communication in MediaWiki. This project depends heavily on the Echo project. This document is a work in progress. Feedback is welcome on the talk page.

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.

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.

Flow is focused on user-to-user communication and not general discussion.

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

Feature Requirements
Flow 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 wiki markup in postings

Personal vs. External Views
MediaWiki does not distinguish between "your view" of your pages, and "other people's view" of your pages; there is no "home page" or "personal feed" other than the watchlist.

The primary interaction problem lies in the fact that there is no distinction between "how others interact with me" and "how I interact with others". Flow seeks to address this by introducing variable views on the data.

Flow Board
Each user will have a personal message board. The Flow board is analogous to a current user talk page in several ways but not in others.


 * It is the place that other users go to leave messages.
 * It is the place that other users can view messages left by others.
 * It is also the place that the user can view his personal subscriptions feed.

A Flow board has different appearance to different users.

For the board owner, the board will show:
 * Threads started by others (or the owner) on the owner's board
 * Threads on other users' boards that the owner has subscribed to or interacted with

For the board visitor, the board will show:
 * Threads started by others (or the owner) on the owner's board
 * Indicators of activity by the board owner that occur "elsewhere"

Ultimately, Flow seeks to merge several data streams into a single "Subscriptions" page for the user. Consider a feed which includes edits by others to your watchlist (click to view the diff, in page) or

Thread and Post "Ownership"
Currently, communication "threads" between users are logically stored on a single talk page. 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 seeks to solve this problem by removing the concept of a "home" for a given thread. Threads are "owned" by all users who have interacted with them; they will appear in all feeds.

Thread Subscriptions
It should be possible to subscribe or "watch" discussion threads without actively engaging in the thread (replying to a comment).

Ideally, one would be able to subscribe to all activity on a user's board. This would greatly improve the situation with regards to mentoring, for example, or watching possible editors who work in bad faith.

Thread Subject versus Replies
Threads are analogous to talk page sections. They have a subject heading and an original author.

There is a distinction that must be drawn between the original subject of a post to a Flow board and replies to it.

Consider a template left for a user by WikiLove - the template is the original post. If the user then replied to it, this would be a sub-communication, and tied to the original template.

Minimal Interface
Postings on Flow boards must have a minimal interface. Posting replies does not require the full weight of the editor, for instance (even if they are wikitext entries).

Elimination of User Talk
A major question to be asked is whether or not a user's talk page be disabled and removed if they have been "Flow-enabled".

Reasons for keeping talk pages alongside Flow boards:
 * Some bots/scripts/systems may break if a talk page is non-existant
 * Some users will absolutely hate any change from their routines, and will want to use talk pages exclusively
 * Flow cannot account for all the use cases that talk pages cover, being that talk pages are free-form.

Reasons for removing talk pages from Flow-enabled users:
 * Additional page is likely redundant; will be unused
 * Additional interface clutter
 * Increased user confusion about where discussions happen
 * Especially if other users decide to post to the talk page rather than the Flow board.

Process for "Flow-Enabling" for a single comment

One possibility would be on a per-thread basis. Basically UI would be surfaced next to each section area for the user of the talk page would allow the user to click to reply in Flow. At that moment:
 * 1) the section data would be copied as a new flow thread [since the actual user-talk may be difficult to follow, this is prone to error and may copy the entire discussion as a single comment in the flow thread]
 * 2) existing commenters to that section should be added as participants to the flow [determination may need to troll/track revisions so some simplification might be done here]
 * 3) a change is done to the user talk to delete the discussion and link the flow discussion
 * 4) user has UI surfaced to reply within flow (so that when the reply is saved, participants will receive notification)

Process for "Flow-Enabling" for an entire page

The argument for this would be certain users want to upgrade their user talk to flow. If this is done some the process above for a single comment would be applied multiply with some changes
 * No UI reply sufficed
 * no link into the discussion would be put in place, instead requests to the user's talk would be redirected to user's flow board
 * some mechanism for archiving the revisions and then deletion of the revisions from the revision table would be done

Data Structure
To prevent the complexities/feature-creep associated with running it on the current revision text stuff, the data store for this would have to be in a new horizontally-scaled data structure in MW core.

Things to Consider (Jorm's Scratchpad)

 * Users who interact with Flow boards who are not themselves Flow-enabled.
 * How do posts/replies to a Flow board appear in a watchlist?
 * IP Editors
 * Connection to GlobalProfile
 * Banner messages/pinned messages
 * Search mechanics
 * Archive/close thread
 * Thread bookmarks?
 * Muting/blocking
 * For users who enable Flow who already have a talk page, what happens?
 * Watchlist integration