Flow/Basic information

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


 * Flow Board - A metaphoric "location" where one views discussions
 * Subscriptions - Similar to the concept of "watching" pages
 * Tags - These are similar to MediaWiki categories but are significantly more powerful, if only due to the concept of "tag interesection"
 * Flow Modules - Software elements which are "Flow-enabled" and thus publish into the Flow feed.

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 topics 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 to topic
It should be possible for a user to subscribe to an individual topic and not an entire page. Currently, users must "watch" an entire talk page in order to keep tabs on a single topic (which may be the only thing they are interested in).

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


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

Subscribe to User
XXX TBD: The concept of private communication regarding subscription requests (see below) must be vetted by legal. Privacy here is an outcropping from the fact that watchlist data is private.

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 topics).

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 topics started on Joe's Flow board
 * 2) New topics Joe starts on other Flow boards

To reduce volume, these topics 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 subscription and permissions
Since subscribing to other users can be problematic when taken from a "stalker" perspective, it is recommended that subscribing to another user require permission to be granted. Further, the act of subscribing to another user should be private.

A subscription request workflow would be created, thus:


 * 1) Jorm want to subscribe to Werdna.  He navigates to Werdna's user page and clicks the "Subscribe" button.
 * 2) A dialog appears that informs Jorm that Werdna must grant permission.  Jorm fills out a short message here and sends the request.
 * 3) A "Permission to Subscribe" post is added to Werdna's feed.  This post behaves like most Flow postings but includes controls to grant (or deny) access.  This is a private posting. Both Jorm and Werdna will be able to see it in their feeds but it will not appear to anyone else.  They may communicate on it as normal and these comments will also not be visible to others.

An open question regarding the privacy of a subscription request posting surrounds using them as vectors for abuse. Accordingly, it may be advisable to allow Administrators to see these postings as well.

Subscription Access Preference
Some users (for example, Jimmy Wales) will have a large number of people wanting to subscribe to them and answering each and every request would be tedious. Other users may not want to ever allow someone to subscribe to their activity (for example, page patrollers who monitor User space for COPPA violations).

Accordingly, a preference should be implemented granting each user a degree of control over their subscription volume, with the following values:


 * Require Authorization:The user must grant permission to those wishing to subscribe to them (this is the default setting)
 * Allow All:Any user may subscribe and permission is automatically granted
 * Allow None:Automatically deny all subscription requests

Other Subscription Types
Subscriptions will not be limited to users, tags, or topics. In the future, there can be a plethora of "subscribable" objects:


 * Articles
 * Revisions
 * Categories
 * Groups (e.g., Wikiprojects - effectively "joining" the group)

"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 topics (follow)
 * User activity/contributions (follow)
 * Tags (follow)
 * Categories (watch)
 * 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.

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 topic visit.

Tags
One of the most powerful tools introduced with Flow is tagging. Tagging is similar to MediaWiki categories with one powerful addition: tag intersection. Tags are also private. "Public" tags are served with Categories (though they are unweildy).

When discussing tags and how they can work, let us begin with watchlists.

The "Multiple Watchlists" Use Case
Users of MediaWiki have long expressed as desire for multiple watchlists. That is, users would like to be able to separate pages watched into categories. This is an attempt to bring exceptionally large watchlists under control and to reduce the apparent velocity of changes.

Most of the proposed solutions surrounding this create problems either with limitation or scaling.

If we allow an arbitrary number of watchlists per user, we quickly run into scaling issues (both within the interface and within back-end performance). But if we limit the number of additional watchlists to a handful, the feature will quickly run into the same problems that having only a single watchlist has.

Upon exploration of the business requirements for such a feature, it became apparent that the concept of "multiple watchlists" is best served by the ability for individual users to "tag" watchlist entries in an arbitrary manner and then be able to sort/filter their watchlist based on these tags.

Expansion of Tags to Other Objects
There is no reason to restrict tagging to article objects. Objects in this sense are broad things:


 * Articles
 * Revisions
 * Users
 * Groups
 * Discussion Topics

Tag Privacy
For privacy reasons, personal watchlist tags would have to be private. For example, an experienced editor may watch a user who is possibly a vandal, and tag that user as "#vandal". This tag should not be made public.

Flow Board Search and Filter
Flow boards have the potential to be very noisy and high-speed. To address this problem, a strong filter and search mechanism must be included.

Tagging would be implemented into the Flow feed as a series of filters. To reduce interface complexity, the filtering mechanism should be done using natural language processing. That is to say that there would be no pull-downs or radio buttons or checkboxes. Instead, users would filter using the Flow board's "search/filter" text box.

The language of the filter system will have to support "keyword tokens". For example, the "#" token could indicate filtering on a tag, and the ":" token could define an object type.

Consider the following text searches:


 * :user and #vandals :Restricts the Flow board to only show content produced or about Users who have been tagged with "#vandal". This might show both topics/conversations that user is involved in as well as their article revisions.
 * :rev and #coi :Restricts to only show Revisions that have been tagged as "#coi"
 * :topic and cat:Articles for Deletion : Restricts to only showing discussion topics in the category "Articles for Deletion".

(Note that this token language is only suggested and has not undergone a full design pass).

Additionally, text searches must also be supported.