Anthere wrote:
What is funny is that it is assumed allright that developers only communicate in their area, but it is not allright for others. Why ?
I tried to explain the difference in my earlier message. Basically, people see developer decisions and actions as more technical than political (most of the time), so they feel less need to be informed. And even so there have been plenty of complaints about lack of information from the developers - usually when something has gone wrong and the developers are too busy trying to fix it to provide much information back to the community.
That's all the comment I have time for at the moment. I'll try to respond to some of the other thoughts and questions floating around later.
--Michael Snow
Michael Snow (wikipedia@earthlink.net) [050819 00:47]:
Anthere wrote:
What is funny is that it is assumed allright that developers only communicate in their area, but it is not allright for others. Why ?
I tried to explain the difference in my earlier message. Basically, people see developer decisions and actions as more technical than political (most of the time), so they feel less need to be informed. And even so there have been plenty of complaints about lack of information from the developers - usually when something has gone wrong and the developers are too busy trying to fix it to provide much information back to the community.
As I understand it, they're snowed under in general. (You try running a top-50 website and writing bespoke software for it on one and a half employees and a handful of volunteers.) Servers are excellent things, but another paid coder/sysadmin would (AIUI) do wonders for us. (Xenu help us if Kate needs to get a dayjob, for example.) I've mentioned this before as something that local chapter money could be put to good use on, though possibly it shouldn't be left waiting on that.
- d.
David Gerard wrote:
As I understand it, they're snowed under in general. (You try running a top-50 website and writing bespoke software for it on one and a half employees and a handful of volunteers.) Servers are excellent things, but another paid coder/sysadmin would (AIUI) do wonders for us. (Xenu help us if Kate needs to get a dayjob, for example.) I've mentioned this before as something that local chapter money could be put to good use on, though possibly it shouldn't be left waiting on that.
There was a discussion in August 2004 about implementing a bounty system for MediaWiki development. Anthere ran a survey in july 2004 among developers and published results on meta on August 25th 2004:
http://meta.wikimedia.org/wiki/Developer_payment_poll/results
About that time, I talked with Anthere about recruiting some of the developers in the Foundation and having them working full time on MediaWiki / server management. We agreed on something: monthly payment would mean that less money would be spend on hardware and the foundation will have to find a good way to get the needed money every month (not paying employee is not something you want happening).
In some years, maybe, the foundation will have an office somewhere in the world and have employees in charge of press, development or paper version publishing. I would probably be among the firsts to post my resume on [[Job offering]] :p
WikiMedia is probably not big enough for that yet.
cheers,
Ashar Voultoiz wrote:
There was a discussion in August 2004 about implementing a bounty system for MediaWiki development. Anthere ran a survey in july 2004 among developers and published results on meta on August 25th 2004:
http://meta.wikimedia.org/wiki/Developer_payment_poll/results
A bounty system assumes someone (unpaid? community vote? donator decides?) can define the tasks and assign the bounties. One question in Anthere's poll was "Which tasks, if any, really ought to be done, but currently are not?". That method of design can only result in a bazaar. To build a cathedral you need an architect with somewhat dictatorial powers, and the authority and salary for an architect is the least likely outcome of a bounty system. For example, what if there is a $2000 bounty for adding complex graphics and another $2000 bounty for improving performance? These bounties are in conflict. Who is to decide? Eric Raymond thinks bazaars are better than cathedrals because of this lack of authority, but not everyone agrees with Eric Raymond. For example, Linus Torvalds' architectural control over the Linux kernel is a good example of dictatorial powers at their best.
Wikipedia has been extremely successful despite (not because) the lack of a technical architect, especially in the last two years. Some people ask how the Swedish Wikipedia can be the 5th biggest with a language spoken by only 9 million people. One strong reason is that the Swedish wiki community enjoyed sub-second response times at susning.nu in 2002 and 2003, while Wikipedia's utter sluggishness during software phase II and III scared away thousands of volunteers. After susning.nu closed, this community has moved over to the Swedish Wikipedia. Just imagine if Wikipedia had performed like that in every language. And once again, I do this only to promote Swedish language among Germans: http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/017624.html
While I appreciate Anthere's outreach, the board should not ask the developers which features need to be implemented. The board should promote growth of free contents (e.g. more encyclopedia articles, more dictionary definitions, more photos, etc.) and investigate why some sectors are growing slower than others. If there are technical bottlenecks, such as slow response times or lacking features, the developers should be informed and asked (and perhaps paid) to help the situation. The goal is never technical features, but the quicker generation of more contents. This is just like any commercial company where the board monitors customers and sales, except that the Wikimedia Foundation is not a profit-optimizing organization but a free-content-optimizing one.
So don't ask why the Swedish Wikipedia is growing so fast, ask why all the others grow so slowly. We can do better than this.
Lars Aronsson wrote:
Ashar Voultoiz wrote:
There was a discussion in August 2004 about implementing a bounty system for MediaWiki development. Anthere ran a survey in july 2004 among developers and published results on meta on August 25th 2004:
http://meta.wikimedia.org/wiki/Developer_payment_poll/results
A bounty system assumes someone (unpaid? community vote? donator decides?) can define the tasks and assign the bounties. One question in Anthere's poll was "Which tasks, if any, really ought to be done, but currently are not?". That method of design can only result in a bazaar. To build a cathedral you need an architect with somewhat dictatorial powers, and the authority and salary for an architect is the least likely outcome of a bounty system. For example, what if there is a $2000 bounty for adding complex graphics and another $2000 bounty for improving performance? These bounties are in conflict. Who is to decide? Eric Raymond thinks bazaars are better than cathedrals because of this lack of authority, but not everyone agrees with Eric Raymond. For example, Linus Torvalds' architectural control over the Linux kernel is a good example of dictatorial powers at their best.
Uh, no. I think you are mistaking. In the case of my poll, it was quite simple who would make the final decision of which tasks really ought to be done. The one paying. In this case the Foundation. Which would make that decision depending on feedback from the community AND the developers. So, it makes sense to ask the developers what they think, because they are the first ones to be able to tell us "yeah, the community wants that, but it is horribly difficult to do" or "yeah, but it is so boring no one will do it even for money" or "yeah, great stuff, very important".
This said. *I* did not make a proposal for a bounty system. I was frankly neutral on this solution, if not having doubts on its workability. Erik proposed the bounty system (though it had another better name which I forgot). I made that poll for several reasons, one of which was per respect of Erik.
Wikipedia has been extremely successful despite (not because) the lack of a technical architect, especially in the last two years. Some people ask how the Swedish Wikipedia can be the 5th biggest with a language spoken by only 9 million people. One strong reason is that the Swedish wiki community enjoyed sub-second response times at susning.nu in 2002 and 2003, while Wikipedia's utter sluggishness during software phase II and III scared away thousands of volunteers. After susning.nu closed, this community has moved over to the Swedish Wikipedia. Just imagine if Wikipedia had performed like that in every language. And once again, I do this only to promote Swedish language among Germans: http://mail.wikipedia.org/pipermail/wikitech-l/2003-July/017624.html
While I appreciate Anthere's outreach, the board should not ask the developers which features need to be implemented. The board should promote growth of free contents (e.g. more encyclopedia articles, more dictionary definitions, more photos, etc.) and investigate why some sectors are growing slower than others. If there are technical bottlenecks, such as slow response times or lacking features, the developers should be informed and asked (and perhaps paid) to help the situation. The goal is never technical features, but the quicker generation of more contents. This is just like any commercial company where the board monitors customers and sales, except that the Wikimedia Foundation is not a profit-optimizing organization but a free-content-optimizing one.
So don't ask why the Swedish Wikipedia is growing so fast, ask why all the others grow so slowly. We can do better than this.
The board monitors customers, which are both editors and developers, because developers are also customers :-)
Hmmm, on another note. Some "developments" were paid by other organizations, without these developments being necessarily widely requested by the community. But this is liberty. Why would we prevent another organization to pay for the development of certain features ????
What is your opinion on that ?
Anthere wrote:
In the case of my poll, it was quite simple who would make the final decision of which tasks really ought to be done. The one paying. In this case the Foundation. Which would make that decision depending on feedback from the community AND the developers. [...] Hmmm, on another note. Some "developments" were paid by other organizations, without these developments being necessarily widely requested by the community. But this is liberty. Why would we prevent another organization to pay for the development of certain features ????
Nothing should stop, say, IBM from downloading the MediaWiki source and pay their own programmers to add functionality to it. If IBM wants to distribute this new software, GPL forces them to publish their source code as well. The version manager for MediaWiki might want to include such changes in the next release, otherwise it becomes IBM's own fork of the software. Both ways are fine. This software development could occur within or outside the Wikimedia Foundation. Linux, Apache, MySQL, and PHP are developed outside, and the Foundation only choses which version to use and which features to enable. The MediaWiki software is only slightly different in that the development "belongs" to the Foundation. It doesn't really matter if this development is driven by bounties or not.
What does matter is how the Foundation selects which products and features to use on the Foundation's own servers. This is really not a development issue, but one of operations. This is where the 5-15 seconds response times of 2002-2003 were a real failure, that caused real damage to the project, as editors were leaving, or at least unable to convince their friends to join the project. New features were taken into use as soon as they were developed, and nobody seemed to monitor the performance. Every enthusiastic developer could introduce new bottlenecks.
If Wikipedia had had a board in 2002-2003, it could have appointed an "editor satisfaction officer" or a "productivity officer", with responsibility to question the editor community what slowed them down, and how productivity could be improved. I believe many editors would have put the blame on the slow response times.
The Foundation's server operations people should require that every new software feature can be monitored and enabled or disabled on its own. This is an architectural issue. Good software performance can save large investments in hardware. And even more, smart software can improve editor productivity.
Lars Aronsson wrote:
The Foundation's server operations people should require that every new software feature can be monitored and enabled or disabled on its own. This is an architectural issue. Good software performance can save large investments in hardware. And even more, smart software can improve editor productivity.
This is already the case; we're already very resistant to new features or changes that may impact performance. This has been a strong factor in attempts to slim down the software and is an overriding factor in acceptance of new code. A number of auxiliary features have been selectively enabled for small wikis only.
Is there something in particular you'd like to see added to our process?
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote:
Is there something in particular you'd like to see added to our process?
There is nothing more to wish for in response time, server uptime, and features. It worries me a little that so much money needs to be spent on hardware, which I think could be done with less. However, the board should focus on a higher level, asking what makes contributors more or less productive, or what makes people join or leave the project.
In order to analyze what makes some projects more successful than others, we need statistics to know which projects are successful. Why hasn't Wikistats been updated since May? And will we ever see web traffic statistics again?
Lars Aronsson wrote:
In order to analyze what makes some projects more successful than others, we need statistics to know which projects are successful. Why hasn't Wikistats been updated since May?
Because Erik Zachte, the third party who makes them, hasn't updated his scripts since May?
And will we ever see web traffic statistics again?
These have been online for a month or so.
-- brion vibber (brion @ pobox.com)
Lars Aronsson wrote:
What does matter is how the Foundation selects which products and features to use on the Foundation's own servers. This is really not a development issue, but one of operations. This is where the 5-15 seconds response times of 2002-2003 were a real failure, that caused real damage to the project, as editors were leaving, or at least unable to convince their friends to join the project. New features were taken into use as soon as they were developed, and nobody seemed to monitor the performance. Every enthusiastic developer could introduce new bottlenecks.
If Wikipedia had had a board in 2002-2003, it could have appointed an "editor satisfaction officer" or a "productivity officer", with responsibility to question the editor community what slowed them down, and how productivity could be improved. I believe many editors would have put the blame on the slow response times.
In 2003 the problem was lack of hardware. We disabled every non-essential feature: just about every query page, search, even watchlists at times. A number of innovative performance features were developed, which kept our backs off the wall. We would have been better off at that time with a financing officer than a productivity officer.
-- Tim Starling
Tim Starling wrote:
In 2003 the problem was lack of hardware.
You were able to solve the problem by adding hardware. Whether that is a victory or a failure is a matter of opinion.
We disabled every non-essential feature: just about every query page, search, even watchlists at times.
Yes, blindly hacking away, disabling useful functions at random, instead of analyzing where the bottlenecks were. It was very embarrasing to watch. The growth numbers in 2002-2003 for susning.nu (which still runs on a single server) show what software optimization can do, should you have chosen that path.
On 8/23/05, Lars Aronsson lars@aronsson.se wrote:
Tim Starling wrote:
In 2003 the problem was lack of hardware.
You were able to solve the problem by adding hardware. Whether that is a victory or a failure is a matter of opinion.
I don't think you realise Wikimedia's popularity.
http://www.alexa.com/data/details/traffic_details?&range=2y&size=lar...
I'm pretty sure that Wikipedia has more features than that site in addition to receiving a couple of magnitudes more traffic.
We disabled every non-essential feature: just about every query page, search, even watchlists at times.
Yes, blindly hacking away, disabling useful functions at random, instead of analyzing where the bottlenecks were. It was very embarrasing to watch. The growth numbers in 2002-2003 for susning.nu (which still runs on a single server) show what software optimization can do, should you have chosen that path.
I can't speak for the devs, but I know full well that they were doing profiling and still are. I think you should be more respective until you know what actually goes on.
Lars Aronsson wrote:
Tim Starling wrote:
In 2003 the problem was lack of hardware.
You were able to solve the problem by adding hardware. Whether that is a victory or a failure is a matter of opinion.
We disabled every non-essential feature: just about every query page, search, even watchlists at times.
Yes, blindly hacking away, disabling useful functions at random, instead of analyzing where the bottlenecks were. It was very embarrasing to watch. The growth numbers in 2002-2003 for susning.nu (which still runs on a single server) show what software optimization can do, should you have chosen that path.
At the time, we were using larousse, an 850 MHz P3, for our PHP processing. You were sharing a load balanced cluster of apaches. Yes, you were only paying $50/month for it, but it's likely you were subsidised by their smaller customers. And we were serving 8 times as much traffic. I really don't think you appreciate the challenge we faced. And like Dori said, we did use profiling data to optimise the code.
References:
http://mail.wikipedia.org/pipermail/wikitech-l/2003-September/018605.html http://mail.wikipedia.org/pipermail/wikitech-l/2003-October/018657.html
-- Tim Starling
Michael Snow wrote:
I tried to explain the difference in my earlier message. Basically, people see developer decisions and actions as more technical than political (most of the time), so they feel less need to be informed. And even so there have been plenty of complaints about lack of information from the developers - usually when something has gone wrong and the developers are too busy trying to fix it to provide much information back to the community.
We definitely need to do a better job notifying the public of issues. Part of the problem is just need being disciplined about it -- being busy or tired and assuming somebody else will drop a note when they're done.
Part of it is having too many possible channels of information: a couple dozen mailing lists, a few hundred wikis, a myriad half-forgotten community pages, village pumps, and announcements lists, several blogs, topic messages on a half dozen (or dozen? or more?) IRC channels, etc, about several different major projects and in many languages.
At a minimum, all relevant tech issues need to get noted at http://wp.wikidev.net/Server_admin_log so all of us can keep track of what's broken, what needs to be left untouched or fixed immediately, etc. Hopefully, more public announcements of general issues can get done too.
Roughly we can speak of three kinds of issues: * Here's this neat new feature / old bug we fixed! * There was a brief service hiccup, here's what happened, and a list of expected side effects. * Massive ongoing breakage: here's what's down and roughly when we hope to have it fixed.
-- brion vibber (brion @ pobox.com)
Brion Vibber wrote: <snip>
At a minimum, all relevant tech issues need to get noted at http://wp.wikidev.net/Server_admin_log so all of us can keep track of what's broken, what needs to be left untouched or fixed immediately, etc. Hopefully, more public announcements of general issues can get done too.
Roughly we can speak of three kinds of issues:
- Here's this neat new feature / old bug we fixed!
- There was a brief service hiccup, here's what happened, and a list of
expected side effects.
- Massive ongoing breakage: here's what's down and roughly when we hope
to have it fixed.
We also have a livejournal blog [1]. Maybe the admin internal stuff can be kept on wp.wikidev.net as it is now and have messages aimed at the whole community on livejournal blog ?
[1] http://www.livejournal.com/community/wikitech/
wikimedia-l@lists.wikimedia.org