On Nov 14, 2012, at 6:37 PM, Erik Moeller <erik(a)wikimedia.org> wrote:
On Wed, Nov 14, 2012 at 10:31 PM, Steven Walling
But I want to fundamentally reject a norm I think
I am hearing here: that we
should be working toward perfection upfront, rather than iteration.
I don't believe that's a fair characterization of what's been said. My
main point is this: We need to take front-end performance and
maintainability seriously, and it can't become someone else's problem.
Forgive my boldness but here's a few points:
* We already ran the workaround js implementation 2 year ago. It works, it has proven
successful in user testing and afaik the people from the Usability Initiative still
believe so (Trevor, Roan, and co.)
* Wikia (not sure who was first with the idea) also did a similar thing. They also
experienced a positive effect and went ahead to proceed to non-hacky implementation
(altering the Skin and/or Parser to output the correct HTML, and add the relevant CSS to
the skin stylesheet).
For example: http://southpark.wikia.com/wiki/South_Park#History
* Last year, as if it wasn't enough, we ran the js-hack experiment again on English
Wikipedia for a while (with ClickTracking hooks on top of it). And once again, has proven
module and deploy it once again (all it needs is to remove old references to ClickTracking
again, the actual logic is still working fine. All it does is replace one link with a
Instead start focussing on an acceptable implementation for the long term. PHP Parser tree
markers, Skin output, edit section language fragmentation etc. those factors are relevant
for discussion. Those factors are what held us back 2 years ago from doing that in the
first place (because editsection links have a long history in MediaWiki PHP Parser,
they're hard to change due to their language connection to user instead of content
etc.). To become the default in MediaWiki.
form, related to this feature is by definition obsolete and temporary. One could even
argue and say this is outside the scope of the E teams. The usability team (which is sort
of a 2009 E-like team equivalent) has already proven this. We've been there, done
that. Now it is up to Platform to implement it for the long term in a way that doesn't
break our servers. We no longer need event logging and what not, it'll be like any
other native link in MediaWiki core.