Re: [Wikitech-l] selenium browser testing proposal and prototype
On Thu, Apr 5, 2012 at 5:25 PM, Ryan Lane rlan...@gmail.com wrote: How many languages can we reasonably support? We're currently using PHP, Python, Java, OCaml and Javascript (and probably more). Should we also throw Ruby in here as well? What level of support are the Selenium tests really going to get if they require developers to use Ruby? It might be good to see examples of what MW developers would actually have to do to implement new Selenium tests once the framework is complete. There's a login example in the github prototype that's straight forward but I assume it will get simpler as more is written which can be reused. I doubt it will require much in terms of actual ruby finesse. We've already gone down the Ruby road once. I think a lot of the people involved with that would say it was a bad call, especially ops. Ruby at scale can certainly be a lulz engine, especially for those on the sidelines. This project doesn't seem to place any software demands on the production cluster, or even necessarily require anything from ops though. I assume the road you refer to was the mobile gateway; I consider that to have been a train wreck primarily from a project standpoint as opposed to a technical one. When I stumbled upon it, there wasn't an employee with the combination of access and knowledge required to commit code changes to its read-only-to-us repo, and to deploy those changes. We were essentially passing bits of duct tape back and forth by transatlantic carrier pigeon. For a slew of reasons, it makes much more sense to do what we're doing now with MobileFrontend, but we've yet to reach the point where it does anything the ruby gateway couldn't have done with a bit of iteration. In its last incarnation, it was typically faster than the current MobileFrontend for a request not served by the frontend caching layer. The point being, I don't think language was the main issue there. Chris makes a compelling argument that his preferred route is closer to being off the shelf and widely supported by industry and community. I have no comment on what QA engineers prefer to hack on, but I think the ease of hiring new ones who are good at what they do and excited about the tools they get to use should be part of the decision. -A ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [pywikipedia r10088]: Revision status changed
Xqt changed the status of pywikipedia.r10088 to ok URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/10088 Old status: new New status: ok Commit summary for pywikipedia.r10088: Adding two namespaces to meta_family.py ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] selenium browser testing proposal and prototype
You should talk to Jeremy Postlethwaite jpostlethwa...@wikimedia.org. He did some work on setting up automated Selenium tests for our fundraiser. Ryan Kaldari On 4/5/12 2:45 PM, Chris McMahon wrote: As QA Lead for WMF, one of the things I want to do is to create an institutional suite of automated cross-browser regression tests using Selenium. I have two goals for this suite: first, to make it attractive and convenient for the greater software testing community to both use the suite locally and also to contribute to it. Second, to have the suite be a useful regression test tool within WMF, tied to Beta Labs and controlled by Jenkins. For various reasons, I think the best language for this project is Ruby. I realize that is a controversial choice, and I would like to explain my reasoning. First let me address what I think will be the most serious objections: ** Ruby gems are incompatible with Debian/Ubuntu apt packaging, making it difficult or impossible to maintain Ruby code in production. The selenium test suite is not intended to run on production servers. There are two targets for this code. The first target is users' local machines, including and especially Windows users. The second target is a single dedicated headless Labs Ubuntu instance, controlled by Jenkins, serving as a client to selenium-server, where selenium-server is running on the various Windows etc. VMs that exist today on the WMF VPN. ** It's not PHP. As of today, PHP has no complete or authoritative implementation of selenium-webdriver/Selenium 2.0. That situation is unlikely to change any time soon. This leaves a choice of Ruby or Python. For various reasons I think Ruby is the superior choice. ** Design goals and their implementation. In the interest of making this project as attractive as possible to the greater testing community, I have defined a browser automation stack, using the most current and accepted practices for browser test automation. The stack looks like this: * Selenium-webdriver low-level toolbox API. * Higher-level API for consistent access to pages and elements without the user having to create their own handling for timeouts, exceptions, stale objects, multiple access criteria, etc. * Modern, BDD-style assertions for pass/fail criteria (as opposed to xUnit style assertions) * Page Object design pattern in place and functioning out of the box * Support for mobile emulators * Institutional support for Jenkins integration I submit that having these things in place and working when the user downloads the suite is what will make this project attractive to the global testing community. Taking these point by point: Even as I write this, the W3C is meeting in London to approve webdriver as an internet standard, with Selenium 2.0 as the reference implementation of that standard. This means that the selenium 2.0 API is only a fraction the size of that of Selenium 1.0, and serves a very different purpose. The selenium 2.0 API can be considered a toolbox from which higher-level APIs are constructed. Both Ruby and Python have full implementation and support for the Selenium 2.0 API. At higher levels of the stack, the Python and Ruby communities take different design approaches, with Python being more DIY/NIH and Ruby being more shared and organized around communities of practice. This is what makes Ruby so attractive as I implemented the rest of the stack. Watir (Web Application Testing In Ruby) is a browser test project that pre-dates Selenium itself. Watir provides an intuitive, thoughtful, well-designed high-level API for access to pages and elements that the native selenium-webdriver API does not. While historically Watir and Selenium have been different projects, as of about 2010 watir-webdriver is simply a wrapper for the low-level selenium API that preserves all of the convenience and good design Watir has always had. Watir is in use today at Facebook, The Gap, and many other places. Python has no such equivalent high-level API. Behavior Driven Development (BDD) style assertions are implemented in Ruby with the Rspec library. This approach to assertions has been a generally accepted standard in the Ruby community for some time. The Rspec Book was published by Pragmatic Press in 2010. Python has no equivalent BDD-style assertion library. In fact, Rspec takes advantage of Ruby's affordance for metaprogramming, something not possible in Python. Page Objects is a design pattern for browser testing that has become a generally accepted practice in the browser testing community, with a lot of momentum particularly in the last one or two years. Page Objects have institutional support in Ruby with the 'page-object' gem, which supports both watir-webdriver and selenium-webdriver syntax. Python has no such institutional support for page objects, each Python project using page objects implements the pattern locally, from scratch. Some support for mobile emulators is provided by
[MediaWiki-CodeReview] [MediaWiki r114752]: New comment added
Nikerabbit posted a comment on MediaWiki.r114752. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114752#c32640 Commit summary for MediaWiki.r114752: rearranged the filter control menu removed abusefilter tags for now, they'll go back soon removed some leftover debugging cruft Nikerabbit's comment: Thanks for removing Title Case. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r114759]: Revision status changed
Nikerabbit changed the status of MediaWiki.r114759 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114759 Old status: new New status: ok Commit summary for MediaWiki.r114759: Fix duplicate wgSpecialPageGroups entry ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[MediaWiki-CodeReview] [MediaWiki r114760]: Revision status changed
Nikerabbit changed the status of MediaWiki.r114760 to ok URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114760 Old status: new New status: ok Commit summary for MediaWiki.r114760: Use buildLike ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] GSoC - Integrate Flickr and Picasa
Hi, I would am interested in doing the GSoC. My proposal is here https://www.mediawiki.org/wiki/User:Johnnorro/GSoC_2012_application The 'integrate upload from Flickr and Picasa' would be perfect for me as I have already worked with the Picasa API in the past and I am aware of its uses and capabilities, the Flickr API is very similar to it. I know this is a bit late for amendments, but any feedback I receive would be much appreciated. Also does anyone know someone who could be interested in mentoring a project such as this? Regards, John ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal to complete manually complete unification of all accounts
Yes, I agree we should merge all accounts with no exceptions. For beginning we could create a dump of all users who could be merged and who couldn't be so that we get overview of what is needed to do. Probably a simple sql query could do that. On Fri, Apr 6, 2012 at 1:49 AM, K. Peachey p858sn...@gmail.com wrote: Indef user on one project != (always) a project wide issue. Not doing so, would potentially cause issues the same as we already do where the accounts can't unify because they exist elsewhere. ___ 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] selenium browser testing proposal and prototype
On Fri, Apr 6, 2012 at 10:17 AM, Daniel Friesen
li...@nadir-seen-fire.com wrote:
I've seen this assertion waved around again and again, but don't see where
it originates from, besides the very unreliable fact that we just don't talk
much about ruby around here.
When I said community not knowing it, I was more referring to the OPs
community (compared to the wider developer community) and others that
are more likely to be around {if|when} something breaks and the
perceivable monkey is flinging things, although it is a testing setup
so it wouldn't matter as much compared to other utilities, or if there
is a change of circumstances in the future and needs maintaining (eg:
person resonbile leaves, assigned to other projects and doesn't have
time, etc)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] GSOC 2012: Lucene Automatic Query Expansion From Wikipedia Text
Hi, I have addressed the issues in my talk page and added a 'Future Project Maintenance' section to address maintenance needs. https://www.mediawiki.org/wiki/User:Gautham_shankar/Gsoc Kindly let me know if there are any other changes i have to make. Thank you for your support, Regards, Gautham Shankar ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC - Integrate Flickr and Picasa
On 06.04.2012, 12:11 John wrote: I would am interested in doing the GSoC. My proposal is here https://www.mediawiki.org/wiki/User:Johnnorro/GSoC_2012_application The 'integrate upload from Flickr and Picasa' would be perfect for me as I have already worked with the Picasa API in the past and I am aware of its uses and capabilities, the Flickr API is very similar to it. I know this is a bit late for amendments, but any feedback I receive would be much appreciated. Also does anyone know someone who could be interested in mentoring a project such as this? Hi, your project definitely makes sense and your proposal looks good, however I don't see it on google-melange.com which is required for acceptance. Please hurry - you have less than 10 hours. -- Best regards, Max Semenik ([[User:MaxSem]]) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC 2012 : Lucene Automatic Query Expansion From Wikipedia Text
Hi Gautham, I think mining wiktionary is an interesting project. However, about the more practical Lucene part: at some point I tried using wordnet to expand queries however I found that it introduces too many false positives. The most challenging part I think it *context-based* expansion. I.e. a simple synonym-based expansion is of no use because it introduces too many meanings that the user didn't quite have in mind. However, if we could somehow use the words in the query to find a meaning from a set of possible meanings that could be really helpful. You can look into existing lucene-search source to see how I used wordnet. I think in the end I ended up using it only for very obvious stuff (e.g. 11 = eleven, UK = United Kingdom, etc..). Cheers, r. On 06/04/12 01:58, Gautham Shankar wrote: Hello, Based on the feedback i received i have updated my proposal page. https://www.mediawiki.org/wiki/User:Gautham_shankar/Gsoc There is about 20 Hrs for the deadline and any final feedback would be useful. I have also submitted the proposal at the GSOC page. Regards, Gautham Shankar ___ 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
[Wikitech-l] Advanced options
Hi, Chad recently mentioned that based on opinion of wikimedia users, most of users prefer simple options, I guess we could create a feature, perhaps a checkbox Display advanced options to user preferences, move lot of current settings which aren't really supposed to be changed by people who do not understand how they work and implement various new options in that. The advanced options could allow users to customize their recent changes feed and many similar pages, hiding certain links, or toggling various stuff. This would be great benefit for regular users since the option would be more clear and contain only stuff they likely want to change. I think we should move following to hidden section: Anything related to unified logins, new users do not need to use this Image size limit etc, most of regular users do not even understand what is this for Advanced options (whole section) Watchlist token, most of regular users do not even understand what is this for Search: Disable AJAX suggestions, Enable enhanced search suggestions (Vector skin only) Whole misc Instead of these options we could fill the space with description of remaining options When user check the Advanced they would of course see all options + some extra new options I guess this would be benefit either for advanced users as well as newbies / computer illiterates ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC - Integrate Flickr and Picasa
Max Semenik maxsem.wiki at gmail.com writes: Hi, your project definitely makes sense and your proposal looks good, however I don't see it on google-melange.com which is required for acceptance. Please hurry - you have less than 10 hours. Thanks Max, I've just submitted it now. I will still keep working on it today and try to improve it right up to the deadline. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] selenium browser testing proposal and prototype
Le 06/04/12 08:43, Asher Feldman a écrit : passing bits of duct tape back and forth by transatlantic carrier pigeon. At least that was using a standard: RFC 1149 http://www.ietf.org/rfc/rfc1149.txt A Standard for the Transmission of IP Datagrams on Avian Carriers ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Advanced options
On 6 April 2012 12:41, Petr Bena benap...@gmail.com wrote: Hi, Chad recently mentioned that based on opinion of wikimedia users, most of users prefer simple options, I guess we could create a feature, perhaps a checkbox Display advanced options to user preferences, move lot of current settings which aren't really supposed to be changed by people who do not understand how they work and implement various new options in that. I think sweeping the problem under the carpet just like that is a good idea. I don't oppose hiding some preferences by default, but only if we consider also these issues: *1 Changing preferences directly from where they are used (like from special pages) *2 Make sure we are not going to add new preferences just because they are not shown by default anymore *3 Make sure each preference label is understandable, amending with longer description where needed. There must be enough information that *any* user can understand what the preference does after reading the provided information. *4 Not call them 'advanced' but something that indicates they are rarely used and only relevant to minority of users. In other words, the criteria for hiding must be the number of users, not difficulty of understanding the preference. *5 Have sane defaults, obviously. Re 5: For example I hate that I must everywhere change enhanced recent changes to be the default. -Niklas -- Niklas Laxström ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Languages supported by Jenkins (was Changes status in Gerrit)
Le 05/04/12 20:20, Diederik van Liere a écrit : Which languages will Jenkins support? Jenkins is just a bot, we can make it do whatever we want. The plan is to have a universal linting job able to analyse any language or format in use, be it PHP, Python, JS, CSS ... https://www.mediawiki.org/wiki/Continuous_integration/Workflow_specification I am not sure when I am going to work on it, but for sure after we have bring back Testswarm alive. -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Advanced options
On 04/06/2012 07:01 AM, Niklas Laxström wrote: On 6 April 2012 12:41, Petr Bena benap...@gmail.com wrote: Hi, Chad recently mentioned that based on opinion of wikimedia users, most of users prefer simple options, I guess we could create a feature, perhaps a checkbox Display advanced options to user preferences, move lot of current settings which aren't really supposed to be changed by people who do not understand how they work and implement various new options in that. I think sweeping the problem under the carpet just like that is a good idea. I don't oppose hiding some preferences by default, but only if we consider also these issues: *1 Changing preferences directly from where they are used (like from special pages) *2 Make sure we are not going to add new preferences just because they are not shown by default anymore *3 Make sure each preference label is understandable, amending with longer description where needed. There must be enough information that *any* user can understand what the preference does after reading the provided information. *4 Not call them 'advanced' but something that indicates they are rarely used and only relevant to minority of users. In other words, the criteria for hiding must be the number of users, not difficulty of understanding the preference. *5 Have sane defaults, obviously. Re 5: For example I hate that I must everywhere change enhanced recent changes to be the default. -Niklas This is an interaction design proposal, so I'm bringing in Brandon Harris, the WMF's senior designer. Brandon, could you comment on this? -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal to complete manually complete unification of all accounts
On 06/04/12 01:49, K. Peachey wrote: Indef user on one project != (always) a project wide issue. Not doing so, would potentially cause issues the same as we already do where the accounts can't unify because they exist elsewhere. I'm talking about the account only existint in the indefinetly blocked project. Also note the case of accounts oversighted so they don't appear at Special:Listusers, would be a real failure to begin showing them at Special:Globalusers. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Advanced options
What about people changing the options, then not findign them to change them back? Yes, if they managed to misconfigure their account, they should be able to reset it noting that they did something wrong there, but many itmes that's not the case. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Museum Computer Network conference: Talk submission deadline 27 April
Heads-up. If you need a travel subsidy, you can apply for a participation grant: https://meta.wikimedia.org/wiki/Grants:Participation Call for talks: http://www.mcn.edu/mcn-2012-call-proposals -Sumana Original Message Subject:A strongly encouraged RFP MCN 2012: Call for Proposals Date: Thu, 15 Mar 2012 12:14:17 -0400 From: Lori Phillips lori.byrd.phill...@gmail.com Please see the Museum Computer Network's call for proposals below. There has been a stable Wikimedia presence at MCN for the past few years, and I hope that we'll keep it up! This year, I was shocked to be invited to be a part of the conference program committee, specifically for my unique insights as a Wikipedian and emerging museum professional. If that doesn't say something about their status as Wikipedia-supporters, I don't know what does. As a conference for museum technologists and theorists, this is a great opportunity to show off more specific uses of Wikimedia and mediawiki tools in museums. They no longer need convincing of cooperating with Wikipedia - they're looking for the next steps in how to integrate our tools and resources into their systems, and vise versa. It's an important year for more technically-inclined Wikipedians to step in and help facilitate this ongoing partnership with museum technologists more generally. The deadline for submissions is April 27th, and I do hope you'll consider submitting a proposal. Let me know if you have any questions - and please disperse this liberally! (Local lists, Tech lists, whatever lists.) Thanks so much, Lori -- Forwarded message -- From: *Elizabeth Neely* ene...@artic.edu mailto:ene...@artic.edu Date: Thu, Mar 15, 2012 at 12:02 PM Subject: [MCN-L] MCN 2012: Call for Proposals To: mc...@mcn.edu mailto:mc...@mcn.edu *The Museum Unbound:* *Shifting Perspectives, Evolving Spaces, Disruptive Technologies * MCN 2012 Seattle November 7 - 10, 2012 *Call for Proposals* http://bit.ly/xSVMXY The annual Museum Computer Network (MCN) conference brings together a diverse community of museum professionals interested in using technology to improve their organizations and enhance the visitor experience. It is not a conference purely for technologists – it’s for anyone who wants to explore exciting opportunities—and tackle the unique challenges—associated with using technology in cultural organizations. This year’s theme, “The Museum Unbound: Shifting Perspectives, Evolving Spaces, Disruptive Technologies”, focuses on exploring how the quickening pace of technological innovation is expanding the very definition of what it means to be a museum. MCN Seattle will feature a newly expanded program with a diverse set of offerings. The conference will kick off with ‘Ignite MCN’, a fast-paced and provocative idea forum. Supporting the innovation theme, the program will also feature a full set of ‘Maker’ hardware-hacking activities and a revamped un-conference program. These new activities will work hand-in-hand with the main program’s set of excellent workshops, sessions, and roundtables, providing attendees with many ways of exchanging ideas, interacting with peer professionals and learning new skills. MCN Seattle promises to be an inspiring and energetic gathering, which will be assured with your your participation! *Share your ideas and know-how: submit a proposal http://bit.ly/xSVMXYfor a session or paper at the conference. * CONTACT US Need more information? Have questions? Koven Smith Liz Neely, Program Co-Chairs: prog...@mcn.edu mailto:prog...@mcn.edu ___ You are currently subscribed to mcn-l, the listserv of the Museum Computer Network (http://www.mcn.edu) To post to this list, send messages to: mc...@mcn.edu mailto:mc...@mcn.edu To unsubscribe or change mcn-l delivery options visit: http://mcn.edu/mailman/listinfo/mcn-l The MCN-L archives can be found at: http://toronto.mediatrope.com/pipermail/mcn-l/ -- Lori Phillips Web Content Specialist | Wikipedian in Residence The Children's Museum of Indianapolis US Cultural Partnerships Coordinator Wikimedia Foundation 703.489.6036 | http://loribyrdphillips.com/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Advanced options
If users would check show advanced, then this would be checked until they would uncheck it. So if they changed the advanced stuff, they could simply go back and reset it. On Fri, Apr 6, 2012 at 2:16 PM, Platonides platoni...@gmail.com wrote: What about people changing the options, then not findign them to change them back? Yes, if they managed to misconfigure their account, they should be able to reset it noting that they did something wrong there, but many itmes that's not the case. ___ 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] Proposal to complete manually complete unification of all accounts
They could be just reserved do that it wouldn't be possible to create them Same should apply for accounts which are indefinitely blocked, the fact that someone block user Bob on some wikipedia, doesn't mean that Bob can't participate on another project. There are many active users who are indefinitely blocked on another project, so why not to process them as well On Fri, Apr 6, 2012 at 2:14 PM, Platonides platoni...@gmail.com wrote: On 06/04/12 01:49, K. Peachey wrote: Indef user on one project != (always) a project wide issue. Not doing so, would potentially cause issues the same as we already do where the accounts can't unify because they exist elsewhere. I'm talking about the account only existint in the indefinetly blocked project. Also note the case of accounts oversighted so they don't appear at Special:Listusers, would be a real failure to begin showing them at Special:Globalusers. ___ 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] Languages supported by Jenkins (was Changes status in Gerrit)
Thanks, I meant to say what languages initially will be supported :) D On 2012-04-06, at 7:04 AM, Antoine Musso wrote: Le 05/04/12 20:20, Diederik van Liere a écrit : Which languages will Jenkins support? Jenkins is just a bot, we can make it do whatever we want. The plan is to have a universal linting job able to analyse any language or format in use, be it PHP, Python, JS, CSS ... https://www.mediawiki.org/wiki/Continuous_integration/Workflow_specification I am not sure when I am going to work on it, but for sure after we have bring back Testswarm alive. -- Antoine hashar Musso ___ 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] Proposal to complete manually complete unification of all accounts
On 06/04/12 14:48, Petr Bena wrote: They could be just reserved do that it wouldn't be possible to create them Same should apply for accounts which are indefinitely blocked, the fact that someone block user Bob on some wikipedia, doesn't mean that Bob can't participate on another project. There are many active users who are indefinitely blocked on another project, so why not to process them as well In such case, they would be not blocked at least one project, so they could still be processed. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Proposal to complete manually complete unification of all accounts
Forwarding in behalf of the original user: Platonides wrote: K. Peachey wrote: Why would we not want blocked accounts to be processed? Presumably because an indefinetely blocked name (or worse, oversighted) would then need a global block. Of course blocked accounts anywhere must not be processed. Is there a need to unify old blocked sock/vandal accounts to globally block them later? No. Is there a need to unify oversighted accounts via the wpHideUser function to globally oversight later? No. Do you know that before CentralAuth had the global oversight function accounts had to be locked at meta and then you need to go wiki by wiki manually blocking with 'wpHideUser', then manually oversight meta logs? - Creating global accounts for those users, most of them with personal information, would be appalling. Creating global accounts for blocked accounts creates no benefits but would be an absolute mistake and would indeed increase the level of work stewards (I am one) would have to do to fix the problems. So, I beg *not* to include blocked accounts anywhere into this proposal. Vandals, socks and abusive names does not need to be unified so they can continue vandalizing anywhere, or exposing personal information/libel, etc. Best regards. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git migration - Extension signup
On Sat, Mar 31, 2012 at 2:48 PM, Chad innocentkil...@gmail.com wrote: Hi everyone, I'm putting together the list of existing extensions that want to be migrated with the next batch. Everyone who has an existing extension and wishes to be migrated in this batch, please add your extension and maintainer(s) to the page on mw.org[0]. I believe there was some confusion and people were signing up on the new repositories page. All of those entries were moved to the new page. The deadline to get on the list is Wednesday at 23:59 UTC. The planned migration window is going to be on Friday. Again, this is only for extensions that are already in SVN. We've got 34 awesome extensions[0] making the migration today. I'm all ready to go on my end, so let's make this the 1-hour warning. If nobody objects, in an hour I'll make these 34 extensions read-only in SVN, dump the last of their changes to git, and push them over. -Chad [0] https://www.mediawiki.org/wiki/Git/Conversion/Extensions_queue#The_list ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC, conflicts, and competition
Conflicting proposals (we will almost certainly only choose one of these): Editor rewards/ Who's been awesome: https://www.mediawiki.org/wiki/User:Shubh09/gsoc and https://www.mediawiki.org/wiki/User:Erangamapa/mygsoc I see there's another editor rewards/who's been awesome proposal: https://www.mediawiki.org/wiki/User:Timothyandrew/GSOC_2012_Proposal Timothy, you have about five hours left to submit your proposal through Google Melange http://www.google-melange.com/gsoc/homepage/google/gsoc2012 -- if you don't, you're ineligible to participate in our GSoC program this year. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC proposal: Native application uploader
On Apr 5, 2012, at 1:40 AM, Platonides wrote: Hello all, I'm presenting a GSOC proposal for a native desktop application designed for mass uploading files on upload campaigns. This follows the call by Odder at [1] for such a tool, and indeed the scope of the tool would be tailored to WikiLovesMonuments. The deliverable is such an application, which shall be: * A tiny autocontained program (probably in C++), with different versions for each target operating system. * Configurable defaults for uploading to Wikimedia Commons own images as cc-by-sa with given templates and categories. * The user shall be able to change the license / categories if needed. * Request the monument id for the image. * Validation of the monument identifier through a web service if available and time permits. * Basic documentation of the competition (rules and FAQ) * Contains the WLM logo somewhere. * Localisable through translatewiki.net for at least the 28 countries of [2] * Save configuration of images description for later upload. * Asynchronous upload of the images in the background. Opinions? Improvements? Sexy names? Mentors? All of them are welcome! 1- http://lists.wikimedia.org/pipermail/wikilovesmonuments/2012-March/002538.html 2- http://commons.wikimedia.org/wiki/Commons:Wiki_Loves_Monuments_2012/Participating_countries Blame me for loving front-end technology, but maybe one of these ideas are useful to you: * Not WLM specific internally, please (instead it could come with a number of modes, possibly extendable with plugins) * Perhaps not a desktop application at all (nothing more mobile and future proof than the web[1]). Something like a MediaWiki extension or a standalone web application. Or extend / improve UploadWizard. * If none of these, perhaps you can be persuaded to go for a hybrid, look at Adobe AIR. With AIR you can use HTML/CSS/JS but not deal with traditional web browsers. Instead it runs as a native application, also very flexible and cross-OS. And no cross-browser issues since the only engine it'd run on is that of AIR (uses WebKit). With AIR it still has most desktop application possibilities such as caching files locally, updating the application periodically, storing preferences, accessing the file system, details I/O and up/download uploading/progress meters etc. -- Krinkle [1] disclaimer, disclaimer, .. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Advanced options
On Fri, Apr 6, 2012 at 6:16 AM, Platonides platoni...@gmail.com wrote: What about people changing the options, then not findign them to change them back? Yes, if they managed to misconfigure their account, they should be able to reset it noting that they did something wrong there, but many itmes that's not the case. Most of these sorts of config displays have a reset to default values switch. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC - Green SMW
On 05/04/12 19:49, Gregory Varnum wrote: ... Oy - I love GSOC but the whole competition part makes me sad. :) Yes, and I think you are actually right with your observation (in a way). Sumana has pointed out that there are no topic conflicts for SMW-applications so far, but there are resource conflicts on other levels: we will have to limit the number of projects to ensure that there are enough dedicated mentors for each project. So even different projects can be mutually exclusive. This is still a bit sad, but I would rather do this than have insufficient guidance for the students. Markus On Apr 5, 2012, at 4:41 AM, Markus Krötzschmar...@semantic-mediawiki.org wrote: On 04/04/12 06:01, Gregory Varnum wrote: I'll admit - I'm intrigued by the notion of carbon footprint reduction via software enhancements.. :) I appreciate that you've concisely provided background on the what and how. I'm curious if you can expand a tad more on the why. To many the notion of energy conservation is very familiar - but in all fairness - I've suggested to others that they not assume everyone will know as much as they do - so a bit more info there wouldn't hurt. The title Green SMW should not lead to wrong expectations. The goal of this project is to address a number of long-standing performance issues in various components. The tasks are based on concrete problem reports we got from various SMW users. Is this what you mean with the why? The goal is to take a more general perspective in Green SMW and to not optimize for one use-case only, but to address known architectural weaknesses that are causing these issues. You've been in IRC actively - so you're aware of that resource. Same comment to SMW folks as Flickr folks - contemplate each other's proposals and be mindful of any overlap and the stated criteria like quality of apps, etc. Might not be a bad idea to see what others are proposing. :) I am not sure I know what you are referring to. I don't see Flickr-related projects that are similar to this project. We should of course be careful with overlaps, but I cannot see any issue there right now. Or maybe you meant something else? Markus On Apr 4, 2012, at 12:33 AM, nischay nahatanischay...@gmail.com wrote: Hi, I am participating in GSOC'12 with my proposal for Green SMW [1]. This proposal is about reducing the carbon footprint of SMW , in other words it will enhance the performance of SMW significantly. All the details are on [1], suggestions to improve or comments are most welcome. I have also been contributing to MW with my new Extension:AllTimeZones [2], comments to that are welcomed as well. My other contributions to MW are listed here [3]. [1]www.mediawiki.org/wiki/User:Nischayn22/Gsoc [2]www.mediawiki.org/wiki/Extension:AllTimeZones [3]www.mediawiki.org/wiki/User:Nischayn22 -- With Regards Nischay Nahata B.tech 3rd year Department of Information Technology NITK,Surathkal ___ 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 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Advanced options
On Fri, Apr 6, 2012 at 10:07 AM, Chris McMahon cmcma...@wikimedia.org wrote: On Fri, Apr 6, 2012 at 6:16 AM, Platonides platoni...@gmail.com wrote: What about people changing the options, then not findign them to change them back? Yes, if they managed to misconfigure their account, they should be able to reset it noting that they did something wrong there, but many itmes that's not the case. Most of these sorts of config displays have a reset to default values switch. Yeah, we've had a link saying Restore all default settings for years now. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Renaming deployment site central wiki
The central wiki was renamed deployment.wikimedia.beta.wmflabs.org On Tue, Apr 3, 2012 at 2:52 PM, Petr Bena benap...@gmail.com wrote: Test wiki is running production version of mediawiki, so it's not useful to perform any tests of software which wasn't reviewed and isn't considered stable. It's a last place where sw goes to before it's updated on production sites. Developers can test some configuration changes and scripts to test if it wouldn't break anything. The deployment site on labs is meant to be a place where unstable software and development version is running, so that community of wikimedia projects and tech folks can test it while it's still in development and prepare their gadgets to work with future version of software. I hope it's more clear now On Tue, Apr 3, 2012 at 12:09 PM, Srikanth Lakshmanan srik@gmail.com wrote: On Tue, Apr 3, 2012 at 13:07, Petr Bena benap...@gmail.com wrote: since some of them thought that deployment site is wikimedia labs, while in fact it's a project of wikimedia labs Backstage projects in the meta homepage[1] might need an update to reflect the correct understanding too. Also correct me if am wrong, TestWiki is to test *any* change while the deployment site is for testing next wmf release. Translatewiki is the place to preview/test all i18n changes. Has testwiki become redundant after having the deployment site? [1] http://meta.wikimedia.org/wiki/Main_Page -- Regards Srikanth.L ___ 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
[Wikitech-l] GSoC: Caterpillar the Category Tool
Hello, I present a proposal for a system that is going to solve the category intersection problem (and, in fact, allow all set-theory operations for categories). The name I suggest for it is “Caterpillar”. Such a system would consist of a C or C++ backend daemon that stores all the category graph in RAM and MediaWiki extension frontend. Here is the full text of the proposal: https://www.mediawiki.org/wiki/User:Kalan/gsoc I am seeking for an interested mentor. — Kalan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] selenium browser testing proposal and prototype
PHPUnit has been working on Selenium2 with the backwards compatibility API: https://github.com/sebastianbergmann/phpunit-selenium/blob/master/PHPUnit/Extensions/Selenium2TestCase.php I have not had a chance to test it out, it is still experimental. It would seem appropriate for someone to add it to the extension UnitTest extension: https://www.mediawiki.org/wiki/Extension:UnitTest I have spoken to Chris and Mark about the extension. Correct me if I am wrong, Chris: I think we came to the conclusion that UnitTest may be better suited for local developer usage instead of automated testing. I would also like to see examples of Watir. On Fri, Apr 6, 2012 at 4:00 AM, Antoine Musso hashar+...@free.fr wrote: Le 06/04/12 08:43, Asher Feldman a écrit : passing bits of duct tape back and forth by transatlantic carrier pigeon. At least that was using a standard: RFC 1149 http://www.ietf.org/rfc/rfc1149.txt A Standard for the Transmission of IP Datagrams on Avian Carriers ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jeremy Postlethwaite jpostlethwa...@wikimedia.org 415-839-6885 x6790 Backend Software Developer Wikimedia Foundation http://wikimediafoundation.org/ ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] selenium browser testing proposal and prototype
Correct me if I am wrong, Chris: I think we came to the conclusion that UnitTest may be better suited for local developer usage instead of automated testing. Jeremy, yes, I'm aware of what you're doing and I think it makes sense in context. In my original post I said Since the purpose of this project is to attract members of the global testing community, and to provide an institutional regression test suite for Mediawiki/Wikipedia, I see no reason to require individual WMF projects to use this framework... I would also like to see examples of Watir. Watir is pretty slick: http://rubydoc.info/gems/watir-webdriver/0.5.4/frames . I'm not sure if you're using selenium-webdriver or the old Selenium 1.0, but Watir solves a lot of issues for selenium-webdriver. In fact, if you're using selenium-webdriver in any language, you probably end up hacking up something that looks like Watir anyway. Watir has the advantage of nearly a decade of design and refiinement behind it, plus the API is generated directly from the HTML5 spec today. (just an aside, Selenium 1.0 is not yet fully deprecated, there is still a ton of Se1.0 out in the world, but the Se1.0 API will eventually be fully retired.) On Fri, Apr 6, 2012 at 4:00 AM, Antoine Musso hashar+...@free.fr wrote: Le 06/04/12 08:43, Asher Feldman a écrit : passing bits of duct tape back and forth by transatlantic carrier pigeon. At least that was using a standard: RFC 1149 http://www.ietf.org/rfc/rfc1149.txt A Standard for the Transmission of IP Datagrams on Avian Carriers ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- Jeremy Postlethwaite jpostlethwa...@wikimedia.org 415-839-6885 x6790 Backend Software Developer Wikimedia Foundation http://wikimediafoundation.org/ ___ 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
[MediaWiki-CodeReview] [pywikipedia r10090]: Revision status changed
Xqt changed the status of pywikipedia.r10090 to ok URL: http://www.mediawiki.org/wiki/Special:Code/pywikipedia/10090 Old status: new New status: ok Commit summary for pywikipedia.r10090: Follow-up to r10089, removing debug stuff. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] GSOC 2012 : Lucene Automatic Query Expansion From Wikipedia Text
Robert Stojnic rainmansr at gmail.com writes: Hi Gautham, I think mining wiktionary is an interesting project. However, about the more practical Lucene part: at some point I tried using wordnet to expand queries however I found that it introduces too many false positives. The most challenging part I think it *context-based* expansion. I.e. a simple synonym-based expansion is of no use because it introduces too many meanings that the user didn't quite have in mind. However, if we could somehow use the words in the query to find a meaning from a set of possible meanings that could be really helpful. You can look into existing lucene-search source to see how I used wordnet. I think in the end I ended up using it only for very obvious stuff (e.g. 11 = eleven, UK = United Kingdom, etc..). Cheers, r. On 06/04/12 01:58, Gautham Shankar wrote: Hello, Based on the feedback i received i have updated my proposal page. https://www.mediawiki.org/wiki/User:Gautham_shankar/Gsoc There is about 20 Hrs for the deadline and any final feedback would be useful. I have also submitted the proposal at the GSOC page. Regards, Gautham Shankar ___ Wikitech-l mailing list Wikitech-l at lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Hi Robert, Thank you for your feedback. Like you pointed out, query expansion using the wordnet data directly, reduces the quality of the search. I found this research paper very interesting. www.sftw.umac.mo/~fstzgg/dexa2005.pdf They have built a TSN (Term Semantic Network) for the given query based on the usage of words in the documents. The expansion words obtained from the wordnet are then filtered out based on the TSN data. I did not add this detail to my proposal since i thought it deals more with the creation of the wordnet. I would love to implement the TSN concept once the wordnet is complete. Regards, Gautham Shankar ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git migration - Extension signup
On Fri, Apr 6, 2012 at 9:44 AM, Chad innocentkil...@gmail.com wrote: On Sat, Mar 31, 2012 at 2:48 PM, Chad innocentkil...@gmail.com wrote: Hi everyone, I'm putting together the list of existing extensions that want to be migrated with the next batch. Everyone who has an existing extension and wishes to be migrated in this batch, please add your extension and maintainer(s) to the page on mw.org[0]. I believe there was some confusion and people were signing up on the new repositories page. All of those entries were moved to the new page. The deadline to get on the list is Wednesday at 23:59 UTC. The planned migration window is going to be on Friday. Again, this is only for extensions that are already in SVN. We've got 34 awesome extensions[0] making the migration today. I'm all ready to go on my end, so let's make this the 1-hour warning. If nobody objects, in an hour I'll make these 34 extensions read-only in SVN, dump the last of their changes to git, and push them over. -Chad [0] https://www.mediawiki.org/wiki/Git/Conversion/Extensions_queue#The_list This is now done. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSOC 2012 : Lucene Automatic Query Expansion From Wikipedia Text
Hi Robert Stojnic and Gautham Shankar I wanted to let Gautham that he has written a great proposal and thank you for the feedback as well. I wanted to point out that in my point of view the main goal of this multilingual wordnet isn't queary expansion, but rather means for ever greater cross language capabilites in search and content analytics. A wordnet seme can be further disambiguated using a topic map algorithm run which would consider all the contexts like you suggest. But this is planned latter and so the wordnet would be a milestone. To further clarify Gautham's integration will place a XrossLanguage-seme Word Net tokens during indexing for words it recognises - allow the ranking algorithm to use knowldege drawn from all the wikipedia articles. (For example one part of the ranking would peek into featured article in German on A rank it then B featured in Hungarian and use them as oracles to rank A B ... in English where the picture might now be X Y Z ... B A ...) I mention in passing that I have began to develop dataset for use with open relavance to sytematicly review and evaluate dramatic changes to relevance due to changes in the search engine. I will post on this in due course as it matures - since I am working on a number of smaller projects i'd like to demo at WikiMania.) On Fri, Apr 6, 2012 at 6:01 PM, Gautham Shankar gautham.shan...@hiveusers.com wrote: Robert Stojnic rainmansr at gmail.com writes: Hi Gautham, I think mining wiktionary is an interesting project. However, about the more practical Lucene part: at some point I tried using wordnet to expand queries however I found that it introduces too many false positives. The most challenging part I think it *context-based* expansion. I.e. a simple synonym-based expansion is of no use because it introduces too many meanings that the user didn't quite have in mind. However, if we could somehow use the words in the query to find a meaning from a set of possible meanings that could be really helpful. You can look into existing lucene-search source to see how I used wordnet. I think in the end I ended up using it only for very obvious stuff (e.g. 11 = eleven, UK = United Kingdom, etc..). Cheers, r. On 06/04/12 01:58, Gautham Shankar wrote: Hello, Based on the feedback i received i have updated my proposal page. https://www.mediawiki.org/wiki/User:Gautham_shankar/Gsoc There is about 20 Hrs for the deadline and any final feedback would be useful. I have also submitted the proposal at the GSOC page. Regards, Gautham Shankar ___ Wikitech-l mailing list Wikitech-l at lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Hi Robert, Thank you for your feedback. Like you pointed out, query expansion using the wordnet data directly, reduces the quality of the search. I found this research paper very interesting. www.sftw.umac.mo/~fstzgg/dexa2005.pdfhttp://www.sftw.umac.mo/%7Efstzgg/dexa2005.pdf They have built a TSN (Term Semantic Network) for the given query based on the usage of words in the documents. The expansion words obtained from the wordnet are then filtered out based on the TSN data. I did not add this detail to my proposal since i thought it deals more with the creation of the wordnet. I would love to implement the TSN concept once the wordnet is complete. Regards, Gautham Shankar ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l Hi again -- Oren Bochman Office tel. 061 4921492 Mobile +36 30 866 6706 skype id: orenbochman e-mail: o...@romai-horizon.com site http://www.riverport.hu ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC: Caterpillar the Category Tool
Kalan, I would expand more on what you'd like to accomplish and why. Also move some of the About info to the top and fill out the bottom About with information about yourself in particular - we'd like to get to know you (for those that don't already). Have you had any interest from potential mentors? If not, I would look into the resources outlining interested volunteers - and touch base with folks in IRC. https://www.mediawiki.org/wiki/GSOC#Mentor_signup -greg aka varnent On Apr 6, 2012, at 11:11 AM, Kalan kalan@gmail.com wrote: Hello, I present a proposal for a system that is going to solve the category intersection problem (and, in fact, allow all set-theory operations for categories). The name I suggest for it is “Caterpillar”. Such a system would consist of a C or C++ backend daemon that stores all the category graph in RAM and MediaWiki extension frontend. Here is the full text of the proposal: https://www.mediawiki.org/wiki/User:Kalan/gsoc I am seeking for an interested mentor. — Kalan ___ 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] Languages supported by Jenkins (was Changes status in Gerrit)
Le 06/04/12 15:16, Diederik van Liere wrote: Thanks, I meant to say what languages initially will be supported Most probably PHP first then Python since you have already provided a linter for it :-D ;) -- Antoine hashar Musso ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git migration - Extension signup
I need BookManager in git before GSoC =D 2012/4/6 Chad innocentkil...@gmail.com On Fri, Apr 6, 2012 at 9:44 AM, Chad innocentkil...@gmail.com wrote: On Sat, Mar 31, 2012 at 2:48 PM, Chad innocentkil...@gmail.com wrote: Hi everyone, I'm putting together the list of existing extensions that want to be migrated with the next batch. Everyone who has an existing extension and wishes to be migrated in this batch, please add your extension and maintainer(s) to the page on mw.org[0]. I believe there was some confusion and people were signing up on the new repositories page. All of those entries were moved to the new page. The deadline to get on the list is Wednesday at 23:59 UTC. The planned migration window is going to be on Friday. Again, this is only for extensions that are already in SVN. We've got 34 awesome extensions[0] making the migration today. I'm all ready to go on my end, so let's make this the 1-hour warning. If nobody objects, in an hour I'll make these 34 extensions read-only in SVN, dump the last of their changes to git, and push them over. -Chad [0] https://www.mediawiki.org/wiki/Git/Conversion/Extensions_queue#The_list This is now done. -Chad ___ 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] GSOC - Green SMW
Hi, Thanks for the reply, I hope it will be useful to you (if got selected). Could you please link to your site? On Fri, Apr 6, 2012 at 9:01 PM, Thomas Fellows thomas.fell...@gmail.comwrote: Hey Nischay! Really excited about your proposal - we use an incredibly large SMW instance (something like 36million pages, ~167805989 triples and another 30mil coordinates). As you might expect, it doesn't really work. Granted, we haven't moved to a triple store yet, but after the work you're doing we might have a chance to take another look at it. Good luck! -Tom. On Wed, Apr 4, 2012 at 12:33 AM, nischay nahata nischay...@gmail.comwrote: Hi, I am participating in GSOC'12 with my proposal for Green SMW [1]. This proposal is about reducing the carbon footprint of SMW , in other words it will enhance the performance of SMW significantly. All the details are on [1], suggestions to improve or comments are most welcome. I have also been contributing to MW with my new Extension:AllTimeZones [2], comments to that are welcomed as well. My other contributions to MW are listed here [3]. [1]www.mediawiki.org/wiki/User:Nischayn22/Gsoc [2]www.mediawiki.org/wiki/Extension:AllTimeZones [3]www.mediawiki.org/wiki/User:Nischayn22 -- With Regards Nischay Nahata B.tech 3rd year Department of Information Technology NITK,Surathkal ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l -- With Regards Nischay Nahata B.tech 3rd year Department of Information Technology NITK,Surathkal ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Git migration - Extension signup
On Fri, Apr 6, 2012 at 2:00 PM, Raylton P. Sousa raylton.so...@gmail.com wrote: I need BookManager in git before GSoC =D I'll announce the next window early next week. -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] GSoC: Caterpillar the Category Tool
Hello Kalan, This is a late proposal, but still a very interesting goal. I wonder however about how you expect to perform it. What kind of structure would you use for in-memory storage of the categories? How do you perform intersection in that? How do you update them? (ie. category insertion/deletion) Do you have a rough estimate of the complexity order of each of those operations? I agree it's a good challenge, and I'm happy that you're excited with that, but I'm afraid that it might be too hard to actually accomplish. Or it may be doable, but needing several compromises. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Advanced options
Yet some people still shoots itself in the foot by enabling the 'external editor'. I'm not opposed to the concept of Advanced options, but beware of the ingenuity of fools when making the system. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Development process doesn't work (yes this is another complaint from another community member)
On Wed, Apr 4, 2012 at 8:47 PM, Tim Starling tstarl...@wikimedia.org wrote: Anyway, it certainly isn't the case for core contributions, or for contributions to existing extensions, both of which have a healthy level of community commits. The problem is limited to new extension deployments, and perhaps to major core branch merges like IWTransclusion. I agree with this, but also with the fact that extension review is currently broken. Part of the answer, IMO, is going to have to be to trust more volunteers to do lots of legwork on getting extensions ready for deployment. Part of the answer is more systematic resourcing. Right now we're dealing with a flood of new committers across the board (thanks to the lightweight developer access process), so keeping up with changes to core and deployed extensions, and getting onto a two-week deployment schedule from core, is our highest priority internally. Petr, regarding the extensions you're hoping will get deployed, do we have existing test setups in labs (single-instance wiki or deployment-prep) so we can give these more eyes from developers and non-devs alike? If not, would you be willing to set those up? We're not behaving like Oracle does with Java or MySQL, or like Google does with Android. We develop code in public repositories and grant commit access liberally. This is very true. Moreover, we're not merely shipping a software product, but actually installing software on a top 5 web property with a large, active and vocal community. What seems trivial is often not. It's clear that WMF will get plenty of blame if we're seen to ignore consensus or install software with unforeseen negative side effects, so any extension, no matter how small or large, can potentially be fairly hairy. We do want to make sure we have eyeballs not just from devs but also from user interface/UX folks where needed. Criticism is warranted and needed. However, I'm always interested in seeing examples of people or organizations who do a better job at solving the same kinds of problems. That would allow us to learn from them, and also add weight to criticism where we're failing to do the obvious. But mostly, these aren't obvious problems. Resourcing to support an ever-changing firehose of suggested changes, many of which should _not_ be made or need improvement, while also making our own pace of continued improvements is inherently hard -- as our problems with new editor retention in the all-volunteer editorial community show. Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Development process doesn't work (yes this is another complaint from another community member)
On Wed, Apr 4, 2012 at 3:27 PM, MZMcBride z...@mzmcbride.com wrote: I asked about this policy a few months ago: http://lists.wikimedia.org/pipermail/wikitech-l/2012-March/058665.html. Rob never replied and the thread died. There's a difference between having a page on MediaWiki.org and having a policy. From what I've seen, it's mostly the former, though I'd be thrilled if someone can prove me wrong. Currently 20% is being enforced by reminders from Rob or his delegate during the days that a person's signed up for it. It's typically going towards code review or deployment support. When a person's not ponying up, Rob will escalate the issue if needed. In some cases we've created exemptions (e.g. fundraising engineering has only 2 staff right now, so they're exempt until they get a couple more engineers on board, so they can get any work done). I'd love more metrics, of course. Do we have any git/gerrit metrics already? Erik -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [Wikimedia r1591]: New comment added
Jpostlethwaite posted a comment on Wikimedia.r1591. URL: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/1591#c32641 Commit summary for Wikimedia.r1591: Adding search by order id to module. See r1590. Jpostlethwaite's comment: This was done for the Mingle card: https://mingle.corp.wikimedia.org/projects/fundraiser_2011/cards/385 This allows someone to search by order id from the recurring_globalcollect_module: /?q=admin/settings/recurring_globalcollect/search If necessary, I can move this to a separate module. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
Re: [Wikitech-l] selenium browser testing proposal and prototype
We've already gone down the Ruby road once. I think a lot of the people involved with that would say it was a bad call, especially ops. Ruby at scale can certainly be a lulz engine, especially for those on the sidelines. This project doesn't seem to place any software demands on the production cluster, or even necessarily require anything from ops though. I had mentioned in IRC that I don't have any major ops objections as long as whatever gems are required are installable via apt in some way, rather than using gems. I assume the road you refer to was the mobile gateway; I consider that to have been a train wreck primarily from a project standpoint as opposed to a technical one. When I stumbled upon it, there wasn't an employee with the combination of access and knowledge required to commit code changes to its read-only-to-us repo, and to deploy those changes. We were essentially passing bits of duct tape back and forth by transatlantic carrier pigeon. For a slew of reasons, it makes much more sense to do what we're doing now with MobileFrontend, but we've yet to reach the point where it does anything the ruby gateway couldn't have done with a bit of iteration. In its last incarnation, it was typically faster than the current MobileFrontend for a request not served by the frontend caching layer. The point being, I don't think language was the main issue there. Ubuntu support for ruby was problematic. The need for a bunch of gems was also problematic. This particular use of ruby is less problematic since we won't need to run a web service using ruby. My main objection is really that we're fracturing our codebase into a bunch of languages. It's hard enough getting people to write tests, and making people write their code in PHP, some of their tests in PHP, and some of the tests in Ruby is likely prone to failure. I don't think python is a reasonable choice here either, honestly. Chris makes a compelling argument that his preferred route is closer to being off the shelf and widely supported by industry and community. I have no comment on what QA engineers prefer to hack on, but I think the ease of hiring new ones who are good at what they do and excited about the tools they get to use should be part of the decision. I'd be more interested in what's more likely to grow and keep our community, and give us proper tests, than who's easier to hire. We're based on the concept of scaling people by building communities. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] selenium browser testing proposal and prototype
On Fri, 06 Apr 2012 12:33:40 -0700, Ryan Lane rlan...@gmail.com wrote: We've already gone down the Ruby road once. I think a lot of the people involved with that would say it was a bad call, especially ops. Ruby at scale can certainly be a lulz engine, especially for those on the sidelines. This project doesn't seem to place any software demands on the production cluster, or even necessarily require anything from ops though. I had mentioned in IRC that I don't have any major ops objections as long as whatever gems are required are installable via apt in some way, rather than using gems. Ryan, I only ran into it recently. But look over bundler: http://gembundler.com/rationale.html If another situation where something needs gems without existing apt packages comes up it may be a helpful thing to have in your toolkit of solutions. Two useful things that bundler seems to provide: - In deployment it can install gems in a place local to the application. So instead of using `gem` or apt to globally install the gems needed they'll be installed locally in a way that won't conflict with other applications. - Bundler uses a Gemfile.lock setup; When you initially install and updated gems on development it tracks the installed versions of every single dependency installed (even indirect ones you didn't depend on directly). And when you develop you check this file into version control with the rest of your source code. Using this setup bundler ensures that every gem you install using bundler (especially under deployment) is installed using the exact same version of the gem that you used during development.; So if you're using apt and a central apt sources server to ensure that all servers have the same package versions installed, bundler should help you attain that same goal with gems that don't have apt packages. - Ryan -- ~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name] ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] selenium browser testing proposal and prototype
Ryan, I only ran into it recently. But look over bundler: http://gembundler.com/rationale.html If another situation where something needs gems without existing apt packages comes up it may be a helpful thing to have in your toolkit of solutions. Two useful things that bundler seems to provide: - In deployment it can install gems in a place local to the application. So instead of using `gem` or apt to globally install the gems needed they'll be installed locally in a way that won't conflict with other applications. - Bundler uses a Gemfile.lock setup; When you initially install and updated gems on development it tracks the installed versions of every single dependency installed (even indirect ones you didn't depend on directly). And when you develop you check this file into version control with the rest of your source code. Using this setup bundler ensures that every gem you install using bundler (especially under deployment) is installed using the exact same version of the gem that you used during development.; So if you're using apt and a central apt sources server to ensure that all servers have the same package versions installed, bundler should help you attain that same goal with gems that don't have apt packages. If that goal is constantly changing versions of packages that may or may not have proper security patches applied due to dependency chains, then yes, it meets the goal. I hate programming language package installers like pip, gems, etc. When Ubuntu ships versions of things, they keep stable versions and backport security fixes. This ensures that you'll have a consistent environment until you upgrade the OS, and that security patches are applied properly for everything in this environment. If your application depends on gem blah-0.1, and specifies that, then you won't get security patches since gems expects you'll just upgrade to blah-0.9. It fills me with rage. - Ryan ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Updated 1.20wmf1 deployment schedule - starting April 10
Hi everyone, In order to avoid stomping on the Easter holiday in Europe, we're postponing the first day of the deployment of MediaWiki 1.20wmf01 Tuesday, April 10, 18:00-20:00 UTC (11am-1pm PDT): MediaWiki 1.20wmf01 deployment - test2, potentially mediawiki.org Wednesday April 11, 18:00-20:00 UTC (11am-1pm PDT): Potentially window for MediaWiki.org 1.20wmf01 deployment if needed Monday, April 16, 18:00-20:00 UTC (11am-1pm PDT): MediaWiki 1.20wmf01 deployment - Deploy to all non-Wikipedia sites (commons, Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity) -- potentially split into two deployments if needed Monday, April 23, 18:00-20:00 UTC (11am-1pm PDT): MediaWiki 1.20wmf01 deployment - Deploy to English Wikipedia Wednesday, April 25, 18:00-20:00 UTC (11am-1pm PDT): MediaWiki 1.20wmf01 deployment - Deploy to other Wikipedias Also, some bikeshedding on the branch name: I vote that the branch name to be wmf/1.20wmf01 , and subsequent deployments to follow that scheme. That way, we can still say 1.20wmf01 as shorthand, and people can figure out that oh, you prefix wmf/ on the front for permissions reasons. Other work that's underway or needs to get underway: * Chad has started the work of converting make-wmf-branch to Git: https://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/make-wmf-branch/default.conf?view=markup * Aaron is also working on the scripts for pulling our WMF-specific hacks and reapplying them in 1.20. * We still need to audit the scap/sync scripts to make sure that .git folder is being excluded on scap. Roan has started looking at that now. During the next few weeks while both 1.19wmf1 and 1.20wmf01 are out there, we're going to need to use both Subversion and Git for deployment-oriented code. Rob ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Advanced options
On Fri, Apr 6, 2012 at 08:01, Niklas Laxström niklas.laxst...@gmail.com wrote: Re 5: For example I hate that I must everywhere change enhanced recent changes to be the default. I hated it even more when I was looking for the enhanced watchlist and discovered it is not in the Watchlist section of the preferences page, but instead, on the Recent changes section under the description Enhanced recent changes (requires JavaScript), which doesn't even mention the watchlist... https://bugzilla.wikimedia.org/show_bug.cgi?id=35768 Helder ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Updated 1.20wmf1 deployment schedule - starting April 10
On Fri, Apr 6, 2012 at 4:59 PM, Rob Lanphier ro...@wikimedia.org wrote: Also, some bikeshedding on the branch name: I vote that the branch name to be wmf/1.20wmf01 , and subsequent deployments to follow that scheme. That way, we can still say 1.20wmf01 as shorthand, and people can figure out that oh, you prefix wmf/ on the front for permissions reasons. Sounds fine. Other work that's underway or needs to get underway: * Chad has started the work of converting make-wmf-branch to Git: https://svn.wikimedia.org/viewvc/mediawiki/trunk/tools/make-wmf-branch/default.conf?view=markup This is almost done enough for the first deploy. * Aaron is also working on the scripts for pulling our WMF-specific hacks and reapplying them in 1.20. Like I said to him on IRC, the absolute best thing to do here is get them into master so we can avoid the conflicts. Worst case, we can just apply them manually to the branch once we've made it. * We still need to audit the scap/sync scripts to make sure that .git folder is being excluded on scap. Roan has started looking at that now. Awesome. During the next few weeks while both 1.19wmf1 and 1.20wmf01 are out there, we're going to need to use both Subversion and Git for deployment-oriented code. That's part of the fun ;-) -Chad ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Updated 1.20wmf1 deployment schedule - starting April 10
On Fri, Apr 6, 2012 at 2:16 PM, Chad innocentkil...@gmail.com wrote: * We still need to audit the scap/sync scripts to make sure that .git folder is being excluded on scap. Roan has started looking at that now. Awesome. Done in https://www.mediawiki.org/wiki/Special:Code/MediaWiki/114777 , filed https://rt.wikimedia.org/Ticket/Display.html?id=2785 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[MediaWiki-CodeReview] [MediaWiki r114782]: New comment added
^demon posted a comment on MediaWiki.r114782. URL: http://www.mediawiki.org/wiki/Special:Code/MediaWiki/114782#c32642 Commit summary for MediaWiki.r114782: More robust error detection for when you misconfigure ^demon's comment: Also makes it possible to pin an extension to a specific sha1 when $oldVersion is master. ___ MediaWiki-CodeReview mailing list mediawiki-coderev...@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-codereview
[Wikitech-l] GSoC applications closed
The deadline for students to apply to Google Summer of Code has now passed. We received 41 substantive proposals*, but of course can only accept a small subset of those. We don't have that many willing mentors, we certainly won't get that many slots from Google, and I want to accept only students who are very likely to succeed. Early next week I'll be in touch with mentors to finish ranking and grading the proposals. Also next week, several applicants who still haven't found mentors will be looking for experienced developers to fall in love with their proposals. :-) We'll announce the acceptances on April 23rd. * And 22 that were spam, copy-and-paste from our ideas list, incredibly vague, etc. In 2011 we only got about 24 consideration-worthy proposals, so this year's quite an increase. Thanks to everyone who did outreach and who helped people apply. -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] You are invited to join the wikiHow source code cleanup project
Sumana: we can revisit that once the project's complete. ;-) Daniel: It's no secret that I'm not a big fan of git (let alone gerrit, which won't even _load_ when using IE9's default rendering mode), but you almost convinced me there. For now, I think we'll stick with SVN because it's what I and Lewis are familiar with; of course, I hope that the project matures so that one day I won't be needed at all. Platonides: I don't deny what you're saying at all...but in all honesty I pretty much lost the passion for contributing code after the -- rather sudden -- transition to git, because it overcomplicated what was once a simple and working workflow. Yes, it's horribly selfish for me to say this, but then again, most MediaWiki developers are familiar with SVN and I want to be able to contribute, too. I find the addition of MediaWiki 1.18.1 in r5 quite confusing What's confusing about it? The official wikiHow codebase (as in the codebase powering wikihow.com) is based on 1.12 and we want to ditch it altogether and find better approaches than over 9000 core hacks, which is why we chose to use the most recent stable edition of MediaWiki, which is 1.18.1, as the basis for the new and improved wH codebase. Currently, diff -ur wikihow-src wikihow-read-only/wikiHow/ contains lots of unrelated changes. How is one expected to make sense of it? Are you trying to diff the official version(s) against ours? If so, that probably explains why you're seeing a lot of unrelated stuff. We're keeping official releases around so that people have an interface for viewing changes between (any) given weekly code releases. The changes we've made to wikiHow extensions, let alone the changes we _plan_ to make, are so big that diffs between the official releases and our versions are basically useless. Greg: Recruiting more people, participating in code review, testing code, and of course, writing code are just some of the ways to help out! I've tried to get some non-technical people interested (with very little success so far...) as there are plenty of tasks for newbies (such as updating indentation to use tabs instead of spaces and whatnot) to do, let alone for experienced programmers, such as yourself. Ping me or Lewis somewhere if you want commit access -- we'd be thrilled to have you onboard! Having more info about the project on MW.org, especially in the context of WikiProject Extensions, would be splendid -- as people are likelier to read such more official (so to say) pages than my user subpages. ;-) Thanks and regards, -- Jack Phoenix MediaWiki developer ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] You are invited to join the wikiHow source code cleanup project
we chose to use the most recent stable edition of MediaWiki, which is 1.18.1 Was. 1.18.2 was released with security fixes. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Development process doesn't work (yes this is another complaint from another community member)
Petr Bena wrote: My point is that if review of 15 lines of code, takes 6+ months, there is very likely a reason for improvement of current process, which may look as working. If I knew it works like it actually works I would never tried to work on what I did. So if there is not going to be improvement in this area, there should either be notification that review of code may take years unless you work for wmf on the page describing the current process, or people from community shouldn't be even suggested to work on that. Regarding the 15 lines of code, are you referring to https://bugzilla.wikimedia.org/show_bug.cgi?id=32819? It looks like a bug was submitted on December 6. Less than a week later, Bawolff came along and reviewed the code (on December 15; see comment 3). And then you never responded to any of the review he left. Did you simply overlook it? It seems rather strange that you'd complain about this situation, though, so perhaps you're talking about a different 15 lines of code? Clarification would be appreciated. :-) There are a lot of problems with Wikimedia's/MediaWiki's code review processes, but in this particular case, it looks like the ball is in your court. (And, for what it's worth, I'm not sure your implementation of the idea makes much sense; see my comment on the bug.) And if you'd like to document the current practices/procedures regarding code review (including the excessive wait time), you're more than welcome to create or update a page on Meta-Wiki or MediaWiki.org (or several pages, go wild!). Tim's suggestion that to document the current situation somehow makes it more real is incredibly silly and can safely be ignored. Giving volunteer developers fair warning is the right thing to do, even if it currently involves ugly truths. MZMcBride ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] Want to teach an online course in MediaWiki administration?
http://codelesson.com/courses/view/mediawiki-administration-and-development They'll help you develop the syllabus and curriculum, and you'd get paid. More info: http://codelesson.com/teach -- Sumana Harihareswara Volunteer Development Coordinator Wikimedia Foundation ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
