On Mon, Jun 9, 2014 at 12:12 PM, Risker risker.wp@gmail.com wrote:
This. Nobody, but nobody, asked the WMF to create this sort of system, and it is a rather quixotic goal given that each project has its own set of workflows.
Hey Anne,
We're of course pretty familiar with many of the highly specialized workflows that exist across wikis, and have had lots of conversations about how/when we could improve such workflows. Brandon originally titled the system "Flow" because of precisely that reason - the idea that Flow would provide building blocks through which workflows can be created, much the same way that an ordinary wiki page provides a very flexible mechanism by which users can create their own workflows.
To keep the project manageable, however, I recommend a more staged approach: Solving for discrete use cases that can reasonably be solved with a new user experience, testing/validating whether the new user experience is in fact superior to the old one, and iterating from there. In this process we need to be wary of UX fragmentation -- but I think this is reasonably manageable as long as we're careful how we're staging use cases (e.g. I don't think it's unreasonable for a page like the Teahouse to have a different UX than an ordinary article talk page).
Danny knows that I'm worried about the user talk page use case (called out in the goals) in that respect, because it represents a possible major fragmentation (old user talk vs. new user talk). My recommendation so far has been to target use cases where there exists local consensus to support them _and_ fragmentation of the user experience can be avoided.
Beyond just managing scope, I think it's important to recognize that wiki-based workflows like AfD and RFCs are built around what a wiki allows you to do. If it's easy to tag comments/threads in such a way that they show up on relevant noticeboards, this may enable completely new workflows that are significantly simpler. So I think we need to be careful when modeling a new user experience to not just try to "copy the old one, but better". We may find that users actually like some of the capabilities a new tool creates, just like Echo's completely new, never-asked-for mention notifications became very popular, very quickly. :)
It's absolutely true that Flow is a risky project, but it's not true that it's designed to solve problems nobody's asked to be solved. You yourself quoted some of the issues with talk pages. And did you attend Jimmy's talk at Wikimania (I think 2012) about how difficult it is to perform simple tasks in the wiki precisely because every workflow is wiki-based? I absolutely want to make sure that WMF solves real problems and not just imagined ones -- but you'll need to allow for people in WMF to have reasonable debates (with each other, and with the community) about what the solutions could look like, and to try different approaches.
Meanwhile, core tasks like SUL finalisation are languishing on the back burner, to the detriment of several other projects and products. Yes, I know it's on the roadmap for Mediawiki Core in Q1 starting in July - but it will not be the priority product for any of the three people tasked to it.
It's indeed a complex migration that needs to be done carefully, as any issues would be difficult to resolve/debug and could cause massive angst. And it needs to involve people with deep Wikimedia subject matter expertise, and folks from the MediaWiki core team. Engineers aren't fungible -- we have to schedule a project like that with the folks who're best suited and most interested in working on it, and that's what we're doing. But we've scheduled it, and we'll take that commitment seriously, so please do hold our feet to the fire if we try to kick the can down the road.
Erik