Simetrical,
Thanks for your research. I have read the links you sent in full. Here is the motivation for developing developing parser functions:
"*In response to a campaign by users of the English Wikipedia to harrass
developers by introducing increasingly ugly and inefficient meta-templates to popular pages, I've caved in and written a few reasonably efficient parser functions.*" -- Tim Starling 15:25, 5 April 2006 (UTC)
I see on Village Pump (technical) and wikitech-l, in addition to an associated talk page, that there was a vocal group of people who objected to parser functions and that they were ignored and the extension was enabled anyway.
At all Wikimanias I have been to, including ones in 2006 and 2007, there have been discussions on usability where the audience contains 50-100 people. There is always an inspired discussion about how awful wiki syntax is. You are correct that I do not like templates, but I do not blame that on a process that still exists. It certainly would be interesting to know the history of the implementation of templates, if anyone knows that. The point is that I am aware of a much larger community than I see in these links that would have at least liked to have a meeting of the minds on parser functions before they were enabled. The community was apparantly bypassed by the developers. Compare the process here to that which Guido uses in the Python community: "*A quick poll during my keynote presentation at PyCon 2007 shows this proposal has no popular support. I therefore reject it.*" -- Guido
I strongly disagree with your point that a lack of uprise in the community against parser functions is evidence that they should have been implemented. Uprise take a lot of energy - certainly a lot more energy than the "few hours of work" that Tim put into them. As a previous poster pointed out, "I would bet there's at least one template that uses a ParserFunction on 75% or more of all the articles on enwiki." MediaWiki effectively has a programming language in it because of a few hours of developer work and a few minutes of conversation. A programming language that, apparantly, cannot be reverted.
I have been to the developer presentations at all but one Wikimania, and they are dissapointing. I don't really see new ideas for features being presented to the community, and I do not believe that the developers ideas are *a priori* better than the community ideas. The presentations put together by community members are better thought out, more polished, more comprehensive and more inspired than those that come from the developers. And they are often ignored by the developers. I reject the argument they do not have time. Over the course of years, I expect that a CTO would both the time, inspiration and technology vision to recognize something amazing when he saw it, and take it upon himself to review it, rather than implement a new interface for the iPhone.
I maintain my position that the process of adding new features to MediaWiki is broken, and that it happens largely at developer whim. I am discouraged that Erik believes we should maintain the broken status quo, and kludge a WYSIWYG on top of it.
On Sun, Jan 11, 2009 at 10:13 AM, Aryeh Gregor < Simetrical+wikilist@gmail.com Simetrical%2Bwikilist@gmail.com> wrote:
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_%28technical%29/Archive&oldid=49208103
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)...http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29/Archive&oldid=50342128
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)...http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29/Archive&oldid=51448619
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)...http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29/Archive&oldid=52579836
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)...http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29/Archive&oldid=53776093
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)...http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_%28technical%29/Archive&oldid=54982355
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.
foundation-l mailing list foundation-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l