On Sat, Jan 10, 2009 at 10:20 PM, Brian Brian.Mingus@colorado.edu wrote:
ParserFunctions are my specific example of how the current development process is very, very broken, and out of touch with the community.
However, the community as a whole has not objected to ParserFunctions. They were enabled with the full consent of the community. You seem to be claiming support that you don't have.
I believe that the introduction of ParserFunctions to MediaWiki was not done with community consensus
Source?
Is there *anybody* on this list that is willing to say that this is more usable than what we had before? http://en.wikipedia.org/w/index.php?title=Template:Infobox&action=raw
You cannot blame that on ParserFunctions. Notwithstanding some revert-warring by Netoholic, the template before ParserFunctions used {{qif}}:
http://en.wikipedia.org/w/index.php?title=Template:Infobox&oldid=4907322...
The only change attributable to ParserFunctions was the change from {{qif}} to {{#if}}. The rest of the increase in complexity is due to the community only.
You're attacking the wrong thing. You don't have a problem with ParserFunctions' introduction, in that historical context. Your problem is with the complexity of templates. Yes, that's potentially unusable, if you need to edit templates. Of course, the overwhelming majority of editors, particularly new ones, do not need to edit templates, only use them. ParserFunctions make it easier to use templates, not harder.
But the bigger point is that complex templates serve a purpose. They allow uniformity across the site with much less effort. The answer to any usability problems they cause is not to try abolishing complex templates -- that would make usability even worse. You'd have to subst in the infobox HTML for every article, which would make them even harder to edit; clutter up histories with bot changes (because that *would* happen); etc. The answer is to allow new editors to suppress complicated and confusing templates, or edit them in a more user-friendly manner. This is likely to be something that the usability work will address. Disabling ParserFunctions would solve absolutely nothing, and nor would have skipping it in the first place.
Of course, any individual wiki that wanted to could ask for ParserFunctions to be disabled. No community has even attempted this that I'm aware of, which says to me that your views are pretty idiosyncratic. If you think ParserFunctions should be disabled on enwiki, start a discussion there and get consensus. Good luck at even getting a *lack of* consensus in *favor* of them. I'd be a little surprised if you could get a single other person to agree with you.
On Sat, Jan 10, 2009 at 10:38 PM, Brian Brian.Mingus@colorado.edu wrote:
The proper way to do this is to provide a better user interface, not to add new syntax that takes an already Turing-complete template language to the next level.
There is a need on Wikipedia for complex user-generated logic. It's crystal-clear that this is how the community feels. The interface for *using* templates should be a lot simpler -- in fact, so should the interface for using all wikitext features, including simple stuff like italics. But the interface for *creating* complex templates necessarily cannot be very simple, any more than any interface to something really programmable can be very simple. This isn't a big problem, because the average user does not need to create or maintain complex templates.
On Sat, Jan 10, 2009 at 10:55 PM, Brian Brian.Mingus@colorado.edu wrote:
I don't believe the specific technical details that led to the development of ParserFunctions are all that relevant. It is always possible to implement a simple 'crash guard', so its not even that great of an excuse.
Only possible if you don't mind site functionality becoming unreliable, with some articles updated and some not.
No single person should have the power to develop and deploy such a thing on Wikipedia, even with the consensus of a tiny fraction of editors who were being inconvenienced.
The overwhelming majority of editors supported ParserFunctions' deployment, and the minority who did not have long since fallen silent as far as I know. If Wikipedians had asked for ParserFunctions to be disabled, it would have been. If they did that now, with demonstrated consensus, it still would be.
On Sun, Jan 11, 2009 at 12:43 AM, Brian Brian.Mingus@colorado.edu wrote:
Should ParserFunctions be reverted (a simple procedure by my estimate, which is a good thing) based solely on the fact that they are the most clear violation of Jimbo's principle that I am aware of?
I don't know who you think Jimbo is. He's the (co-)founder of Wikipedia and holds a seat on its board. He is not the director of technical affairs. He cannot give the developers direct orders on his own. What he says is not authoritative except *maybe* on the English Wikipedia, and then only if it's very specific.
And he has never objected to ParserFunctions in the past. You're the only one who's construing his principle (which was written years ago and can't be feasibly applied to the vastly larger communities today anyway) as applying to ParserFunctions.
On Sun, Jan 11, 2009 at 11:42 AM, Brian Brian.Mingus@colorado.edu wrote:
I believe this example is an even clearer demonstration of the usability disaster that is parser functions. And it is just the kind of thing that can be essentially snuck into MediaWiki without the complete community consensus. Perhaps that's not the case - I would be interested in reading a more complete history of the discussions around ParserFunctions if there are significant details I am missing.
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)... http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)... http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)... http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)... http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)... http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)...
I found this quote from Tim Starling particularly interesting:
"The main reason I'm calling it a trial is to avoid appearing to have made a unilateral decision to enable it permanently. The critics of this concept now have one final chance to turn community opinion against it, before it becomes ingrained. However the reception has generally been positive. I've received a number of private compliments on it, in addition to what can be seen publically."
Not a single objection was raised on the Village Pump in that time period. See also the mailing list announcement, which received more replies:
http://lists.wikimedia.org/pipermail/wikitech-l/2006-April/022548.html
There were some objections, but the objectors seemed to pretty clearly be outnumbered. (Especially if you ignore people making generic complaints about RTL support that actually had nothing to do with ParserFunctions.) The idea that this was a unilateral decision by Tim against the community's wishes is completely wrong, although he was the one who did it.