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 > <[email protected]<simetrical%[email protected]> >> wrote: > >> On Sat, Jan 10, 2009 at 9:04 PM, Brian <[email protected]> >> 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 <[email protected]> >> 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 <[email protected]> >> wrote: >> > I do have another question: Who approved deploying parser functions >> on >> > Wikipedia? >> >> Tim Starling both wrote and deployed ParserFunctions. >> >> _______________________________________________ >> foundation-l mailing list >> [email protected] >> Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l >> > > > > -- > You have successfully failed! > _______________________________________________ > foundation-l mailing list > [email protected] > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l > _______________________________________________ foundation-l mailing list [email protected] Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/foundation-l
