Flow/Basic information

The Basics

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

• Board - A metaphoric "location" where one views discussions, analogous to a User Talk Page
• Feed - A stream of discussions and other activity that a user is subscribed to (most closely analogous to LiquidThreads' "Special:NewMessages")
• 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.

Boards

The most central concept to understanding Flow is that of the Board. It is perhaps easiest to think of a Board as a super-charged version of a User_talk page, wherein each topic entry can have its own specialized workflow. In the case of user discussions, that workflow is simple: Person A makes a topic, person B responds to the topic, and so forth.

However, more complicated workflows can be created - topics and posts that have specialized functionality (such as a block notice including controls to automatically request an unblock). These additional workflows could be designed on a per-wiki basis, to handle each wiki's unique requirements.

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

Feeds

A user's Feed is a stream of activity that concerns or interests them, potentially across multiple wikis. In contrast to the Board, the Feed can change rapidly and will contain entries that lie "outside" of the normal purview of the user's Board. It is a stream of interactions and data that can ultimately contain everything that a user is interested in. A "home base," perhaps.

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

Feeds 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.

Transcluding Feeds

Users should be able to transclude their personal Feed 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).

Board versus Feed

Well, what is the distinction between a "Board" and a "Feed"? The answer lies primarily in how they are used:

• Boards are primarily used by other people to get a glimpse into your activity. Like User_talk pages, they are where other users go to contact you. Eventually, they will become an "at a glance" spot for all your activity: blocks, contributions, etc.
• Feeds are private and used only by the owner. This is where you go to get a glimpse into your activity, or activity that interests you. For example, if you watch another user's Board, new topics on that Board will flow into your Feed without you having to visit the other user's Board.

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

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

A design diagram showing the process by which users may subscribe to each other

A design diagram showing side cases for user subscriptions

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.

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. They may communicate on it as normal and these comments will also not be visible to others.

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 "[[User:Jorm|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 unwieldy).

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.