Structured Discussions/FAQ

This page hopes to answer several frequently asked questions about Flow.

Nomenclature

 * Flow team - WMF staff working on the Flow project (including developers, designers, analysts, and product managers)
 * Core Features team - WMF development team that builds and maintains features like PageCuration, Echo notifications, and Flow. This team will primarily be focused on Flow this fiscal year (July 2013-July 2014)
 * Extension:Flow, aka "Flow" - the software product, which has two components: a discussion system and a workflow engine. The Flow team will be working primarily on the former this fiscal year (July 2013-July 2014).
 * w:WP:Flow or Flow Portal - the Flow Portals, or homepages.

Development principles
With any complex software project, it's almost impossible for the designers, developers and product people to know everything. This is a particular problem in an environment like that of the Wikimedia projects - due to the sandbox-like nature of the place, there are tens of thousands of different workflows, different user needs, and different problems. Even if we could accurately identify all of them, we can't necessarily tell if our solution is the right one until we put it in front of users.

Accordingly, we're keeping two things in mind while we're developing the Flow software. First: we are partners with the community on this. Editors are welcome and encouraged to participate in the development process, pointing out things we've missed, identifying and describing new workflows, and helping keep us honest - when something hits this level of complexity, it's impossible to make things work without as many people helping as possible. Before and after we build things, we'll open a conversation about the feature. Second: a lot of the work we're going to do, at least initially, is experimental: we don't know if it's the right implementation of a feature. If it's not, we'll be happy to roll it back.

Components of the discussion system
Here's a brief list of the main feature areas for a discussion system, a description of what the plan is for each one, notes about the status, and links to any ongoing discussions. It'll be regularly updated to factor in new discussions, and to note the permanency of the feature.

Is this replacing talkpages?
Yes, but not for a long time. Talkpages are incredibly complex, with the number of processes they have to support (discussion closing, unblocking, requested moves) and the number of things a user can do on them – there's some research into this at Flow Portal/Use cases.

The first release (live on English Wikipedia since February 2014) is a trial of Flow on just a few talkpage where community members have volunteered to test the software. Post MVP, we will roll out gradually to more pages and namespaces on a limited opt-in basis. At some point in the future, once the software is stable and a significant portion of active Wikimedians have had a chance to trial it and offer their feedback, we may mandate Flow on all discussion pages, but we have 1-2 years' worth of work ahead of us before that happens.

What pages will be Flow-enabled initially?
In the first release, we've enabled Flow on a few WikiProject talkpages. Throughout the rest of 2014, on English Wikipedia, we plan to enable Flow on more WikiProject talkpages, offer Flow as an opt-in Beta feature on user talk, and enable Flow on a small sample of article talk pages – all of these deployments will occur on an opt-in basis, with consensus from community members who use those discussion spaces.

Can I opt out?
During the early release period throughout 2014, Flow will be opt-in for existing users – you won't be forced to have it on your talkpage if you don't want it. If you convert to using Flow during the trial period (in a WikiProject discussion space, on your user talk page, etc.), we'll be able to convert the content back into a normal talkpage if needed. In terms of viewing, you won't be able to opt out of seeing Flow. If other users have converted their talkpages to Flow pages, or reached consensus that a Wikipedia or article talkpage should be converted, there's not going to be a way to avoid using Flow if you want to contribute to that page.

At some point in the future (no sooner than 2015), after a great deal of community testing and feedback, we may graduate the opt-in user talk trial to the default experience, enable Flow on new talkpages, begin converting existing talkpages to Flow, etc. If you're concerned about how Flow will look and behave, your best bet is to trial the software early, so you can give us feedback on what needs changing well before we begin discussion on whether or not it should become the default on all discussion pages.

What will happen to current talkpage discussions?
The current plan is to archive the talkpage and link to the archives from the talkpage header. Each Board has a header area, for permanent things like project banner templates and archive links to go in. See this copied article talkpage, or mw:Talk:Sandbox.

Ultimately, we plan to have a search feature for Flow that allows users to go through the pre-Flow archives and find content from there, too, but this is not part of the first release.

What about IP/anonymous editors?
Anonymous users will be able to use Flow-enabled talkpages as any other user. When Flow is more widely enabled, they'll have Flow-enabled talkpages (again, like any other user).

Why don't we use a pre-built system, like PHPBB or Discourse?
The simple answer is that "they won't cut it". The complex answer is that pre-built systems are designed around singular use cases, and Wikimedia projects do not have "singular" use cases. On the English Wikipedia alone, the following are discussions that take totally different forms: The list goes on and on. A singular package will not and cannot cover these cases. So we have to build our own.
 * User talk
 * Article talk
 * Requests for Comment
 * Request for Adminship
 * Deletion discussions
 * Merge discussions
 * Village pump discussions
 * AN/I
 * Arbcom cases

Why not use LiquidThreads?
LiquidThreads (LQT) was an early attempt at creating a structured discussion system. It has both strengths and weaknesses. After exploration and discussion, LQT was abandoned as a solution going forward for several reasons: incredibly poor performance, due to the way individual comments or posts are stored, parsed, rendered, cached, and assembled; no support for globally unique identifiers; and lack of flexibility with regards to workflows and collaboration techniques beyond simple discussion.

How will Flow handle spam and vandalism?
In the first release, each topic and individual post will come with a set of moderation features. These are:
 * 1) Hide (equivalent to reversion/rollback);
 * 2) Delete (equivalent to revision-deletion), and
 * 3) Suppress (equivalent to oversight or suppression)

Handling spam and vandalism in Flow should actually be easier than dealing with it on existing talkpages. Because Flow topics and comments exist as discrete elements, a specific post can be removed with a single set of actions: there's no need to go through the page history removing intervening comments, for example. In terms of spam, Flow is integrated with the AbuseFilter and the global and local Spam Blacklist.

Will Flow support wikitext or the VisualEditor?
Both. Flow is linked into Parsoid, which is the software that the VisualEditor uses to read and write wikimarkup. Hooked into that is a wikitext editor and, in later releases, the VisualEditor. Users will be able to pick which they want to use.

Will Flow support all the templates and other markup we need in discussions?
Yes. Whatever markup Parsoid supports, Flow can support. There may be restrictions on certain magic words or complex templates that affect performance, but, generally speaking, anything users commonly need to use (mathematical symbols, references, templates) can be added to a Flow post. You can see and test templates and other markup in the prototype, eg this thread has some examples. Note that we've only imported a few hundred test templates – more can be requested at w:Wikipedia:Flow/Top templates.

What happens to my custom signature?
Flow will not directly support custom signatures, for a couple of reasons. The first is that they're disruptive from a UI point of view. Custom signatures are great for letting people know who said what; they allow for a specific user to be easily, visually distinguishable in discussions. The problem is that the way this comes about is by allowing refactoring of where links live, how they're displayed, and so on. As a result, there's a complete lack of consistency, which hurts the ability of users to navigate easily. One user might have their talkpage link in one place – another in a different place, and with a signature that doesn't actually reveal their username. The second is technical; allowing people to add raw HTML formatting into Flow boards could cause serious issues and errors in how the page is displayed.

Having said that, we appreciate the advantages of custom signatures; it allows for some distinguishing elements, it allows for forms of identification that extend beyond username. We're going to be working a "preferred name" field into the interface to allow for the latter; while it won't be as malleable as the status quo, it will allow for some originality. Your own posts will be visually highlighted to be more easily findable.

Will we be able to edit other people's posts?
In the first release, no. Only administrators can modify the posts of others (anyone can edit topic titles, however). As with all design decisions at the early stage of this project, this is open to being revisited if it negatively impacts users.

Users being allowed to edit the posts of others is atypical and unexpected: nearly every discussion medium on the modern Internet does not allow this, because it breaks the expectation that the comment you are replying to is genuine, and that your comment will not itself be tweaked or corrupted by others. The need to meet this expectation should be balanced with the fact that the community has developed various workflows in discussions and in the talk namespaces that are dependent on that kind of editing and interleaving. See the list of situations where users need to be able to edit comments

How will you support all of the processes Wikipedia uses?
It's a complex problem, which is why we're starting with the most basic process – unstructured user-to-user discussion – first. Before we proceed to enable Flow in different namespaces, we will identify the critical workflows that need to be supported with software and build lightweight support for those processes: for example, a simple block/unblock workflow on new user talk pages. In the first 1-2 years of this project, we do not expect to cover 100% of the workflows across all our projects. Because each Wikipedia (and other Wikimedia sites) has developed its own workflows, based on the local social conventions, templates, categories, and bots, there is no easy way to discover all of these processes or build something based on feedback from one Wikimedia community and abstract it to other projects.

Longer term, once we've completed the discussion side of Flow, we may build a workflow engine – a structured language that editors can use to describe a workflow and incorporate it into Flow, for a specific action or a specific page.

Design FAQ
The initial design is experimental in nature and intent, and will be changing based on feedback and onwiki testing, over the coming months. You can read about the decisions that went into the current design at w:Wikipedia:Flow/Design FAQ, and discuss them at its talkpage. [Reminder: As of October 2013, the design on the prototype site is still full of holes.]