Ultimately this is an issue of answering the following question: Does the Wikimedia Foundation have a responsibility to help projects it hosts with development resources?
It appears that to some degree, the answer is yes: the foundation pays for hosting and proper maintenance of servers to ensure uptime, and pays for some development to move the platform forward. However, so far the stance has been that the projects are on their own when it comes to developing or enabling additional features.
My recommendation would be that the foundation retains a technical assistant (perhaps on a part-time basis); someone whose entire paid responsibility is to be the arbiter of feature implementation. Sometimes this person's job might be to enable an extension, and make sure it doesn't break things when it goes live; other times it might be trying to help implement a particular minor change. From trying to get some things deployed for Wikinews, I know just how much of a pain it was to get a minor feature pushed through -- ultimately requiring months of back-and-forth for one page worth of code. However, when we did get some of the technican Wikimedians' help (thank you Brion!) we got our problems resolved within seconds.
I really believe that since Brion's job is likely to be defined in terms of Wikimedia as a whole, it is cruicial to have someone else own the domain of the little , individual problems on the technical front. This way the small projects won't have to wait months for the smallest changes. I suspect that having someone in that kind of a dedicated role will cut down a lot of project frustration.
Alternatively, the foundation should make an explicit decision as to where they want to deliniate the responsibility between the Foundation's technical resources and the resources each project, chapter, or language is supposed to provide to accomplish its goals. This way each project will know what they need to do themselves and what they should be expecting from WMF-based resources.
-ilya haykinson en.wikinews
On 9/23/06, George Herbert george.herbert@gmail.com wrote:
On 9/23/06, Birgitte SB birgitte_sb@yahoo.com wrote:
--- David Gerard dgerard@gmail.com wrote:
On 23/09/06, Birgitte SB birgitte_sb@yahoo.com wrote:
people are becoming frustrated with this. It
seems a
great deal of very minor issues are handled for
en.WP
very quickly. They have recently gotten help to rearrange the side bar display of all things. Yet everyone says the developers are overworked. So I would think somehow this system of prioritizing
what
gets done (bugzilla) must be broken. Now this is my personal opinion. I care ten
times
more that the development needs of my community
are
more fairly addressed, than that the community's voices in the Board Elections are not drowned out
by
en.WP.
It's an Americocentric conspiracy to take over Wikimedia, and absolutely the most effective thing for you to do is Assume Bad Faith! DOWN WITH EN:WP!!
No, actually it's probably because a lot of the devs start as editors on en:wp and so that tends to be the project they hang around on and hear the bugs of most. e.g. Rob Church, who has done a *remarkable* amount of recent work on MediaWiki and can be found on en:wp and on #wikipedia ... or Tim Starling, who started as a contributor, realised there was an urgent need for development and sysadmin and pretty much moved to that.
That is: if your project doesn't get its favourite bugs fixed, it's not favouritism to en:wp - it's your project not contributing to the development. These are volunteers, if you recall.
- d.
Yes I do realize a big part of issue is that the people interested in development are inherently not interested in Wikisource. I was just trying to compare this issue with everyone talking about en.WP dominating election issues and voting (which everyone seemed to classify as a "bad thing") But seriously to everyone who thinks I am just being unrealistic here, is nine months to short a time to start complaining? Seriously what should my expectations be?
Birgitte SB
Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l
I think your expectations should be that:
A. Some methods of promoting enhancements to the code are more effective than others, and that your series of emails here has hopefully pointed you to some more effective methods.
B. As with many open source projects, there are probably many enhancements that would be good, or at worst harmless, that do not happen because nobody who actually does coding ends up highly interested in the problem.
The ultimate solution to B is to successfully accomplish A. If you don't seem to get leverage there, then you may want to learn PHP and the MediaWiki codebase... A lot of enhancements ultimately happen because one person wants it badly enough to code it, even if the existing community didn't.
MediWiki is no different from any generic open source project in these regards.
The very best, very large development base projects can have a more user-requirements-request driven approach, but that only works if you have enough coders / developers that they have "spare time" beyond the tasks they see as personal individual must-have or individual interest drivers. I'm not sure how many people are working on MediaWiki right now, but it seems relatively small for a very large userbase project.
-- -george william herbert george.herbert@gmail.com _______________________________________________ foundation-l mailing list foundation-l@wikimedia.org http://mail.wikipedia.org/mailman/listinfo/foundation-l