On Nov 14, 2012, at 6:37 PM, Erik Moeller erik@wikimedia.org wrote:
On Wed, Nov 14, 2012 at 10:31 PM, Steven Walling swalling@wikimedia.org wrote:
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 They've had that for over a year now, no javascript involved (view source).
* 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 successful.
So please, please, please. Stop discussing this hack. Yes, we could update that javascript 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 different link).
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.
This feature is not in need of javascript code. Any javascript, regardless of the shape or 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.
-- Timo