Yes, ParserFunctions has been a nightmare for me, a detour into coding that, while challenging, defeats the essence of a wiki, quick.
Fred
Thank for your answers.
ParserFunctions are my specific example of how the current development process is very, very broken, and out of touch with the community. According to Jimbo's user page (his bolded): "*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."
I believe that the introduction of ParserFunctions to MediaWiki was not done with community consensus and has led to an extremely fast devolution in wiki syntax. Further, the usability of Wikipedia has declined at a rate proportional to the adoption of parser functions.
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
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.
On Sat, Jan 10, 2009 at 7:53 PM, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Sat, Jan 10, 2009 at 9:04 PM, Brian Brian.Mingus@colorado.edu wrote:
False: Extension Matrix.
See the rest of that paragraph. Anyone who can write code and wants commit access can get it. The only ones without commit access who want it are those who can't or won't write code. Most of the extension developers are apparently uninterested in getting commit access, since they haven't asked for it. There is only a small barrier between developers, and people who are willing and able to code and want to become developers.
The development of MediaWiki should not be based on what the core developers believe the flavor of the day is. It leads
to
monstrosities such as the current parser.
I already pointed out that the current parser was not originally written in the current development model. It's not a reasonable example to support your point.
If the community funds MediaWiki development, they should have a very strong say in what features get implemented.
The Wikimedia Foundation funds MediaWiki development. It employs both of the core developers and therefore has total control over what features get implemented. The Board delegates most of these decisions to its CTO, who's one of the core developers in question.
The developers should not be the ones deciding what their time should
be
spent on.
The majority of developers are volunteers, so no one else can decide what their time is spent on. The few who are employees are told what to do by the Wikimedia Foundation, through its CTO Brion Vibber, as in any organization. You appear to disagree with some of Brion's decisions, but he was appointed CTO and lead developer by the Board of Trustees. How can he not have discretion to do what he thinks is best? Who should, then?
And I am under the impression that various language Wikipedia's can enable SMW if they
reach a
consensus. Is that wrong?
Yes. All code must pass review regardless of consensus, and SMW has not.
And yet major features to MW have been implemented on developer whim.
Not remotely as large as SMW, without the approval of a senior developer. If you think you can find a counterexample, show me.
I'm curious: of all the possible "improvements" to MediaWiki, why do you feel the horrifying "parser" functions were chosen? For the increase in usability? Pfffft.
ParserFunctions were developed to address the fact that the community was using horrible hacks like {{qif}} to achieve the functionality anyway. The conclusion was that a relatively efficient and clean way of achieving basic logic was preferable to what people were devising. It's been proposed that we ditch these as well and move to embedding a real programming language instead, but there hasn't been much activity on that.
I do not believe the job of the core developers should be choosing
what
extensions are enabled. If an extension appears to solve the
usability
issue, and yet it does not scale, their job is to scale it.
Someone must make the decision of what to spend limited development resources on. In practice, that has to be a developer of some kind, because no one else would be informed enough to properly evaluate proposals on their merits. The community can decide whether it wants a given extension, but it is in no position to determine whether the cost of fixing it up and enabling it is worth the benefit. That must be made by some individual or group appointed for this purpose. That would currently be the senior developers.
And when expert PHP developers write extensions, give talks at Wikimania, provide
community
support, and do what it takes to develop a thorough understanding of MediaWiki, they should be given a larger voice. Much larger than
being
ignored altogether.
Any such person can ask for commit access and be given it. If they gain the trust of the senior developers, they can potentially become trusted enough to do things like extension review themselves. We've had people other than Tim and Brion who were allowed to enable extensions -- Avar, for instance (although that was a long time ago, when things were different). In practice, nobody I know of meets your description.
I do not dispute review. I dispute the fact that the core developers
only
review code that suits their fancy.
They only review code that they have time to review. There are two of them, what do you expect? And not only must they review all code, they need to write code too, and fulfill other duties.
I think the fundamental point you're missing here is lack of resources. Brion and Tim do not fail to review Semantic MediaWiki because that's their "whim". They simply don't have the resources to review everything. They need to make decisions. If they spent time reviewing SMW, that would be time they couldn't spend on other things. They've judged that the other things are currently more important. On what basis do you question that judgment, since you evidently don't know what development resources *are* actually being spent on?
This is partly false. There have been several efforts to write a
proper
parser, and the current parser has undergone major structural
changes. I
don't believe a computer scientist would have a huge problem writing
a
proper parser. Are any of the core developers computer scientists?
If you're familiar with the attempts to write a parser, you're also familiar with the fact that they've all failed, because wikitext is unparseable using a real parser. Tim knows a considerable amount of computer science, as well as understanding the requirements for a parser much better than any outsider, and would be the logical one to write a new parser -- but he's needed for a lot of other things as well. Again, limited resources.
I do not believe that is how Firefox is developed.
According to a statistic I recently saw, 80% of Firefox source code is written by people not employed by Mozilla. Moreover, even the people employed by Mozilla live in radically different places. Of the layout/content superreviewers, for instance, Google indicates that Robert O'Callahan lives in New Zealand, David Baron lives in California, Boris Zbarsky lives in Illinois, Jonas Sicking lives in Sweden, etc.
So no, that's exactly how Firefox is developed. Along with every other project that uses an open-source development model. Open development inherently means you're willing to accept any contributors. That means you accept them from anywhere in the world. That means over the Internet.
The linux kernel is another story - it has proper oversight, and Torvald's "network of
trust"
15 crack developers whom he knows well and have written exceptional
quality
code for him for many years.
What bearing does that have on what I said? It's still perfectly good software developed over the Internet exclusively.
On Sat, Jan 10, 2009 at 9:08 PM, Brian Brian.Mingus@colorado.edu wrote:
I was not disputing that the community should vote: In fact, I
believe all
code that is written should be a result of a) community vote and b)
rational
oversight provided by the foundation, but at a higher level than the
core
developers.
What's a "higher level than the core developers"? Do you mean to imply that development resources should be allocated on a fine-grained level by non-developers? How could anyone who's not a developer of the software make such decisions intelligently? What, moreover, is wrong with the current system, other than the fact that it doesn't agree with you?
On Sat, Jan 10, 2009 at 9:33 PM, Brian Brian.Mingus@colorado.edu wrote:
I do have another question: Who approved deploying parser functions
on
Wikipedia?
Tim Starling both wrote and deployed ParserFunctions.
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