On 9 June 2014 13:51, Martijn Hoekstra martijnhoekstra@gmail.com wrote:
On Mon, Jun 9, 2014 at 9:56 AM, Nathan nawrich@gmail.com wrote:
On Mon, Jun 9, 2014 at 5:30 AM, Martijn Hoekstra < martijnhoekstra@gmail.com> wrote:
That's precisely my point. Because current talk page discussions are -
on
the software level - unstructured, it allows social conventions to do everything you want it to do structure wise, and to invent new uses as
we
go. The domain model is just that complicated that we found that we
need
that power in implementation (even if we all(tm)[citation needed] agree that the current discussion form is pretty horrible UI wise). If you're going to force a software structure on in it will most likely not be as powerful[1] as what there is now and represents a trade off without us having a clear sight of what we will lose, even if we can have a
somewhat
clear picture of what we will gain: easier use and navigatability for
the
kinds of discussions we do support. Discussing a trade off where only
one
side is known is hard.
[1] i.e. a tree structure is far less powerful than what we have now to approximate the domain, a dag with dividable nodes probably comes
closer,
and is already fiendishly complicated to pull off on a UI level. And
then I
haven't even gone in to the current practices of taking a comment back
by
striking it, which means that nodes aren't only arbitrarily and
multiply
dividable, but also mutable over time in a linear(?) history? 'sblood
man,
discussions are complicated.
-- Martijn
The assumption I think you are making here is that the goal is to get a discussion system with maximum functionality and flexibility.
The assumption I am making is that Flow will (not may, or aims to, but will) replace all current discussion mechanisms on all(?) Wikipedias[1], and possibly all other WikiMedia projects as well, and that if that happens, we should know which trade-offs we are making when we're doing away with the virtual unlimited structuring power before we do.
So I think a much better goal, and one that I know others share and has
been the focus of development work, is to adopt a system of communication that is easy and intuitive for as many participants as possible.
yes, please! But again, at what cost? What are the possibilities we are going to lose when Flow is turned on? Will we know before it's turned on? Should we discuss it before it's turned on? I would think so. We're talking about taking away most power of our current discussion system, and since it's a social system rather than a technical system, it's difficult to define all ways we are currently using it, and how valuable each of those ways is.
This may mean the problem of inventing a better mousetrap needs to be set aside in favor of determining what mechanism is the most familiar and easy for the majority of Wikimedia users.
This is simply insufficient. If Flow replaces all talk, all processes will have to be re-tailored to use Flow. AfD, RfA, ArbCom proceedings, mediation, Sockpuppet investigations, FA evaluations, RfCs, they will all become Flow. While it is very important that we have a mechanism that is easy to use, it must be powerful enough to accommodate all these processes. They're going to need re-engineering, but I'm afraid that in some cases we will lose more than we'll be willing to swallow in order to make other discussions easier to participate in. I'm not only willing but very much hoping I will be proven wrong. But from where I'm standing, with the only possible exception of AfD and SPI, I can't see yet how tree-based software will handle these processes. It would be interesting to see a random RfA, ArbCom case, mediation case, and FA nom and an RfC being "flowified", so we can take a look how the new processes will work on a techinical level, and what problems turn up.
[1] http://www.mediawiki.org/wiki/Flow: "Flow is a project of the Core features http://www.mediawiki.org/wiki/Core_features team at the Wikimedia Foundation to build a modern discussion and collaboration system for all Wikimedia projects. Flow will eventually replace the current Wikipedia talk page system"
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.
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. And the biggest challenge there isn't the code, it's the community interaction, negotiating the prioritization rules for who gets to keep a username (which currently varies widely amongst projects) and working with users whose longtime Wikimedia identities will have to be changed. This is optimistically a year-long project that's been passed around amongst WMF staff for years as if it was a hot potato. Well, I guess it actually is, so I can see why. But if this is hard, then I don't understand why anyone would think that forcing projects to conform to WMF's vision of how they should manage everything from Wikiproject templates to content quality reviews to RFA to any other process that isn't actually creation or editing of content is going to be perceived as anything but the WMF sticking its nose into areas that are none of its business.
Risker/Anne