On 9 June 2014 13:51, Martijn Hoekstra <martijnhoekstra(a)gmail.com> wrote:
On Mon, Jun 9, 2014 at 9:56 AM, Nathan
<nawrich(a)gmail.com> wrote:
On Mon, Jun 9, 2014 at 5:30 AM, Martijn Hoekstra
<
martijnhoekstra(a)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