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

Gerard Meijssen gerard.meijssen at gmail.com
Sun Jan 11 18:01:14 UTC 2009


Hoi,
I mentioned it before, the Neapolitan wikipedia decided to do away with
templates because it prevents people from contributing to their project. It
works for them not to use templates.

Please do not understand this as a request to do away with templates.
Templates are an important impediment for new people to contribute to our
projects. I hope that the Stanton project will help us improve the usability
of templates because that is sorely needed. We are currently at a point
where the parser functionality is its own worst enemy from a usability point
of view.
Thanks,
      GerardM

2009/1/11 Aryeh Gregor
<Simetrical+wikilist at gmail.com<Simetrical%2Bwikilist at gmail.com>
>

> 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
>


More information about the foundation-l mailing list