On Mon, Jun 9, 2014 at 12:12 PM, Risker <risker.wp(a)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
--
Erik Möller
VP of Engineering and Product Development, Wikimedia Foundation