Mailing List Archive

Hoi,
Usability research done by UNICEF on MediaWiki, by English language people
in Tanzania had 100% of their test subjects failing to create a new article.
This research is repeatable, and it is easy to improve on this because
UNICEF created extensions that will be part of the initial research. The
Uniwiki extensions are being tested elsewhere and bugfixes to make it work
with the latest MediaWiki have been supplied.

People like myself positively HATE editing English language Wikipedia
because of all the crap that is considered "must have" like citations, info
boxes et al. Wikia has worked on software that separates the crap from the
text. This means that it will become a lot easier to edit Wikipedia text.

When the usability of MediaWiki is improved, people will be encouraged to
contribute to MediaWiki projects. It will be really hard to make the
convoluted policies of the different Wikipedias clear. Many policies exist
that on the face of it makes sense. However, when you combine them all, you
get a mess that prevents people from contributing. I recently declined to
write an en.wp article because I am hesitant because of all this.

Realistically, in order to make MediaWiki and Wikipedia more usable, there
are two aspects. There are technical aspects that will make it easy to
contribute and there are the community aspects. For the Stanton project to
do the technical aspects is a no brainer; obviously they will experiment
with all the technical bits and bobs and make a difference. To get some
traction on the community aspects, it takes a community that acknowledges
that cleanup is needed.

When both technical and community issues are addressed, many more people
will edit but be realistic, the biggest difference will be in the other
Wikipedias because that is where the growth still has to happen. This is in
turn dependent on the quality of the Internationalisation that is part of
the Stanton project and the Localisation that is done at Betawiki.
Thanks,
GerardM

2009/1/10 emijrp <emijrp@gmail.com>

> Hi all;
>
> I would like to know how is going to be rated the success of this
> operation/project. Do you hope a big wave of new users? More edits per
> day? To improve the visits/edits ratio? What are your wishes and your
> realistic predictions?
>
> Regards,
> emijrp
>
> Naoko Komura escribió:
> > On Fri, Jan 9, 2009 at 3:19 PM, <mbimmler@gmail.com> wrote:
> >
> > <snip>
> >
> >
> >> Erik/Naoko: does the Stanton grant include a condition for (external)
> >> specific program evaluation?
> >>
> >>
> >
> > Yes, we are required to submit a quarterly report to the Stanton
> Foundation
> > to inform the project progress and status which includes financial
> report.
> >
> > Best,
> >
> > - Naoko
> >
>
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Brian wrote:
> I am quite sure that the answer to Wikipedia's usability issues was not
> properly taken into concern when ParserFunctions were written. This is based
> on a very simple principle that I am following in this discussion:
> Improvements in usability in MediaWiki will not happen through the addition
> of syntax, but rather the removal of syntax, and the improvement of the User
> Interface Design.
>
> I also believe this new grant will help, but I do not believe it will fix a
> broken process. I would like to discuss that process further, and how it
> could be improved.

[Apologies in advance for a fairly long email.]

Although I agree that wiki-syntax in many cases is far from ideal, this
is also a rather tricky issue that hasn't been satisfactorily solved
despite decades of academic and industrial research. So I don't think
it's really the case that best practices exist that MediaWiki developers
have egregiously failed to follow. I have a bit of interest in /
knowledge of this, since developing end-user-programmable systems that
are also easy to use is my research area / day job. ;-)

The fundamental issue is that in complex domains (like "writing an
encyclopedia"), you can't fully analyze and understand the domain ahead
of time, use that understanding to provide an easy-to-use
domain-specific language or interface, and then be done. So for
Wikipedia, it's virtually impossible to provide a built-in set of simple
formatting features (a person infobox, a map-dot-placement feature,
etc.) that are both easy to use and cover all situations. Domains
change, understanding of domains changes, new issues come up, and users
need some way to develop their structures and representations as they're
being used. If you *don't* allow that, what ends up happening is that
people keep using the simple features you've provided, but in more and
more convoluted ways to try to force the system to do what they want.

MediaWiki's first solution to that was templates, which are supposed to
factor out common formatting. But they ought to be edited to handle new
cases---i.e. the proper solution to a template not handling a case is to
change the template, not to ask article authors to use it in some more
complicated way. That often requires if-else type of logic. To implement
that required a convoluted use of templates to force if-else logic into
a feature not designed for it. That started happening a lot---as always,
when faced with something that they want to do that the system has no
interface for, users creatively resort to convoluted ways to force it to
do what they want anyway. ParserFunctions were a solution to the
convoluted template logic, giving MediaWiki some logic that can be used
directly.

I don't think it's on the whole a terrible solution. The general problem
of making systems both end-user-extensible and easy to use has been
rediscovered dozens of times, ranging from the 1980s idea of "open
systems" [1], to attempts to make end-user-programming usable [2], to
an idea of "meta-design" [3] that argues for the need for design
environments like CAD to be built with end-user-customization in mind
[3]. But how to do all that is hard, and I think it'd be fair to say
it's an open problem.

So of course I'd welcome a usability push and carefully designed
solutions, and no doubt there are things that could be done to make
templates/ParserFunctions easier to use while retaining their power. But
I wouldn't expect too much magic to appear. =]

-Mark

[1] Carl Hewitt (1985). The challenge of open systems. _Byte_ 10(4):
223-242.

[2] Bonnie A. Nardi (1993). _A Small Matter of Programming_. MIT Press.

[3] G. Fischer, E. Giaccardi, Y. Ye, A. G. Sutcliffe, and N. Mehandjiev
(2004). Meta-Design: A manifesto for end-user development.
_Communications of the ACM_ 47(9): 33-37.
http://l3d.cs.colorado.edu/~gerhard/papers/CACM-meta-design.pdf


_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Mark,
Keep in mind regarding my Semantic drum beating that I am not a developer of
Semantic Mediawiki or Semantic Forms. I am just a user, and as Erik put it,
an advocate.

That said, I believe these two extensions together solve the problem you are
talking about. And for whatever reason, the developers of MediaWiki are
willing to create new complicated syntax, but not new interfaces.

In your assessment, do these extensions solve the interface extensibility
problem you describe?

To the list,

Regarding development process, why weren't a variety of sophisticated
solutions, in addition to ParserFunctions, thoroughly considered before they
were enabled on the English Wikipedia?

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?

The fundamental issue is that in complex domains (like "writing an
> encyclopedia"), you can't fully analyze and understand the domain ahead
> of time, use that understanding to provide an easy-to-use
> domain-specific language or interface, and then be done. So for
> Wikipedia, it's virtually impossible to provide a built-in set of simple
> formatting features (a person infobox, a map-dot-placement feature,
> etc.) that are both easy to use and cover all situations. Domains
> change, understanding of domains changes, new issues come up, and *users
> need some way to develop their structures and representations as they're
> being used.* If you *don't* allow that, what ends up happening is that
> people keep using the simple features you've provided, but in more and
> more convoluted ways to try to force the system to do what they want.
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Brian wrote:
> Mark,
> Keep in mind regarding my Semantic drum beating that I am not a developer of
> Semantic Mediawiki or Semantic Forms. I am just a user, and as Erik put it,
> an advocate.
>
> That said, I believe these two extensions together solve the problem you are
> talking about. And for whatever reason, the developers of MediaWiki are
> willing to create new complicated syntax, but not new interfaces.
>
> In your assessment, do these extensions solve the interface extensibility
> problem you describe?
>
> To the list,
>
> Regarding development process, why weren't a variety of sophisticated
> solutions, in addition to ParserFunctions, thoroughly considered before they
> were enabled on the English Wikipedia?
>
> 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?
>

A simple procedure? Yes, disabling the extension would be rather simple,
repairing the thousands of templates that would be broken in the
process, not so much.

--
Alex (wikipedia:en:User:Mr.Z-man)

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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.

On Sat, Jan 10, 2009 at 11:42 PM, Alex <mrzmanwiki@gmail.com> wrote:

> Brian wrote:
> > Mark,
> > Keep in mind regarding my Semantic drum beating that I am not a developer
> of
> > Semantic Mediawiki or Semantic Forms. I am just a user, and as Erik put
> it,
> > an advocate.
> >
> > That said, I believe these two extensions together solve the problem you
> are
> > talking about. And for whatever reason, the developers of MediaWiki are
> > willing to create new complicated syntax, but not new interfaces.
> >
> > In your assessment, do these extensions solve the interface extensibility
> > problem you describe?
> >
> > To the list,
> >
> > Regarding development process, why weren't a variety of sophisticated
> > solutions, in addition to ParserFunctions, thoroughly considered before
> they
> > were enabled on the English Wikipedia?
> >
> > 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?
> >
>
> A simple procedure? Yes, disabling the extension would be rather simple,
> repairing the thousands of templates that would be broken in the
> process, not so much.
>
> --
> Alex (wikipedia:en:User:Mr.Z-man)
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>



--
You have successfully failed!
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

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@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@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>



--
You have successfully failed!
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Aryeh Gregor wrote:
> On Tue, Jan 13, 2009 at 12:28 PM, geni <geniice@gmail.com> wrote:
>> How well do those concepts stand up when you have a lot of people
>> copying and pasting code they don't really understand (writing an
>> infobox from scratch is hard modifying an existing one less so)?
>
> Pretty well, I suspect. Of course, real languages are less tolerant
> of error than templates (even PHP makes syntax errors fatal), but I
> don't think the bar to entry would be huge. You might also get more
> real programmers willing to deal with complex templates instead of
> avoiding them like the plague because the language is so hideous, as I
> at least currently do.
>

If we have things like functions and libraries, it may actually do
better than the current system. It would be easier to just have one main
template that contains most of the more complex code, subtemplates would
just include the main template and call the necessary functions and
there'd be less need for copy/pasting. This is already done to a certain
extent with "meta-templates," but they aren't quite as versatile as they
could potentially be with a real programming language.

--
Alex (wikipedia:en:User:Mr.Z-man)

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

David Gerard wrote:
> The other useful thing that can be done with templates is to
> standardise the field names in them as much as possible per wiki.
>
> The reason? To enhance machine readability of data in them. People are
> SERIOUSLY INTERESTED in this.

Another useful thing: after an article is parsed, write all the
templates it uses and their parameters in the database. Even if at first
it isn't possible to read this data on Wikipedia, Toolserver could do
wonders with it :)

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On Wed, Jan 14, 2009 at 9:57 AM, Nikola Smolenski <smolensk@eunet.yu> wrote:
> David Gerard wrote:
>> The other useful thing that can be done with templates is to
>> standardise the field names in them as much as possible per wiki.
>>
>> The reason? To enhance machine readability of data in them. People are
>> SERIOUSLY INTERESTED in this.
>
> Another useful thing: after an article is parsed, write all the
> templates it uses and their parameters in the database. Even if at first
> it isn't possible to read this data on Wikipedia, Toolserver could do
> wonders with it :)

People (including yours truly) have been asking for this for years...

Magnus

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On Wed, Jan 14, 2009 at 4:57 AM, Nikola Smolenski <smolensk@eunet.yu> wrote:
> Another useful thing: after an article is parsed, write all the
> templates it uses and their parameters in the database. Even if at first
> it isn't possible to read this data on Wikipedia, Toolserver could do
> wonders with it :)

This should be fairly easy . . . the table would be absolutely
ginormous, probably bigger than any table we currently have, but with
zero reads (or near-zero, supposing it's made available through the
API and such) that might not be the end of the world.

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

That's pretty much exactly what Semantic MediaWiki offers.

SMW has developed a lot, since many of you saw it. By now, you may
* switch off inline queries if you are afraid they won't work fast enough
* get rid of the ugly syntax everyone is scared about (and simply hide
it all in templates by using the #declare function)
* have all that data sitting there inside the DB and export it in
standard data formats like RDF or JSON (ok, well, the last one is
*almost* finished)

We would be very much interested in having SMW tested on a labs machine
with a copy of a reasonably big Wikipedia (e.g. German).

And, just to take note to the title of this thread -- I never thought
and the developers never gave me the feeling that the software is out of
reach for the community. Access to SVN was swiftly granted, and both Tim
and Brion were always giving encouraging and valuable feedback to us.

Cheers,
denny

Magnus Manske wrote:
> On Wed, Jan 14, 2009 at 9:57 AM, Nikola Smolenski <smolensk@eunet.yu> wrote:
>> David Gerard wrote:
>>> The other useful thing that can be done with templates is to
>>> standardise the field names in them as much as possible per wiki.
>>>
>>> The reason? To enhance machine readability of data in them. People are
>>> SERIOUSLY INTERESTED in this.
>> Another useful thing: after an article is parsed, write all the
>> templates it uses and their parameters in the database. Even if at first
>> it isn't possible to read this data on Wikipedia, Toolserver could do
>> wonders with it :)
>
> People (including yours truly) have been asking for this for years...
>
> Magnus
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Access to svn does not imply access to MediaWiki. Changes to MediaWiki have
been almost entirely up to core developer discretion, and as I have
demonstrated, 'consensus' has largely implied that they, and only they,
thought the changes made Wikipedia better. The ideas are rarely presented to
the community in a formal, well-designed demo format (as SMW has been, time
and time again), and they are not evaluated for their usability. When a
usability issue arises third party tools are not properly considered.
Rather, they reinvent the wheel in an inferior manner.

On Thu, Jan 15, 2009 at 11:07 AM, Denny Vrandeèiæ <dvr@aifb.uni-karlsruhe.de
> wrote:

> That's pretty much exactly what Semantic MediaWiki offers.
>
> SMW has developed a lot, since many of you saw it. By now, you may
> * switch off inline queries if you are afraid they won't work fast enough
> * get rid of the ugly syntax everyone is scared about (and simply hide
> it all in templates by using the #declare function)
> * have all that data sitting there inside the DB and export it in
> standard data formats like RDF or JSON (ok, well, the last one is
> *almost* finished)
>
> We would be very much interested in having SMW tested on a labs machine
> with a copy of a reasonably big Wikipedia (e.g. German).
>
> And, just to take note to the title of this thread -- I never thought
> and the developers never gave me the feeling that the software is out of
> reach for the community. Access to SVN was swiftly granted, and both Tim
> and Brion were always giving encouraging and valuable feedback to us.
>
> Cheers,
> denny
>
> Magnus Manske wrote:
> > On Wed, Jan 14, 2009 at 9:57 AM, Nikola Smolenski <smolensk@eunet.yu>
> wrote:
> >> David Gerard wrote:
> >>> The other useful thing that can be done with templates is to
> >>> standardise the field names in them as much as possible per wiki.
> >>>
> >>> The reason? To enhance machine readability of data in them. People are
> >>> SERIOUSLY INTERESTED in this.
> >> Another useful thing: after an article is parsed, write all the
> >> templates it uses and their parameters in the database. Even if at first
> >> it isn't possible to read this data on Wikipedia, Toolserver could do
> >> wonders with it :)
> >
> > People (including yours truly) have been asking for this for years...
> >
> > Magnus
> >
> > _______________________________________________
> > foundation-l mailing list
> > foundation-l@lists.wikimedia.org
> > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Brian wrote:
> Chad,
>
> What more would you like me to do, specifically? I have attended the
> conferences, I am aware of the MediaWiki development process and I am
> pointing towards high-quality code that meets every possible standard the
> community could reasonably ask. The most important of those standards is
> that the design was very well thought out and presented to the community
> over a period of years. At the same time many features which have come to be
> known as mainstays of Wikipedia have been snuck into the source code with
> far less effort.
>
> In this discussion I have expressed feelings I have had for years, and now
> that there is money on the table, I believe it is time we got to the heart
> of the issue. I am pointing to the MediaWiki development process being
> broken as a core part of that issue.
>
> I reject many of the excuses that have been presented. For example:
>
> - Developers didn't have the time
>
> When one considers the period of years that we are talking about this
> certainly appears to be false.

There's currently over 3000 open bugs with dozens being added very week,
many have been sitting for years. We currently have 2 developers who are
tasked with reviewing basically every change to MediaWiki core and
extensions currently used by Wikimedia. They also have to review
extensions requested by various projects as well as core features that
are disabled pending further review. They also do server admin work and
add new committers. Brion also oversees new technical hiring and Tim
handles releases of new versions. They also manage to find time to some
substanital coding work themselves.

Most of the rest of the developers are volunteers.

> - Users were already doing this, so we just made it easier for them
>
> This is patently false - that particular advanced users are doing something
> *does not imply consensus.* Before ParserFunctions were implemented
> consensus should have been checked. Specifically, I believe a design should
> have been presented at Wikimania so that everyone had a chance to evaluate
> them. My experience has been that the community looks down on templates.
> That these templates were hurting the servers is a great opportunity to ask
> the community what the best solution is. Was the best solution to ingrain
> templates into Wikipedia by making them even easier to use, or to remove
> them altogether in favor of some alternate technology? That discussion was
> simply not had. And ParserFunctions is just one such example.

400 people went to Wikimania 2006 (according to the Wikipedia article),
I would hardly call that "everyone." If something is hurting the
servers, we probably can't spend half a year or so having people submit
proposals and vote on things. Template writers were using inefficient
conditionals, so efficient conditionals were implemented. I can't say
I've witnessed this general disdain for templates that you claim, is
there some evidence for this?


> - Show us the code - why don't you just fix the problem?
>
> I do not consider writing code to be an impediment to design and process
> discussions. Furthermore, it would be suggested that I implement the code as
> an extension so that it might be ignored by the core developers along with
> every other extension. Lastly, the code has already been written. If it is
> not production-ready it is at the very least an excellent demo. This is also
> related to the 'Developers didn't have the time' issue. I fully believe that
> the core developers could reimplement various extensions in a scalable
> manner in relatively short order - they are, after all, crack php coders.
> The real problem is that they do not have the incentive. They have been
> given the keys and the community has not been given a voice. When a
> community member writes code to help MediaWiki, its put into the archives of
> extensions and quickly made obsolete by changes to core MediaWiki code.

Most extensions are ignored because they are written, /possibly/
documented on mediawiki.org or some random external site, then never
mentioned or touched. If people want to get their extensions
implemented, they should propose them to the community, then if the
community wants it, the core developers will have an incentive to review
and possibly improve them.

--
Alex (wikipedia:en:User:Mr.Z-man)

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

On 1/15/09 11:19 AM, Brian wrote:
> Chad,
>
> What more would you like me to do, specifically?

The first things that would help would be:

1) Stop looking to blame someone for past wrongs
2) Think of something that *would* actually help, and do that

When a discussion starts in a negative direction, and continues on and
on and on in that direction, it ends up alienating the people you would
need to be working with to accomplish your goal -- it all ends up
sidetracked as a big ad-hominem debate about who's a bigger jerk and
nothing actually productive gets done.


If you'd like to push for more active evaluation of SMW and introduction
of either SMW or a refactored, slimmed down data storage/query system to
testing and production use, I think that's great!

We've been looking at it for years and hoping we'd have a chance to poke
at it some day; it's the beginning of a new year, projects are starting
up, and this is a time that we're setting priorities.


But it would probably be better to focus on positives like thinking
about what can be accomplished and getting interested parties excited
about working together than to repeat over and over that you believe a
past decision was wrong -- even if you're absolutely sure that it was.

-- brion

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

To be clear, I still consider the process to be broken, and I think it would
help if there were more transparency there. More transparency means features
do not get implemented just because someone with the keys thinks its a good
idea, but because they spec'd the feature out formally and there was no
doubt in anyones mind that they had given due process to finding consensus.
I did not come to this thread attacking anyone, but rather a process. That
certain people felt attacked is unfortunate - they have missed my point.

I am willing to put in some work though. What I plan to do is show the grant
usability team (and mediawiki-l list) what editing Wikipedia articles might
look like with SMW+SF. I haven't been able to find an adequate demo of this.

On Fri, Jan 16, 2009 at 11:31 AM, Brion Vibber <brion@wikimedia.org> wrote:

> On 1/15/09 11:19 AM, Brian wrote:
> > Chad,
> >
> > What more would you like me to do, specifically?
>
> The first things that would help would be:
>
> 1) Stop looking to blame someone for past wrongs
> 2) Think of something that *would* actually help, and do that
>
> When a discussion starts in a negative direction, and continues on and
> on and on in that direction, it ends up alienating the people you would
> need to be working with to accomplish your goal -- it all ends up
> sidetracked as a big ad-hominem debate about who's a bigger jerk and
> nothing actually productive gets done.
>
>
> If you'd like to push for more active evaluation of SMW and introduction
> of either SMW or a refactored, slimmed down data storage/query system to
> testing and production use, I think that's great!
>
> We've been looking at it for years and hoping we'd have a chance to poke
> at it some day; it's the beginning of a new year, projects are starting
> up, and this is a time that we're setting priorities.
>
>
> But it would probably be better to focus on positives like thinking
> about what can be accomplished and getting interested parties excited
> about working together than to repeat over and over that you believe a
> past decision was wrong -- even if you're absolutely sure that it was.
>
> -- brion
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

Brian hett schreven:
> There is only one thing stopping it from going live in my opinion - developer
> enthusiasm.
What about community consensus?

Marcus Buck

_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l

There cannot be community consensus if the developers are unwilling to
seriously consider alternate technological solutions to the ones they come
up with. That is a key piece of the broken process -- developers of SMW have
presented their ideas to the community, but whether or not there was ever
consensus (or could have been consensus) has not mattered since the
developers were unwilling to give the software serious look. In other
words, there has been a chilling effect. Why bother going to as many people
as you can for input if that input will make no difference?



On Mon, Jan 19, 2009 at 1:45 PM, Marcus Buck <me@marcusbuck.org> wrote:

> Brian hett schreven:
> > There is only one thing stopping it from going live in my opinion -
> developer
> > enthusiasm.
> What about community consensus?
>
> Marcus Buck
>
> _______________________________________________
> foundation-l mailing list
> foundation-l@lists.wikimedia.org
> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
>
_______________________________________________
foundation-l mailing list
foundation-l@lists.wikimedia.org
Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l