Flow/Basic information

The Basics
Flow consists of the following major components and ideas:


 * Flow Board
 * Subscriptions
 * Tags

Flow Boards
The most central concept to understanding Flow is that of the Flow board. It is perhaps easiest to think of a Flow board as a super-charged "feed" of interactions and data that can ultimately contain everything that a user is interested in. A "home base," perhaps.

Flow boards mean to serve as a single point of contact for workflows. Various content "modules" will publish their data into the feed of the Flow board. This will allow users unprecedented (and frankly ridiculous) access to their interest graphs.

Flow boards could conceivably contain data from any part of the software that publishes to it, from discussion threads to watchlist activity to unblock requests to new Teahouse questions to new deletion discussions to requests for oversight to invitations to join Wikiprojects or even calls to action to help with Wikiproject activity.

First Person v. Third Person Views
Each user's Flow board can be (and will be) viewed in two modes: first person and third person. This is an important distiction.


 * A First Person view is when a user is looking at their own Flow board.
 * A Third Person view is when a user looks at someone else's Flow board.

The visible content will change depending on the viewing mode. Generally, in third person mode, only public content will be visible - things that one could normally get by visiting a user's contributions log and talk page together. No private data will be leaked this way (e.g., users that someone is subscribed to).

Transcluding Boards
Users should be able to transclude their personal Flow board into other pages using magic words. This would enable the Main Pages of many Wikis to also serve as dynamic content "home pages" for all users (consider transcluding Special:Flow into a column on the Main Page).

Non-User Flow Boards
There is no reason why Flow boards must be restricted to users. Consider the English Wikipedia's Signpost: each issue is ripe for having its own Flow board associated with it (which can then be transcluded into the issues themselves, much like each page's talk page currently is).

Subscriptions
In the most basic sense, subscriptions are analogous with watching. One subscribes to an element and at that point activity about that element will start flowing into one's Flow board.

The subscriptions metaphor radically expands upon the concept of "watching". Currently, users may only watch "pages" (and associated talk pages). There is no nuance or understanding exactly what one is "watching" - it is a wikitext entity only.

Subscribing creates a finer granulation which allows for more powerful combinations (especially when paired with tagging).

"Subscribe" v. "Watch"
Why a new term, you may ask? It is very simple: the verb "watch" does not work in all cases in which a subscription may be applied. One can "watch" or "guard" pages or articles, and this works, but "watching" people brings negative connotations into the mix.

Consider the following "objects" which could be made available for subscription (and common verbs used):


 * Articles (watch)
 * Discussion threads (follow)
 * User activity/contributions (follow)
 * Tags (follow)
 * Processes (e.g., requests for adminship, deletion discussions, elections) (follow)
 * Wikiprojects (join)

"Subscribe" is the only term that fits all areas and doesn't imply creepiness.

Subscribe to Thread
It should be possible for a user to subscribe to an individual thread and not an entire page. Currently, users must "watch" an entire talk page in order to keep tabs on a single thread (which may be the only thing they are interested in).

Users should be able to subscribe to a thread in one of two ways:


 * 1) By commenting in the thread
 * 2) By manually choosing to subscribe to the thread

Subscribe to User
Additionally, users should be able to subscribe to other users. In the context of the User-to-User discussion module, this means that all discussions that are started on the subscribed user's Flow board will feed into the subscriber's (though in slightly different format than subscribed threads).

Example:

Mary is an experienced editor and wants to mentor Joe, who is fairly new. She subscribes to Joe. Now, when Mary visits her Flow board, she will see additional content, not directly related to her:


 * 1) New threads started on Joe's Flow board
 * 2) New threads Joe starts on other Flow boards

To reduce volume, these threads will be collapsed and not marked as "subscribed" and will fall off the stack unless Mary decides to subscribe to them.

With a watchlist/contributions module, the subscribed user's edits to articles will also flow into the feed.

User Namechecking
The system should be smart about recognizing user names and not require standard wikitext ways of typing links to other users. A user should just be able to type "@username" and have the system recognize another user and react accordingly (e.g., typing "@Jorm" will insert the equivalent of " Jorm ").

Additionally, when a user is "namechecked", an Echo notification will be sent to them informing them that they have been referenced. To avoid spammyness, this should happen only once per thread visit.

Thread Depth Models
Jorm's Law, a corrollary to Godwin's Law: As the depth of a thread increases, the likelihood of the thread 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".

Thread Locking/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:


 * Thread Lock: Someone has decided to close the thread for discussion. Typically this means "hatting" the section.
 * Thread Archive: Someone has decided to move the thread 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" threads but mainly they serve to prevent discussions from being re-opened. This is often desirable with off-topic or argumentative threads (locking) and stale threads (archiving).

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


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

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

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


 * Parts of the thread have gone off topic. These comments are useful and should be kept but are clutter in the context of the current thread.
 * Parts of the thread 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 thread which exists as normal.

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

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
When a new thread is created, there will be the ability for the user to mark the starting post (but not replies) 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.