[Wikitech-l] [HTML5] Improving Commons upload interface
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-from-a-local-jpeg-file/ and there : http://hacks.mozilla.org/2009/12/file-drag-and-drop-in-firefox-3-6/ All the best, -- Christophe ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
On Thu, Sep 2, 2010 at 6:01 AM, Christophe Henner christophe.hen...@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-from-a-local-jpeg-file/ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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 :) -- Guillaume Paumier Product Manager, Multimedia Usability Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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 :) -- Neil Kandalgaonkar ( ne...@wikimedia.org ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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_Plan_FINAL_FOR_WEBSITE.pdf -- Guillaume Paumier ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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_Plan_FINAL_FOR_WEBSITE.pdf 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
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
On Thu, Sep 2, 2010 at 3:16 PM, Marcus Buck w...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
Marcus Buck w...@marcusbuck.org wrote in message news:4c7ff181.7010...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
Chad wrote: On Thu, Sep 2, 2010 at 3:16 PM, Marcus Buck w...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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 w...@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_Plan_FINAL_FOR_WEBSITE.pdf 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
On Thu, Sep 2, 2010 at 2:48 PM, Marcus Buck w...@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. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
An'n 02.09.2010 21:23, hett Happy-melon schreven: Marcus Buckw...@marcusbuck.org wrote in message news:4c7ff181.7010...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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 mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
On Thu, Sep 2, 2010 at 4:42 PM, Marcus Buck w...@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
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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+wikil...@gmail.comsimetrical%2bwikil...@gmail.com wrote: On Thu, Sep 2, 2010 at 4:42 PM, Marcus Buck w...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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 -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
An'n 02.09.2010 22:50, hett Aryeh Gregor schreven: On Thu, Sep 2, 2010 at 4:42 PM, Marcus Buckw...@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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] [HTML5] Improving Commons upload interface
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_transclusion 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Community vs. centralized development
Over the last couple of years, MediaWiki development has moved from being almost entirely volunteer-based to having a large contingent of paid developers. A lot of people have noted that this has led to a lot of work being done without much community involvement. Just for a basic statistic, in July, I estimate that about 90% of non-localization commits to extensions/UsabilityInitiative/ were by paid employees. (I use employee loosely in this post, to include all paid staff, such as contractors.) By contrast, about 25% (ballpark figure) of non-localization commits to phase3/ were by paid employees, and the number of volunteer commits to phase3/ was much higher than the total number of commits to UsabilityInitiative, so this isn't just a matter of community members not doing as much work overall. I've commented on this a few times before, but never at length. I think there's widespread confusion about what the problem even is, never mind how to solve it, so I'm writing this to set out at least my own views on the topic. Since my shorter remarks in other places tended to be misunderstood, I'll start at the beginning and go into considerable detail, which means this post will probably end up pretty long. I should say in advance that I'm discussing institutional problems here, not anything specific to individuals or projects, and no one should feel slighted if I pick them as an example. If you aren't really interested, start skimming. ;) Let me begin with definitions. I will draw a basic distinction between community development and centralized development. I'll start with two motivating examples. Firefox is developed by a community. Everything involved in the project and its development is open. Most of the work is done by employees of Mozilla, and all important decisions are made by employees of Mozilla, but anyone on the Internet can view what's happening and get involved. Bugs you open might get ignored forever, and you might have to poke people a bunch to get patches reviewed, and you might have to tolerate a considerable amount of bluntness and follow other people's marching orders if you want to contribute anything. But in principle, any random person in the world can make largely the same contributions as a Mozilla employee. Internet Explorer is developed by a centralized team. They have blogs where they sometimes share detailed info about their development process and reasoning. They very carefully read all user feedback left in the comments. They have a bug tracker where anyone can file bugs, and they guarantee that they'll look at and attempt to reproduce every single bug filed in a timely fashion. But although they pay close attention to feedback, giving feedback is the only way you can really participate without getting hired by Microsoft. You can't write any code, or have a voice in discussions at all comparable to an IE team member. These examples illustrate some important things: * Community development does not mean democracy. Even in a totally community-oriented project, all decisions might ultimately be made by a small group of individuals. (For instance, in the case of the Linux kernel, one person.) * Community development does not mean community members do most of the work. From what I've heard, employees of Mozilla write most of Firefox's code, but it's still completely community-oriented development. * Listening to feedback is not the same as actually involving the community. Even a totally closed project can be extremely attentive to feedback. In fact, it's common for community projects to be *less* receptive to feedback, taking a we'll listen to you when you write the code attitude. Keeping these in mind, I'll characterize a perfectly community-based development process like this: your say in the project is proportional to your contributions, and nothing prevents you from contributing as much as your time and ability allow. If you happen to be paid, it doesn't give you any additional say -- you just happen to be able to spend more time contributing. The decision-making process is open and transparent, and arguments are weighed on the basis of their merits and the speaker's history of contributions. This is of course not fully attainable in practice, but one can see how close or far a project is from the ideal. Centralized and community development processes both have advantages and disadvantages. Some of the advantages of centralized development (as relevant to open-source projects) are: * Paid employees don't have to spend time reviewing code from a lot of people who will only ever contribute a few patches, so they don't duplicate effort teaching everyone their project's coding conventions, or even educating them on basic things like XSS. * Because discussion can be private and everyone is more likely to be in similar time zones, it's possible to rely heavily on face-to-face or voice communication, which a lot of people are more comfortable with
Re: [Wikitech-l] Community vs. centralized development
On Fri, Sep 3, 2010 at 9:05 AM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: ... I scrolled; but agree with the bits I read... I don't know how seriously these suggestions will be taken in practice by the powers that be, but I hope I've made a detailed and cogent enough case to make at least some impact. There is one very, very simple solution. All changes should either be: a) a patch on bugzilla, reviewed by anyone, and approved _on_bugzilla_ by a tech lead b) the landing of a branch, approved by a tech lead in some public forum. From that, all else flows. -- John Vandenberg ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On Thu, Sep 2, 2010 at 7:05 PM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: I don't know how seriously these suggestions will be taken in practice by the powers that be, but I hope I've made a detailed and cogent enough case to make at least some impact. I hope so as well. You managed to articulate a feeling I share quite deeply. I agree with you on pretty much every point here. A /very/ strong +1 -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
2010/9/3 Aryeh Gregor simetrical+wikil...@gmail.com: * Consider what to do about code review. This is pretty much the hardest problem on this list, which is why I don't propose a specific solution here, but there has to be a better solution than assume a bunch of employees are trusted enough to sync their own code, force everyone else to wait months for central review. The current code review situation is a problem, and I don't have a ready-to-go solution for it either. Just wanted to point out I do completely agree with one of your important points before I start disagreeing with parts of almost all your other points. * Stop concentrating tech employees in San Francisco. Either have most of them work from home, or perhaps establish other small offices so that they're split up. The point is, make them rely on telecommunication, because if you put people in the same office they'll talk a lot face-to-face, and volunteers simply cannot participate. The purpose of putting people together in an office is so that they work together as a team, and this is exactly what you do *not* want, because volunteers cannot be part of that team. This is the second-hardest problem, or maybe the hardest, and I can't give a full solution for it either. I'd suggest checking with Mozilla about how they do it, because I know they do have offices, but they're a perfect example of community-oriented development. I personally don't think it should be necessary to enforce discipline (i.e. doing stuff in public) this way. Sometimes, you just want to bounce your ideas off this one person that happens to be an expert in that specific field. To give another example, I did in-person code review at the office with Ryan Kaldari last week, which was very productive. Both are inherently one-on-one and don't need to happen in public: in the bouncing ideas case, you're gonna take it public later after one person has told you it's not totally insane, in the code review case there's barely any benefit to doing it in public because it's really this one guy reviewing revisions written by this other guy. I also think that we already have a fair number of tech employees outside of San Francisco, and AFAIK we're definitely open to hiring remote people for tech jobs unless in-person interaction is essential, say for a CTO or an EPM (although we do have a half-remote EPM). I do agree that the current level of community participation and feeling like you're part of the community is lacking, but I don't agree with your solutions. * Explicitly encourage all paid developers to do everything in public and to treat volunteer developers as they would paid ones. I'm not saying this should be enforced in any particular manner, but it should be clearly stated so that everyone knows how things are intended to be. I mostly agree here. As I said above I think there's things that don't need to happen in public (little to no added value while raising the bar: walking over to someone's cubicle is easier than broadcasting your possibly stupid idea to the world), but I agree that we're not doing enough in public at this time. * Shut down the secret staff IRC channel. Development discussion can take place in #mediawiki, ops in #wikimedia-tech, other stuff in #wikimedia or whatever. If users interfere with ops' discussions sometimes in #wikimedia-tech during outages or such, set all sysadmins +v and set the channel +m as necessary. That's worked in the past. You're assuming that development discussions actually take place in these channels, which is not the case. We mostly use them for chit-chat and private or office-related things. Questions like how should I design X in my code very rarely show up in these channels, and I don't think anyone would have a problem with being more conscious about this and moving to a public place for such a discussion. * Shut down #wikimedia-dev (formerly #wikipedia_usability, kind of). The explicit purpose of the channel is to allow development discussion with less noise, but noise here means community involvement. In community development, you do get a lot more discussion, but that's not something you should try avoiding. In general, use existing discussion fora wherever possible, and if you do fragment them, make sure you don't have too much of a staff-volunteer split in which fora people use. No, noise means bots and people trying to support people with questions like how do I disable anon reads on my wiki as opposed to developers (paid and unpaid alike) being engaged in a design discussion. Maybe #wikimedia-dev should be renamed to #mediawiki-dev to remove the suggestion of WMF-exclusivity, but I definitely see the value of a channel dedicated to communication between developers with support questions and bots kept out. * Don't conduct teleconferences about development, ever. Even if volunteers are invited (are they?), time zones and non-MediaWiki obligations make all synchronous
Re: [Wikitech-l] Community vs. centralized development
On 2 September 2010 17:40, Roan Kattouw roan.katt...@gmail.com wrote: 2010/9/3 Aryeh Gregor simetrical+wikil...@gmail.com: * Shut down the secret staff IRC channel. Development discussion can take place in #mediawiki, ops in #wikimedia-tech, other stuff in #wikimedia or whatever. If users interfere with ops' discussions sometimes in #wikimedia-tech during outages or such, set all sysadmins +v and set the channel +m as necessary. That's worked in the past. You're assuming that development discussions actually take place in these channels, which is not the case. We mostly use them for chit-chat and private or office-related things. Questions like how should I design X in my code very rarely show up in these channels, and I don't think anyone would have a problem with being more conscious about this and moving to a public place for such a discussion. I don't think he is making that assumption, lots of chit-chat happens on any channel — it makes us feel left out if you have a special one (humans are really bad at the jealousy thing). What private or office-related things are there that you can't share with developers? Conrad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
Aryeh Gregor wrote: I don't know how seriously these suggestions will be taken in practice by the powers that be, but I hope I've made a detailed and cogent enough case to make at least some impact. In large part, the problems and solutions are obvious (you pointed out most of them, and this is hardly the first time this has come up). The issue is that those in power (those who sign the paychecks and employment contracts) are deliberately choosing to ignore these problems and their solutions. This isn't an assumption of bad faith and I won't hear anything of the sort. It's the reality. The problems are obvious; the solutions are obvious. What isn't obvious is why certain people in executive positions have chosen to ignore the problems. It would take a matter of minutes to shutdown the private IRC channels and private mailing lists. It would take one order from one of the members of the executive team for substantive code review and deployment to take place. But the current reality is that if it isn't part of usability or fundraising, it doesn't get any type of attention or priority. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
2010/9/3 MZMcBride z...@mzmcbride.com: In large part, the problems and solutions are obvious (you pointed out most of them, and this is hardly the first time this has come up). The issue is that those in power (those who sign the paychecks and employment contracts) are deliberately choosing to ignore these problems and their solutions. This isn't an assumption of bad faith and I won't hear anything of the sort. It's the reality. The problems are obvious; the solutions are obvious. What isn't obvious is why certain people in executive positions have chosen to ignore the problems. Your allegations that these problems are deliberately being ignored is a serious one, and you may take my word for it (although I'm fairly sure that you won't) that these people definitely care. I think you're wrong in assuming that all these solutions are totally obvious to everyone: serious thought needs to be given to this, and these people have more issues on their mind that just this single one. You are right that there doesn't seem to have been any concrete action or clear statements from people in key positions (say Erik, or, better, Danese) and I very much want that to change. I just disagree with the assertion that they don't care. It would take a matter of minutes to shutdown the private IRC channels and private mailing lists. You're assuming this is one of the obvious solutions, which I contend above. It would take one order from one of the members of the executive team for substantive code review and deployment to take place. Oh really? So I guess we have dozens of people capable of and available for reviewing and deploying code? We don't. As you have said yourself and Aryeh has pointed out, review and deployment has been a problem for a long time, and if one order could have solved it that would've happened long ago. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
Roan Kattouw wrote: 2010/9/3 MZMcBride z...@mzmcbride.com: In large part, the problems and solutions are obvious (you pointed out most of them, and this is hardly the first time this has come up). The issue is that those in power (those who sign the paychecks and employment contracts) are deliberately choosing to ignore these problems and their solutions. This isn't an assumption of bad faith and I won't hear anything of the sort. It's the reality. The problems are obvious; the solutions are obvious. What isn't obvious is why certain people in executive positions have chosen to ignore the problems. Your allegations that these problems are deliberately being ignored is a serious one, and you may take my word for it (although I'm fairly sure that you won't) that these people definitely care. I think you're wrong in assuming that all these solutions are totally obvious to everyone: serious thought needs to be given to this, and these people have more issues on their mind that just this single one. You are right that there doesn't seem to have been any concrete action or clear statements from people in key positions (say Erik, or, better, Danese) and I very much want that to change. I just disagree with the assertion that they don't care. I'm not sure if you intended it as such, but this reads as an appeal to emotion. It's not a matter of feelings or a matter of whether someone is committed to Wikimedia's mission or anything of that sort. That is, it isn't about whether people care in the sense in which you're using it. It's a matter of whether those in control are making it a priority. And from where I'm sitting, it seems fairly clear that general code review and deployment isn't being made a priority. At least where I work, if my boss says to do something, it gets done. And, more to the point, how many managers (or other employees) need to be hired before serious thought can be devoted to these issues? They seem fairly fundamental to me for an organization that runs websites. It would take a matter of minutes to shutdown the private IRC channels and private mailing lists. You're assuming this is one of the obvious solutions, which I contend above. It seems fairly obvious to me. Aryeh's points about #wikimedia-dev seem fairly spot-on. Do you disagree? If so, why? It would take one order from one of the members of the executive team for substantive code review and deployment to take place. Oh really? So I guess we have dozens of people capable of and available for reviewing and deploying code? We don't. As you have said yourself and Aryeh has pointed out, review and deployment has been a problem for a long time, and if one order could have solved it that would've happened long ago. Yes, really. When it's fundraising-related or Usability-related, there seems to be no issue with code deployment. The server admin log bears me out on this.[1] So yes, I will contend that there would be man-power for review and deployment of the rest of the codebase if it were made a priority. MZMcBride [1] http://wikitech.wikimedia.org/view/Server_admin_log ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
All of us at WMF care and follow discussions like this, especially clearly laid out and well thought-out analysis like Aryeh's original post. We don't always agree. :-) I know Danese is planning to weigh in, so I won't write too much at this time, but will point to this post from a couple of months ago where I laid out my view on some (not all) of these topics. http://lists.wikimedia.org/pipermail/foundation-l/2010-June/059052.html In general, I think most of us are in favor of more public communications, including public lists, participation in public IRC channels, wikis, etc. I don't agree with unrealistic suggestions (e.g. face-to-face meetings have very real and very serious productivity advantages that we don't want to lose), but we've generally been trending in this direction. Finally, most of these decisions aren't made by executive fiat -- Wikimedia is a very collaborative organization, and virtually all the decisions about how/where to communicate and work have been made by the people doing the work. I would wager a guess that some less constructive individuals on this list and others play a role in what choices people make. :) So, if you're trying to change the dynamics, please call out and help put an end to unconstructive and unprofessional behavior just as much as you ask for public collaboration. -- Erik Möller Deputy Director, Wikimedia Foundation Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
Erik Moeller wrote: All of us at WMF care and follow discussions like this, especially clearly laid out and well thought-out analysis like Aryeh's original post. We don't always agree. :-) I know Danese is planning to weigh in, so I won't write too much at this time, but will point to this post from a couple of months ago where I laid out my view on some (not all) of these topics. In general, I think most of us are in favor of more public communications, including public lists, participation in public IRC channels, wikis, etc. I don't agree with unrealistic suggestions (e.g. face-to-face meetings have very real and very serious productivity advantages that we don't want to lose), but we've generally been trending in this direction. Finally, most of these decisions aren't made by executive fiat -- Wikimedia is a very collaborative organization, and virtually all the decisions about how/where to communicate and work have been made by the people doing the work. I realize that management styles can and will differ, but here's the breakdown for posts by Danese to wikitech-l since she was hired in late January / early February: Feb 2010: 0 Mar 2010: 5 Apr 2010: 0 May 2010: 0 Jun 2010: 2 Jul 2010: 1 Aug 2010: 2 That's ten posts to the central Wikimedia development mailing list in seven months. Are you suggesting Danese is just a very quiet person? And while I have these tabs open, your stats for the same time period, Erik: Feb 2010: 0 Mar 2010: 3 Apr 2010: 1 May 2010: 0 Jun 2010: 0 Jul 2010: 1 Aug 2010: 1 That would be six posts in seven months. Do you think this is acceptable? Do you think it leaves anyone on the outside (or on the inside) with the perception that the Wikimedia technical executive team is concerned with being engaged with the community? When you contrast Danese's stats or your stats with Brion's or Tim's, what do you think the underlying message is? MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On 9/2/2010 9:04 PM, Roan Kattouw wrote: Oh really? So I guess we have dozens of people capable of and available for reviewing and deploying code? We don't. As you have said yourself and Aryeh has pointed out, review and deployment has been a problem for a long time, and if one order could have solved it that would've happened long ago. A long time ago, we didn't have this much of a problem with code review (except extensions/branches) and deployment. A couple years ago, we updated the site to trunk at least once a month from what I recall. We still had big features (CentralAuth, preprocessor rewrite) and still ran a fundraiser. The foundation now has probably 3 times as many staff members as then, but from the community's POV seems to get less done. -- Alex (wikipedia:en:User:Mr.Z-man) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 37-01--10 03:59 PM, Alex wrote: The foundation now has probably 3 times as many staff members as then, but from the community's POV seems to get less done. Seems true to me, except in the case of the Vector project where the red carpet gets laid out. Obviously a concern - especially since the Foundation has consistently said they aim to hire smart instead of fast. Is the tech team really doing better now than they were then? - -Mike -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) iEYEARECAAYFAkyAXV4ACgkQst0AR/DaKHtg6wCfUpcMSnRU78ZLGvWrSuh3GuaT K2kAn1RO6OcRNEuBNIkBGHETZ4NCEUPI =bUhE -END PGP SIGNATURE- ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
On Fri, Sep 3, 2010 at 3:05 AM, Aryeh Gregor simetrical+wikil...@gmail.com wrote: * Consider what to do about code review. This is pretty much the hardest problem on this list, which is why I don't propose a specific solution here, but there has to be a better solution than assume a bunch of employees are trusted enough to sync their own code, force everyone else to wait months for central review. There are three ways this problem may be dealt with: * People responsible for code review focus on code review. * People responsible for code review involve more people to review code. * People responsible for code review don't do code review and don't want to lose the control over code review process -- what is done now, does not work. The review backlog is one of the things I stopped contributing at some point. * Stop concentrating tech employees in San Francisco. Either have most of them work from home, or perhaps establish other small offices so that they're split up. The point is, make them rely on telecommunication, because if you put people in the same office they'll talk a lot face-to-face, and volunteers simply cannot participate. The purpose of putting people together in an office is so that they work together as a team, and this is exactly what you do *not* want, because volunteers cannot be part of that team. This is the second-hardest problem, or maybe the hardest, and I can't give a full solution for it either. I'd suggest checking with Mozilla about how they do it, because I know they do have offices, but they're a perfect example of community-oriented development. That won't work. Face-to-face communications are extremely efficient for many things (like Roan pointed out, it works well with code review). * Explicitly encourage all paid developers to do everything in public and to treat volunteer developers as they would paid ones. I'm not saying this should be enforced in any particular manner, but it should be clearly stated so that everyone knows how things are intended to be. Or at least document all their decision in public. * Shut down the secret staff IRC channel. Development discussion can take place in #mediawiki, ops in #wikimedia-tech, other stuff in #wikimedia or whatever. If users interfere with ops' discussions sometimes in #wikimedia-tech during outages or such, set all sysadmins +v and set the channel +m as necessary. That's worked in the past. AFAIK this is mostly a sysadmin channel. * Shut down #wikimedia-dev (formerly #wikipedia_usability, kind of). The explicit purpose of the channel is to allow development discussion with less noise, but noise here means community involvement. In community development, you do get a lot more discussion, but that's not something you should try avoiding. In general, use existing discussion fora wherever possible, and if you do fragment them, make sure you don't have too much of a staff-volunteer split in which fora people use. I'd rather rename it to #mediawiki-dev. * Stop using private e-mail for development, at least to any significant extent. If there are any internal development mailing lists or aliases or whatever used for development, retire them. Or at least make usabil...@wikimedia.org a publicly logged mailing list. I see no reason why it should not be (you may create a separate internal mailing list). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
2010/9/3 Victor Vasiliev vasi...@gmail.com: Or at least make usabil...@wikimedia.org a publicly logged mailing list. I see no reason why it should not be (you may create a separate internal mailing list). It's not really being used anymore because the Stanton grant is over now, and the people that used to work on it are now working on other tasks while still supporting the existing UsabilityInitiative / Vector software and performing rollouts such as the one this week. Other such project-specific mailing lists should preferably be public, yes. Roan Kattouw (Catrope) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Community vs. centralized development
The quotes below are illustrative excerpts, my replies are to the whole post. On 03/09/10 09:05, Aryeh Gregor wrote: That's what leads to things like http://www.mediawiki.org/wiki/Special:Code/MediaWiki/67299. Some people said that maybe that could have been phrased better, or something. But the revert wasn't the problem, it was a symptom of the problem. The problem was that the design was decided on somewhere that volunteers couldn't or wouldn't participate. Of course you revert something that contradicts an agreed-upon design -- the problem is that the agreed-upon design was only agreed upon by a small group of employees. How are volunteers supposed to contribute in that environment, if they don't know what tune they're supposed to be dancing to? The usability team has shown some amount of arrogance and aloofness in their dealings with the developer community, and I understand that you were upset by that. But I don't think arrogance is a trait which is confined to employees, in fact I think it's a near-universal fault. Being able to get stuff done in spite of it is an essential skill. I think that all developers care about usability, and that UI design should be a part of every project team. I don't think we should have one team writing bad interfaces, and another team rewriting them to be usable, it's inefficient. Ideally, UI experts should be available to be assigned to any project, and this is already happening to some extent. Project-based teams should hopefully be more open and accessible than the usability team was. As for fundraising, the work is uninspiring, and I don't think we've ever managed to get volunteers interested in it regardless of how open we've been. * Shut down the secret staff IRC channel. Development discussion can take place in #mediawiki, ops in #wikimedia-tech, other stuff in #wikimedia or whatever. If users interfere with ops' discussions sometimes in #wikimedia-tech during outages or such, set all sysadmins +v and set the channel +m as necessary. That's worked in the past. Your recommendations seem insensitive and unrealistic. What works for you does not necessarily work for everyone. Some contributors (both employees and volunteers) are not comfortable talking in a public forum, and prefer to not say anything at all than to broadcast their ideas to the world on a publically logged IRC channel or mailing list. I used to rail against such sensitivities, but I've come to see that as unproductive. I still think that we should encourage people to use public forums, but only to a point, and that point should not be use the public forum or don't contribute at all, as you seem to be suggesting. -- Tim Starling ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
