Hi Everyone,
I searched the archives of both list and couldn't find any thread about it. I could miss it, so sorry it it already has been discussed.
We all know that uploading a file on commons, and on Wikimedia, is kind of tricky nowdays. However, this could be changed thanks to HTML5.
HTML5 includes the drag and drop thingy that makes the uploads easier and that can automatically fetch the EXIF datas. If we want we could even allow the multiple drag and drop.
Anyway this could be a solution to look at, you can get more information there : http://hacks.mozilla.org/2009/12/firefox-36-fileapi-demo-reading-exif-data-f... and there : http://hacks.mozilla.org/2009/12/file-drag-and-drop-in-firefox-3-6/
All the best,
On Thu, Sep 2, 2010 at 6:01 AM, Christophe Henner christophe.henner@gmail.com wrote:
Hi Everyone,
I searched the archives of both list and couldn't find any thread about it. I could miss it, so sorry it it already has been discussed.
We all know that uploading a file on commons, and on Wikimedia, is kind of tricky nowdays. However, this could be changed thanks to HTML5.
HTML5 includes the drag and drop thingy that makes the uploads easier and that can automatically fetch the EXIF datas. If we want we could even allow the multiple drag and drop.
Anyway this could be a solution to look at, you can get more information there : http://hacks.mozilla.org/2009/12/firefox-36-fileapi-demo-reading-exif-data-f... and there : http://hacks.mozilla.org/2009/12/file-drag-and-drop-in-firefox-3-6/
All the best,
-- Christophe
Keeping in mind that it won't work for everybody :)
http://caniuse.com/#feat=fileapi
-Chad
Bonjour,
Le jeudi 02 septembre 2010 à 12:01 +0200, Christophe Henner a écrit :*
We all know that uploading a file on commons, and on Wikimedia, is kind of tricky nowdays. However, this could be changed thanks to HTML5.
HTML5 includes the drag and drop thingy that makes the uploads easier and that can automatically fetch the EXIF datas. If we want we could even allow the multiple drag and drop.
There are a lot of things we /could/ do, but only few we /can/ do with limited resources. Unless you're offering to develop the feature yourself :)
For what it's worth, I'm taking a multiple-backend approach where the actual upload method can be configured based on browser capabilities. It's been a "nice to have" feature since day one to do an HTML5 drag & drop upload, but that keeps getting delayed as other things come up.
If someone is interested in doing this feature, I'd help.
On 9/2/10 8:36 AM, Guillaume Paumier wrote:
Bonjour,
Le jeudi 02 septembre 2010 à 12:01 +0200, Christophe Henner a écrit :*
We all know that uploading a file on commons, and on Wikimedia, is kind of tricky nowdays. However, this could be changed thanks to HTML5.
HTML5 includes the drag and drop thingy that makes the uploads easier and that can automatically fetch the EXIF datas. If we want we could even allow the multiple drag and drop.
There are a lot of things we /could/ do, but only few we /can/ do with limited resources. Unless you're offering to develop the feature yourself :)
An'n 02.09.2010 17:36, hett Guillaume Paumier schreven:
Bonjour,
Le jeudi 02 septembre 2010 à 12:01 +0200, Christophe Henner a écrit :*
We all know that uploading a file on commons, and on Wikimedia, is kind of tricky nowdays. However, this could be changed thanks to HTML5.
HTML5 includes the drag and drop thingy that makes the uploads easier and that can automatically fetch the EXIF datas. If we want we could even allow the multiple drag and drop.
There are a lot of things we /could/ do, but only few we /can/ do with limited resources. Unless you're offering to develop the feature yourself :)
The Foundation has a budget of 20 million $ this financial year. It plans to spend 8.972 million $ on 91 staff members. That's 98,593.41$ per person. So there are resources. They are just planned to be spend for other things.
With that background I do not like the "yeah, nice idea, do it yourself" approach whenever somebody proposes good ideas. We have many great ideas lingering around for years that never get implemented because the number of volunteer developers is limited especially when it comes to projects that could take months to implement. (Datawiki, Central Interwiki, support for internal map services instead of JPGs on Commons, true support for multilingual wikis, working category intersections etc. pp.)
In my opinion the Foundation should employ several developers who don't have any other task than improving Wikimedia. There should be a pool of improvement ideas that can be rated by importance by the Wikimedia users. The paid developers should then be able to pick improvement ideas and implement them preferring projects that are rated important. That way we can ensure a constant flow of innovation for Wikimedia.
Guillaume, you are a Foundation employee, how about presenting my improvement idea in the next meeting with the bosses ;-)
Marcus Buck User:Slomox
Hi,
Le jeudi 02 septembre 2010 à 20:48 +0200, Marcus Buck a écrit :
The Foundation has a budget of 20 million $ this financial year. It plans to spend 8.972 million $ on 91 staff members. That's 98,593.41$ per person.
I wish that were my salary.
So there are resources. They are just planned to be spend for other things.
With that background I do not like the "yeah, nice idea, do it yourself" approach whenever somebody proposes good ideas. We have many great ideas lingering around for years that never get implemented because the number of volunteer developers is limited especially when it comes to projects that could take months to implement. (Datawiki, Central Interwiki, support for internal map services instead of JPGs on Commons, true support for multilingual wikis, working category intersections etc. pp.)
In my opinion the Foundation should employ several developers who don't have any other task than improving Wikimedia. There should be a pool of improvement ideas that can be rated by importance by the Wikimedia users. The paid developers should then be able to pick improvement ideas and implement them preferring projects that are rated important. That way we can ensure a constant flow of innovation for Wikimedia.
Guillaume, you are a Foundation employee, how about presenting my improvement idea in the next meeting with the bosses ;-)
They don't seem to have waited for you to get that idea ;-) See http://wikimediafoundation.org/wiki/File:2010-11_Wikimedia_Foundation_Annual...
An'n 02.09.2010 20:58, hett Guillaume Paumier schreven:
They don't seem to have waited for you to get that idea ;-) See http://wikimediafoundation.org/wiki/File:2010-11_Wikimedia_Foundation_Annual...
That's where I got the numbers from. It speaks about hirings (the new hirings are already included in the number of 91 employees) but it does nowhere mention developers.
So, was your post a statement of a Foundation employee that confirms that the Foundation will hire several developers whose main and only task it is to program new functionalities for Wikimedia, based on demand ratings, functionalities like the ones I named and the community has waited for since at least half a decade? Is that correct?
Marcus Buck User:Slomox
On Thu, Sep 2, 2010 at 3:16 PM, Marcus Buck wiki@marcusbuck.org wrote:
So, was your post a statement of a Foundation employee that confirms that the Foundation will hire several developers whose main and only task it is to program new functionalities for Wikimedia, based on demand ratings, functionalities like the ones I named and the community has waited for since at least half a decade? Is that correct?
What a terrible way to write software.
-Chad
Chad wrote:
On Thu, Sep 2, 2010 at 3:16 PM, Marcus Buck wiki@marcusbuck.org wrote:
So, was your post a statement of a Foundation employee that confirms that the Foundation will hire several developers whose main and only task it is to program new functionalities for Wikimedia, based on demand ratings, functionalities like the ones I named and the community has waited for since at least half a decade? Is that correct?
What a terrible way to write software.
Terrible because it might produce something that isn't vaporware or an uninstalled extension?
MZMcBride
Hey Marcus, Slow down. There used to be no budget and now that there is a budget they have to grow the workforce. That is not easy and as you will have seen there is a very ambitious program. You may be right that for some features we have been waiting for five years, for other features we have been waiting even longer.
Let us not go into who has waited the longest for what as it is not productive. It is more interesting to bitch about priorities. To do that it makes sense to first decide how to measure benefit and potential. Then have a look at the current plans and understand them. It may require a question or two to understand the plan. Now when we ask polite questions, we may even get a true answer even an answer we do not like :)
The good news is, we are growing the workforce during a recession. That means that we get talent for not too outrageous prices .. :)
Any way, the question is how to measure benefit and potential. Thanks, GerardM
On 2 September 2010 21:16, Marcus Buck wiki@marcusbuck.org wrote:
An'n 02.09.2010 20:58, hett Guillaume Paumier schreven:
They don't seem to have waited for you to get that idea ;-) See
http://wikimediafoundation.org/wiki/File:2010-11_Wikimedia_Foundation_Annual... That's where I got the numbers from. It speaks about hirings (the new hirings are already included in the number of 91 employees) but it does nowhere mention developers.
So, was your post a statement of a Foundation employee that confirms that the Foundation will hire several developers whose main and only task it is to program new functionalities for Wikimedia, based on demand ratings, functionalities like the ones I named and the community has waited for since at least half a decade? Is that correct?
Marcus Buck User:Slomox
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
An'n 02.09.2010 21:26, hett Gerard Meijssen schreven:
Any way, the question is how to measure benefit and potential.
My idea for that, as I said, is having a pool of possible improvements and then letting decide a mix of user ratings ("pro - we need this!", "contra - not really necessary...") and common sense of the developers. Create a page at Meta where people can propose things. Then check the proposal (can it be implemented in a performant way? is it actually a direction we want to develop to? technical traps? etc.pp.). If the check is positive put the proposal on a second, protected, page on Meta and let users vote pro and contra. Developers can then choose from the list which project they want to implement next (preferring projects with high ratings, but with room for an amount of common sense by the developers because they know better about the technical feasibility).
My main point is, that at the moment I as a user have no chance to influence the development of Wikimedia (except for doing it myself). I can pray or I can vote on Bugzilla but I have no way to predict when and who takes the time to start a project. It would be nice to know that there are people committed.
If I have an idea, what do I do at the moment? I can post on wikitech-l. I will be told that the best way to get it done is by doing it myself. I can go to Meta and propose something there. On Meta nobody will even read it. So what I would like to have is a process. When I make a proposal it should either get rejected or it should end up in the above-mentioned pool and be implemented sooner or later dependant on its importance.
My concern is that people have ideas, propose them, people tell them "great idea!" and then nothing happens for years. If we had an official process to handle proposals people can at least have confidence that the proposal gets attention and they can observe their proposal and estimate the proposal's chances based on its ratings.
Marcus Buck User:Slomox
On Thu, Sep 2, 2010 at 4:42 PM, Marcus Buck wiki@marcusbuck.org wrote:
My idea for that, as I said, is having a pool of possible improvements and then letting decide a mix of user ratings ("pro - we need this!", "contra - not really necessary...") and common sense of the developers. Create a page at Meta where people can propose things. Then check the proposal (can it be implemented in a performant way? is it actually a direction we want to develop to? technical traps? etc.pp.). If the check is positive put the proposal on a second, protected, page on Meta and let users vote pro and contra. Developers can then choose from the list which project they want to implement next (preferring projects with high ratings, but with room for an amount of common sense by the developers because they know better about the technical feasibility).
We have this system already, it's called Bugzilla.
My main point is, that at the moment I as a user have no chance to influence the development of Wikimedia (except for doing it myself).
It's not possible to give users significant direct influence. There are too many users and too few developers. Users are collectively given significant say in development, but the influence is spread very thin because the users are so numerous. You have little say because there are many thousands of users whose say is weighted equally to yours.
I can pray or I can vote on Bugzilla but I have no way to predict when and who takes the time to start a project. It would be nice to know that there are people committed.
You do know when there are people committed, because the bug is changed to ASSIGNED (or FIXED if it's quick). Usually there are no people committed, but this is because there are vastly more ideas than implementer time, not because of procedural issues.
If I have an idea, what do I do at the moment? I can post on wikitech-l. I will be told that the best way to get it done is by doing it myself. I can go to Meta and propose something there. On Meta nobody will even read it. So what I would like to have is a process. When I make a proposal it should either get rejected or it should end up in the above-mentioned pool and be implemented sooner or later dependant on its importance.
This is exactly what Bugzilla does. In practice, of course, the overwhelming majority of feature requests there are not fixed, but again, this is not a problem with the process and it cannot be fixed or even mitigated by changing the process.
Hoi, It sounds nice "all users have equal say". They have not and, they should not. Because what will be the benefit? People are more happy when they are told what the priorities are and why and when they are kept informed about developments.
Questions like "what will be the benefit", "how to measure benefit" are vitally important. It is a question of what should be rated and how. Many of the obvious projects have been rated and are getting attention. There are many great ideas, there are even many coded "solutions" and it takes a lot of effort to get those considered and evaluated.
The notion that bugzilla is the obvious solution is interesting. It is not obvious to me because it is not where the important questions are answered. With too little resources the only thing is to make choices and explain them. <grin> this will not please everyone that is a given, but it leaves plenty of room for a lot of bitching </grin> Thanks, GerardM
On 2 September 2010 22:50, Aryeh Gregor <Simetrical+wikilist@gmail.comSimetrical%2Bwikilist@gmail.com
wrote:
On Thu, Sep 2, 2010 at 4:42 PM, Marcus Buck wiki@marcusbuck.org wrote:
My idea for that, as I said, is having a pool of possible improvements and then letting decide a mix of user ratings ("pro - we need this!", "contra - not really necessary...") and common sense of the developers. Create a page at Meta where people can propose things. Then check the proposal (can it be implemented in a performant way? is it actually a direction we want to develop to? technical traps? etc.pp.). If the check is positive put the proposal on a second, protected, page on Meta and let users vote pro and contra. Developers can then choose from the list which project they want to implement next (preferring projects with high ratings, but with room for an amount of common sense by the developers because they know better about the technical feasibility).
We have this system already, it's called Bugzilla.
My main point is, that at the moment I as a user have no chance to influence the development of Wikimedia (except for doing it myself).
It's not possible to give users significant direct influence. There are too many users and too few developers. Users are collectively given significant say in development, but the influence is spread very thin because the users are so numerous. You have little say because there are many thousands of users whose say is weighted equally to yours.
I can pray or I can vote on Bugzilla but I have no way to predict when and who takes the time to start a project. It would be nice to know that there are people committed.
You do know when there are people committed, because the bug is changed to ASSIGNED (or FIXED if it's quick). Usually there are no people committed, but this is because there are vastly more ideas than implementer time, not because of procedural issues.
If I have an idea, what do I do at the moment? I can post on wikitech-l. I will be told that the best way to get it done is by doing it myself. I can go to Meta and propose something there. On Meta nobody will even read it. So what I would like to have is a process. When I make a proposal it should either get rejected or it should end up in the above-mentioned pool and be implemented sooner or later dependant on its importance.
This is exactly what Bugzilla does. In practice, of course, the overwhelming majority of feature requests there are not fixed, but again, this is not a problem with the process and it cannot be fixed or even mitigated by changing the process.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello all,
just a quick big picture update:
1) In general, as you may have noticed, Danese has hired Engineering Program Managers. This is a standard way in growing tech organizations to manage, organize and communicate technology projects. The current setup is:
Rob Lanphier - general core engineering (MediaWiki core, API, code review, QA, etc.) Alolita Sharma - features/product engineering Tomasz Finc - fundraising, mobile/offline
Guillaume Paumier is currently doing both product planning and some EPM work for the multimedia usability project.
This has led to much-improved internal planning and organization of WMF's technical projects, and as you've probably seen, a solid general update and documentation of the engineering projects that are underway:
http://techblog.wikimedia.org/2010/09/wmf-engineering/
If you want to keep up with hiring of staff and contractors, there's now also a new Twitter feed:
http://twitter.com/wikimediaatwork
2) My role is shifting to helping articulate our overall product development strategy and research, meaning to synthesize input from many different sources (community, other departments, researchers, etc.) that helps inform our decision as to which projects we either want to build or prioritize. That includes questions such as "Let's take this existing MediaWiki extension and help review it and whip it into shape". To support this work, I will work with one strategically oriented Senior Product Manager (Howie Fung) and a Senior Research Analyst (currently posted).
This, of course, will be primarily relevant to projects we're directly paying for, but also to some extent the kinds of meetings and the types of volunteer projects we'll facilitate and try to actively generate interest in. Ultimately, volunteer developers invest time in projects they care about, but we do not guarantee that every MediaWiki extension will be reviewed, improved or deployed by WMF staff engineers, irrespective of whether there's a large amount of community interest in it or not. (For example, there might be large interest in a feature that's prohibitively complex, or poorly thought out, or very low-impact.)
Indeed, I don't believe in an approach that only relies on user ratings or votes, rather, priorities should be set based on the overall impact on our strategic objectives that any planned project (technology or not) is going to have. Is it going to help our editor community be more effective? Is it going to help us reach more people? Is it going to drive the overall quality of the content? Is it going to support reaching disadvantaged or underrepresented communities?
That said, that doesn't mean that a process can't be open and consultative. I invite you to look at the (permanently open) Call for Proposals on StrategyWiki, and the special extension that's used to show a dashboard of particularly active or interesting proposals:
http://strategy.wikimedia.org/wiki/Main_Page
I hope to help kick this process back into gear a little bit, and improve upon it, as a way to solicit more extensive and carefully thought-out proposals than what typically finds its way into Bugzilla. (And I agree that Bugzilla is a great tool, especially for smaller requests.)
Together with Danese, the EPM team, and others, we will aim to make WMF's decisions transparent and understandable. When Danese writes about "making code review more transparent", this is a big part of what she's talking about -- the entire process of deciding, for example, that a community-developed software extension is being reviewed, deployed, and possibly even integrated into MediaWiki core. So we do want to be clear _why_ something happens, even if you might disagree with the reasons.
Last but not least, please bear with us, as we're a) still a small team, b) still generally professionalizing and maturing our engineering practices, c) in active growth and transition mode, meaning we have to absorb and orient lots of new people. We're all here to help Wikimedia succeed, and we appreciate patience, kindness, good faith and good humor in working together.
All best, Erik
An'n 02.09.2010 22:50, hett Aryeh Gregor schreven:
On Thu, Sep 2, 2010 at 4:42 PM, Marcus Buckwiki@marcusbuck.org wrote:
My idea for that, as I said, is having a pool of possible improvements and then letting decide a mix of user ratings ("pro - we need this!", "contra - not really necessary...") and common sense of the developers. Create a page at Meta where people can propose things. Then check the proposal (can it be implemented in a performant way? is it actually a direction we want to develop to? technical traps? etc.pp.). If the check is positive put the proposal on a second, protected, page on Meta and let users vote pro and contra. Developers can then choose from the list which project they want to implement next (preferring projects with high ratings, but with room for an amount of common sense by the developers because they know better about the technical feasibility).
We have this system already, it's called Bugzilla.
My main point is, that at the moment I as a user have no chance to influence the development of Wikimedia (except for doing it myself).
It's not possible to give users significant direct influence. There are too many users and too few developers. Users are collectively given significant say in development, but the influence is spread very thin because the users are so numerous. You have little say because there are many thousands of users whose say is weighted equally to yours.
I can pray or I can vote on Bugzilla but I have no way to predict when and who takes the time to start a project. It would be nice to know that there are people committed.
You do know when there are people committed, because the bug is changed to ASSIGNED (or FIXED if it's quick). Usually there are no people committed, but this is because there are vastly more ideas than implementer time, not because of procedural issues.
If I have an idea, what do I do at the moment? I can post on wikitech-l. I will be told that the best way to get it done is by doing it myself. I can go to Meta and propose something there. On Meta nobody will even read it. So what I would like to have is a process. When I make a proposal it should either get rejected or it should end up in the above-mentioned pool and be implemented sooner or later dependant on its importance.
This is exactly what Bugzilla does. In practice, of course, the overwhelming majority of feature requests there are not fixed, but again, this is not a problem with the process and it cannot be fixed or even mitigated by changing the process.
It certainly can be improved. As I said, my main concern is not bugfixing, but development. Like the implementation of a common image repository, parser functions, single user login to name some from the past. The HTML5 upload is smaller, but it's a new feature and not a bugfix.
Nikola Smolenski has done great work on Interwiki transclusion. But nothing has happened since two years. If I were a member of the tech department at Wikimedia, I'd be enthused and would put all my energy in reviewing his code, straigthening out any remaining problems and making it real as soon as possible. I mean, making interwiki bots obsolete, making obsolete like hundreds of thousands edits per day, that would be an amazing improvement, wouldn't it? This dormancy worries me.
Marcus Buck User:Slomox
Marcus Buck schreven:
An'n 02.09.2010 22:50, hett Aryeh Gregor schreven:
This is exactly what Bugzilla does. In practice, of course, the overwhelming majority of feature requests there are not fixed, but again, this is not a problem with the process and it cannot be fixed or even mitigated by changing the process.
It certainly can be improved. As I said, my main concern is not bugfixing, but development. Like the implementation of a common image repository, parser functions, single user login to name some from the past. The HTML5 upload is smaller, but it's a new feature and not a bugfix.
Bugzilla is also for enhacements, not only for bugfixes Having the proposal in bugzilla gives a point where it is recorded and hopefully taken up at some time. As opposed to an email which gets buried int he archive. Although if there's no reaction to the bug, a note here eg. after a week may help to raise attention.
You may also come to #mediawiki in irc to talk with us about specific features (How likely is that we can get a foobar bazinastic implemented soon?).
Nikola Smolenski has done great work on Interwiki transclusion. But nothing has happened since two years. If I were a member of the tech department at Wikimedia, I'd be enthused and would put all my energy in reviewing his code, straigthening out any remaining problems and making it real as soon as possible. I mean, making interwiki bots obsolete, making obsolete like hundreds of thousands edits per day, that would be an amazing improvement, wouldn't it? This dormancy worries me.
Have you seen http://www.mediawiki.org/wiki/User:Peter17/Reasonably_efficient_interwiki_tr... recent GSOC project? It's still not merged to trunk, but it's there. And do note that you can help reviewing the code, even if you can't give it the final ok. Any problem you spot now, is an error less to be found later. You can follow MediaWiki (core & extensions) development at http://www.mediawiki.org/wiki/Special:Code/MediaWiki
On Thu, Sep 2, 2010 at 5:34 PM, Marcus Buck wiki@marcusbuck.org wrote:
It certainly can be improved. As I said, my main concern is not bugfixing, but development. Like the implementation of a common image repository, parser functions, single user login to name some from the past. The HTML5 upload is smaller, but it's a new feature and not a bugfix.
Feature requests go on Bugzilla too.
Nikola Smolenski has done great work on Interwiki transclusion. But nothing has happened since two years. If I were a member of the tech department at Wikimedia, I'd be enthused and would put all my energy in reviewing his code, straigthening out any remaining problems and making it real as soon as possible. I mean, making interwiki bots obsolete, making obsolete like hundreds of thousands edits per day, that would be an amazing improvement, wouldn't it? This dormancy worries me.
There is no dormancy. You are making the cardinal error of feature requests: assuming that if you think something is important, everyone else must too. Quite simply, other people aren't as interested as you in this particular feature. They're working on other things that they feel are more interesting or important. In the end, the people who are doing the work, or paying for it, call the shots on where resources are invested -- there is nothing that can change that.
An'n 03.09.2010 19:43, hett Aryeh Gregor schreven:
Nikola Smolenski has done great work on Interwiki transclusion. But nothing has happened since two years. If I were a member of the tech department at Wikimedia, I'd be enthused and would put all my energy in reviewing his code, straigthening out any remaining problems and making it real as soon as possible. I mean, making interwiki bots obsolete, making obsolete like hundreds of thousands edits per day, that would be an amazing improvement, wouldn't it? This dormancy worries me.
There is no dormancy. You are making the cardinal error of feature requests: assuming that if you think something is important, everyone else must too. Quite simply, other people aren't as interested as you in this particular feature. They're working on other things that they feel are more interesting or important. In the end, the people who are doing the work, or paying for it, call the shots on where resources are invested -- there is nothing that can change that.
The people who are paying for it... Hm, and by that you mean the Foundation? Cause, the money comes from the users, by donations. And the Foundation's purpose is to be the executing branch of the community.
I certainly have a POV. My POV is that of "let's make MediaWiki a more powerful tool" and of "let's make MediaWiki easier for the wiki users". If I look at the techblog post linked by Erik Möller I see some new features that are aimed at the wiki users, like LiquidThreads, Upload and AddMedia wizard, and Pending changes. But I also see several features that are aimed solely at the Wikimedia employees, like media storage architecture, monitoring, resource loader, CentralNotice, Analytics, Selenium deployment, CiviCRM upgrade, and fraud prevention.
I don't want to say that these projects are bad ideas. They are certainly very good ideas. But they have no big advantages to the average wiki user.
In my opinion the work of the wiki volunteers is viewed as a cheap resource. Well, it _is_ cheap, it doesn't cost us anything. But we should value it more. Every day hundreds of working hours by our volunteers are wasted to set interwiki links. This work would be unnecessary if we had a central interwiki repository. In my own home wiki more than three quarters of all edits are done by interwiki bots, cluttering the edit histories.
So if you say that my support of the central interwiki repository is based on false assumptions of importance then I really don't like your assumptions of importance.
The central datawiki could immediately make available information on millions of topics in dozens of languages with very few effort. It would also improve the reliability of all our existing articles, even on projects with big communities like en or de. If that is less important than improved spamming using CentralNotice, then please tell me. The oldest proposal for Wikidata I could find on Meta (although it's not unlikely that the idea is even older) is from 2004 and was proposed by Erik Möller. There are a bunch of other proposals for the same. So there are much more people who deem this important than just me.
Maybe I appear as a grudgy grouser who dispraises your hard work and doesn't contribute much myself, but all I want is that somebody maybe says "oh, remember the days when we didn't care about financing plans and fundraising and deployment and maintaining our servers, but when we had visions about free access to the sum of all human knowledge!"
Marcus Buck User:Slomox
"Marcus Buck" wiki@marcusbuck.org wrote in message news:4C8172C8.1030609@marcusbuck.org...
The people who are paying for it... Hm, and by that you mean the Foundation? Cause, the money comes from the users, by donations. And the Foundation's purpose is to be the executing branch of the community.
No, the purpose of the Foundation is to fulfil its stated vision and principles. People join the communities, or donate, because they agree with that vision; both are donations, or either money or time, towards the famous "free access to all human knowledge". The Foundation does *not* serve the community, nor the other way around; they work together in symbiosis, the community doing the bulk of the heavy work, the Foundation being a more streamlined and efficient decision-making process to guide the development.
I certainly have a POV. My POV is that of "let's make MediaWiki a more powerful tool" and of "let's make MediaWiki easier for the wiki users". If I look at the techblog post linked by Erik Möller I see some new features that are aimed at the wiki users, like LiquidThreads, Upload and AddMedia wizard, and Pending changes. But I also see several features that are aimed solely at the Wikimedia employees, like media storage architecture, monitoring, resource loader, CentralNotice, Analytics, Selenium deployment, CiviCRM upgrade, and fraud prevention.
I don't want to say that these projects are bad ideas. They are certainly very good ideas. But they have no big advantages to the average wiki user.
In my opinion the work of the wiki volunteers is viewed as a cheap resource. Well, it _is_ cheap, it doesn't cost us anything. But we should value it more. Every day hundreds of working hours by our volunteers are wasted to set interwiki links. This work would be unnecessary if we had a central interwiki repository. In my own home wiki more than three quarters of all edits are done by interwiki bots, cluttering the edit histories.
So if you say that my support of the central interwiki repository is based on false assumptions of importance then I really don't like your assumptions of importance.
No one is saying that CentralInterwiki isn't important, or that it wouldn't be a huge improvement. We're saying that there are other projects which are *more* beneficial to Wikimedia, in terms of increasing our reach, drawing in new editors, and improving productivity, that are therefore more deserving of our perpetually limited development time. Please understand the difference between "not important" and "not _as_ important as...".
Maybe I appear as a grudgy grouser who dispraises your hard work and doesn't contribute much myself, but all I want is that somebody maybe says "oh, remember the days when we didn't care about financing plans and fundraising and deployment and maintaining our servers, but when we had visions about free access to the sum of all human knowledge!"
Yes, those were the days when Wikimedia was a tiny fraction of its present size, and where users were uploading dozens of duplicate files to each wiki individually, where the technology was so far behind where it is today that you can't even remember how hamstringed we were by it. Don't think that going back to a time without any development team at all is going to make your projects go any faster, it would just mean that all the other projects would join them on the pile of "not going anywhere because no one's got any money to spend on them".
--HM
2010/9/4 Marcus Buck wiki@marcusbuck.org:
But I also see several features that are aimed solely at the Wikimedia employees, like media storage architecture, monitoring, resource loader, CentralNotice, Analytics, Selenium deployment, CiviCRM upgrade, and fraud prevention.
I don't want to say that these projects are bad ideas. They are certainly very good ideas. But they have no big advantages to the average wiki user.
So you're saying the average wiki user doesn't care about higher site uptime and faster responses to downtime (monitoring), a sustainable and more performant infrastructure for file uploads and downloads (media storage) or making our wikis load faster (resource loader)?
Also, while fundraising (CentralNotice, CiviCRM and the fraud prevention thing are all part of this) isn't directly interesting for most users, it does pay for the servers that keep Wikipedia up.
Roan Kattouw (Catrope)
An'n 04.09.2010 01:15, hett Roan Kattouw schreven:
2010/9/4 Marcus Buckwiki@marcusbuck.org:
But I also see several features that are aimed solely at the Wikimedia employees, like media storage architecture, monitoring, resource loader, CentralNotice, Analytics, Selenium deployment, CiviCRM upgrade, and fraud prevention.
I don't want to say that these projects are bad ideas. They are certainly very good ideas. But they have no big advantages to the average wiki user.
So you're saying the average wiki user doesn't care about higher site uptime and faster responses to downtime (monitoring), a sustainable and more performant infrastructure for file uploads and downloads (media storage) or making our wikis load faster (resource loader)?
Also, while fundraising (CentralNotice, CiviCRM and the fraud prevention thing are all part of this) isn't directly interesting for most users, it does pay for the servers that keep Wikipedia up.
Citing the message you are responding to: "I don't want to say that these projects are bad ideas. They are certainly very good ideas."
I like higher site uptime, but even in the worst times Wikipedia always was up for read access for - I guess - about 95% of the time.
And I find it interesting that you say that fundraisers are necessary to keep the servers up. The fundraiser is planned to earn over 15 million $ between November and January. The rates in other months are at about 0.2 million $. 12 months at 0.2 million each are 2.4 million $ in non-fundraiser donations. Hosting only costs 1.837 million $. So the servers wouldn't go down without a fundraiser. Of course I support the Fundraiser, but I don't accept it as a valid reason if you tell me that it is necessary to delay projects that improve the actual _content of our projects_.
Marcus Buck User:Slomox
On Sat, Sep 4, 2010 at 10:08 AM, Marcus Buck wiki@marcusbuck.org wrote:
And I find it interesting that you say that fundraisers are necessary to keep the servers up. The fundraiser is planned to earn over 15 million $ between November and January. The rates in other months are at about 0.2 million $. 12 months at 0.2 million each are 2.4 million $ in non-fundraiser donations. Hosting only costs 1.837 million $. So the servers wouldn't go down without a fundraiser. Of course I support the Fundraiser, but I don't accept it as a valid reason if you tell me that it is necessary to delay projects that improve the actual _content of our projects_.
Without our fundraising team, there would be no money to spend on the projects that you nominate, regardless of how important we think they are.
I think I speak for us all when I say that we're incredibly grateful for the work that the fundraising team does in keeping Wikimedia running – one small part of that being the great things that our engineering team works on.
Perhaps your time would be better-spent arguing for the importance of projects that you feel are neglected, rather than picking holes in projects that you think might be unnecessary. Though I might say that this really is a "big picture" thread, and it might not be constructive to argue with individual decisions at this time.
An'n 04.09.2010 02:43, hett Andrew Garrett schreven:
Perhaps your time would be better-spent arguing for the importance of projects that you feel are neglected, rather than picking holes in projects that you think might be unnecessary.
I didn't deem any project unnecessary and I didn't pick any holes. All the projects are useful. But if I say "I'd like more focus on project X" and the answer is "our resources are limited and we want to work on projects Y and Z first" than my options are to either provide more resources (which I can't) or to argue that X is more important than Z.
I have tried to argue for the projects that I feel are important on several occasions, but the answer was "yeah, nice idea, do it yourself". Putting feature requests on Bugzilla is ineffective too (https://bugzilla.wikimedia.org/show_bug.cgi?id=164 exists since 2004 and still people invest thousands of working hours removing diacritics in category sorting keys). And that's why I made suggestions to focus more on development of features.
I have a whole list of features that we lack. Another one is better multilingual support. Commons is multilingual, but the software doesn't support multilingualism on content pages well. Commons created a whole bunch of rather esoteric templates to work around the limitations of MediaWiki. Template:ISOdate is used to render dates in a localized format. It's used on 6.5 million pages and it's logic is rather complex. I guess it would be a big performance gain for Commons if MediaWiki would natively support the functionality of ISOdate.
Marcus Buck User:Slomox
"Marcus Buck" wiki@marcusbuck.org wrote in message news:4C81A467.7070908@marcusbuck.org...
I didn't deem any project unnecessary and I didn't pick any holes. All the projects are useful. But if I say "I'd like more focus on project X" and the answer is "our resources are limited and we want to work on projects Y and Z first" than my options are to either provide more resources (which I can't) or to argue that X is more important than Z.
I have tried to argue for the projects that I feel are important on several occasions, but the answer was "yeah, nice idea, do it yourself". Putting feature requests on Bugzilla is ineffective too (https://bugzilla.wikimedia.org/show_bug.cgi?id=164 exists since 2004 and still people invest thousands of working hours removing diacritics in category sorting keys). And that's why I made suggestions to focus more on development of features.
I think that's pretty much the crux of it. You have been trying to opine that X is more important than Z, and not, in the general opinion, succeeding. You certainly make the case that X is important, we generally all agree on that. Numerous people have explained why various Z, which you have tried to portray as less important, are in fact either vital for the Foundation's continued operation, or more closely aligned with the Foundation's goals and will achieve more for the amount of time and money which must be spent on them. Ultimately, you haven't provided any concrete argument why X is *relatively* more important than Y or Z. You won't achieve that by talking up the merits of X and talking down the merits of Z, that's not a *relative* comparison. Why is CentralInterwiki more important *than*, say, LiquidThreads?? I'm not convinced that that's a question which can be sensibly debated, in either direction; and without it, this thread isn't really going anywhere interesting.
--HM
An'n 04.09.2010 12:04, hett Happy-melon schreven:
I think that's pretty much the crux of it. You have been trying to opine that X is more important than Z, and not, in the general opinion, succeeding. You certainly make the case that X is important, we generally all agree on that. Numerous people have explained why various Z, which you have tried to portray as less important, are in fact either vital for the Foundation's continued operation, or more closely aligned with the Foundation's goals and will achieve more for the amount of time and money which must be spent on them. Ultimately, you haven't provided any concrete argument why X is *relatively* more important than Y or Z. You won't achieve that by talking up the merits of X and talking down the merits of Z, that's not a *relative* comparison. Why is CentralInterwiki more important *than*, say, LiquidThreads?? I'm not convinced that that's a question which can be sensibly debated, in either direction; and without it, this thread isn't really going anywhere interesting.
LiquidThreads: * what problems need to be solved? - fixing some dozen bugs - convincing hundreds of communities and hundred thousands of users that their current form of communication is inefficient (which will be very hard, wiki editing sometimes can be hard for newbies, but it's not "broken" in any way)
* benefits: - watchable discussion threads - removing the need to know wiki syntax like signatures or headings to participate in discussion - more intuitive handling for people accustomed to forums
Central Datawiki: * what problems need to be solved? - review Nikola's existing code - create a new wiki to host the data and set it up as a transclusion repository
* benefits: - articles with basic information on millions of topics like places, administrative entities, mountains, lakes, rivers, species, stars, etc. pp. immediately available on any wiki that localizes the datawiki templates (there are translators for almost all our language versions registered at translatewiki) - instead of having to maintain and update data on 280 different projects you just have to maintain/update the data in one single place
Central interwiki repository: * what problems need to be solved? - review Nikola's existing code - create a new wiki to host the data and set it up as a transclusion repository
* benefits: - no more history cluttering by bot edits on smaller projects - no more need for interwiki bots on the single projects - no more need for manual interwiki additions (which sum up to several manhours every day) - effective way of solving complex interwiki conflicts (at the moment you need a bot and hours of time to solve a interwiki conflict that spreads over many wikis and the conflict can return if just one problematic interwiki link is inserted in any of the wikis)
From the point of view of a person living in California and speaking English, Wikipedia works fine. All the important topics are covered by the English Wikipedia and saving 0.3 seconds by improved resource loading seems a relevant problem. But a Buryat student (Buryat Wikipedia having 94 articles) would be very willing to wait 20 seconds or more for a page to load if only there was content he could load. With Datawiki we could reach out to all the small languages and give them access to a vast amount of information they don't have access to at the moment. If the Buryat student wonders how many people live in Ulan-Ude he hopefully has had lectures in Russian and was an attentive pupil. Otherwise he won't get the information. With Datawiki he can look up the information easily and in his native language.
Marcus Buck User:Slomox
Marcus Buck wrote:
I have a whole list of features that we lack. Another one is better multilingual support. Commons is multilingual, but the software doesn't support multilingualism on content pages well. Commons created a whole bunch of rather esoteric templates to work around the limitations of MediaWiki. Template:ISOdate is used to render dates in a localized format. It's used on 6.5 million pages and it's logic is rather complex. I guess it would be a big performance gain for Commons if MediaWiki would natively support the functionality of ISOdate.
Marcus Buck User:Slomox
I don't see there was any bug requesting that. Can you make a list of the templates that would be replaced? That would be {{ISOdate}}, {{date}}, {{I18n month}}, what else?
An'n 04.09.2010 16:16, hett Platonides schreven:
Marcus Buck wrote:
I have a whole list of features that we lack. Another one is better multilingual support. Commons is multilingual, but the software doesn't support multilingualism on content pages well. Commons created a whole bunch of rather esoteric templates to work around the limitations of MediaWiki. Template:ISOdate is used to render dates in a localized format. It's used on 6.5 million pages and it's logic is rather complex. I guess it would be a big performance gain for Commons if MediaWiki would natively support the functionality of ISOdate.
Marcus Buck User:Slomox
I don't see there was any bug requesting that. Can you make a list of the templates that would be replaced? That would be {{ISOdate}}, {{date}}, {{I18n month}}, what else?
Depends what you want to solve, the whole complex of Commons localisation or just the dates. Relevant templates for dates are Template:Formatnum Template:FormatnumDigit Template:ISOyear Template:Time Template:Other date Template:Date-time separator
I think that's it.
Marcus Buck User:Slomox
On 9/3/10 5:08 PM, Marcus Buck wrote:
Of course I support the Fundraiser, but I don't accept it as a valid reason if you tell me that it is necessary to delay projects that improve the actual _content of our projects_.
No projects are delayed due to fundraising. The developers who work on Fundraising (me and Arthur) just work on Fundraising, nothing else. Also, I think your estimate of the amount of money brought in during non-fundraising months seems a bit high. I've heard 120K myself, not 200K, but I don't have the numbers in front of me.
Ryan Kaldari
An'n 04.09.2010 03:53, hett Ryan Kaldari schreven:
On 9/3/10 5:08 PM, Marcus Buck wrote:
Of course I support the Fundraiser, but I don't accept it as a valid reason if you tell me that it is necessary to delay projects that improve the actual _content of our projects_.
No projects are delayed due to fundraising. The developers who work on Fundraising (me and Arthur) just work on Fundraising, nothing else. Also, I think your estimate of the amount of money brought in during non-fundraising months seems a bit high. I've heard 120K myself, not 200K, but I don't have the numbers in front of me.
I took that number from http://upload.wikimedia.org/wikipedia/foundation/d/dd/2010-11_Wikimedia_Foundation_Annual_Plan_FINAL_FOR_WEBSITE.pdf, p. 40. It's 0.2 million income, so I guess your number is correct if it's donations only.
Marcus Buck User:Slomox
"Marcus Buck" wiki@marcusbuck.org wrote in message news:4C7FF181.7010501@marcusbuck.org...
The Foundation has a budget of 20 million $ this financial year. It plans to spend 8.972 million $ on 91 staff members. That's 98,593.41$ per person. So there are resources. They are just planned to be spend for other things.
The "salaries, wages and recruiting" category includes spending on pensions, healthcare, recruitment advertising, consultancy, and spending on employing contractors not counted in the permanent staff, AFAIK.
In my opinion the Foundation should employ several developers who don't have any other task than improving Wikimedia...
Can I ask what you think the current technical team members are doing? :-P
The WMF is planning to almost double the size of the technical staff this year, including one role intriguingly titled "Bugmeister"... You're right that it's no longer accurate to say that the money is not there, but it's also rather unfair to suggest that what the current tech team are doing is solely firefighting. We have seen some great developments over the past year or two, and hopefully the pace will continue to accelerate.
--HM
An'n 02.09.2010 21:23, hett Happy-melon schreven:
"Marcus Buck"wiki@marcusbuck.org wrote in message news:4C7FF181.7010501@marcusbuck.org...
The Foundation has a budget of 20 million $ this financial year. It plans to spend 8.972 million $ on 91 staff members. That's 98,593.41$ per person. So there are resources. They are just planned to be spend for other things.
The "salaries, wages and recruiting" category includes spending on pensions, healthcare, recruitment advertising, consultancy, and spending on employing contractors not counted in the permanent staff, AFAIK.
It's clear to me and I didn't say that's the sum that ends up on their accounts. But it's the sum that is spent on them.
In my opinion the Foundation should employ several developers who don't have any other task than improving Wikimedia...
Can I ask what you think the current technical team members are doing? :-P
The WMF is planning to almost double the size of the technical staff this year, including one role intriguingly titled "Bugmeister"... You're right that it's no longer accurate to say that the money is not there, but it's also rather unfair to suggest that what the current tech team are doing is solely firefighting. We have seen some great developments over the past year or two, and hopefully the pace will continue to accelerate.
I don't want to downplay the role of bugfixing or maintenance of the existing systems or all the other great stuff the tech team does. But a Bugmeister will not help us to leap forward with big innovations. For the big leaps we need people who dedicate full-time on a project.
Marcus Buck User:Slomox
On Thu, Sep 2, 2010 at 2:48 PM, Marcus Buck wiki@marcusbuck.org wrote:
The Foundation has a budget of 20 million $ this financial year. It plans to spend 8.972 million $ on 91 staff members. That's 98,593.41$ per person. So there are resources. They are just planned to be spend for other things.
With that background I do not like the "yeah, nice idea, do it yourself" approach whenever somebody proposes good ideas.
What's the alternative? There are *always* going to be many more ideas than implementers. Ideas are cheap. Wikimedia has to decide which features are the most critical to invest developer time in. Their decision is not going to make everyone happy. The only guarantee you can ever have is if you do it yourself. Happily, MediaWiki is open-source, so you *do* have that option! On practically any other major website, you couldn't add a feature no matter how much you wanted to.
In my opinion the Foundation should employ several developers who don't have any other task than improving Wikimedia. There should be a pool of improvement ideas that can be rated by importance by the Wikimedia users. The paid developers should then be able to pick improvement ideas and implement them preferring projects that are rated important. That way we can ensure a constant flow of innovation for Wikimedia.
We already have that to a decent extent. Bugzilla votes do count for something. That's undoubtedly part of why I was asked to work on bug 164 -- it's had the most votes of any Bugzilla bug for years. But popularity is only a small part of the story. What you have to ask is not what features would you like to see most, but what features are most *cost-effective*. Users can easily say how much they'd like feature X, but they're in no position to gauge how many other features would have to be cut to account for it. A very popular bug that would require a couple of developers working full-time for months to fix properly might just not be worth it, if the same development effort could fix a large number of less-popular bugs. Users are just not in a position to judge this, so while popularity is a factor, it can't be the deciding one.
Aryeh Gregor wrote:
What's the alternative? There are *always* going to be many more ideas than implementers. Ideas are cheap. Wikimedia has to decide which features are the most critical to invest developer time in. Their decision is not going to make everyone happy. The only guarantee you can ever have is if you do it yourself. Happily, MediaWiki is open-source, so you *do* have that option! On practically any other major website, you couldn't add a feature no matter how much you wanted to.
The current status of Wikimedia code deployment makes this no longer applicable to Wikimedia either.
MZMcBride
On Thu, Sep 2, 2010 at 9:36 PM, MZMcBride z@mzmcbride.com wrote:
The current status of Wikimedia code deployment makes this no longer applicable to Wikimedia either.
Ack. I recall a thread on this list about that. Did that have any outcomes?
Bryan
On 2010-09-02, MZMcBride wrote:
Aryeh Gregor wrote:
What's the alternative? There are *always* going to be many more ideas than implementers. Ideas are cheap. Wikimedia has to decide which features are the most critical to invest developer time in. Their decision is not going to make everyone happy. The only guarantee you can ever have is if you do it yourself. Happily, MediaWiki is open-source, so you *do* have that option! On practically any other major website, you couldn't add a feature no matter how much you wanted to.
The current status of Wikimedia code deployment makes this no longer applicable to Wikimedia either.
See also: https://bugzilla.wikimedia.org/show_bug.cgi?id=23268 https://bugzilla.wikimedia.org/show_bug.cgi?id=18461 https://bugzilla.wikimedia.org/show_bug.cgi?id=15308 https://bugzilla.wikimedia.org/show_bug.cgi?id=14207 https://bugzilla.wikimedia.org/show_bug.cgi?id=15165
All asking for a feature which has been implemented since April 2008 to be reviewed and installed.
Robert
wikitech-l@lists.wikimedia.org