--- Erik Moeller erik_moeller@gmx.de wrote:
It is true that Wikinews is reaching the limits of human scaling. This is because we're getting so large that we will soon have to stop listing all stories on the Main Page, and will have to use separate index pages instead.
Yep. Such as pages devoted to news in particular nations. We could register wikinews.us, for example, and redirect it to the U.S. news page on the English Wikinews. If and when other Wikinews' U.S. news pages get busy enough, then we could have xx.wikinews.us redirects as well. But wikinews.us by itself should still auto redirect to the English version (and wikinews.ru should always prefer the Russian Wikinews even if other xx.wikinews.ru redirects exist, ect for each nation/primary language spoken in that nation).
Since I'm the person Gerard spoke about who is going to implement structured data functionality over the next 3-4 months, my own resources are limited. However, I have offered in the past to act as a development task coordinator for the Wikimedia Foundation, and that offer still stands.
For what it is worth you have my support. :)
Such a task coordinator would prioritize tasks, maintain contacts to potentially interested sponsors, and make recommendations on spending a certain part of our internal budget on development tasks. He would write the basic specifications, try to locate interested developers (both by inviting them directly, and by having public calls for tenders), watch over the implementation, and decide whether it meets the specs (together with the Board and the MediaWiki Release Manager, Brion Vibber).
Sounds more like a Chief Technical Officer to me. If we can't pay you to do this, then you might as well have a nice title to put on your resume. :) That would not prevent us from finding a way to pay you in the future for this (if the board so wishes), nor should it prevent you from working on and getting paid for development tasks approved by the board in the interim.
I strongly believe that a combined model of full-time employment for people like Brion, and task-based contracts for project-specific needs, is the only way forward.
Nod. We certainly have enough money for a couple full time employees and a few limited term mini contract positions without putting a significant dent in the overall budget. Whether or not the board wants to do that is a policy matter for them to decide.
As for the specific needs Wikinews has, Ilya has already written a bit about that. I have a fairly good idea in my head how news feeds could work within MediaWiki in a scalable fashion. The question is, are we willing to spend the money to get this done?
We have $20,000 budgeted for development projects and/or extra hardware this quarter. http://wikimediafoundation.org/wiki/Budget/2005
What we need is somebody to coordinate spending priorities and have that approved by the board. A good deal of justification will be needed to spend money on anything other than hardware so this is not a trivial task.
Just because Wikipedia sort of works (even though we still don't have peer review functionality after more than 4 years), we shouldn't start slacking. We have half a dozen active developers at any given time. We have hundreds of thousands of users and even more readers. We've tried recruiting. Jimbo has given his speech at FOSDEM. There's more we can do, but in part due to the growing complexity of MediaWiki, this imbalance can ultimately only be addressed with one resource: money.
I've also noticed some fairly obvious vandalism slipping through for days before being corrected. Our old way of RC patrol is not scaling well by not letting different users divide the workload.
If I trust a set of users, then why would I need to check a diff they already checked? And why would their edits show up just as prominently as people I don't know/trust? Right now there is no way for me to know that somebody I trust (or trust by proxy) has checked any particular diff. So I either check it again or miss it in the flood of 20 to 30 edits a minute we get on the English Wikipedia.
-- mav
__________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/
On Tuesday, March 29, 2005 1:15 AM, Daniel Mayer <maveric149@yahoo.com]> wrote:
--- Erik Moeller erik_moeller@gmx.de wrote:
[Snip]
However, I have offered in the past to act as a development task coordinator for the Wikimedia Foundation, and that offer still stands.
For what it is worth you have my support. :)
Mine, too, very much so, though that's no doubt worth much less. ;-)
Such a task coordinator would prioritize tasks, maintain contacts to potentially interested sponsors, and make recommendations on spending a certain part of our internal budget on development tasks. He would write the basic specifications, try to locate interested developers (both by inviting them directly, and by having public calls for tenders), watch over the implementation, and decide whether it meets the specs (together with the Board and the MediaWiki Release Manager, Brion Vibber).
Sounds more like a Chief Technical Officer to me.
Chief Software Co-ordinator, perhaps? CTO suggests a hardware role as well (unless that was meant to have been included in the suggested scope, but I don't think it is).
If we can't pay you to do this, then you might as well have a nice title to put on your resume.
Agreed. :-)
[Snip]
Yours,
Daniel-
Yep. Such as pages devoted to news in particular nations. We could register wikinews.us, for example, and redirect it to the U.S. news page on the English Wikinews. If and when other Wikinews' U.S. news pages get busy enough, then we could have xx.wikinews.us redirects as well. But wikinews.us by itself should still auto redirect to the English version (and wikinews.ru should always prefer the Russian Wikinews even if other xx.wikinews.ru redirects exist, ect for each nation/primary language spoken in that nation).
I'm not too fond of getting those domain names, because we have to look after them. People link to them, put them in their bookmarks, etc., and if one of them stops working, we have a big problem - and may not even notice it. I'd prefer short canonical URLs (some of the arguments why this is bad on Wikipedia don't apply to Wikinews), but Brion opposes that.
Such a task coordinator would prioritize tasks, maintain contacts to potentially interested sponsors, and make recommendations on spending a certain part of our internal budget on development tasks. He would write the basic specifications, try to locate interested developers (both by inviting them directly, and by having public calls for tenders), watch over the implementation, and decide whether it meets the specs (together with the Board and the MediaWiki Release Manager, Brion Vibber).
Sounds more like a Chief Technical Officer to me. If we can't pay you to do this, then you might as well have a nice title to put on your resume. :)
Two problems with that: - I am not qualified, by myself, to give good hardware recommendations; software is my main focus of interest. - The position should exist alongside that of the MediaWiki Release Manager, not above it. In the long term, I believe that the RM position should be an official Wikimedia title.
But, in line with Sj's comments about mobilizing volunteers, an alternative would be a "Research Committee" with an elected or appointed chair (Chief Scientist or Chief Research Officer). This also makes it clear that everything the committee comes up with are recommendations that can be ignored by the board, by the Release Manager, and by the other developers (though it would be helpful, in the long term at least, if a reason was required for ignoring the recommendations).
This committee could eventually also cover hardware recommendations, though perhaps it would be sensible to have a separate elected chairperson for that department.
I would be willing to set up this Committee and the elections for its chairperson(s) on Meta, but I'd like to get at least a basic go-ahead from Jimbo et al. before doing this - there's not much point if the committee is going to be ignored.
Regards,
Erik
wikimedia-l@lists.wikimedia.org