FWIW, for me as a power user who watches many discussions simultaneously on multiple wikis, a unified watchlist and more refined tools for watchlist management are among the features at the top of my development wish list.
Pine On Mon, Jun 9, 2014 at 6:51 PM, Erik Moeller <[email protected]> wrote: > On Mon, Jun 9, 2014 at 12:12 PM, Risker <[email protected]> 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 > > _______________________________________________ > Wikitech-l mailing list > [email protected] > https://lists.wikimedia.org/mailman/listinfo/wikitech-l > -- Pine _______________________________________________ Wikitech-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikitech-l
