Flow/MVP

This document outlines the high-level requirements for the first release of Flow as an opt-in beta to Wikipedia; specifically, to a subset of WikiProject discussion spaces where users have agreed to trial the software. These requirements are subject to change, and very much open for discussion.

Rationale
Users of Wikimedia projects need a lean, responsive, modern interface for collaboratively improving content. WikiProject discussion pages are one of the places where peer-to-peer content collaboration occurs. The first release of Flow to a live Wikimedia project will be geared toward tackling the core needs of Flow as a peer-to-peer content discussion feature in the WikiProject talk space.

This release aims to support existing discussion workflows (talking about content, including markup from that content), as well as improve the user experience of talk pages by facilitating:


 * 1) Productive, efficient discussions that resolve the issue at hand quickly. E.g., It should be fast and easy to ask and answer a question.
 * 2) Transparency and clarity of communication to ensure good-faith dialog among peers. E.g., It should be easy to get a sense of the main points of a discussion and understand who is addressing whom.
 * 3) Ease of use, inviting users to participate if they have something constructive to add to the conversation, regardless of their level of experience with the WikiProject, the Wikimedia project, or with editing wikis in general. E.g., a volunteer translator with no Wikipedia editing experience who is assisting a WikiProject should feel comfortable discussing her translations in the WikiProject discussion space.

In addition to providing users with intuitive, easy-to-use discussion software that allows them to collaboratively improve content, we need to ensure that users can quickly and easily moderate sensitive or offensive comments.

Inspiration
(Adapted from a discussion during first release planning in Agile Training.)

Every release planning, I like to say things that are inspirational for the release.

I've been struggling with something Vibha said the first day, "It feels like we're writing enterprise software." How do I feel inspired to do this thing when people using it don't seem real people?

I am really excited on working on Flow because I love Wikipedia and want more Wikipedians. And yet, the tension we face is between openness and health. What our jobs are at the Foundation is to respond to a call by the Board for openness (there was a Board Resolution on this), but since 2006 we've been closing up, being harder to use, creating workflows people can't participating in. Our job is to start correcting that through any means necessary.

But, there are costs to openness. We know this because we've tried to do this and seen it. On the Mobile web we introduced an upload button and found a lot of uploads were not good. In Article Feedback Tool, we wanted to encourage readers to participate, we got a lot of people but a lot wasn't useful, the readers were talking but they didn't understand how Wikipedia worked, they weren't there.

In addition to that, in both cases, someone on the Wikis had to do something about the stuff being created, and the community is really tiny and not paid staff members. When we flood them with crap, they understandably get mad at us. If we don't give them tools to deal with it, then what? Their current tools were self-created and right now are brittle; they don't have resources to create stuff that solves problems for themselves.

It was 6 or 7 years ago that comments became a thing on Internet. I remember the first day, I thought we'd see some brilliant minds on places like the New York Times, discussing deep, important issues. Instead what we got was a lot of: “FIRST POST!” “Jake is queer, Kyle rulez”, and Truthers. Remember the amazing potential that fizzled?

The world dealt with this by locking everything down, or they paid staff to deal with stuff. What you see today is a meticulously curated discussion, karma points, paid moderation, etc.—it's a lot of software and money being spent to solve that problem.

We don't have the luxury to do that.

We also have a community that has formed in 10+ years that is incredibly passionate about the project. You can't roll out a karma point system, and don't have the resources to extract that data.

What we can do, we can take this existing set of users, and empower them with actual software that does those things.

For me, that is going to be how this project lives or dies. We are creating the balance between openness (a giant reply button everywhere) and health. But we don't know what's going to happen (10,000 penis-drug commercials?). We have to build them, and the tools to make it a healthy system.

Does that get you excited about building tools for suppressing inappropriate content? :-)

…

What does this mean for new users? Initially Flow will be a discussion system that's usable by human beings, not experts in wikimarkup and wiki-policy and bots. That's a start! Most of the work here is not because discussion is a solved problem, because that is solved. The draw for new users will be the interface stuff, true; but we have to add these other features to make it succeed—and all the paperwork to do that.

Our vision statement covers every single being, and it's a big world out there with over a billion users right now, and we are trying to build something that reaches down to them.

…

Remember, there are many things in Wikipedia that don't resemble discussions on the web. Wikipedia discussions concern concrete outcomes, not discussion for discussion sake. Wikipedians use them for Workflows, not just talk. There is no "flag" button, and there is no place elsewhere where anyone is empowered to just edit things. If someone says, “You're a huge idiot bitch, but …” I'm supposed to remove the first, but keep the second.

If the reason we're doing agile is to keep the cost of change low, then the most likely source of change is from the existing community; the biggest risk is if they reject that software. But even if this group represents the biggest risk, it's also a great opportunity. Because if you build something that speaks to them, that empowers them, they will demand it…and then we can sit back and let the money roll in :-D.

It's the most interesting cultural problem of Wikipedia and its biggest challenge: the Wiki means you can do something about it. We need to build a discussion system for that.

Proposed user experience
A Flow-enabled WikiProject discussion space will become a structured discussion spaces with the following features:


 * A configurable header area (for information about the discussion space, links to archives and FAQ, or any other information that the WikiProject facilitators deem useful)
 * A "start new discussion" affordance, containing:
 * a dialog for naming and starting a new topic
 * A list of topics, in order of most recently updated to least recently updated, top to bottom. Each topic contains:
 * an editable title
 * an affordance for collapsing or uncollapsing all comments in the topic
 * a history view of the topic, including modification and state changes of each child element (edited, hidden, unhidden, etc.)
 * Threaded replies. Each individual comment contains:
 * whom the comment was posted by (automatically generated signature)
 * a human-readable timestamp indicating when a comment was posted and when it was last modified (and by whom, if not the original poster)
 * Parsoid compatibility, allowing users to copy-paste markup for most templates and advanced wiki syntax (math, IPA symbols, etc.) into their comments
 * an affordance for editing a comment (available to those with correct user rights)
 * an affordance for hiding or unhiding a comment – hidden comments will leave a placeholder visible to all users
 * an affordance for deleting or undeleting a comment (viewable only for administrators) – a deleted comment will leave a placeholder visible to all users
 * an affordance for suppressing a comment (viewable only for oversighters) – a suppressed comment will only be viewable to oversighters
 * a history view of the comment, including modification and state changes (edited, hidden, unhidden, etc.)
 * Topics and comments will not be archived; instead, they will be lazy-loaded, with less recent conversations accessible by scrolling down.
 * A search box to search the contents of the board for:
 * Topic title
 * Post authors
 * Post content