On Fri, Jan 9, 2009 at 5:00 PM, Brian Brian.Mingus@colorado.edu wrote:
Why are so few community-developed mediawiki extensions used by the Foundation?
Because there's approximately one person (Tim Starling) who reviews such extensions in practice, and he has limited time. There's approximately one other person (Brion Vibber) who is qualified review such extensions, although he hasn't for a long time that I can think of, presumably because he's busy with other things.
Why do developers have such priviledged access to the source code
So that they can actually improve it. I don't know what alternative you're suggesting.
and the community such little input?
Because the community can't write code, or won't. Features will not get implemented unless someone writes the code. Therefore, anyone who cannot write the code themselves will not get their features implemented unless they happen to convince someone with commit access. Anyone who writes reasonably good code and shows mild commitment to the project is given commit access and becomes a developer if they so choose.
Why must the community 'vote' on extensions such as Semantic MediaWiki
The community is not being asked to vote on SMW that I've heard. If they don't show enough interest, however, it might not be worth the time of one of the few possible extension reviewers to try reviewing such a huge extension.
and yet the developers can implement any feature they like, any way they like it?
No developer can implement any feature without review by Brion. If a developer were to commit a feature as large as SMW, it would be disabled or reverted, for the same reason as given above: nobody with time to review. This has happened with a number of features at various points, like category and image redirects/moves, and rev_deleted. They were all committed by developers but haven't been enabled (or have by now, but weren't for a pretty long time).
Why does the Foundation need 1 million for usability when amazing tools continue to be ignored and untested?
Part of that million will be spent on looking at existing tools. The resources for that currently don't exist, or anyway aren't allocated.
Why has the Foundation gone ahead and approved the hire of several employees for usability design, when the community has had almost zero input into what that design should be?
We've received multiple assurances that all the usability improvements will be made in a fully transparent fashion with community input, as befits Wikimedia's mission.
Why is this tool not being tested on Wikipedia, right now? http://wiki.ontoprise.com/ontoprisewiki/index.php/Image:Advanced_ontology_br...
Because it hasn't met review for enabling on Wikipedia, and likely won't without major structural changes (for performance reasons). Wikimedia handles 70,000 requests per second peak on 400 servers or so. You cannot do that if you willy-nilly enable code that hasn't been carefully tested in a suitably large production environment. And no non-Wikimedia wiki is anywhere close to the size of Wikipedia.
On Fri, Jan 9, 2009 at 5:33 PM, Brian Brian.Mingus@colorado.edu wrote:
800,000 / 30,000 = 26. Is that not a fair wage?
I find it incredibly unlikely that you'd be able to find 26 developers with enough skill who are willing to work for $30,000 a year average. That's below entry level for programmers, let alone senior programmers. You certainly can't rely on current economic conditions, unless you don't mind if they all jump ship as soon as the economy improves and before they're properly familiar with the software.
Moreover, I'm pretty sure that a large chunk of the money is going to have to go to conducting the actual usability tests. I don't know how expensive those are, but they can't be free.
I would like to make clear that I believe the usability issue has largely been solved, and the community is just waiting for the core developers, who have kept a tight lock and key on the source code, to recognize that.
Can you propose any tenable alternative development model that wouldn't overload the servers or crash the site when people upload code that's buggy or just doesn't scale? We have enough of that checked in with our current procedures. It's only kept at bay because everything is reviewed by one of a few highly trusted people, who have worked on MediaWiki and Wikimedia for several and are intimately familiar with the details of how it works and what's been done before.
You cannot escape that review barrier. Every open-source project has it, and must have it, to avoid their code becoming a complete mess.
On Fri, Jan 9, 2009 at 6:13 PM, Brian Brian.Mingus@colorado.edu wrote:
I am skeptical of the current development process. That is because it has led to the current parser, which is not a proper parser at all, and includes horrifying syntax.
The current parser is inherited from somewhere between 2001 or 2003. It's possibly even inherited from UseModWiki. It was developed before the current development process was in place, and so has nothing to do with it.
On Fri, Jan 9, 2009 at 6:50 PM, George Herbert george.herbert@gmail.com wrote:
It would be a potentially acceptable technical solution to change the parser and markup syntax to make it easier to work with, as long as there was an automated conversion tool to shift from what's in the DB now to what would be there going forwards.
Correct, but it would still be a huge project. And there's only about one person who would possibly be situated to do it right, and he has a ton of other critical things to do.
On Fri, Jan 9, 2009 at 6:59 PM, Brian Brian.Mingus@colorado.edu wrote:
I believe it my be the case that the often bizarre idiosyncrasies of MediaWiki were implemented because the developers were spread out around the world, in isolation, communicating only over IRC and sometimes e-mail. I know there are yearly developer spurts at Wikimania, but I do not know about the daily development environment at the offices, and whether development continues in a largely isolated fashion.
The large majority of new code is written by volunteers in their spare time. These volunteers are not going to be willing or able to move to a centralized place to improve communication, and Wikimedia cannot afford to drop them. In any event, communication over IRC, e-mail, and websites is the universal standard in the open source world, and has resulted in a large number of unquestionably high-quality products, like the Linux kernel and Firefox.
I don't know what you want -- more involvement of the community (which is distributed across the world), or less communication by purely electronic means? You can't have both.