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

Sun Jan 11 19:08:22 UTC 2009

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 at gmail.com <Simetrical%2Bwikilist at gmail.com>> wrote:

> 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_%28technical%29/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_%28technical%29/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_%28technical%29/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_%28technical%29/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_%28technical%29/Archive&oldid=53776093>
>
> http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive&oldid=54982355<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 at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>

-- 
You have successfully failed!