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.