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

[Brian]

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.

When Guido van Rossum makes a change to Python as seemingly trivial as a
switch statement, he writes a formal description of the change. The change
is then discussed on community mailing lists for a long period of time, and
it is compared directly to other submissions. He then polls the community
regarding the change at his keynote address, and rejects it if there is no
popular support. http://www.python.org/dev/peps/pep-3103/

There absolutely are people out there who would like to have a larger voice
in wiki syntax, WikiCreole comes to mind.  These folks have usability in
mind. ParserFunctions do not.

"*Any changes to the software must be gradual and reversible.* We need to
make sure that any changes contribute positively to the community, as
ultimately determined by everybody in Wikipedia, in full consultation with
the community consensus." -- Jimmy Wales

On Sun, Jan 11, 2009 at 9:11 AM, Alex <mrzmanwiki at gmail.com> wrote:

> Brian wrote:
> > I believe it is possible to expand the parser functions in place in a
> > non-destructive way. There are always edge cases of course.
> > But if it is not possible, it is a clear violation of a core wiki
> principle
> > - that all changes be easily revertible.
> >
>
> ParserFunctions was checked into SVN in April 2006, presumably enabled
> around the same time. Its had nearly 3 years for ParserFunctions to
> integrate themselves into wikitext. By expanding them in place, you're
> going to be replacing the infobox syntax in articles with table syntax,
> hardly an improvement. To use a real example:
> {{Infobox Mountain
> | Name = Mount Blackmore
> | Elevation = 10,154 feet (3,094 m)
> | Location = [[Montana]], [[United States|USA]]
> | Range = [[Gallatin Range]]
> | Coordinates = {{coord|45|26|40|N|111|00|10|W|type:mountain_region:US}}
> | Topographic map = [[United States Geological Survey|USGS]] Mount
> Blackmore
> | Easiest route= Hike
> }}
>
> would be replaced by something like:
>
> {| cellpadding="5" cellspacing="0" class="infobox geography vcard"
> style="border:1px solid #999966; float:right; clear:right;
> margin-left:0.75em; margin-top:0.75em; margin-bottom:0.75em;
> background:#ffffff; width:305px; font-size:95%;"
> |- class="fn org"
> ! style="text-align:center; background:#e7dcc3; font-size:110%;"
> colspan="2"| Mount Blackmore
> |-
> |- class="note"
> | style="border-top:1px solid #999966; border-right:1px solid #999966;
> background:#e7dcc3; width:85px;" | [[Summit (topography)|Elevation]]
> | style="border-top:1px solid #999966; width:220px;" | 10,154 feet (3,094
> m)
> |-
> | style="border-top:1px solid #999966; border-right:1px solid #999966;
> background:#e7dcc3;" | Location
> | class="label" style="border-top:1px solid #999966;" | [[Montana]],
> [[United States|USA]]
> |-
> | class="note" style="border-top:1px solid #999966; border-right:1px
> solid #999966; background:#e7dcc3;" | [[Mountain range|Range]]
> | style="border-top:1px solid #999966;" | [[Gallatin Range]]
> |-
> | style="border-top:1px solid #999966; border-right:1px solid #999966;
> background:#e7dcc3;" | [[Geographic coordinate system|Coordinates]]
> | style="border-top:1px solid #999966;" |
> {{coord|45|26|40|N|111|00|10|W|type:mountain_region:US}}
> |-
> | style="border-top:1px solid #999966; border-right:1px solid #999966;
> background:#e7dcc3;" | [[Topographic map|Topo map]]
> | style="border-top:1px solid #999966;" | [[United States Geological
> Survey|USGS]] Mount Blackmore
> |-
> | style="border-top:1px solid #999966; border-right:1px solid #999966;
> background:#e7dcc3;" | Easiest [[Climbing route|route]]
> | style="border-top:1px solid #999966;" | Hike
> |-
> |}
>
> I'm not making this up. I picked a random, small infobox from an article
> on Special:Random, and expanded it with Special:ExpandTemplates. Like
> them or not, ParserFunctions do a pretty good job of hiding complex
> wikitext from the average user, by putting it all in the templates.
> Without them, you have to A) put the tables directly into articles,
> which is a lot worse looking than using an infobox, B) Use the infoboxes
> and show all the unused fields as blank (which is ugly to the readers as
> well), C) Go back to using the pre-ParserFunctions template hacks, or D)
> Replace all the infoboxes with SMW.
>
> Of course, infoboxes aren't the only use of ParserFunctions in
> templates. They're used in all of the "maintenance templates" like
> {{cleanup}} on enwiki, I would bet there's at least one template that
> uses a ParserFunction on 75% or more of all the articles on enwiki. Most
> could be substituted a lot easier than the infoboxes, but the question
> is, why? Why make the wikitext in articles harder to edit by forcing
> templates to be replaced by tables? Why make the job of template-coders
> harder by making it so templates can't be as useful? Rather than 1
> infobox that works for all types of settlements, we'd have to have
> thousands, an infobox that works for a major Chinese city wouldn't work
> for a small town in America.
>
> Are you saying that we should be able to revert the software to any
> given revision and expect it to work fine? If we made sure every single
> software change was fully backwards compatible, you could bet MediaWiki
> would have far fewer features and a lot more bugs than it does now.
>
> All changes are easily revertible in the short term. When changes exist
> for years, causing thousands of other changes as a result, how to revert
> them gets rather difficult (the same is somewhat true of edits to
> articles as well). You're proposing we install Semantic MediaWiki and
> rewrite the Parser in a way that will likely not be fully backwards
> compatible. Neither of these changes will be easily revertible once
> deployed, especially after 2+ years.
>
> --
> Alex (wikipedia:en:User:Mr.Z-man)
>
> _______________________________________________
> foundation-l mailing list
> foundation-l at lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>



-- 
You have successfully failed!