Structured Discussions/Community engagement

Background
The relationship between the WMF and the community shouldn't be about conflict, or about one side having dominance over the other: it should be collaborative. When conflicts arise, the solution is to compromise between what the WMF wants out of software and what the community wants out of software. In the past, both sides have failed at this process. What we'd like to do with Flow is establish a set of ground rules and principles that both sides implicitly agree to follow.

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 random (but intelligent) people at the WMF office, who are being brought in to play around with the software and give us 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 temporary labs instance (toro? ee-labs? unicorn? Someone, please tell us). A moderately-sized group of users will be invited to use the software and give feedback on it - primarily users who have demonstrated the ability to be constructive. 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 - who can productively critique the implementation of that premise. We fully expect them to tell us we're wrong, and for us to be wrong, and to have to course-correct: 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? - this will undoubtedly also hit talkpage stalkers/followers/random other editors, which is awesome. Our thoughts on who is good for this are unlikely to be canonical, and finding new people to participate is always a good use of time. Once we've got that feedback, we'll discuss it with the users and make tweaks to ensure both the developers and the editors are happy with the outcome (or, at least, equally unhappy. That's how consensus works).

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 consenting wikiprojects, probably just one or two. Flow will be deployed there and users invited to 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 were chosen or not chosen, and underlining that this is just an experiment. We expect to be substantially wrong about some things: we expect to get pushback. We then expect to alter course. 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.

???
Let's see how the others go!

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.