On Thu, Sep 24, 2009 at 2:38 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Thu, Sep 24, 2009 at 4:28 PM, Brian Brian.Mingus@colorado.edu wrote:
I definitely think it's a good idea to go after the low hanging fruit
first,
which it sounds like is what they are doing with this 800k. Fixing the
core
of the problem is definitely not low hanging fruit - it's hard work. On
the
other hand, the foundation just got a couple million in unrestricted
funds,
and when I say that they can start fixing the problem at any time, I mean they can seek out an additional grant if necessary for this specific
issue.
Basically what I am saying is that I don't jive with the perspective that
we
should accept wikitext as it is and hack in new "fixes" on top of it. I would like to see the foundation go out and try to fix this problem the correct way, starting nowish.
They could do that. I wouldn't be surprised if they start serious WYSIWYG work in a year or two. But there are a *lot* of things on Wikipedia that could be improved. Even with the big grants Wikimedia's now getting, it operates on a budget less than 0.1% that of some comparably large websites (like Google).
Right now I hope we're going to focus on getting more full-time experienced programmers, like hiring a CTO and letting Brion become only senior software architect. We have lots of junior people doing work, but code review is still a huge bottleneck AFAICT. Just look at the current discussion on JS2, for instance, or the outages caused by performance problems that weren't caught before deployment.
Working through the current backlog of bugs definitely counts as low hanging fruit so I definitely agree that there should be more hackers on hand at the foundation and a CTO to guide them. On the other hand, given the admitted size of the wysiwyg problem and the large number of existing smaller problems it doesn't seem wise to to try and shoehorn it into the current usability initiative if we all agree that they already have their work cut out for them. The solution we come up with, for example this xml proposal for templates, could in practice end up being counter to our long term goals to standardize wikitext. It could quickly propagate throughout the wikisphere and not only will we have to deal with templates and parser functions, but now an entire form language. I think something much simpler and cleaner than all of that is desirable.