Structured Discussions/Community engagement

Background

The relationship between the Wikimedia Foundation and the volunteer community shouldn't be about conflict, or about one side having dominance over the other; it should be collaborative. Both the community and the Foundation share a common goal – to grow and improve the sum of all human knowledge. When conflicts arise, the solution is to come to a consensus that brings us closer to that goal.

In the past, we have spent too much time in conflict and not enough in collaboration. When staff and the community fail to work together, we don't just foster hostility and grudges; we all waste time, energy, and resources that could have been better spent improving Wikimedia projects. We're not going to promise that, from now on, everyone will always be in agreement on everything, but we will promise to learn from the past and experiment with new ways of doing things that offer us a shot at working together better and more efficiently.

What we've learnt so far

Discussions within the community often don't reach WMF staff, and vice versa. We don't have a good system for communicating with a large, decentralized body of volunteers.
Massive, rapid deployments annoy users and overwhelm development teams with feedback all at once.
Bringing users into the conversation at the end of the development process makes it hard for their feedback to be incorporated. Ideas gather inertia, particularly when implemented, so it's hard to change course.
Users who have taken the time to learn a particular way of doing things on a wiki have some natural resistance to change. They need a clear rationale for change, so they can understand the tradeoffs between maintaining and breaking with the status quo.

What we'd like to try with the Flow project

To avoid the problem listed above, we've come up with a simple set of ground rules that both groups can follow:

The Flow team will deploy slowly and incrementally – on a page-by-page basis at first, and only with the consensus of those using the pages – and will target smaller subsets of the community (WikiProjects) for both the release and feedback. This will make it easier to have a focused conversation on the specific needs of community members who are actually using the software.
Community members (both those who are the target audience of a release and the wider community in general) will be invited to participate in the development process throughout the release cycle: before we release anything to Wikipedia, and after the first and subsequent releases. Nothing will be set in stone – we expect Flow to evolve rapidly and significantly based on community feedback at each stage of the process.
Staffers commit to responding to good-faith concerns from users, treating them with the same weight as concerns from any other member of the WMF design or development team.
Community members who want to see specific changes to Flow commit to acting in good faith, and to engaging in a conversation about how the changes they want will further the goal of making Wikipedia discussion easier, faster and more intuitive for everyone. WP:IDONTLIKEIT is not an acceptable position from either the community or the staff side.

In summary

For this collaboration to be successful, both the WMF and the community must commit to a shared set of goals and engage in an open, good-faith dialog about how their ideas further those goals. Neither WMF staff nor the community have all the answers; both sides need to complement each others' skills and knowledge. Staffers will be expected to treat community members as an equal partner on the Flow team and will actively solicit their feedback on design and development ideas. But they won't be under an obligation respond to actively uncivil or bad-faith comments. Users who do not not share the view that discussion on Wikipedia can or should be made more accessible to everyone are still free to participate in discussions about Flow, but their feedback will not inform the development process.

Release plan

For the remainder of 2013, we've plotted out two, small-scale releases, only one of which is to active projects, along with a set of informal feedback sessions for different user groups.

Pre-release feedback sessions

The first set of interactions with Flow won't be formal releases or active software: they'll be discussions. The first will take place in the WMF office and involve user experience designers, developers, and anyone interested in open source software or discussion systems, who will be invited to test out an early Flow prototype and give feedback. In this session, we will be testing for UI/UX best-practices and newbie friendliness. The second will be an office hours session in #wikimedia-office and will be open to anyone from the editing community who wants to attend. The goal will be to get experienced user feedback on the latest design iterations and workflows, ask some questions, and get a general idea of where sticking points are likely to be, so we can figure out what needs to be addressed before the sandbox release. The outcome of both discussions will be documented and shared.

In addition to these more structured sessions, the Flow team will participate in discussions on the Flow portal talk page and sporadically solicit user feedback on design and feature ideas. Anyone interested in talking with us should follow the Flow portal main page and talk page, or come find us in IRC: #wikimedia-corefeatures ^connect

Sandbox release

The first release is a "sandbox" release, in which the set of features that we've identified as the minimum viable product will be put on a test wiki (ee-flow.wmflabs.org). Anyone is welcome to test it out and give feedback, though we will personally invite a moderately-sized group of users – those who are actively involved in a WikiProject and/or have expressed interest in collaborating with us on Flow. We fully expect this process to generate new ideas, challenge assumptions, and raise critical issues that we must fix: that's what the process is there for. As outlined in the ground rules above, anyone is free to comment on our work, but in order for community feedback to be incorporated into the next release, it must come with a rationale for how it will make discussion on Wikipedia faster, easier, and better.

At the end of this process, we'll discuss with community members whether the first release of Flow is ready to be piloted on a WikiProject discussion space, or whether there are still outstanding issues that need to be fixed before it goes live. Ultimately, it'll be up to WikiProject members to make the call.

Wikiproject release

The first on-wiki release will be small-scale, in line with the team's principles and motivations. Targets are the discussion spaces of a small number of Wikiprojects whose members have agreed to a beta trial of Flow. We'll deploy and invite users test it out and use it as they normally would a Wikiproject talkpage. Any feedback they might have – good or bad – will be gathered on the Flow portal talkpage. This page will be archived to avoid confusion between older and newer discussions and will also be converted to use Flow, as a way of forcing us to confront deficiencies in the software we expect others to use.

Before this release, the team will produce documentation explaining the software, why specific features and designs were chosen or not chosen, and highlighting that this is just a trial, not a finished product. We expect this trial period to generate a discussion, and we will make changes to Flow based on that discussion. Documentation will also be added to the Flow talkpage, making transparent the behavioural guidelines we'll be adhering to, and the behavioural guidelines we expect users to adhere to in return.

Later releases

Based on the outcome of the WikiProject release, the Flow team and the community will decide whether we need to:

End the trial and temporarily revert back to talkpages (all Flow discussion content will be turned back into free-form wikitext) while we implement any necessary changes
Continue in beta, adding more features on a case-by-case basis and giving more WikiProjects the option to opt into Flow

If the trial is successful, we will also begin working on a strategy to roll out to other discussion spaces (e.g., article talk, user talk) in a similar incremental fashion

Community participation in development

We tend to announce and discuss changes on the public wikitech-l mailing list.

Like the rest of MediaWiki software, the Flow code is open source. Anyone is free to examine and modify it. Some fruitful areas for developer participation include:

Flow bugs marked "easy" in bugzilla.
User CSS & JS or gadgets to experiment with changing the appearance and interaction of Flow pages.
Use the Flow API actions in MediaWiki action API to get information about Flow pages and write or adapt "bots" to work with Flow boards and topics.
The Flow team sometimes identifies a feature for Mentorship programs such as the Outreach Program for Women and Google Summer of Code.

Timelines

April 2016: Flow satisfaction survey - More and more communities are using Flow and suggest to improve some details to have a better experience. With this survey, we want to know what is your opinion concerning Flow as a user, and, maybe, have good leads to add future developments in 2016 Q1 (July-September 2016).