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, both sides have failed at this process. By failing to collaborate, we all waste time, energy, and resources on conflict – resources that could have been better spent improving Wikimedia projects. We're not going to promise that from now on, everything will be perfect, but we will promise to learn from our failures and experiment with new ways of doing things that offer us a shot at working together better, faster, and more efficiently.

What we've learnt so far

 * 1) Discussions within the community don't reach WMF staff, and vice versa. We don't have a good system for communicating with a large, decentralized body of volunteers.
 * 2) Massive, rapid deployments don't work; they annoy users and overwhelm development teams with feedback all at once.
 * 3) Bringing users into the conversation at the end of the development process doesn't work. Ideas gather inertia, particularly when implemented, so it's hard to change course.
 * 4) Users who have taken the time to learn a particular way of doing things on a wiki will always have some natural resistance to change. They need a clear rationale for the changes being proposed, 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:


 * 1) The Flow team will deploy slowly and incrementally – on a page-by-page basis at first, and only with the consensus of those using that page – without forcing everyone to switch to a new system all at once.
 * 2) Community members 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. As much as possible, our design and development work will evolve transparently, with the expectation that nothing is set in stone.
 * 3) Staffers commit to responding to good-faith concerns from users, treating them with the same weight as concerns from the design or development team.
 * 4) Community members who want to collaborate with the Flow team commit to acting in good faith, and to commenting in a way that furthers the goals of Flow: to make talkpages easier, faster and more intuitive to use for everyone.

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 to interact with users who are actively uncivil, assume bad faith, or do not share the view that discussion on Wikipedia can or should be made more accessible to everyone. Those users are still free to comment on our work, of course, but their feedback will not inform our development process.

Releases
At the moment we've plotted out two, small-scale releases, only one of which is to active projects, along with a set of informal discussions for different usergroups

Discussions
The first set of interactions with Flow won't be formal releases or active software: they'll be discussions. Two of them, in fact. One of them will be with user experience designers, developers, and anyone interested in open source software or discussion systems, who are invited to test out an early Flow prototype and give feedback on how it looks to people unfamiliar with Wikipedia. The other will be an office hours session in #wikimedia-office with editing community members, and will be open to any editor who wants to attend. Our intention here is to get feedback on the latest design iterations and workflows, ask some questions and get a general idea of what sticking points there are likely to be, and where we need to put additional thinking in.

The office hours session will be advertised via the normal venues - the village pumps, the office hours page, and potentially the mailing lists. Quiddity, thoughts here? In terms of when it'll be, it would probably be best to have it aroundabouts the 15th: that way feedback from both groups can be synthesised, instead of redesigning Flow in one direction and then the other.

Sandbox release
The first release is a "sandbox" release, in which Flow 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. This is fundamentally not "people who agree with us"; you can agree with us and be non-constructive, or disagree with us and be totally constructive. What we're looking for is people who accept the fundamental premise of Flow - that the confusing nature of talkpages is impeding user and project development - and who can productively critique the implementation of that premise. 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.

Said users will be sent talkpage notifications inviting them to play around with the prototype and give feedback where do we want them giving feedback? -- via Flow! :) Or, I dunno, a wiki page + IRC, I guess? - this will undoubtedly also hit talkpage stalkers/followers/random other editors, which is awesome. Once we've got some feedback, we'll discuss it with the community and decide on a course of action that ensures all parties - developers, designers, and community members - are happy with the outcome.

Wikiproject release
The second release - and first on-wiki release - will be small-scale, in line with the team's principles and motivations. Targets are the talkpages 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 directed to the Flow portal talkpage. This talkpage will also be converted to use Flow, as a way of forcing us to confront deficiencies in the software we expect others to use. Additionally, the talkpage will be blanked some time before the deployment to allow a "reset" of the conversation, with old threads archived off and users encouraged to hold their thoughts until the release version is live, rather than relying on outdated discussions.

For 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 an experiment. We expect this to be a discussion, and we will make changes to Flow based on that discussion. Documentation will also be added to the Flow talkpage (in the metadata space) 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:


 * 1) 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
 * 2) 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

Open tasks

 * Quiddity
 * Identify people to invite to the sandboxed release
 * Get documentation ready for the Wikiproject release
 * Advertise Office Hours


 * Oliver
 * custos to Quiddity and Maryana


 * Maryana
 * Find wikiproject
 * Review documentation/socialisation plan, when ready.