[Foundation-l] Big problem to solve: good WYSIWYG on WMF wikis

MZMcBride z at mzmcbride.com
Wed Dec 29 05:13:16 UTC 2010


David Gerard wrote:
> Our current markup is one of our biggest barriers to participation.
> 
> [snip]
>  
> * Tim doesn't scale. Most of our other technical people don't scale.
> *We have no resources and still run on almost nothing*.
> 
> ($14m might sound like enough money to run a popular website, but for
> comparison, I work as a sysadmin at a tiny, tiny publishing company
> with more money and staff just in our department than that to do
> *almost nothing* compared to what WMF achieves. WMF is an INCREDIBLY
> efficient organisation.)

You inexplicably posted this to foundation-l, so let's look at this from an
organizational/political standpoint.

The issue isn't a technical one, though there are technical challenges, to
be sure. The issue is one of priorities. If there were a grant involved,
Wikimedia would find a way to push out some half-assed code at the eleventh
hour. If there were some way to tie this to fundraising, you could get one
or two full-time developers working on this, plus a staff of "associates."
But this isn't tied to a grant and it isn't fundraising-related. It isn't
glamorous work and it doesn't directly involve money, so it's left in The
Pile next to the thousands of other ideas that desperately need attention.

Or put another way, "this seems like far better outreach than a thousand
outreach officers."

It's clear where Wikimedia is putting its priorities. Screw being able to
click edit on the "Microsoft" article and not wanting to kill yourself,
in-person wiki editing training is the way forward! Or so the funds flow.

The saving grace of this idea (i.e., the reason it might one day move
forward) is that, as you note, easier editing bolsters participation. And if
one thing has been made clear through the strategic planning charade, it's
that participation is actually viewed as very important to Wikimedia.
Quality be damned, Wikimedia wants quantity. It's this attitude that might
finally drive some resources toward making the edit screen less of a
nightmare, but I wouldn't hold my breath. It still assumes a higher level of
competence than has been demonstrated historically.

All of this sidesteps that even if you had a brilliant extension/patch that
could solve this problem (and it's not as though such a patch or extension
would be simple), the likelihood of it being committed to SVN and going live
before 2012 is pretty low. (Unless, again, there were a grant attached.)

I think this is an important problem that deserves thoughtful consideration
and attention. Which of course begs the question of why you think Wikimedia
will be the one to solve it. This is the prime target for a competitor
coming in and making something better. Why stand in the way?

MZMcBride






More information about the wikimedia-l mailing list