[Foundation-l] Why is the software out of reach of the community?

[Aryeh Gregor]

On Sat, Jan 10, 2009 at 10:20 PM, Brian <Brian.Mingus at 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=49073226&action=raw

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 at 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 at 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 at 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 at 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)/Archive&oldid=49208103
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive&oldid=50342128
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive&oldid=51448619
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive&oldid=52579836
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive&oldid=53776093
http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/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.