January 2016 - Wikitech-l - lists.wikimedia.org

Database dumps
by Byrial Jensen 17 Apr '25

17 Apr '25

Until some weeks ago http://dumps.wikimedia.org/backup-index.html used to show 4 dumps in progress at the same time. That meant that new database dumps normally was available within about 3 weeks for all databases except for enwiki and maybe dewiki where the dump process due to size took longer time. However the 4 dumps processes at one time become 3 some weeks ago. And after massive failures at June 4, only one dump has been in progress at the same time. So at the current speed it will take several months to come thru all dumps. Is it possible to speed up the process again using several dump processes at the same time? Thank you, Byrial

3 2

User-Agent:
by Domas Mituzas 17 Apr '25

17 Apr '25

Hi! from now on specific per-bot/per-software/per-client User-Agent header is mandatory for contacting Wikimedia sites. Domas

19 61

EBNF grammar project status?
by Steve Bennett 01 Apr '25

01 Apr '25

What's the status of the project to create a grammar for Wikitext in EBNF? There are two pages: http://meta.wikimedia.org/wiki/Wikitext_Metasyntax http://www.mediawiki.org/wiki/Markup_spec Nothing seems to have happened since January this year. Also the comments on the latter page seem to indicate a lack of clear goal: is this just a fun project, is it to improve the existing parser, or is it to facilititate a new parser? It's obviously a lot of work, so it needs to be of clear benefit. Brion requested the grammar IIRC (and there's a comment to that effect at http://bugzilla.wikimedia.org/show_bug.cgi?id=7 ), so I'm wondering what became of it. Is there still a goal of replacing the parser? Or is there some alternative plan? Steve

26 217

Missing Section Headings
by Marc Riddell 13 Sep '24

13 Sep '24

Hello, I have been a WP editor since 2006. I hope you can help me. For some reason I no longer have Section Heading titles showing in the Articles. This is true of all Headings including the one that carries the Article subject's name. When there is a Table of Contents, it appears fine and, when I click on a particular Section, it goes to that Section, but all that is there is a straight line separating the Sections. There is also no button to edit a Section. If I edit the page and remove the "== ==" markers from the Section Titles, the Title then shows up, but not as a Section Heading. Also, I don't have any Date separators on my Want List. This started 2 days ago. Any thoughts? Thanks, Marc Riddell [[User:Michael David]]

10 11

How to make commits from mirrored Wikimedia repos show up on your GitHub profile
by Bartosz Dziewoński 28 Jun '24

28 Jun '24

I know it has been annoying a couple of people other than me, so now that I've learned how to make it work I'll share the knowledge here. tl;dr: Star the repositories. No, seriously. (And yes, you need to star each extension repo separately.) (Is there a place on mw.org to put this tidbit on?) ------- Forwarded message ------- From: "Brian Levine" <support(a)github.com> (GitHub Staff) To: matma.rex(a)gmail.com Cc: Subject: Re: Commits in mirrored repositories not showing up on my profile Date: Tue, 09 Jul 2013 06:47:19 +0200 Hi Bartosz In order to link your commits to your GitHub account, you need to have some association with the repository other than authoring the commit. Usually, having push access gives you that connection. In this case, you don't have push permission, so we don't link you to the commit. The easy solution here is for you to star the repository. If you star it - along with the other repositories that are giving you this problem - we'll see that you're connected to the repository and you'll get contribution credit for those commits. Cheers Brian -- Matma Rex

3 3

Deploying the UrlShortener extension to Wikimedia wikis
by Legoktm 12 Nov '16

12 Nov '16

Hi, YuviPanda, prtksxna, and myself (with help from Tim and Aaron) have been working the UrlShortener extension, which is designed to implement the URL shortener RfC[1] (specifically Tim's implementation suggestion). I've filed T108557[2] to deploy the extension to Wikimedia wikis. We'd like to use the "w.wiki" short domain, which the WMF is already in control of. A test wiki has been set up mimicking what Wikimedia's configuration would be like: http://urlshortener.wmflabs.org/, and has an accompanying "short" domain at us.wmflabs.org (e.g. http://us.wmflabs.org/3). Please play with it and report any bugs you might find :) [1] https://www.mediawiki.org/wiki/Requests_for_comment/URL_shortener [2] https://phabricator.wikimedia.org/T108557 Thanks, -- Legoktm

3 5

Introducing WikiToLearn to developers
by Riccardo Iaconelli 29 Apr '16

29 Apr '16

Hi all, I would like to introduce to the Wikimedia community WikiToLearn, a FOSS project of which I am a participant and which is lately getting a lot of contributions and momentum. It is a KDE project sponsored (among the others) by Wikimedia Italy and recently joined by institutions such as HEP Software Foundation (CERN, Fermilab, Princeton...) or Universities such as University of Pisa and Milano- Bicocca. These institutions are already populating the website with content. We aim to provide a platform where learners and teachers can complete, refine and re-assemble lecture notes in order to create free, collaborative and accessible textbooks, tailored precisely to their needs. Although the project is quite young (only a few months old), it is already growing in allure at an unexpected rate. Thanks to this we are now counting on nearly 40 developers, and growing (including content developers). We are different from Wikipedia and other WMF projects in several ways, and in a sense, complementary. Our focus is on creating complete textbooks (and not encyclopedic articles), drawing from a professor’s or a student’s own notes, either existing or that have to be written down. We also have a strong focus on offline use: all the content of WikiToLearn should be easily printable by any student for offline use and serious studying. Besides a good team for content development, we can count on a small but motivated team of developers, and we would like to improve communication with upstream (a.k.a. you ;-) ), because we found ourselves developing a few features which could probably be made available to the general public, with some generalization and polishing. ;-) Is this a right place to start such a discussion? We would like to help as much as we can, but we might need some mentoring in how to best approach MediaWiki development, as many of us are relatively new to OSS/Web development. Bye, -Riccardo

8 16

Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Gabriel Wicke 18 Apr '16

18 Apr '16

We have decided to officially retire the rest.wikimedia.org domain in favor of /api/rest_v1/ at each individual project domain. For example, https://rest.wikimedia.org/en.wikipedia.org/v1/?doc becomes https://en.wikipedia.org/api/rest_v1/?doc Most clients already use the new path, and benefit from better performance from geo-distributed caching, no additional DNS lookups, and sharing of TLS / HTTP2 connections. We intend to shut down the rest.wikimedia.org entry point around March, so please adjust your clients to use /api/rest_v1/ soon. Thank you for your cooperation, Gabriel -- Gabriel Wicke Principal Engineer, Wikimedia Foundation

4 7

RFC: Defining a policy for REST API result format versioning / negotiation
by Gabriel Wicke 25 Feb '16

25 Feb '16

Hi, we are considering a policy for REST API end point result format versioning and negotiation. The background and considerations are spelled out in a task and mw.org page: https://phabricator.wikimedia.org/T124365 https://www.mediawiki.org/wiki/Talk:API_versioning Based on the discussion so far, have come up with the following candidate solution: 1) Clearly advise clients to explicitly request the expected mime type with an Accept header. Support older mime types (with on-the-fly transformations) until usage has fallen below a very low percentage, with an explicit sunset announcement. 2) Always return the latest content type if no explicit Accept header was specified. We are interested in hearing your thoughts on this. Once we have reached rough consensus on the way forward, we intend to apply the newly minted policy to an evolution of the Parsoid HTML format, which will move the data-mw attribute to a separate metadata blob. Gabriel Wicke

1 3

Google Code-in 2015 is over. Congratulations everybody!
by Andre Klapper 03 Feb '16

03 Feb '16

Google Code-in 2015 has come to an end. Thanks to our students for resolving 461 Wikimedia tasks. Thanks to our 35 mentors for being available, also on weekends & holidays. Thanks to everybody on IRC for your friendliness, patience, and help provided to new contributors. Some more achievements, apart from those already mentioned in https://lists.wikimedia.org/pipermail/wikitech-l/2015-December/084421.html : * The CommonsMetadata extension parses vcards in the src field * The MediaWiki core API exposes "actual watchers" as in "action=info" * MediaWiki image thumbnails are interlaced whenever possible * Kiwix is installable/moveable to the SD card, automatically opens the virtual keyboard for "find in page", (re)starts with the last open article * imageinfo queries in MultimediaViewer are cached * Twinkle's set of article maintenance tags was audited and its XFD module has preview functionality * The RandomRootPage extension got merged into MediaWiki core * One can remove items from Gather collections * A new MediaWiki maintenance script imports content from text files * Pywikibot has action=mergehistory support implemented * Huggle makes a tone when someone writes something * Many i18n issues fixed and strings improved * Namespace aliases added to MediaWiki's export dumps * The Translate extension is compatible with PHP 7 The Grand Prize winners & finalists will be announced on February 8th. Again congratulations everybody, and thanks for the hard work. See you around on IRC, mailing lists, Gerrit, and Phabricator! Cheers, andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/

6 6

Developer Relations Weekly Summary
by Quim Gil 02 Feb '16

02 Feb '16

The Winter break took longer than expected. Busy times! You can help develop the next summary. *Developer Relations focus* * Wrapping up Google Code-in 2015 * Wikimedia Hackathon 2016 travel sponsorship requests * Wikimedia Developer Summit 2016/Lessons Learned * Developer Relations strategy and annual plan There is a lot more at https://www.mediawiki.org/wiki/Developer_Relations/Weekly_summary#2016-01-26 -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

5 6

New [[Main Page]] for Wikitech
by Bryan Davis 02 Feb '16

02 Feb '16

I've been working on a little redesign project for the Main Page on wikitech [0] and three key sub pages it points to since 2016-01-01 in my User space. Tonight I decided that although it is far from perfect it is better enough. I hope that some of you like it better than the old page and that none of you hate it with a fiery passion that compels you to revert it rather than helping me make it better. [0]: https://wikitech.wikimedia.org/wiki/Main_Page Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

10 10

Parsoid entrypoint http://parsoid-lb.eqiad.wikimedia.org being decommissioned
by Subramanya Sastry 02 Feb '16

02 Feb '16

Hello everyone, The public Parsoid endpoint http://parsoid-lb.eqiad.wikimedia.org is being decommissioned [1] once we migrate over all straggler references to that endpoint [1] possibly as soon as 3 weeks from now. As far as we know, there are very few requests to that endpoint right now, but if you have been using that endpoint, please switch over to using the RESTbase service instead. You can access Parsoid HTML for the wikimedia wikis via their REST API endpoint. For example, https://en.wikipedia.org/api/rest_v1/?doc is the REST API url for English Wikipedia content. Thanks, Subbu. 1. https://phabricator.wikimedia.org/T110474

3 4

VisualEditor deployment to 1000+ users: who wants the feedback?
by Daniel Barrett 01 Feb '16

01 Feb '16

Within the next few weeks, I'll be deploying VisualEditor for 1000+ authors here at Cimpress/Vistaprint, in a wiki with 225,000 articles. I plan to collect feedback from our users on what works and what doesn't. What would be the best way to communicate this feedback to Wikimedia? Here are some early, informal comments from our pilot group of 20 users: "I am in love!" "TemplateData integration is awesome." "How do I insert <code> tags?" (He didn't notice the "More" link in the font menu.) "How do I set the width of a table column?" "How do I copy and paste table rows?" "Editing links is fiddly" (https://phabricator.wikimedia.org/T124305) "I didn't see the editing tools at first because they're white on a white background." "Can we save the page without having a pop-up?" Thanks, DanB

3 3

Announcing mediawiki-containers, a Docker-based MediaWiki installer
by Gabriel Wicke 30 Jan '16

30 Jan '16

I am writing to announce mediawiki-containers [1], a simple installer for MediaWiki with VisualEditor, Parsoid, RESTBase and other services, using Linux containers. The main goal of this project is to make it really easy to set up and maintain a fully featured MediaWiki system on a wide range of platforms. The project is in an early stage, but already supports full installation on Ubuntu, Debian and other systemd-based distributions, as well as starting containers on OS X via the Docker toolbox [6]. These are the basic steps involved in setting up your own MediaWiki instance with VisualEditor: 1) Get a Linux VM in labs or from a hosting provider, and select Debian (Jessie or newer) or Ubuntu 15.04+ as the distribution. Commercial VMs with reasonable specifications cost about $5 per month [2]. 2) Log into your VM, and run this command [7]: curl https://raw.githubusercontent.com/wikimedia/mediawiki-containers/master/med… | sudo bash 3) Answer the questions in the installer. Here is a screencast of an installer run, illustrating steps 2) and 3): https://people.wikimedia.org/~gwicke/mediawiki-containers-install.ogv Under the hood, mediawiki-containers uses several Docker containers: - wikimedia/mediawiki [3] with MediaWiki 1.27-wmf9 and VisualEditor. - wikimedia/mediawiki-node-services [4] with Parsoid and RESTBase running in a single process to minimize memory use. - MariaDB as the database backend [5]. Data and configurations are stored on the host system in /srv/mediawiki-containers/data, which means that upgrading is as simple as fetching the latest container images by re-running the installer. Optionally, the installer can set up automated nightly updates, which helps to keep your wiki installation up to date. The project is brand new, so there is a fair chance that you will encounter bugs. Please report issues at https://phabricator.wikimedia.org/maniphest/task/create/?projects=mediawiki… . Here are some ideas we have for the next steps: - Forward `/api/rest_v1/` to RESTBase & configure RESTBase updates. Enable Wikitext / HTML switching in VE. - Improve security: - Run each container under a different, unprivileged user. - Secure the install / update process with signatures. - Add popular extensions, and streamline the support for custom extensions. - Add services like mathoid, graphoid. - Use the HHVM PHP runtime instead of Zend, possibly using ideas from https://github.com/kasperisager/php-dockerized. - Support developer use cases: - Optionally mount code volumes from the host system. - Improve configuration customization support. - Support for more distributions. Let us know what you think & what you would like to see next at https://phabricator.wikimedia.org/T92826. Happy holidays, Gabriel Wicke and the Services team [1]: https://github.com/wikimedia/mediawiki-containers [2]: http://serverbear.com/compare?Sort=BearScore&Order=desc&Server+Type=VPS&Mon… [3]: https://github.com/wikimedia/mediawiki-docker and https://hub.docker.com/r/wikimedia/mediawiki [4]: https://github.com/wikimedia/mediawiki-node-services and https://hub.docker.com/r/wikimedia/mediawiki-node-services/ [5]: https://hub.docker.com/_/mariadb/ [6]: https://docs.docker.com/mac/step_one/ [7]: We agree that `curl | bash` has its risks, but it is hard to beat for simplicity. The Chef project has a good discussion of pros, cons & alternatives at https://www.chef.io/blog/2015/07/16/5-ways-to-deal-with-the-install-sh-curl… .

5 6

Unable to log into phabricator
by Devang Gaur 29 Jan '16

29 Jan '16

I registered into phabricator with my Mediawiki account initially . Now when I opt for "login or register via mediawiki" . It takes me to a new account registration page whereas I have an existing phabricator account (@dg711) already linked with that same mediawiki account . Is that a bug or what ? Please help me resolve this . Thanks , Devang Gaur

2 1

*unclear-"now"-timestamp* (was Re: Bot operators: Please check your configuration)
by Brad Jorsch (Anomie) 29 Jan '16

29 Jan '16

On Fri, Jan 29, 2016 at 1:41 PM, Bináris <wikiposta(a)gmail.com> wrote: > 2016-01-29 18:56 GMT+01:00 Brad Jorsch (Anomie) <bjorsch(a)wikimedia.org>: > > > by going to > > https://www.mediawiki.org/wiki/Special:ApiFeatureUsage, entering your > > agent > > (or any useful prefix of it), and looking for "https-expected". > > > > What does *unclear-"now"-timestamp* mean here? > For various API timestamp-typed parameters, you can pass unusual values such as the empty string or "0" and it will be interpreted as meaning "now", which doesn't make very much sense except for the fact that it has always done that. If you really mean "now", you should pass that as the value instead. action=edit even has to hack around this to avoid spurious edit conflicts if you do it for the 'basetimestamp' parameter. Ideally we'd make empty string and '0' be rejected as invalid timestamps, but first people have to stop passing them in. -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

2 1

Bot operators: Please check your configuration
by Brad Jorsch (Anomie) 29 Jan '16

29 Jan '16

It currently still works to POST to the API via http instead of https. But we'd really like to stop allowing that, see https://phabricator.wikimedia.org/T105794. Thus, the API will now return a warning if https was expected but not used. If you run a bot, please check your configuration to make sure that you're using https rather than http. If you're using a distinctive user agent for your bot (which you all are, right?[1]), you can now check whether your bot is using http by going to https://www.mediawiki.org/wiki/Special:ApiFeatureUsage, entering your agent (or any useful prefix of it), and looking for "https-expected". If for some reason your bot cannot support https, you really should upgrade it to make that happen. [1]: https://meta.wikimedia.org/wiki/User-Agent_policy -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

2 1

[FINAL COMMENT PERIOD] [RFC]: Defining a policy for REST API result format versioning / negotiation
by Gabriel Wicke 29 Jan '16

29 Jan '16

This is now entering its final comment period, so please weigh in at https://phabricator.wikimedia.org/T124365. Based on your input, the Parsing, Editing & Services teams will make a decision on this next Wednesday, Feb 2nd. Thanks, Gabriel On Thu, Jan 21, 2016 at 4:29 PM, Gabriel Wicke <gwicke(a)wikimedia.org> wrote: > Hi, > > we are considering a policy for REST API end point result format > versioning and negotiation. The background and considerations are > spelled out in a task and mw.org page: > > https://phabricator.wikimedia.org/T124365 > https://www.mediawiki.org/wiki/Talk:API_versioning > > Based on the discussion so far, have come up with the following > candidate solution: > > 1) Clearly advise clients to explicitly request the expected mime type > with an Accept header. Support older mime types (with on-the-fly > transformations) until usage has fallen below a very low percentage, > with an explicit sunset announcement. > > 2) Always return the latest content type if no explicit Accept header > was specified. > > We are interested in hearing your thoughts on this. > > Once we have reached rough consensus on the way forward, we intend to > apply the newly minted policy to an evolution of the Parsoid HTML > format, which will move the data-mw attribute to a separate metadata > blob. > > Gabriel Wicke -- Gabriel Wicke Principal Engineer, Wikimedia Foundation

1 0

Re: [Wikitech-l] [Mediawiki-api] [Engineering] Deprecating rest.wikimedia.org in favor of /api/rest_v1/
by Gabriel Wicke 29 Jan '16

29 Jan '16

Luigi, On Thu, Jan 28, 2016 at 2:09 AM, XDiscovery Team <info(a)xdiscovery.com> wrote: > I tried /rest_v1/ endpoint and it is terribly fast. that is great to hear. A major goal is indeed to provide high volume and low latency access to our content. > @Strainu / @Gabriel , what does 'graph' extension do ? If you refer to https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_graph_png…, this is an end point exposing rendered graph images for https://www.mediawiki.org/wiki/Extension:Graph (as linked in the end point documentation). > I have few questions for using proxy cache: > 1# Is it possible to query a page by page_ID and include redirect? We don't currently provide access by page ID. Could you describe your use case a bit to help us understand how access by page id would help you? > /page/title/{title} > allow to get metadata by page, including the pageID , but I would like to > have final page redirect (e.g. dna return 7956 and I would like to fetch > 7955 of redirected 'DNA' ) We are looking into improving our support for redirects: https://phabricator.wikimedia.org/T118548. Your input on this topic would be much appreciated. > /page/html/{title} get the article but page_ID / curid is missing in source > I would like to get the two combined. This information is actually included in the response, both in the `ETag` header and in the <head> of the HTML itself. I have updated the documentation to spell this out more clearly in [1]. The relevant addition is this: The response provides an `ETag` header indicating the revision and render timeuuid separated by a slash (ex: `ETag: 701384379/154d7bca-c264-11e5-8c2f-1b51b33b59fc`). This ETag can be passed to the HTML save end point (as `base_etag` POST parameter), and can also be used to retrieve the exact corresponding data-parsoid metadata, by requesting the specific `revision` and `tid` indicated by the `ETag`. > 2# The rest are experimental: > what could happen if a query fail? > Does it raise an error, return 404 page or what else? The stability markers are primarily about request and response formats, and not about technical availability. Experimental end points can change at any time, which can result in errors (if the request interface changed), or return a different response format. We are currently discussing the use of `Accept` headers for response format versioning at https://www.mediawiki.org/wiki/Talk:API_versioning. This will allow us to more aggressively stabilize end points by giving us the option of tweaking response formats without breaking existing clients. > I am thinking if possible to use api.wikipedia as fallback, and use proxy > cache as primary source any ajax example for doing that to handle possible > failures? Yes, this is certainly possible. However, you can rely on end points currently marked as "unstable" in the REST API. Basically all of them are used by a lot of production clients at this point, and are very reliable. Once we introduce general `Accept` support, basically all of the unstable end points will likely become officially "stable", and several `experimental` end points will graduate to `unstable`. > 3# Does /rest/ endpoint exist also for other languages? Yes, it is available for all 800+ public Wikimedia projects at /api/rest_v1/. [1]: https://github.com/wikimedia/restbase/pull/488/files#diff-2b6b60416eaafdf0a… -- Gabriel Wicke Principal Engineer, Wikimedia Foundation

1 0

MediaWiki Language Extension Bundle 2016.01 release
by Kartik Mistry 29 Jan '16

29 Jan '16

Hello all, I would like to announce the release of MediaWiki Language Extension Bundle 2016.01. This bundle is compatible with MediaWiki 1.25.x and 1.26.x. Next MLEB is expected to be released in 3 months. If there are major changes or important bug fixes, we will do intermediate release. Please give us your feedback at [[Talk:MLEB|https://www.mediawiki.org/wiki/Talk:MLEB]]. * Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2016.01.tar… * sha256sum: 7a46bb96f852aa42f728c68e4e21558878c8cba703ce9f8f6c2316af7bbe03e3 Quick links: * Installation instructions are at: https://www.mediawiki.org/wiki/MLEB * Announcements of new releases will be posted to a mailing list: https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n * Report bugs to: https://phabricator.wikimedia.org/ * Talk with us at: #mediawiki-i18n @ Freenode Release notes for each extension are below. -- Kartik Mistry == Babel, CleanChanges and LocalisationUpdate == * Localisation updates only. == CLDR == * Hebrew names for Cebuano and Norwegian are fixed. * cldr converted to extension registration. Please update your LocalSettings.php! == Translate == * Old custom tokens were deprecated in favor of using regular "csrf" (previously known as "edit") token. If you are using Translate WebAPIs you might need to migrate. * Special:Translations no longer shows PHP notices for pages with invalid language codes * Special:Translate now longer shows deprecation warnings about access keys in the JavaScript console. * Translate is now syntactically compatible with PHP7. * Message group selector on Special:SearchTranslations no longer has glitchy behavior after selecting a group. * MessageIndex code was optimized. It now ignored messages not in $wgTranslateMessageNamespaces. By default this should be fine, but if you have translations in custom namespaces, check that they are included. * Pages with <languages /> now load faster with cold caches. * MachineTranslationAid no longer throws uncaught exceptions with default configuration that broke other translation aids. == UniversalLanguageSelector == * ULS now uses extension registration and thus requires MediaWiki 1.25 or later * Input methods should now work inside Visual Editor. * Fonts: ** OpenDyslexic font updated to latest upstream. ** Akkadian font should work again. * Input Methods: * New input methods: ** Rodali (Assamese) layout. ** OdiScript (Oriya) layout. ** Yoruba layout. * Updated input methods: ** Updated Oriya Lekhani layout. ** Digit fixes in Southern Kurdish layout. ** Minor fixes in Sinhala layout. -- Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_ {kartikm, 0x1f1f}.wordpress.com

1 0

Scope of ArchCom
by Rob Lanphier 29 Jan '16

29 Jan '16

Hi everyone, Those with a keen eye will notice that I filed T124255 <https://phabricator.wikimedia.org/T124255>, which calls for renaming #MediaWIki-RfCs in Phab to "#ArchCom-RfC". This would be a boring Phab administrivia email if it was simply that. The reason I want the rename: ArchCom is the mechanism we hope to ensure we build and deploy increasingly excellent software on the Wikimedia production cluster in a consensus-oriented manner. MediaWiki is at the center of this, but ArchCom's responsibility doesn't end with MediaWiki. T124255 <https://phabricator.wikimedia.org/T124255> is an odd place to have a more sweeping conversation about the scope of ArchCom, but it'll do for now. Feel free to comment there or on this mailing list. Thanks Rob

10 26

Close test2wiki?
by Ori Livneh 29 Jan '16

29 Jan '16

The setup of test2.wikipedia.org is no longer meaningfully different from test.wikipedia.org. Is there a good reason for keeping test2?

11 14

(no subject)
by イノウエナオキ 29 Jan '16

29 Jan '16

1 0

Changes in the RFC decision making process
by Gabriel Wicke 29 Jan '16

29 Jan '16

In the last weeks we have been exploring ways to improve our technical consensus building and decision making process. I wrote a short RFC [1] describing some issues, and proposed to adopt ideas from the Rust community [2] to address them. The discussion on the task and in an IRC meeting showed broad support for the proposals. In yesterday's architecture committee meeting, we decided to adopt much of the Rust RFC decision making process [3] on a trial basis. Concretely, this means: - We will nominate a member of the architecture committee as a shepherd, guiding an active RFC through the process. Among other things, the shepherd is responsible for informing all relevant stakeholders of the ongoing discussion on the task. The shepherd might also lead an IRC discussion on the RFC, which will be summarized on the task. - Once the discussion on a task plateaus or stalls, the shepherd (in coordination with the RFC author(s)) announces and widely publicizes a "Final Comment Period", which is one week. - At the end of the "Final Comment Period", the architecture committee decides based on the points made in the RFC discussion, and justifies its decision based on the overall project principles and priorities. If any new facts or aspects are surfaced in this discussion, a new Final Comment Period needs to be started before making a decision. For now, we are holding off on the second part of the RFC, the introduction of working groups. There is agreement that we need to broaden the involvement and scale the process, but the details of how are still under discussion. Gabriel [1]: https://www.mediawiki.org/wiki/Requests_for_comment/Governance [2]: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md [3]: https://github.com/rust-lang/rfcs/blob/master/text/1068-rust-governance.md#…

2 1

releases.wikimedia.org server has moved
by Daniel Zahn 29 Jan '16

29 Jan '16

TLDR: The backend server used for releases.wikimedia.org has moved. use bromine.eqiad.wmnet instead of caesium.eqiad.wmnet Do i care? You do if you are a "releaser" in one of the admin groups who upload files to releases.wm.org. Hi, the backend of releases.wm.org has moved away from caesium.eqiad.wmnet over to bromine.eqiad.wmnet. The reason was to get rid of yet another outdated Ubuntu system and replace it with a Debian jessie system. All the releases files in /srv/org and your /home directories have been copied over, everything should be like before, just use the new server name please. The task for that was https://phabricator.wikimedia.org/T124261 While on it i made the directory index page look a bit nicer and sort files differently so that new release versions are on top. The details for that were in https://phabricator.wikimedia.org/T125164 Let me know if you see any issues, Best, Daniel -- Daniel Zahn <dzahn(a)wikimedia.org> Operations Engineer

1 0

PHP-side breaking changes to login and account creation tokens in 1.27.0-wmf.12
by Brad Jorsch (Anomie) 28 Jan '16

28 Jan '16

With the merge of Gerrit change 264309,[1] to be deployed with 1.27.0-wmf.12, note the following changes to the PHP interface around login and account creation tokens: - LoginForm::setLoginToken() and LoginForm::setCreateaccountToken() are deprecated and no longer do anything. The token is automatically created when fetched. - LoginForm::getLoginToken() and LoginForm::getCreateaccountToken() now return a MediaWiki\Session\Token object rather than a string. This object implements __toString(), so automatic casting to a string is supported and will likely mask this change for many uses. - The token strings themselves are now similar to edit tokens: they're longer, end in "+\", and include an embedded timestamp for expiration. - Due to the embedded timestamp, tokens must now be compared using the ->match() method on the Token object. String equality comparison will no longer work. - It is no longer possible to determine if the token was not already generated for the session by looking for an empty response from LoginForm::getLoginToken() and LoginForm::getCreateaccountToken(). If this is necssary (it shouldn't be), use the ->wasNew() method on the Token object. If your PHP code makes use of login or account creation tokens for some reason, please check to see if your code needs updating for these changes. For the record, a new method User::getEditTokenObject() has been added to fetch edit tokens as MediaWiki\Session\Token objects as well, but User::getEditToken() and User::matchEditToken() have not been changed or deprecated at this time. Note that API clients and other non-PHP users of these tokens are unlikely to be broken by this change. See https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2016-January/0… for details on changes to the API related to this change. [1]: https://gerrit.wikimedia.org/r/#/c/264309/ -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

1 0

INFO: Reading web release process update
by Jon Robson 28 Jan '16

28 Jan '16

As you may be aware, the reading team was unhappy with its current release process and shared its rationale <https://www.mediawiki.org/wiki/Reading/Web/Release_process/experiment#Ratio…> for a different release process. This resulted in an experiment on Gather, QuickSurveys, Cards and RelatedArticles where the team developed on the dev branch by default. When the team was happy that the dev branch was stable, it would tag a release and merge to master. The idea was to minimise the deployment of incomplete features and SWAT deploys. This process saw mixed success. Although we felt more comfortable and in control of the code we shipped due to more time for designers and product owners to input into our process it was clear there was an impedance mismatch with the expectations in the MediaWiki developer community and for a small team of 5, we were unable to keep up with the periodic releases of extensions we were not actively maintaining. As a result we are abandoning this experiment and going back to the Mediawiki Way™ of releasing and merging directly to master. When we work on new features, we will be more mindful of +2, marking the initial commit of a chain of commits that requires sign off from a designer and product owner with a -2. We think this will be a better approach for everyone. Our only remaining question is when and if to do release number bumps in future. We'll be back with an answer about that shortly... ideas welcomed. Thank you for your patience while we experimented and let us know if there is anything else of interest to you in this experiment we have run. Notes from post-mortem are on wiki <https://www.mediawiki.org/wiki/Reading/Web/Notes/2016-Q3_Branching_strategy…>

4 5

Fwd: Your speaking schedule at FOSDEM
by Matthew Flaschen 28 Jan '16

28 Jan '16

I will be presenting at FOSDEM on the LiquidThreads to Flow conversion, at 2016-01-30, 16:00 Belgium time: http://www.timeanddate.com/worldclock/fixedtime.html?msg=FOSDEM+LiquidThrea… It will be live-streamed at https://live.fosdem.org/watch.php?room=H.2215%20(Ferrer) (from what I can tell in advance). Thanks, Matt Flaschen -------- Forwarded Message -------- Subject: Your speaking schedule at FOSDEM Date: Fri, 15 Jan 2016 22:13:33 +0100 (CET) From: FOSDEM Programme Team <speakers(a)fosdem.org> Reply-To: speakers(a)fosdem.org Organization: FOSDEM - https://fosdem.org/ To: Matt Flaschen <mflaschen(a)wikimedia.org> CC: speakers(a)fosdem.org Dear speaker, Thank you for agreeing to speak at FOSDEM! Our programme is now complete: https://fosdem.org/2016/schedule/ This is your schedule: .----------------------------------------------------------------------------. | day | time | room | title | +------------+----------+-----------------+----------------------------------+ | 2016-01-30 | 16:00:00 | H.2215 (Ferrer) | Converting LiquidThreads to Flow | '------------+----------+-----------------+----------------------------------' .---------------------------------------------. | links | +---------------------------------------------+ | https://fosdem.org/2016/schedule/event/flow | '---------------------------------------------' Please check these links carefully. If you already created an account at: https://fosdem.org/submit you can login and update the information if need be. In particular, please upload a photograph if you have not already done so and enter or update your biography. Changes take a few minutes to reach the website - the time it was last updated appears at the bottom of this page: https://fosdem.org/2016/schedule/events/ If you find yourself unable to attend, please let your room's organiser know this as soon as possible. FOSDEM intends to record and stream the entire conference live - that's over 300 hours of content! The recordings will be published under the same licence as all FOSDEM content (CC-BY). You are agreeing to this by taking part in the event. Any slide decks you present should be uploaded by about half-an-hour before the start of your talk so that people watching the live stream can follow them locally if their video resolution leaves slide content indistinct. (Our system does not hold back publication, so if you don't want people to see them too far in advance, don't upload them yet.) Projectors work at 1024x768 but expect slides (and any demonstrations) to be scaled down to 720x576 for the video, so try to make them readable at this lower resolution if you can. Please don't forget to bring a VGA adaptor if you hope to present from a laptop that only has a different type of output connector! We also recommend bringing a spare copy of any slides on a USB stick. As usual, we aim to provide free high-quality wireless network connectivity throughout the event. Best wishes, The FOSDEM Programme Team

5 5

Changes to token system?
by Magog The Ogre 28 Jan '16

28 Jan '16

Good evening. For the past week, my bot has intermittently been seeing this error when it tries to edit or upload: API Error: Array ( [code] => badtoken [info] => Invalid token [*] => See http://commons.wikimedia.org/w/api.php for API usage ) It is unpredictable; it will occasionally fail for one thread, and then work for a thread an hour later. Deleting the cookies has on occasion fixed the issue for a few days. Is there anything that can be done to fix this? Magog

2 1

Changes in Quarterly Planning
by Trevor Parscal 28 Jan '16

28 Jan '16

As we approach another quarterly planning cycle, I'd like to bring my proposal for how we can improve our quarterly planning and review process. https://www.mediawiki.org/wiki/Wikimedia_Engineering/Goals_Proposal Do people support implementing these changes for the Q4 planning cycle? If you have input, could you please participate in the discussion on the talk page by Feb 5 (next Friday)? - Trevor

1 0

2015-01-27 Scrum of Scrums notes
by Grace Gellerman 28 Jan '16

28 Jan '16

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-01-27 = 2015-01-27 = == Product == === Reading === ==== Android ==== * Hotfix for login issues, v2.1.138, in production. * v2.1.139 beta published for changes in Wiktionary API and removal of "m." requests. * Android saved synchronized articles implementation in progress (using API's userjs feature). * Even better memory profile coming soon. ==== iOS ==== * Evaluating pageviews API usage for "Trending/Top Articles" feature in 5.0 * Need to start evaluating impact of API usage in 5.0 (particularly extensive use of extracts prop w/ search * Login/Account creation integration meeting (AuthManager API changes in MW core) ==== Web ==== * User page enhancements coming to mobile web (removal of Special:UserProfile) * PageImages API updates being examined (Fair use of images) * Language overlay changes * QuickSurveys enhancements ==== Reading Infrastructure ==== * Block: Security, are we good on https://gerrit.wikimedia.org/r/#/c/264309/ ? === Community Tech === * Wrapping up work on Gadgets 2.0 https://www.mediawiki.org/wiki/Gadgets_2.0 ** Could probably use a security review from Chris once it's done - https://phabricator.wikimedia.org/T124943 * Collaborating with volunteers on Dead link rescue (bot) and Pagestats tool (still in planning stage) * Working on getting PageAssessments extension ready for testing as a prototype https://www.mediawiki.org/wiki/Extension:PageAssessments ** Already had security review and DBA review === Editing === ==== Language ==== * Got parallel corpora tables created * Working on AbuseFilter ** Many articles not published due to AbuseFilter warnings/errors ** We are improving UI to better surface these warnings and what they mean ** Also trying to figure how to get more exact locations of the issues out of AbuseFilter ** If any AbuseFilter experts around, I might have questions * cxserver itself is ready for Node 4.2, but the Apertium packages are still WIP (T106385), no estimate of when they'll be done. ** how urgent is this? *** Answer: Don't have to do both at the same time. ==== Collaboration ==== * Moriel is working on having human-readable names for all Wikimedia wikis available programatically in all languages. Initially, this will be used for cross-wiki notifications, but it can potentially be used in many other areas. https://phabricator.wikimedia.org/T121936 * Jaime approved the Flow dry run patch for the External Store migration. It now needs to be reviewed by our team and then tested on Beta Cluster. * I'll (Matt Flaschen) be at FOSDEM, and lead the MediaWiki stand presence. I'm also presenting on the LiquidThreads to Flow conversion. See wikitech-l for more information. ==== VisualEditor ==== * Blockers: https://phabricator.wikimedia.org/T58337 is blocked on review from Krinkle for https://gerrit.wikimedia.org/r/#/c/259771/ and https://gerrit.wikimedia.org/r/#/c/265878/ and so https://gerrit.wikimedia.org/r/#/c/265879/ * Blockees: Only known blockee is Design Research, waiting on above patches to land on Beta Cluster. * Production deployment on shared feedback page and VE default-on for another few wikis delayed from Monday due to the train; not yet scheduled. ==== Multimedia ==== * No known blockers or blockees. === Discovery === * found temp solution for load spikes, moved more_like traffic to another cluster ** working on improving "more like" performance, may change results, will a/b test https://phabricator.wikimedia.org/T124258 * working on yearly plan/budget * started loading analytics data into ElasticSearch, full run takes ~12 hrs, may need to look for performance improvement * Working on integrating completion search into SearchEngine API * Blazegraph 2.0 is out, Wikidata Query service upgrading soon * Blocked: ** need help from Ops for access analytics->codfw for elastic20{01..24}.codfw.wmnet, er, I 'd rather not have ACLs on the routers referring to non intra DC things. Why is that needed ? Task ? Same reason we needed it before, we need to get data from analytics to ES machines and this is the only way we found we can do it right now. https://phabricator.wikimedia.org/T120281 eqiad access works, but codfw one does not. == Advancement == === Fundraising Tech === * Creating CI job to test DonationInterface on mw branch deployed on payments cluster ** thanks Antoine! * Working on new fraud filters * More CiviCRM fixes and improvements * Making code changes to expand Latin America fundraising from just Brazil to six other countries == Technology == === Technical Operations === * Blocked: Research on ORES * Blocked by: none * Updates: ** Had an outage yesterday. all *.wikimedia.org was redirected to wikimedia.org ** mira is now the deployment server, NOT tin ** Got an OTRS upgrade on Feb 3 ** HHVM 3.11 packages are ready to go: http://anonscm.debian.org/cgit/pkg-hhvm/hhvm.git/log/ ** mobile traffic varnish clusters get folded into the text clusters. ** Need help with: *** https://phabricator.wikimedia.org/T124649 module dependencies handling, mediawiki core ? *** https://phabricator.wikimedia.org/T124651 RELENG. phabricator is misbehaving when a git repo is missing *** https://phabricator.wikimedia.org/T124418 Investigate massive increase in htmlCacheUpdate jobs in Dec/Jan === Services === * EventBus :* extension emitting events live in prod * Move to Jessie and Node 4.2 :* Graphoid and Citoid - done :* CXServer - please check! ::* Apertium pkgs? :* RELENG. CI support for Node 4.2 ::* https://phabricator.wikimedia.org/T119143 :* RELENG. Migrate to Node 4.2 in BetaCluster ::* task to be created :P === Security === * More patches on the cluster; deploying updates for LanguageConverter this week * Keystone plugin development underway === Research === * Blocked: none * Blocked by: ** ORES moving to new meso-level (Labs < Meso < Prod) support -- blocked on Ops time to set up machines *** See https://phabricator.wikimedia.org/T106867 -- working with Yuvi to flesh out sub-tasks -- need to know who to CC === Release Engineering === * *Blocking*: YES (as of today ;-) ) * *Blocked*: none * *Updates:* ** scap 3.0 will be tagged and packaged soon *** Finishing work on puppet provider ** Shifting the MW train window starting next week to 2000 UTC (noon PST) ** Re-deploying 1.27.0-wmf.11 this week after last week's rollback due to SessionManager issues ** Discussing ways to improve reliability and recoverability of train deploys (tools and process) ** Annual planning all the things

1 0

Saving MediaWiki:common.js
by Legault, Phillip [ITSUS] 27 Jan '16

27 Jan '16

I ran into an issue trying to save MediaWiki:Common.js I get this page not available (index.php?title=MediaWiki:Common.js&action=submit) MediaWiki:Common.css save fine Any Idea what I'm doing wrong? Thank you!

4 6

Re: [Wikitech-l] [Engineering] Proposal regarding the future of X-Wikimedia-Debug and testwiki
by Alex Monk 27 Jan '16

27 Jan '16

Trying again from a different address On 26 January 2016 at 01:04, Alex Monk <amonk(a)wikimedia.org> wrote: > Forwarding to wikitech-l since this is not really specific to staff, but > all shell users. > > On 25 January 2016 at 20:39, Ori Livneh <ori(a)wikimedia.org> wrote: > >> The X-Wikimedia-Debug header, for those of you who don't know, is an HTTP >> request header that you can set on your requests (either manually, or by >> using the Chrome[1] or Firefox[2] extensions). Requests bearing this header >> are always treated as cache misses by Varnish, and they are always routed >> to the same backend, mw1017. >> >> In addition to handling X-Wikimedia-Debug requests, mw1017 is also >> configured as the sole application server backend for all requests to >> test.wikimedia.org. This was set up before X-Wikimedia-Debug existed, >> and as a debugging tool it is (IMO) inferior to it, because >> X-Wikimedia-Debug allows you to test code changes against any production >> wiki. >> >> What I've seen happen before is developers (like me -- I've done this >> before) live-hack code on mw1017 to debug some issue that is only showing >> up in production. This can cause testwiki to break, which annoys developers >> and editors who use testwiki for testing things like Lua modules or editing >> functionality on mobile apps. >> >> To reduce contention for mw1017, I propose that we do the following: >> >> 1) Keep testwiki, but don't special-case it in Varnish >> (in other words, have testwiki requests go to the standard app server >> pool) >> >> 2) Reserve mw1017 exclusively for X-Wikimedia-Debug requests >> >> 3) Add a service alias (appservers-debug.svc.eqiad.wmnet) for mw1017 and >> update the varnish backend config to use that, rather than hard-code mw1017 >> in VCL. >> >> Thoughts? >> >> [1]: >> https://chrome.google.com/webstore/detail/wikimediadebug/binmakecefompkjggi… >> [2]: >> https://addons.mozilla.org/en-US/firefox/addon/wikimedia-debug-header/ >> >> >> _______________________________________________ >> Engineering mailing list >> Engineering(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/engineering >> >> > -- > Alex Monk > VisualEditor/Editing team > https://wikimediafoundation.org/wiki/User:Krenair_(WMF) >

3 3

Phabricator project naming conventions for skins
by Bartosz Dziewoński 26 Jan '16

26 Jan '16

The other day, someone came and renamed the Phabricator projects for various skins from MediaWiki-skins-Foo to just Foo. A few days later, someone else came and renamed them all back. Since I'm a member of a few of these projects, I've gotten lots of email about this, twice. (Example: https://phabricator.wikimedia.org/project/profile/355/) And the projects are inconsistently named at the moment, since both persons missed a few spots: https://phabricator.wikimedia.org/project/query/xTNAyyYaAY0U/#R So, what should the names be? -- Bartosz Dziewoński

2 1

Revising Sorting of Notifications on the Fly-Out Menu
by Nick Wilson (Quiddity) 26 Jan '16

26 Jan '16

Hi all, The Collaboration team is currently working on a variety of improvements and updates to the Notifications (Echo) extension.[1] One task is improving how the many different types of notifications are sorted, into the two fly-out menus. Your feedback would be especially appreciated here. TL;DR: Please see this spreadsheet, listing the Current split, and 3 alternative groupings: https://docs.google.com/spreadsheets/d/1eVQVbzVhhVejEMnVqRBC98weBnfrnZqcGEx… (or a simplified version, and without the 3rd more complex "Experimental" grouping, at https://phabricator.wikimedia.org/T123018 ) The team is currently recommending we start off with the "By urgency" grouping. There is a list of Pros/Cons for each, in the spreadsheet. Please give us feedback, either at phabricator, or at https://www.mediawiki.org/wiki/Topic:Sw196pvf5vwt6pku Detailed information on the goals and background of this task, is included in both the phabricator and mediawiki.org links. Much thanks, Quiddity / Nick [1] https://www.mediawiki.org/wiki/Notifications#Future_plans_and_requests_for_… -- Nick Wilson (Quiddity) Community Liaison Wikimedia Foundation

1 0

Video: Loading Barack Obama on 2G from Spain on a Nexus 5
by Joaquin Oltra Hernandez 26 Jan '16

26 Jan '16

Hi, Here's an interesting video that we didn't get to show on the Developer Summit. This is me with my Nexus 5 (Android 6) on 2G in Spain loading en.m.wikipedia.org/wiki/Barack Obama https://www.youtube.com/watch?v=W1w0EcuiUjo Write your own conclusions, hopefully this will make us think. If you can set your device from your country to 2G and try it out on an incognito window (cold cache) and share the results, I would be very interested to see if your experience is the same as mine. Cheers, Joaquin

7 15

WikiArabia in Jordan & workshop in Palestine before the Wikimedia Hackathon?
by Quim Gil 26 Jan '16

26 Jan '16

The Wikimedia Hackathon (Jerusalem, 31 March - 3 April) is approaching and we are receiving new registrations every day. Two initiatives are being considered by local members of Wikimedia Levant, thanks to the proximity of the biggest Wikimedia technical event: A technical workshop at WikiArabia in Amman (Jordan) on 24-26 March. https://phabricator.wikimedia.org/T124217 A technical workshop in Ramallah or Birzet (Palestine) one day betweenn WikiArabia and the Wikimedia Hackathon. https://phabricator.wikimedia.org/T124721 We are in the earliest stages of planning. People interested, please subscribe / comment in the tasks. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Mediwiki-vagrant doesn't work with flow role enabled
by Devang Gaur 25 Jan '16

25 Jan '16

I haven't been able to setup the installation for mediawiki-vagrant . I'm running WAMP stack. Is windows the problem ? Anyways, I started again from the scratch to avoid any error caused by myself earlier .Cloned it as -> ssh://dg7@gerrit.wikimedia.org:29418/mediawiki/vagrant.git Now ,on vagrant up , it clones the mediawiki as well as other repositories via https only ,i.e, https://gerrit.wikimedia.org/r/p/mediawiki/core.git ( no commit access) . How should I go about it ? the log gives the following message at last : The SSH command responded with a non-zero exit status ........ The code loads on requesting 127.0.0.1:8080 , The only problem presently is with this SSH issue . So, it runs like this with just monobook role enabled . The screenshot : https://phab.wmfusercontent.org/file/data/rdduw4p2eua22zs3ed77/ PHID-FILE-sjw6fj5oezch467kkdkh/ 3yd57vaes5ncfv3s/Screenshot_%28168%29.png Now, when I enabled and provisioned for "Flow" role besides the monobook role, it all broke when I executed "vagrant reload". screenshot : https://phab.wmfusercontent.org/file/data/ae26yakvhhieoizpkday/ PHID-FILE-xpy3pmwv3ejbxsrcntu2/onrit2xyn2mqmp53/ Screenshot_%28169%29.png log ( provision ) : https://dpaste.de/kO0W log( reload ) : https://dpaste.de/ePbW I'm working on this task currently : https://phabricator.wikimedia.org/T72472

1 0

Fw: Shutting down persona.org in November 2016
by Tyler Romeo 25 Jan '16

25 Jan '16

So... I stopped development on the Persona extension a while ago when Mozilla dropped official support for it, but with persona.org shutting down, I am considering deprecating the extension entirely, especially considering the work that would be required porting it to AuthManager. But I figured I'd give a sort of last call. Is there anybody here that knows if the extension is being used (despite being marked as experimental) and thinks I should still maintain some sort of support for it? -- Tyler Romeo https://parent5446.nyc 0x405D34A7C86B42DF From: Ryan Kelly <rfkelly(a)mozilla.com> Reply: dev-identity(a)lists.mozilla.org <dev-identity(a)lists.mozilla.org> Date: January 11, 2016 at 20:09:31 To: dev-identity(a)lists.mozilla.org <dev-identity(a)lists.mozilla.org>, persona-notices(a)mozilla.org <persona-notices(a)mozilla.org> Subject: Shutting down persona.org in November 2016 Hi Everyone, When the Mozilla Identity team transitioned Persona to community ownership, we committed resources to operational and security support throughout 2014 [1], and renewed that commitment for 2015 [2]. Due to low, declining usage, we are reallocating the project’s dedicated, ongoing resources and will shut down the persona.org services that we run. Persona.org and related domains will be taken offline on November 30th, 2016. If you run a website that relies on Persona, you will need to implement an alternative login solution for your users. We have assembled a wiki page with additional information and guidelines for migration [3], but here are the important things you need to know: Between now and November 30th, 2016, Mozilla will continue to support the Persona service at a maintenance level: * Security issues will be resolved in a timely manner and the services will be kept online, but we do not expect to develop or deploy any new features. * Support will continue to be available on the dev-identity mailing list [4] and in the #services-dev IRC channel [5]. * All websites that rely on persona.org will need to migrate to another means of authentication during this period. Beginning on November 30th, 2016, the Persona service hosted by Mozilla will be decommissioned: * All services hosted on the persona.org domain will be shut down. * Mozilla will retain control of the persona.org domain and will not transfer it to a third party. * Since the privacy of user data is of utmost importance to Mozilla, we will destroy all user data stored on the persona.org servers, and will not transfer it to third parties. We intentionally designed Persona to expose email addresses rather than opaque identifiers, which should ease the transition to other systems that provide verified email addresses. You can find guidelines on alternative login solutions on the wiki [3] and we will continue to update them over the coming year. We strongly encourage affected teams to openly discuss and blog about their migrations on the dev-identity mailing list so that others can learn from their experience. Thank you for your support and involvement with Persona. If you have any questions, please post them to the dev-identity mailing list. Ryan [1] http://identity.mozilla.com/post/78873831485/transitioning-persona-to-commu… [2] https://groups.google.com/forum/#!topic/mozilla.dev.identity/rPIm7GxOeNU [3] https://wiki.mozilla.org/Identity/Persona_Shutdown_Guidelines_for_Reliers [4] https://lists.mozilla.org/listinfo/dev-identity [5] http://irc.mozilla.org/#services-dev _______________________________________________ Persona-notices mailing list Persona-notices(a)mozilla.org https://mail.mozilla.org/listinfo/persona-notices

2 1

Modern module loading needing code review
by Jon Robson 23 Jan '16

23 Jan '16

As part of the work of the frontend standards group https://gerrit.wikimedia.org/r/#/c/260071/ adds require and module.exports to MediaWiki ResourceLoader. This will make it easier to share code outside MediaWiki and with nodejs systems as well as discouraging the overloading of the mediawiki variable. I'm looking for code review at the moment. If you are familiar with ResourceLoader's internals I'd appreciate your input. See https://phabricator.wikimedia.org/T108655 for further background

2 1

Last call on RFC: drop PHP 5.3/5.4 support
by Tim Starling 23 Jan '16

23 Jan '16

This is a last call for new arguments and facts related to the proposal to drop PHP 5.3 and PHP 5.4 support in MediaWiki core git master. If you have anything new to say about this issue, please comment on the Phabricator ticket: https://phabricator.wikimedia.org/T118932 The Architecture Committee plans on making a decision on this issue on the basis of the Phabricator comments in next week's committee meeting (January 27). -- Tim Starling

2 1

VisualEditor roadmap - extensibility within MediaWiki?
by Daniel Barrett 22 Jan '16

22 Jan '16

I was looking through the VisualEditor roadmap (https://www.mediawiki.org/wiki/VisualEditor/Roadmap) and did not notice anything about third-party MediaWiki extensions for the editor. Did I miss it? I do see plans for "non-Mediawiki" extensions (under "Release for third-party non-MediaWiki users"), and also for Mediawiki admins to "easily install and use VisualEditor" (under "Release for third-party MediaWiki users"), but nothing about extending it within MediaWiki. For example, adding a button or menu item to insert a particular parser tag. Is this by design? I did notice "Non-template transclusions" on the roadmap, which looks like a way to insert parser tags & parser functions if you already know their name (the way template transclusions work right now). That will be a big help. However, for (say) inserting a given parser tag, it would be great if we could easily add a button or menu item for it. Thank you very much for any info. DanB

4 4

Fwd: [Wikimedia-l] Launch of Community Consultation on strategic approaches
by Quim Gil 22 Jan '16

22 Jan '16

The Wikimedia Foundation has started a consultation about strategic priorities. https://meta.wikimedia.org/wiki/2016_Strategy There is a survey with one question and several possibilities for each of the main themes: Reach, Community, Knowledge. It is a good chance to influence the WMF strategy with your individual voice. I really mean it! Taking the survey took me about 15 minutes and I found the exercise interesting. This survey is being promoted across all Wikimedia projects. I'm forwarding the announcement to this list in order to help assuring that our technical communities are well represented. Please take the survey, and feel free forwarding this message to whoever might be interested as well. ---------- Forwarded message ---------- From: Lila Tretikov <lila(a)wikimedia.org> Date: Tue, Jan 19, 2016 at 2:37 AM Subject: [Wikimedia-l] Launch of Community Consultation on strategic approaches To: Wikimedia Mailing List <wikimedia-l(a)lists.wikimedia.org> Dear Wikimedians, We are excited to have you participate in an important Community Engagement regarding our strategic approaches. This is a major step to help us prioritize the work of the Foundation beginning in July 2016 and running for the next 12 to 24 months thereafter into a strategic plan. Throughout 2015 the Foundation has been exploring how to prioritize its work to best support the movement's goals, set forth, but not yet reached, in the 2010-15 strategic plan. The strategic approaches presented here are based on our vision, strategy consultations in 2010 <https://meta.wikimedia.org/wiki/Strategy/2010-2015> and 2015 <https://meta.wikimedia.org/wiki/2015_Strategy/Community_consultation>, research on external impacts, and input from staff and a few small community think groups on key challenges and potential solutions. Timeline: These are our target dates for this process. - January 11: Put up pages for translation (done) - January 18: Launch of community consultation on key questions - February 15: Close of consultation - By February 26: Release synthesis of consultation - By March 4: Publish first draft strategy for comment We appreciate your time and efforts to help guide the Foundation in its work to support the movement. Warm regards, Lila _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Page for newbie/projects?
by Andrew Lih 21 Jan '16

21 Jan '16

Hi devs/techs, Is there a wiki page that acts as a first stop or landing page for computer science students who might be interested in working on coding projects with Wikipedia/Wikimedia projects? We have a page on Wikipedia greeting students/instructors who want to do class projects related to *writing* articles, but do we have a similar thing for CS instructors and students who might want to do an assignment or class project with Mediawiki, APIs, or with database dumps? If anyone could point me to the best of what we have now, that’d be great. This would be a way to find “shovel ready” challenges for students to work on, or contribute to projects in progress. Thanks. -Andrew

7 9

New MediaWiki structure test for API module's i18n completeness
by Legoktm 21 Jan '16

21 Jan '16

Hi, Anomie has written a new structure test[1] that checks whether API modules have all the proper i18n messages needed for their documentation. It's possible that your extension's tests will start failing due to this; if you need help figuring it out, please ping one of us and we can help out. [1] https://gerrit.wikimedia.org/r/#/c/260598/ -- Legoktm

1 0

meta: AbuseFilter on mediawiki.org and related sites
by Amir E. Aharoni 21 Jan '16

21 Jan '16

Hi, At least twice I found AbuseFilters that prevented people from testing extensions that I develop or posting feedback about them on MediaWiki.org and the beta testing sites (such as http://en.wikipedia.beta.wmflabs.org/wiki/Main_Page ). By their nature, the extensions I am working on have a lot to do with different (human) languages, and these AbuseFilters relied on the assumption that on these sites everything is supposed to be in English, and whatever is not English is probably spam. One of them filtered out the whole Russian alphabet, so the extension couldn't be tested by Russian-speaking users. Another one didn't allow submitting Flow posts that don't have a sufficient amount of English words from users who have less than 6 edits, so users who have a lot of edits in their home wikis, but no edits in mediawiki.org, and who want to post in languages other than English are blocked. Luckily, one of those people pinged me directly, but I don't know how much useful feedback was filtered out and lost. I acknowledge that spam is a problem and that there may be a better solution for multilingual testing and feedback than doing it all on one site English site, but till there are solutions for this, please consider non-English languages when defining AbuseFilters on our tech sites. Thanks for understanding :) -- Amir Elisha Aharoni · אָמִיר אֱלִישָׁע אַהֲרוֹנִי http://aharoni.wordpress.com ‪“We're living in pieces, I want to live in peace.” – T. Moore‬

3 2

Community Wishlist Survey: Status report #1
by Danny Horn 21 Jan '16

21 Jan '16

Hi everyone, We've posted the Community Tech team's first status report on our progress with the Community Wishlist Survey, and you're invited to come and check it out: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Status_repor… In November and December, we invited active contributors to Wikimedia projects to propose, discuss and vote on the features and fixes that they most want to see. 634 people participated in the survey, voting on 107 proposals. Our team has committed to investigating and responding to the top 10 wishes. In many cases, our team will be designing and building tools ourselves, or collaborating with other teams and volunteers who are working in that area. For the wishes that we can't build this year -- because it's too big for our team, or there's a problem that we can't solve -- then we can at least offer open discussion on the problem, and detailed documentation explaining what we've learned, so the information can be used by other developers in the future. We've done a preliminary assessment of the top 10, which is described in the status report. As of right now (mid-January), the two items that we're actively working on are #1) Migrate dead links to the Wayback Machine, and #7) Pageview Stats tool. Why are we working on those two and not the others? Check out the status report for all the answers. I'm going to post the quick overview of the top 10 wishes here. Each of these wishes is discussed in detail on the status report page. 1. Migrate dead links to the Wayback Machine: Currently in progress, working with a community developer and the Internet Archive. This is one of the two projects we're actively working on now (mid-January). 2. Improved diff compare screen: Needs investigation and community discussion to define the problems that we want to solve. 3. Central repository for templates, gadgets and Lua modules: Needs underlying technical work that's currently under discussion by another team. 4. Cross-wiki watchlist: Needs technical investigation on the existing Crosswatch tool, and the Collaboration team's cross-wiki notifications. 5. Numerical sorting in categories: Investigation is underway. There are a couple potential solutions that we need to figure out. 6. Allow categories in Commons in all languages: Currently talking with Wikidata about using structured metadata to solve the underlying problem. 7. Pageview Stats tool: Currently talking with the Analytics team about their new pageview API. Needs some community discussion to define the front-end spec. This is one of the two projects we're actively working on now (mid-January), because the Analytics team is eager to use the new API that they've developed. 8. Global cross-wiki talk page: Needs community discussion to define the product. 9. Improve copy and paste detection bot: Need to work with volunteer developers to define scope on improving the existing Plagiabot. 10. Add a user watchlist: We've heard significant pushback about the vandal-fighting use case, because of the risk of enabling harassment. Currently investigating an opt-in version that would be useful for mentors, classes, editathons and WikiProjects. Here's the status report link again, for lots more information: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Status_repor… Our team is really excited about the work that we'll get to do this year, and we're looking forward to talking and working with you as we go along. Thanks, Danny Horn Product Manager WMF - Community Tech User:DannyH (WMF)

3 2

RESTBase 0.9.2 (security release)
by Gabriel Wicke 20 Jan '16

20 Jan '16

A vulnerability has been found in RESTBase v0.9.1 and earlier that allowed attackers to read arbitrary files on the host system by passing a specially crafted URL. This vulnerability has been fixed in [1]. All RESTBase users are strongly encouraged to upgrade to v0.9.2 immediately. Files readable by the RESTBase service user might have been accessed by third parties, so appropriate measures should be taken. mediawiki-containers [2] users with automatic updates enabled have already been upgraded to v0.9.2. -- Gabriel Wicke Principal Engineer, Wikimedia Foundation [1]: https://github.com/wikimedia/restbase/commit/1ea649306ae4e85ab2cee5a36318e9… [2]: https://github.com/wikimedia/mediawiki-containers

2 1

Scrum of Scrum notes - 2016-01-20
by Greg Grossmeier 20 Jan '16

20 Jan '16

= 2015-01-20 = == Reading == === Android === * v2.1.137 promoted to production. * Reviewing Gather API re: multiple lists on multiple languages === Web === * Planning === iOS === * Beta has been rolled out to over 1000 testers, there have been 422 installs to date ** Is there a way to mesaure beta API usage (i.e. CPU time?) * Investigating using pageviews/top API as part of iOS "Explore" feature. Main blocker is filtering out things like non-main namespace, main page, Special: Search, etc. ** https://phabricator.wikimedia.org/T123442 (Dan: Joseph commented on this) ** https://phabricator.wikimedia.org/T118841 ? (Dan: this might be a misunderstanding, this sanitization is internal for privacy protection) ** https://phabricator.wikimedia.org/T121912 (Dan: redirects are quite confusing, I have some reading to do on this and it's hard to carve out time right now. But this is a priority) ** https://phabricator.wikimedia.org/T124082 (Dan: I'll comment on the ticket) === Reading Infrastructure === * Block: Could use a quick security look at https://gerrit.wikimedia.org/r/#/c/264309/. * Hey Mobile people: Authmanager is replacing API action=login with action=clientlogin, and action=createaccount is going to completely change. We're currently aiming at end of February for the deployment. ** See https://gerrit.wikimedia.org/r/#/c/265201/ for details, then talk to Brad if you have questions. == Technology == === Research === * ORES serving ~100 external requests per minute * ORES moving to new meso-level (Labs < Meso < Prod) support -- blocked on Ops time to set up machines * See https://phabricator.wikimedia.org/T106867 -- working with Yuvi to flesh out sub-tasks -- need to know who to CC === Security === * kartographer, Ex:ORES, TextCat reviews in progress * Patch to parser/stripmarkers (T110143) deploying today. Contact Security if you see an issue with Xml::escapeTagsOnly. === Services === * Mobile Content Service pre-generation enabled :* running enwiki dump to populate it * /page/definition/ end point for wiktionaries :* functional only on en.wiktionary :* pre-generated * Move to Jessie and Node 4.2 :* Graphoid and Citoid - tomorrow :* CXServer - please check! ::* Apertium pkgs? :* Parsoid - needs testing === Release Engineering === * Blocking: none * Blocked: none * Updates: ** scap 3.0 will be tagged soon *** finalizing changes to simplify configuration deployment *** also working on puppet provider === Technical Operations === * Blocking: Research on ORES * Blocked by: none * Updates: * RESTBase/Kernel security incident * OTRS upgrade on Jan 28th to be rescheduled for Feb 2nd * HHVM 3.11 packaging moving on, almost done === Analytics === * Event Logging replication to analytics-store has been slow for a long time. Right now it's behind by about 3 days for a lot of major schemas. The problem is not obvious but we're on it. * Geowiki stopped updating on December 18th because one of the servers it was using was read-only, that's now fixed * Piwik has been optimized and is working reasonably well with the 15.wikipedia.org website, other **low** traffic apps/sites can use piwik now if they wish (already talking to reading about doing this with their iOS client) == Editing == === Parsing === * No blockers * Not blocking anyone (as far as I know) * Updates: ** QR today (done) ** RT test server (ruthenium) being updated to jessie and node 4.2 *** Needs puppetization fixes to migrate upstart files to systemD ** Parsoid node 4.2 testing with a focus on memory usage / GC behavior === Language === * Delay in adding parallel corpora tables for Content Translation ** seems to be resolving now such that we are going to add them ourselves === Collaboration === * Cross-wiki notification Beta Feature now on test and test2. * Coordinating on Flow dumps from production. Ariel is working on this - https://phabricator.wikimedia.org/T119511 === Fundraising Tech === * Investigating queue outages during December campaign * Updating DonationInterface session handling to work with 1.27 ** Trying to figure out how to run CI tests against the core branch deployed in payments, with 1.27 as non-voting * More CiviCRM enhancements == Discovery == * Portal A/B test is running * Working on Dallas cluster load tests, so far it doesn't appear to hold the peak load, more work is needed * WDQS Blazegraph 2.0 testing successful, will upgrade when GA is released. Started to work on geospatial search implementation. * Quarterly review this Thursday * Waiting for security review on TextCat -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Meeting scribes for WMF meetings
by Rob Lanphier 20 Jan '16

20 Jan '16

Hi folks, One thing we'd love to get better at is taking and publishing useful notes from our meetings. An example of that is ArchCom meetings, for which we have been taking notes for a while, but I haven't gotten around to publishing. Another example is our weekly tech Engineering Tech managers meetings, which are increasing in importance as we head into budget setting season. Is there anyone available to be a volunteer scribe for ArchCom and/or Tech/Eng management meetings? For logistical reasons, I would prefer existing WMF employee offers over non-WMF offers, but beggars can't be choosers ;-) The next meeting opportunity is in 15 hours: the ArchCom is having it's weekly 1pm PST (21:00 UTC) meeting just prior to the 2pm PST public IRC meeting. If you're interested, please let me know! The best way to express your volunteer interest is by adding your sig on the bottom of this page: <https://www.mediawiki.org/wiki/User:RobLa-WMF/Scribes> ...and discussion is welcomed on the associated talk page. Rob

2 1

Fwd: Wikimedia Hackathon Jerusalem 2016: registration is now open!
by Rachel Farrand 20 Jan '16

20 Jan '16

---------- Forwarded message ---------- From: Chen Davidi <chen(a)wikimedia.org.il> Date: Wed, Dec 23, 2015 at 9:02 AM Subject: [Wikitech-ambassadors] Wikimedia Hackathon Jerusalem 2016: registration is now open! To: wikitech-ambassadors(a)lists.wikimedia.org, wikitech-l(a)lists.wikimedia.org, wikitech-announce(a)lists.wikimedia.org, engineering(a)lists.wikimedia.org, wikimedia-l(a)lists.wikimedia.org Hi everyone, I'm thrilled to tell you all that the registration for Wikimedia Hackathon 2016 is now open! The Hackathon will be held in Jerusalem, between March 31st to April 3rd, 2016, by Wikimedia Israel. Scholarship applications are open until January 22nd. You know the drill! Registration here - https://docs.google.com/forms/d/17WFRHTCX5_dnCD5hFk1gHEQUz6pTrKp85QsX01rJGa… More info and updates on https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2016 If you have any questions, please contact us at hackathon2016(a)wikimedia.org.il Hope to see you all in Jerusalem! Chen Davidi-Almog, Activity & Resources Coordinator. Wikimedia Israel

1 1

Could someone relatively new to Python please QA the Accuracy review login framework?
by James Salsman 19 Jan '16

19 Jan '16

An Outreachy candidate for http://mediawiki.org/wiki/Accuracy_review who went ahead and started unpaid has been making good progress, and is about to land the central guts of the project on github. It's a new way to transition from creating to maintaining Wikipedia articles, with an emphasis on detecting outdated statistics, fighting bias including paid advocacy of all kinds, and proofreading WEP student work. It's been going slow, mostly because the original trial run architecture was too dependent on email. However, before she gets there, could one or two people who are maybe beginner or intermediate with Python but advanced with Mediawiki or PHP please test her user authentication and login framework? https://github.com/priyankamandikal/wikireview/ <https://github.com/priyankamandikal/wikireview/issues> It's built for PythonAnywhere because it shouldn't run on Wikimedia servers, because of the safe harbor DMCA provisions precluding editorial control by web hosts. Please report any issues on github and note your results on the Phabricator task to prevent duplication of effort. Thanks in advance! Best regards, Jim Salsman

2 4

Governance model for Wikimedia software development (e.g. MediaWiki)
by Rob Lanphier 19 Jan '16

19 Jan '16

Hi folks, Over the past few weeks (including WikiDev '16) we've had several conversations the Wikimedia software development governance model. For a lot of people, the most important aspect of this is MediaWiki. More generally, though, the scope is about we deploy to Wikimedia sites that we intend to maintain, enhance, and further leverage. On Wednesday, January 20, we intend to continue this conversation, and welcome your participation: <https://phabricator.wikimedia.org/E135> In particular, we plan to discuss the work that Gabriel Wicke started: <https://phabricator.wikimedia.org/T123606> "WIP RFC: Improving and scaling our technical decision making process" ...which is mainly a pointer to: <https://www.mediawiki.org/wiki/Requests_for_comment/Governance> I've quoted the current text as of this writing below, and you're welcome to reply on list or on the talk page (though let's try to ensure a summary of important comments gets captured on T123606). Based on the conversations I've been part of (and Gabriel's initial writeup), Rust's governance model seems to be the leading candidate to iterate toward. This doesn't necessarily mean making one big change with a fanfare-laden launch, but let's discuss. Wait until Wednesday's IRC session if you have to (22:00 UTC, 14:00 PST), but we'd love to hear your thoughts sooner. Rob p.s. Here's the link to the RFC <https://www.mediawiki.org/wiki/Requests_for_comment/Governance> ...and below is the plain text from [mw:Requests for comment/Governance]. Problem statement [Goal: Describe the problem we are seeing with the current process, and why it is important to solve them.] Difficulty of making clear and accepted decisions on important and broad topics. Scaling the decision making process. Stakeholder involvement & legitimacy. Clarity and transparency of decision making process. Prior art [Goal: Give a brief summary and pointers to options we looked at.] IETF process Python PEP process Rust Debian W3C See also this prior etherpad discussion. Strawman proposal [Goal: Summarize key ideas that we consider worth adopting, and point to prior art. Provide rationale by explaining how each addresses specific issues.] More structured RFC decision process Based on the Rust decision making process. Nominate a shepherd from a (sub)team to guide an RFC through the process. Makes sure that stakeholders are informed. Guides the discussion. Once the discussion plateaus or stalls & in coordination with the RFC author(s), announces and widely publicizes a "Final Comment Period", which is one week. At the end of the "Final Comment Period", the (sub)team decides based on the points made in the RFC discussion, and justifies its decision based on the overall project principles and priorities. If any new facts or aspects are surfaced in this discussion, a new Final Comment Period needs to be started before making a decision. Scaling the decision making process with sub-teams Based on Rust subteams. The core team is responsible for creating sub-teams, with a member of the core team as its team leader. Initial membership is determined by the leader, later changes are by consensus within the team. Each sub-team has a specific vision and problem set to work on, and the team leader is responsible for keeping the team on topic. Sub-teams are empowered to decide on RFCs within their scope. The team leader is responsible for elevating RFCs with unclear or broader scope to the core team.

1 0

Re: [Wikitech-l] [Wikimedia-l] Community Wishlist Survey: Top 10 wishes!
by Danny Horn 18 Jan '16

18 Jan '16

Henning, If we're going to solve the problem of dead links, it needs to involve automation, at least for the heavy lifting. Obviously, if a human contributor can add a better source, that's great. But there are more dead links than people willing to replace them. On English Wikipedia, there's Category:All articles with dead external links, and it contains more than 134,000 articles[1] -- and those are just the pages where somebody's added the Dead link template. There are a lot of missing references -- not just on English WP, but on all the projects -- and connecting those links to a live archive makes them useful again. For links that were moved, we may be able to collect and use that information -- I know that we're looking into what kind of metadata we can collect when a new link is added to the page. But I think finding alternative sources has to come from human contributors, and that's hard to scale. Danny PM, Community Tech [1]: https://en.wikipedia.org/wiki/Category:All_articles_with_dead_external_links On Mon, Dec 28, 2015 at 9:51 AM, Henning Schlottmann <h.schlottmann(a)gmx.net> wrote: > On 16.12.2015 21:12, Danny Horn wrote: > > > #1. Migrate dead links to the Wayback Machine (111 support votes) > > I really hope, you don't follow that wish, as it is detrimental to the > quality of Wikipedia. > > Switching dead links to the archive is a move to a dead end, instead of > looking for > > a) the new correct URL, as many links were just moved. > b) alternative sources for the same fact. > > Ciao Henning > > > > _______________________________________________ > Wikimedia-l mailing list, guidelines at: > https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines > New messages to: Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, > <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> >

5 8

SEMANTiCS 2016, Leipzig, Sep 12-15, Call for Research & Innovation Papers
by Sebastian Hellmann 18 Jan '16

18 Jan '16

Apologies for cross-posting <mailbox:///home/julia/.thunderbird/0xgpsb48.default/Mail/Local%20Folders/Trash?number=18993455&part=1.2.2&filename=486eca59914e673f7b637acad4ef4466efdf01db><mailbox:///home/julia/.thunderbird/0xgpsb48.default/Mail/Local%20Folders/Trash?number=18993455&part=1.2.2&filename=486eca59914e673f7b637acad4ef4466efdf01db> Call for Research & Innovation Papers SEMANTiCS 2016 - The Linked Data Conference Transfer // Engineering // Community 12th International Conference on Semantic Systems Leipzig, Germany September 12 -15, 2016 http://2016.semantics.cc <https://www.google.com/url?q=http://2016.semantics.cc/&sa=D&ust=14531132570…> Important Dates (Research & Innovation) * Abstract Submission Deadline: April 14, 2016 (11:59 pm, Hawaii time) * Paper Submission Deadline: April 21, 2016 (11:59 pm, Hawaii time) * Notification of Acceptance:May 26, 2016 (11:59 pm, Hawaii time) * Camera-Ready Paper: June 16, 2016(11:59 pm, Hawaii time) Submissions via Easychair: https://easychair.org/conferences/?conf=semantics2016research <https://www.google.com/url?q=https://easychair.org/conferences/?conf%3Dsema…> As in the previous years, SEMANTiCS’16 proceedings are expected to be published by ACM ICP. The annual SEMANTiCS conference is the meeting place for professionals who make semantic computing work, who understand its benefits and encounter its limitations. Every year, SEMANTiCS attracts information managers, IT-architects, software engineers and researchers from organisations ranging from NPOs, through public administrations to the largest companies in the world. Attendees learn from industry experts and top researchers about emerging trends and topics in the fields of semantic software, enterprise data, linked data & open data strategies, methodologies in knowledge modelling and text & data analytics. The SEMANTiCS community is highly diverse; attendees have responsibilities in interlinking areas like knowledge management, technical documentation, e-commerce, big data analytics, enterprise search, document management, business intelligence and enterprise vocabulary management. The success of last year’s conference in Vienna with more than 280 attendees from 22 countries proves that SEMANTiCS 2016 will continue a long tradition of bringing together colleagues from around the world. There will be presentations on industry implementations, use case prototypes, best practices, panels, papers and posters to discuss semantic systems in birds-of-a-feather sessions as well as informal settings. SEMANTICS addresses problems common among information managers, software engineers, IT-architects and various specialist departments working to develop, implement and/or evaluate semantic software systems. The SEMANTiCS program is a rich mix of technical talks, panel discussions of important topics and presentations by people who make things work - just like you. In addition, attendees can network with experts in a variety of fields. These relationships provide great value to organisations as they encounter subtle technical issues in any stage of implementation. The expertise gained by SEMANTiCS attendees has a long-term impact on their careers and organisations. These factors make SEMANTiCS for our community the major industry related event across Europe. SEMANTiCS 2016 will especially welcome submissions for the following hot topics: * Data Quality Management * Data Science (Data Mining, Machine Learning, Network Analytics) * Semantics on the Web, Linked (Open) Data & schema.org * Corporate Knowledge Graphs * Knowledge Integration and Language Technologies * Economics of Data, Data Services and Data Ecosystems Following the success of previous years, the ‘horizontals’ (research) and ‘verticals’ (industries) below are of interest for the conference: Horizontals * Enterprise Linked Data & Data Integration * Knowledge Discovery & Intelligent Search * Business Models, Governance & Data Strategies * Big Data & Text Analytics * Data Portals & Knowledge Visualization * Semantic Information Management * Document Management & Content Management * Terminology, Thesaurus & Ontology Management * Smart Connectivity, Networking & Interlinking * Smart Data & Semantics in IoT * Semantics for IT Safety & Security * Semantic Rules, Policies & Licensing * Community, Social & Societal Aspects Verticals * Industry & Engineering * Life Sciences & Health Care * Public Administration * Galleries, Libraries, Archives & Museums (GLAM) * Education & eLearning * Media & Data Journalism * Publishing, Marketing & Advertising * Tourism & Recreation * Financial & Insurance Industry * Telecommunication & Mobile Services * Sustainable Development: Climate, Water, Air, Ecology * Energy, Smart Homes & Smart Grids * Food, Agriculture & Farming * Safety & Security * Transport, Environment & Geospatial Research / Innovation Papers The Research & Innovation track at SEMANTiCS welcomes the submission of papers on novel scientific research and/or innovations relevant to the topics of the conference. Submissions must be original and must not have been submitted for publication elsewhere. The Research & Innovation track at SEMANTiCS is a single-blind review process (author names are visible to reviewers, reviewers stay anonymous). The submitted abstract and the topics are leveraged to find adequate reviewers for submitted papers. Please write an email to semantics2016researchtrack(a)easychair.org <mailto:semantics2016researchtrack@easychair.org>, if you have any questions. Papers should follow the ACM ICPS guidelines for formatting and must not exceed 8 pages in length for full papers and 4 pages for short papers, including references and optional appendices. The layout templates can be found here: http://www.acm.org/sigs/publications/proceedings-templates <https://www.google.com/url?q=http://www.acm.org/sigs/publications/proceedin…>All accepted full papers and short papers will be published in the digital library of the ACM ICP Series. Research & Innovation papers should be submitted through EasyChair at: https://easychair.org/conferences/?conf=semantics2016research <https://www.google.com/url?q=https://easychair.org/conferences/?conf%3Dsema…>. Papers must be submitted in PDF (Adobe's Portable Document Format) format. Other formats will not be accepted. For the camera-ready version, the source files (Latex, WordPerfect, Word) will also be needed. Important Dates (Research & Innovation) * Abstract Submission Deadline: April 14, 2016 (11:59 pm, Hawaii time) * Paper Submission Deadline: April 21, 2016 (11:59 pm, Hawaii time) * Notification of Acceptance:May 26, 2016 (11:59 pm, Hawaii time) * Camera-Ready Paper: June 16, 2016 (11:59 pm, Hawaii time) Research and Innovation Chairs: * Anna Fensel <https://www.google.com/url?q=http://www.anna.fensel.com/&sa=D&ust=145311325…>, University of Innsbruck * Amrapali Zaveri <https://www.google.com/url?q=http://dumontierlab.stanford.edu/&sa=D&ust=145…>, Stanford University Contact email address:semantics2016researchtrack@easychair.org <mailto:semantics2016researchtrack@easychair.org> Research and Innovation Deputy Chairs: * Bernhard Haslhofer <https://www.google.com/url?q=http://bernhardhaslhofer.info/&sa=D&ust=145311…>, Austrian Institute of Technology * Artem Revenko <https://www.google.com/url?q=https://www.linkedin.com/in/artem-revenko-1831…>, Semantic Web Company Conference Chairs: * Sebastian Hellmann <https://www.google.com/url?q=http://aksw.org/SebastianHellmann.html&sa=D&us…>, AKSW/KILT, InfAI, Leipzig University * Tassilo Pellegrini <https://www.google.com/url?q=https://en.wikipedia.org/wiki/Tassilo_Pellegri…>, UAS St. Pölten Senior Program Committee: * Paul Buitelaar, Insight - National University of Ireland, Galway * Oscar Corcho, Universidad Politécnica de Madrid * Claudia D'Amato, University of Bari * Brian Davis, DERI NUIG * Victor de Boer, VU Amsterdam * Christian Dirschl, Wolters Kluwer Germany * Michel Dumontier, Stanford University * Agata Filipowska, Department of Information Systems, Poznan University of Economics * Bernhard Haslhofer, AIT-Austrian Institute of Technology * Sebastian Hellmann, AKSW/KILT, InfAI, Leipzig University * Andreas Hotho, University of Wuerzburg * Jose Emilio Labra Gayo, Universidad de Oviedo * Peter Mika, Yahoo! Research * Axel-Cyrille Ngonga Ngomo, University of Leipzig * Josiane Xavier Parreira, Siemens AG Österreich * Heiko Paulheim, University of Mannheim * Tassilo Pellegrini, University of Applied Sciences St. Pölten * Marta Sabou, Vienna University of Technology * Harald Sack, Hasso-Plattner-Institute for IT Systems Engineering, University of Potsdam * Ruben Verborgh, Ghent University - iMinds * Maria Esther Vidal, Universidad Simon Bolivar, Dept. Computer Science Program Committee: * Alessandro Adamou, Knowledge Media Institute, The Open University * Rajendra Akerkar, Western Norway Research Institute * Vladimir Alexiev, Ontotext Corp * Jose María Alvarez Rodríguez, Carlos III University of Madrid * Stefan Bischof, Siemens AG Österreich * Volha Bryl, Springer Nature * Irene Celino, CEFRIEL * Pierre-Antoine, Champin LIRIS * Roland Cornelissen, Metamatter * Gianluca Correndo, University of Southampton * Roberta Cuel, University of Trento * Aba-Sah Dadzie, Knowledge Media Institute, The Open University * Elena Demidova, L3S Research Center * Tommaso Di Noia, Politecnico di Bari * Marin Dimitrov, Ontotext * Mauro Dragoni, Fondazione Bruno Kessler - FBK-IRST * Samhaa El-Beltagy, Cairo University * Ingo Feinerer, University of Applied Sciences Wiener Neustadt * Javier D. Fernández, Computer Science Department. University of Valladolid * Fabien Gandon, Inria * Jorge Garcia, Ontology Engineering Group, Universidad Politécnica de Madrid * Roberto Garcia, Universitat de Lleida * José María García, University of Seville * Alain Giboin, INRIA Sophia Antipolis - Méditerranée * Juan Miguel Gómez-Berbís, Universidad Carlos III de Madrid * Jose Manuel Gomez-Perez, Expert System * Michael Granitzer, University of Passau * Benjamin Heitmann, Insight Centre for Data Analytics, National University of Ireland, Galway * Eelco Herder, L3S Research Center * Laura Hollink, CWI * Katja Hose, Aalborg University * Valentina Janev, Mihailo Pupin Institute, University of Belgrade * Anja Jentzsch, Hasso Plattner Institut * Ali Khalili, VU University Amsterdam * Sabrina Kirrane, Vienna University of Economics and Business - WU Wien * Dimitris Kontokostas, University of Leipzig * Christoph Lange, University of Bonn * Nelia Lasierra Beamonte, UMIT – University for Health Sciences, Medical Informatics and Technology * Isaac Lera, University of the Balearic Islands * Steffen Lohmann, Fraunhofer IAIS * Vanessa Lopez, IBM Research * Sandra Lovrenčić, University of Zagreb, Faculty of organization and informatics Varazdin * Markus Luczak-Roesch, University of Southampton * Elisa Marengo, Faculty of Computer Science, Free University of Bozen-Bolzano * John P. Mccrae, National University of Ireland, Galway * Andras Micsik, SZTAKI * Andrea Moro Sapienza, Università di Roma * Dmitry Mouromtsev, NRU ITMO, Russia * Claudia Müller-Birn, Freie Universität Berlin * Lyndon Nixon, MODUL University * Inna Novalija, Jozef Stefan Institute * Andrea Giovanni Nuzzolese, STLab, ISTC-CNR * Leo Obrst, MITRE * Maryam Panahiazar, Stanford University * Alexander Panchenko, Université catholique de Louvain * Viviana Patti, University of Turin * Silvio Peroni, University of Bologna * Xiuquan Qiao, Beijing University of Posts and Telecommunications * Achim Rettinger, Karlsruhe Institute of Technology * Mariano Rico, Universidad Politécnica de Madrid * Giuseppe Rizzo, ISMB * Marco Rospocher, Fondazione Bruno Kessler * Matthew Rowe, Lancaster University * Anisa Rula, University of Milano-Bicocca * Felix Sasaki, W3C * Vadim Savenkov, Vienna University of Economics and Business (WU) * Francois Scharffe, 3Top * Luciano Serafini, Fondazione Bruno Kessler * Pavel Shvaiko, Informatica Trentina * Nadine Steinmetz, TU Ilmenau * Holger Stenzhorn, Saarland University Hospital * Simon Steyskal, Siemens AG Austria * Vojtěch Svátek, University of Economics, Prague * Konstantin Todorov, LIRMM * Ioan Toma, STI Innsbruck * Jürgen Umbrich, Vienna University of Economy and Business (WU) * Joerg Waitelonis, Hasso-Plattner-Institute Potsdam * Krzysztof Wecel, Poznan University of Economics * Eva Zangerle, Databases and Information Systems, Department of Computer Science, University of Innsbruck

1 0

Fwd: Thank yous and video recordings for the Wikipedia 15 joint celebrations (SF, NYC, and Seattle)
by Pine W 17 Jan '16

17 Jan '16

Forwarding video links (: ---------- Forwarded message ---------- From: Pine W <wiki.pine(a)gmail.com> Date: Sat, Jan 16, 2016 at 6:43 PM Subject: Thank yous and video recordings for the Wikipedia 15 joint celebrations (SF, NYC, and Seattle) To: <snip> Video links to Youtube (Commons uploads will happen in the near future, I believe): * Welcome and lightning talks: https://www.youtube.com/watch?v=dGhxEpowM6A * "Wikipedia's content gender gap": https://www.youtube.com/watch?v=uW1WSVmpvwk * "Stories from the weird old days": https://www.youtube.com/watch?v=ZLmGc-hpp3U * Panel discussion "The impact of 15 years of Wikipedia": https://www.youtube.com/watch?v=CiEjkxCGmgU Here's to the next 15 years! Pine

1 0

Fwd: Chad Horohoe promoted to Senior Software Engineer
by Greg Grossmeier 16 Jan '16

16 Jan '16

While promotions are fairly insular, I think the wikitech community would be happy to see this. ----- Forwarded message from Greg Grossmeier <greg(a)wikimedia.org> ----- > Date: Fri, 15 Jan 2016 14:32:54 -0800 > From: Greg Grossmeier <greg(a)wikimedia.org> > To: "WMF Staff (All)" <wmfall(a)lists.wikimedia.org> > Subject: Chad Horohoe promoted to Senior Software Engineer > > I'm more than pleased to announce that Chad Horohoe has been promoted to > Senior Software Engineer. > > For those of you who don't know Chad, let me give a quick run down: > > 2005 - Started as a volunteer editor[0] > 2008 - Became a MediaWiki developer[1] > 2010 - Started contracting for WMF[2] > 2012 - Became staff[3] > > Those are just the legal/contract related highlights; Chad has done a > lot to help make the Wikimedia technology stack better. Everything from > migrating us from SVN to Git, shepherding multiple RFCs, working with > our upstream projects (HHVM, Phabricator, Gerrit), helped bring us our > new search infrastructure (ElasticSearch), and is generally a great > person to ask when no one else knows the history. > > Please join me in congratulating Chad! > > Greg > > [0] First edit: > https://en.wikipedia.org/w/index.php?diff=prev&oldid=10508529 > [1] https://www.mediawiki.org/wiki/Special:Code/MediaWiki/35764 > [2] Shortly after being stuck in Berlin due to Eyjafjallajökull > erupting. https://phabricator.wikimedia.org/T25223 > [3] Super secret ADP url, I couldn't find a good public reference. > > > -- > | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | > | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D | ----- End forwarded message ----- -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

Bulk link rewrites for HTTP -> HTTPS migration?
by Chris Adams 15 Jan '16

15 Jan '16

I've been working with a number of colleagues getting ready to turn HTTPS on by default for various loc.gov domains. This has been fairly successful and we're working through the old legacy apps now. When that work completes, we'll have somewhere around half a million links which differ only in the URL scheme. What would be the best way to rewrite all of those URLs? I'd like to reduce the window during which users transit from HTTPS -> HTTP -> HTTPS. If anyone's curious, I've been collecting the links for a few dozen wikis in a somewhat oversized Git repo: https://github.com/acdha/lc-wikipedia-links The first site which has completely migrated is the much smaller World Digital Library which has just under four thousand links: https://gist.github.com/acdha/f785b22b356a9842439e Thanks, Chris

6 9

Tech Talk: Creating Useful Dashboards with Grafana: January 14
by Rachel Farrand 14 Jan '16

14 Jan '16

Please join for the following tech talk: *Tech Talk**:* Creating Useful Dashboards with Grafana *Presenter:* Timo Tijhof *Date:* January 13, 2016 *Time: *21:30 UTC <http://www.timeanddate.com/worldclock/fixedtime.html?msg=Timo+Tech+Talk&iso…> Link to live YouTube stream <http://www.youtube.com/watch?v=UlL6UoRUQAM> *IRC channel for questions/discussion:* #wikimedia-office *Summary: *Over the past two years Timo has worked a lot with our metric infrastructure and the various visualisation tools in use at Wikimedia. The aim of this talk is to help you create better dashboards with Grafana. Timo will discuss the various metric types we have, how they are gathered in our software environments, and how you can use Graphite to query this data. He will also share lessons learned in the Performance Team using real world examples.

4 5

MediaWiki authentication changes
by Brad Jorsch (Anomie) 14 Jan '16

14 Jan '16

*TL;DR:* Stuff is changing. If you notice problems with session handling in 1.27.0-wmf.11, file a bug in Phabricator and CC me (Anomie) and Gergő (Tgr). MediaWiki's authentication layer is getting a major overhaul! This will allow us to do cool stuff like 2-factor authentication without the 2-factor extension having to be redone for LdapAuth/CentralAuth/every-other-auth, third-party login (e.g. Google, Facebook) without hacking around everything with crazy hooks, and supporting more than just one authentication method at a time. Broadly speaking, this change involves the addition of two new things: SessionManager (already merged, being deployed with 1.27.0-wmf.11) and AuthManager (hopefully coming by the end of February). - SessionManager replaces the use of PHP's $_SESSION and session_*() functions and the UserLoadFromSession and UserSetCookies hooks with a more extensible mechanism. - AuthManager allows for independent pluggable authentication modules, multiple authentication methods, and removes the assumption that all logins can be handled with a one-page form having "username" and "password" fields. No more needing to adjust every authentication extension to know about every other authentication extension it might have to cooperate with. However, the changes we're making do mean that various things are going to need updating. == For users == You shouldn't notice any changes due to SessionManager. If you do see problems related to session handling in 1.27.0-wmf.11, file a bug in Phabricator and CC me (Anomie) and Gergő (Tgr). Once AuthManager comes around, the most visible change will be that the login form will probably be a bit different, and if your browser remembers your login information for you then you might have to re-enter it. == For bots == You shouldn't notice any changes due to SessionManager, but do make sure your code is handling cookies normally instead of using the deprecated return values from action=login to construct cookies manually.[1] If you are handling cookies properly and see problems related to session handling in 1.27.0-wmf.11, file a bug in Phabricator and CC me (Anomie) and Gergő (Tgr). For AuthManager, the new features mean that unattended login might no longer work since the login flow will now natively support user interaction: the account might have 2-factor enabled, or might need a password reset, or some other thing that requires user interaction. We've created two ways to work around this: - If possible, switch to OAuth. This week (1.27.0-wmf.10) "owner-only" consumers are being rolled out to make this easier for bot operators: log into your bot account, go to https://meta.wikimedia.org/wiki/Special:OAuthConsumerRegistration/propose, and create a consumer with the "This consumer is for use only by MyBotName" checkbox checked.The consumer will be approved for use immediately, no waiting or trying to find someone who can approve the consumer for you. Owner-only consumers also don't tag every edit, since all the edits will be from the one account anyway. - If you need to continue using the existing action=login, next week (1.27.0-wmf.11) we're rolling out Bot Passwords. This is something like OAuth-lite, or Google's application passwords: go to Special:BotPasswords, set one up, and then use new bot-password username and password to login as you've always done (no code changes, just update your bot's configuration). It's already live in Beta Labs if you want to test it out. Login with the "main" account password will continue to work until AuthManager is deployed, and might continue to work after that too (as long as nothing requires user interaction). For bots that run on third-party wikis, Bot Passwords are in core and are enabled by default, but it's possible a wiki could disable them. OAuth is an extension. [1]: https://lists.wikimedia.org/pipermail/mediawiki-api-announce/2015-December/… == For user scripts and gadgets == Since user scripts and gadgets rely on the user already being logged in, you shouldn't notice any changes. == For core and extension developers == There's some other useful stuff that has already been merged, written as part of the groundwork for this project: - User::newSystemUser(), which replaces directly screwing around with accounts when an extension needs a user for logged actions. - Deprecation or removal of much of the password handling logic from the User class. In particular User::getPassword() no longer works. - CentralIdLookup, a generic mechanism for looking up a "central" ID for cross-wiki features instead of everything needing that functionality having to depend on CentralAuth (and on anything else that might implement global accounts). If you have some sort of cross-wiki login extension that isn't CentralAuth, you'll want to implement this class. If you're dealing with session data, - Don't use $_SESSION. Instead, use $request->getSession() or SessionManager::getGlobalSession() to fetch a Session object and access the data through it. Or continue to use the $request->getSessionData() and $request->setSessionData() methods. - Don't use session_id() to test if a session is active. Instead, fetch a Session object as above and call ->isPersistent(). - Don't use wfSetupSession() to make sure a session is active. Instead, fetch a Session object as above and call ->persist(). - Don't use the other PHP session_*() functions either. If you're implementing the UserLoadFromSession hook to bypass the usual cookie-based session handling (e.g. OAuth, SSLClientAuthentication, or CentralAuth's centralauthtoken), you'll now want to implement a subclass of the new SessionProvider class and add it to $wgSessionProviders. OTOH, if you're using UserLoadFromSession because you're trying to add additional security checks (e.g. SecureSessions), you'll probably want to look into the new SessionMetadata and SessionCheckInfo hooks. And if you're using UserLoadFromSession because you're doing some hack around MediaWiki's existing login form, you'll want to wait for AuthManager. The same goes for UserSetCookies. If you maintain an authentication-related extension that does a login of some sort, you'll eventually want to be implementing one of AuthManager's AuthenticationProviders. In particular, an extension implementing AuthPlugin now will want to implement a PrimaryAuthenticationProvider in the future. If you're using the hooks that mess with the login form, such as UserCreateForm or UserLoginForm, you'll likely also be wanting to implement an AuthenticationProvider of some sort. Other hooks called from LoginForm might also need attention. You can see the work-in-progress patch at https://gerrit.wikimedia.org/r/#/c/195297/. A more detailed overview of the new classes is available at https://www.mediawiki.org/wiki/User:Anomie/SessionManager_and_AuthManager. If you have more questions, feel free to ask (email works particularly well). == For apps that log in == Apps shouldn't notice any changes from SessionManager. If you do see problems related to session handling in 1.27.0-wmf.11, file a bug in Phabricator and CC me (Anomie) and Gergő (Tgr). Once AuthManager comes out, though, you'll need to use the new API action=clientlogin and action=query&meta=authmanagerinfo which will provide the information necessary to construct a fully-functional login UI. More details will be provided once I finish writing the new code ;) but be aware that there's the possibility that you'll have to redirect to a third-party website in there (e.g. if a "login with your Google account" extension happens to be installed). Do not be tempted to have your app somehow use bot passwords, that's not a supported use case for that feature. A normal (not owner-only) OAuth consumer would be fine. == For operators of third-party wikis == If you're using $wgSessionsInObjectCache = false (which was the default before SessionManager), note that that configuration is no longer supported. Make sure $wgSessionCacheType is set to something that will function well in your environment. Other than that, things should mostly just work on upgrade with both SessionManager and (in the future) AuthManager. If you use authentication- or session-related extensions that aren't deployed on WMF wikis, however, you may want to check with the maintainers of those extensions. If you're using the OAuth extension, you should also be aware that its $wgMWOAuthGrantPermissions and $wgMWOAuthGrantPermissionGroups settings are replaced by the new core settings $wgGrantPermissions and $wgGrantPermissionGroups. Please report bugs related to these changes in Phabricator, and CC me (Anomie) and Gergő (Tgr). -- Brad Jorsch (Anomie) Senior Software Engineer Wikimedia Foundation

1 0

2015-01-13 Scrum of Scrums meeting notes
by Grace Gellerman 13 Jan '16

13 Jan '16

https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-01-13 = 2015-01-13 = == Reading == === Android === *v2.1.137 beta published. Includes a new native article toolbar and lower memory usage. === Reading Infrastructure === * Nothing blocked this week. * SessionManager and bot passwords should be going out next week. == Discovery == * Working on load test for Dallas cluster * Load spikes on weekend for ES getting worse, cause not clear yet, investigating ( https://grafana.wikimedia.org/dashboard/db/elasticsearch ) ** Did some brainstorming, discovered queries generating a lot of ES calls to handle variants, with very low success rate. Will investigate removing them. * Finalizing data models for TextCat language detection library, security review next * Testing for upgrading WDQS to Blazegraph 2.0 once it's released * No blockers == Community Tech == * Working on assessment report for Community Wishlist Top 10 results: https://meta.wikimedia.org/wiki/2015_Community_Wishlist_Survey/Top_10/Statu… ** Would like feedback from Wikidata, Multimedia, Analytics, and Collaboration before publishing * Working on dead link rescuing bot - talking with Tool Labs and IA * Waiting on feedback from Kunal on Gadgets 2.0 * Wrapping up work on PageAssessments extension: https://www.mediawiki.org/wiki/Extension:PageAssessments == Infrastructure == === RelEng === *Blocking: nothing *Blocked on: nothing *Updates: ** Differential migration discussion at WikiDev16 went really well, very positive, no roadblocks placed ** Scap3 discussion at WikiDev16 also really positive, looking for more early adopters === Technical Operations === *Blocking: nothing *Blocked on: nothing *Updates: ** Started work on the new Quarter goals === Services === * moved to Node 4.2 - RESTBase, Mobile Content Service, Mathoid :* in progress: Graphoid and Citoid * working on enabling pre-generation for Mobile Content Service === Security === * Should get to Kartographer this week * Several patches to deploy this week * Schedule your reviews! === Fundraising Tech === * cleaning up after December * updating CiviCRM extensions to use new core features == Editing == === VisualEditor === *Blocking: nothing *Blocked on: nothing *Updates: ** Single Edit Tab work nearing completion. Planned to release to one wiki next week if all goes well for validation before larger rollout. ** Note the OOUI breaking release from yesterday (in -wmf.11); no known impacts. === Parsing === *Blocking: nothing *Blocked on: nothing *Updates ** Hoping to finish up (this week) puppetizing testing infrastructure on ruthenium ** Coordinating with reading and services to reduce size of HTML payload. === Multimedia === *Blocking: nothing *Blocked on: nothing *Updates: ** Christmas A/B test for cross-wiki upload tool inconclusive. Not sure what's next happening. === Language === *Blocking: nothing *Blocked on: nothing === Collaboration === * Mostly Echo stuff. Cross-wiki notification stuff is getting closer. * MediaWiki-Vagrant code for cross-wiki notifications is implemented and almost merged. This will also facilitate other local multi-wiki testing, e.g. Flow. * Flow Nuke fix merged.

1 0

Accuracy review on tool labs?
by James Salsman 13 Jan '16

13 Jan '16

John, Are you sure it makes sense to run accuracy review on wikimedia servers? Best regards, Jim

3 2

WikiDev '16 summary
by Rob Lanphier 13 Jan '16

13 Jan '16

Hi everyone, As many of you know (because you were here), we had the Wikimedia Developer Summit 2016 last week. It was wonderful to see so many of you! Rachel Farrand and Quim Gil ensured we had an excellent venue and had a wonderful opportunity to work together, and the people here had some great conversations. Valerie Aurora taught us a lot about how to run effective meetings, which greatly increased the quality of the discussions. The conversations we started here are just that: a start. We covered a lot of very important topics. Given the time and expense of bringing everyone to one place, it would be a shame if the conversations we started ended up needing to start over. Hence, it was really important to have good notes, to make it easier to pick up these conversations where we left off. For many of the sessions, the notes made their way into the Phab task associated with the meeting. The main WikiDev '16 landing page makes it a bit easier to find the notes: <https://www.mediawiki.org/wiki/WikiDev16> The session leaders were very motivated to make sure we got something out of the conversations they led, so they will be clarifying the next steps on their respective sessions. It's certainly easier than it was this time last week to find out what happened in each respective session, but there's a lot of work to do. Please help us out! Rachel sent out a survey to all of you who attended. Please fill this out! It will help us figure out if we'd like to have another one like this next year. If you're interested in real time conversation about WikiDev '16, either because you were there and want to follow up or you weren't there and you want to learn what you missed, please attend the RFC office hour in a few hours (Wednesday 22:00 UTC, 14:00 PST): <https://phabricator.wikimedia.org/E134> Rob

1 0

WikiDev '16 summary
by Rob Lanphier 13 Jan '16

13 Jan '16

Hi everyone, As many of you know (because you were here), we had the Wikimedia Developer Summit 2016 last week. It was wonderful to see so many of you! Rachel Farrand and Quim Gil ensured we had an excellent venue and had a wonderful opportunity to work together, and the people here had some great conversations. Valerie Aurora taught us a lot about how to run effective meetings, which greatly increased the quality of the discussions. The conversations we started here are just that: a start. We covered a lot of very important topics. Given the time and expense of bringing everyone to one place, it would be a shame if the conversations we started ended up needing to start over. Hence, it was really important to have good notes, to make it easier to pick up these conversations where we left off. For many of the sessions, the notes made their way into the Phab task associated with the meeting. The main WikiDev '16 landing page makes it a bit easier to find the notes: <https://www.mediawiki.org/wiki/WikiDev16> The session leaders were very motivated to make sure we got something out of the conversations they led, so they will be clarifying the next steps on their respective sessions. It's certainly easier than it was this time last week to find out what happened in each respective session, but there's a lot of work to do. Please help us out! Rachel sent out a survey to all of you who attended. Please fill this out! It will help us figure out if we'd like to have another one like this next year. If you're interested in real time conversation about WikiDev '16, either because you were there and want to follow up or you weren't there and you want to learn what you missed, please attend the RFC office hour in a few hours (Wednesday 22:00 UTC, 14:00 PST): <https://phabricator.wikimedia.org/E134> Rob

1 0

(Update) Improving categorization in Upload to Commons Android App
by Josephine Lim 13 Jan '16

13 Jan '16

Hi, I have been working on a project to improve the categorization of pictures in the Upload to Commons Android app < https://phabricator.wikimedia.org/T115101> as part of the Outreachy Dec '15 program, and I am happy to announce that Phase 1 of the project has been implemented. :) The app should now suggest nearby categories when a picture is uploaded. Feedback on this feature would be greatly appreciated, so please feel free to download the updated version of the app < https://play.google.com/store/apps/details?id=fr.free.nrw.commons> and to post feedback/issues on the GitHub page < https://github.com/nicolas-raoul/apps-android-commons/issues/new>. Please note that to use this new feature, you will need to have location tagging enabled for your camera. Thanks! -- Regards, Josephine

1 0

OOjs UI 0.15.0 Release (breaking change)
by James Forrester 13 Jan '16

13 Jan '16

Hey all, I released OOjs UI 0.15.0 today. It will be in MW from 1.27.0-wmf.11+, which will be deployed to Wikimedia production in the regular train starting on Tuesday 19 January. As there are a couple of nominal breaking changes and a deprecation, please look carefully over them to determine if they affect your code. Breaking changes since last release: - Drop Internet Explorer 8 support from JavaScript code (Ricordisamoa) We have simplified and streamlined the code to drop support for Internet Explorer 8 in the JavaScript code. This follows MediaWiki's dropping of support for executing JavaScript on Internet Explorer 8 clients, as the only significant user of the library and only cause of IE8 support. This is thus a nominal breaking change in environments supported which should not have any effect on developers or end-users in practice. As part of this, we also deprecated the add/removeCaptureEventListener methods, which existed only to support Internet Explorer 8. These will be removed in a later release. Note that the PHP code and related styling should continue to work without issue in Internet Explorer 8; if you have any issues, please raise a task in Phabricator. - Delete deprecated aliases 'picture' and 'insert' (Ed Sanders) These two old icon aliases in the core module were deprecated in v0.13.3 in November. By removing them we save some overhead for all users, as part of our work to slim down the library by de-duplicating and later removing each of the old core icons. For 'picture', use 'image' from the 'media' icon pack. For 'insert', use 'add' from core (still to be moved out). I believe these have had no Wikimedia production usage for months now. Deprecating change since last release: - Create single icon for language/translation (Ed Sanders) As part of our on-going work to slim down the library, we have merged the old 'textLanguage' icon in the 'editing-styling' icon pack, and the 'translation' icon in the 'editing-advanced' icon pack into a new icon, 'language', also in 'editing-advanced'. We have also changed the icon to now use the Chinese character '文' which means language, instead of '大' which means big. For now, 'textLanguage' and 'translation' will still work, but please switch over to 'language' before it is removed in OOjs UI v0.17.0. - Move 'redirect' icon to 'articleRedirect' and cleanup (Ed Sanders) For consistency, we have moved 'redirect' in 'editing-advanced' into the 'content' pack as 'articleRedirect', so that it is alongside the other article type icons. Again, 'redirect' will still work for now, but please switch over to 'articleRedirect' before it is removed in OOjs UI v0.17.0. Additional details are in the full change log[0]. If you have any further questions or need help dealing with deprecations, please let me know. As always, general library documentation is available on mediawiki.org[1], and on doc.wikimedia.org there is generated code-level documentation and interactive demos[2]. [0] - https://phabricator.wikimedia.org/diffusion/GOJU/browse/master/History.md [1] - https://www.mediawiki.org/wiki/OOjs_UI [2] - https://doc.wikimedia.org/oojs-ui/master/ Yours, -- James D. Forrester Lead Product Manager, Editing Wikimedia Foundation, Inc. jforrester(a)wikimedia.org | @jdforrester

1 0

Giving some attention to the wikitech.wikimedia.org wiki
by Bryan Davis 13 Jan '16

13 Jan '16

(cross-posted to labs-l and wikitech-l) I've been thinking quite a bit about Tool Labs developers over the past couple of months. Last week I was in San Francisco for the Wikimedia Developer Summit and had an opportunity to talk to a number of people about some of my ideas. One of them that got a pretty good reception was a few proposed changes to the wikitech.wikimedia.org wiki. I've started "Make wikitech more friendly for the multiple audiences it supports" phab task [0] and started adding blocker tasks for various ideas that have come up in the discussions. One is to enable a "Portal" namespace on wikitech [1] to be used to make landing pages for different audiences. Another is to add a "Tool" namespace [2] that the various Tool Labs projects could use to document their projects. A third is to disable searching "Nova resource" pages by default [3]. The wikitech wiki doesn't currently have what anyone would consider an active on-wiki community to seek consensus from on topics like this so I am reaching out to what I hope are relevant mailing lists to gather feedback. Discussion of why any of these ideas is a great or horrible idea is welcome here on list or possibly even better on the phabricator tasks themselves. Again since we don't have a strong social norm for when consensus has been reached for this wiki I'm going to arbitrarily suggest that discussion remain open until 2016-01-20 after which time I will take further steps to have the new namespaces enabled (or got back to the drawing board if the concept is rejected). [0]: https://phabricator.wikimedia.org/T123425 [1]: https://phabricator.wikimedia.org/T123427 [2]: https://phabricator.wikimedia.org/T123429 [3]: https://phabricator.wikimedia.org/T122993 Bryan -- Bryan Davis Wikimedia Foundation <bd808(a)wikimedia.org> [[m:User:BDavis_(WMF)]] Sr Software Engineer Boise, ID USA irc: bd808 v:415.839.6885 x6855

1 0

Re: [Wikitech-l] [Xmldatadumps-l] Wikipedia dumps
by gnosygnu 12 Jan '16

12 Jan '16

Basically, the xml dumps have 2 IDs: page_id and revision_id. The page_id points to the article. In this case, 14640471 is the page_id for Mars (https://en.wikipedia.org/wiki/Mars) The revision_id points to the latest revision for the article. For Mars, the latest revision_id is 699008434 which was generated on 2016-01-09 ( https://en.wikipedia.org/w/index.php?title=Mars&oldid=699008434). Note that a revision_id is generated every time a page is edited. So, to answer your question, the IDs never change. 14640471 will always point to Mars, while 699008434 points to the 2016-01-09 revision for Mars. That said, different dumps will have different revision_ids, because an article may be updated. If Mars gets updated tomorrow, and the English Wikipedia dump is generated afterwards, then that dump will list Mars with a new revision_id (something higher than 6999008434). However, that dump will still show Mars with a page_id of 1460471. You're probably better off using the page_id. Finally, you can see also reference the Wikimedia API to get a similar view to the dump: For example: https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=Mars&… Hope this helps. On Mon, Jan 11, 2016 at 5:09 AM, Luigi Assom <luigi.assom(a)gmail.com> wrote: > yep, same here! > > Also another question about consistency of _IDs in time. > I was working with an old version of wikipedia dump, and testing some > data models I built on the dumpusing as pivot a few topics. > I might have data corrupted on my side, but just to be sure: > are _IDs of article *persistent* over time, or are they subjected to > change? > > Might happen that due any fallback or merge in an article history, ID > would change? > E.g. as test article "Mars" would first point to a version _ID ="4285430" > and then changed to "14640471" > > I need to ensure _IDs will persist. > thank you! > > > *P.S. sorry for cross posting - I've replied from wrong email - could you > please delete the other message and keep only this email address? thank > you! * > > On Mon, Jan 11, 2016 at 11:05 AM, XDiscovery Team <info(a)xdiscovery.com> > wrote: > >> yep, same here! >> >> Also another question about consistency of _IDs in time. >> I was working with an old version of wikipedia dump, and testing some >> data models I built on the dump using as pivot a few topics. >> I might have data corrupted on my side, but just to be sure: >> are _IDs of article *persistent* over time, or are they subjected to >> change? >> >> Might happen that due any fallback or merge in an article history, ID >> would change? >> E.g. as test article "Mars" would first point to a version _ID ="4285430" >> and then changed to "14640471" >> >> I need to ensure _IDs will persist. >> thank you! >> >> >> On Mon, Jan 11, 2016 at 6:22 AM, Tilman Bayer <tbayer(a)wikimedia.org> >> wrote: >> >>> On Sun, Jan 10, 2016 at 4:05 PM, Bernardo Sulzbach < >>> mafagafogigante(a)gmail.com> wrote: >>> >>>> On Sun, Jan 10, 2016 at 9:55 PM, Neil Harris <neil(a)tonal.clara.co.uk> >>>> wrote: >>>> > Hello! I've noticed that no enwiki dump seems to have been generated >>>> so far >>>> > this month. Is this by design, or has there been some sort of dump >>>> failure? >>>> > Does anyone know when the next enwiki dump might happen? >>>> > >>>> >>>> I would also be interested. >>>> >>>> -- >>>> Bernardo Sulzbach >>>> >>>> _______________________________________________ >>>> Wikitech-l mailing list >>>> Wikitech-l(a)lists.wikimedia.org >>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>>> >>> >>> CCing the Xmldatadumps mailing list >>> <https://lists.wikimedia.org/mailman/listinfo/xmldatadumps-l>, where >>> someone has already posted >>> <https://lists.wikimedia.org/pipermail/xmldatadumps-l/2016-January/001214.ht…> about >>> what might be the same issue. >>> >>> -- >>> Tilman Bayer >>> Senior Analyst >>> Wikimedia Foundation >>> IRC (Freenode): HaeB >>> >>> _______________________________________________ >>> Xmldatadumps-l mailing list >>> Xmldatadumps-l(a)lists.wikimedia.org >>> https://lists.wikimedia.org/mailman/listinfo/xmldatadumps-l >>> >>> >> >> >> -- >> *Luigi Assom* >> Founder & CEO @ XDiscovery - Crazy on Human Knowledge >> *Corporate* >> www.xdiscovery.com >> *Mobile App for knowledge Discovery* >> APP STORE <http://tiny.cc/LearnDiscoveryApp> | PR >> <http://tiny.cc/app_Mindmap_Wikipedia> | WEB >> <http://www.learndiscovery.com/> >> >> T +39 349 3033334 | +1 415 707 9684 >> > > > > -- > *Luigi Assom* > > T +39 349 3033334 | +1 415 707 9684 > Skype oggigigi > > _______________________________________________ > Xmldatadumps-l mailing list > Xmldatadumps-l(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/xmldatadumps-l > >

3 2

Re: [Wikitech-l] Wikipedia dumps
by MZMcBride 12 Jan '16

12 Jan '16

Bartosz Dziewoński wrote: >On 2016-01-11 22:06, gnosygnu wrote: >> So, to answer your question, the IDs never change. 14640471 will always >> point to Mars, while 699008434 points to the 2016-01-09 revision for >>Mars. > >While it's unlikely/rare, I think the page id can change when a page is >deleted and re-created, and maybe some other cases. MediaWiki tries to >keep it constant (for example, I think it's preserved after deletion and >undeletion), but it's not always possible. It looks like <https://phabricator.wikimedia.org/T28123> was just fixed, so page IDs changing should now hopefully be rarer. MZMcBride

1 0

Canceled: January Lightning Talks
by Megan Neisler 12 Jan '16

12 Jan '16

Hi all, The Lightning Talks have been canceled for this month. Please see https://www.mediawiki.org/wiki/Lightning_Talks to view recordings of past Lightning Talks and add your name to the Ideas/Nominations section if you are interested in presenting at the next one. An email will be sent 2 weeks before the next scheduled Lightning Talks. Thanks! Megan Neisler, Kevin Leduc and Rachel Farrand -- Megan Neisler Project Coordinator- Engineering Wikimedia Foundation mneisler(a)wikimedia.org <mguss(a)wikimedia.org>

1 0

XML dumps
by Lars Aronsson 11 Jan '16

11 Jan '16

The XML database dumps are missing all through May, apparently because of a memory leak that is being worked on, as described here, https://phabricator.wikimedia.org/T98585 However, that information doesn't reach the person who wants to download a fresh dump and looks here, http://dumps.wikimedia.org/backup-index.html I think it should be possible to make a regular schedule for when these dumps should be produced, e.g. once each month or once every second month, and treat any delay as a bug. The process to produce them has been halted by errors many times in the past, and even when it runs as intended the interval is unpredictable. Now when there is a bug, all dumps are halted, i.e. much delayed. For a user of the dumps, this is extremely frustrating. With proper release management, it should be possible to run the old version of the process until the new version has been tested, first on some smaller wikis, and gradually on the larger ones. -- Lars Aronsson (lars(a)aronsson.se) Aronsson Datateknik - http://aronsson.se

7 7

New tutorial for interactive graphics on Wiki
by Yuri Astrakhan 11 Jan '16

11 Jan '16

I just finished writing a tutorial on how to build interactive Vega graphs for Wikipedia. And yes, we could build video games this way too :) https://www.mediawiki.org/wiki/Extension:Graph/Interactive_Graph_Tutorial

6 10

Updating the MediaWiki Debian package
by Legoktm 10 Jan '16

10 Jan '16

Hi, Over the past few months, I've been working with LFaraone, Faidon, and Moritz on updating the super old 1.19.x Debian package of MediaWiki to use a more modern version (currently 1.25.x) and just generally improve the quality of it. (Yes, it uses MySQL by default, not postgres!) It's currently waiting in the "new" queue[1], but if you'd like to test it out, I've uploaded the debs at [2]. If you find any bugs or have feature requests, you can let me know or file a request in the MediaWiki-Debian[3] Phabricator project. The debian/ files used to create the package can be found in Gerrit in the mediawiki/debian repository[4]. [1] https://ftp-master.debian.org/new.html [2] https://people.wikimedia.org/~legoktm/debian/ [3] https://phabricator.wikimedia.org/tag/mediawiki-debian/ [4] https://gerrit.wikimedia.org/r/#/projects/mediawiki/debian,dashboards/defau… -- Legoktm

1 0

Fwd: [Wikimedia-l] WMF Scholarship Deadline for Wikimania is Today
by Quim Gil 09 Jan '16

09 Jan '16

---------- Forwarded message ---------- From: "Ellie Young" <eyoung(a)wikimedia.org> Date: Jan 9, 2016 12:56 PM Subject: [Wikimedia-l] WMF Scholarship Deadline for Wikimania is Today To: "Wikimania general list (open subscription)" < wikimania-l(a)lists.wikimedia.org>, "Wikimedia Mailing List" < wikimedia-l(a)lists.wikimedia.org> Cc: Reminder: Scholarship applications for Wikimania 2016 which is being held in Esino Lario, Italy on June 22–27, 2016 are now being accepted. Applications are open until Saturday, January 09 2016 23:59 UTC. Applicants will be able to apply for a partial or full scholarship. A full scholarship will cover the cost of an individual's round-trip travel, shared accommodation, and conference registration fees as arranged by the Wikimedia Foundation. A partial scholarship will cover conference registration fees and shared accommodation. Applicants will be rated using a pre-determined selection process and selection criteria established by the Scholarship Committee and the Wikimedia Foundation, who will determine which applications are successful. To learn more about Wikimania 2016 scholarships, please visit: https://wikimania2016.wikimedia.org/wiki/Scholarships To apply for a scholarship, fill out the multi-language application form on: https://scholarships.wikimedia.org/apply It is highly recommended that applicants review all the material on the Scholarships page and the associated FAQ ( https://wikimania2016.wikimedia.org/wiki/Scholarships/FAQ ) before submitting an application. If you have any questions, please contact: wikimania-scholarships at wikimedia.org <wikimania-scholarships(a)wikimedia.org> or leave a message at: https://wikimania2016.wikimedia.org/wiki/Talk:Scholarships -- Ellie Young Events Manager Wikimedia Foundation eyoung(a)wikimedia.org _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe>

1 0

IPv6 block range size
by Bináris 09 Jan '16

09 Jan '16

Hi, I cannot find a piece of information about $subject. As help page <https://www.mediawiki.org/wiki/Help:Range_blocks/IPv6> was moved from Meta to MediaWiki, it gives now a general talk instead of actual information. It says: "Like IPv4, IPv6 rangeblocks are limited by $wgBlockCIDRLimit <https://www.mediawiki.org/wiki/Manual:$wgBlockCIDRLimit>, which by default allows rangeblocks of up to /64 in size (before MediaWiki 1.20wmf5, which changes the default to /19)." All right, but what is the actual value for WMF wikis, and where is this information available? -- Bináris

3 6

Google code-in progress statistics; opportunity to join
by Federico Leva (Nemo) 08 Jan '16

08 Jan '16

In addition to https://www.mediawiki.org/wiki/File:Wikimedia_at_Google_Code-in_2015.png, which shows we've completed more tasks in the first half of the contest than in the entire last year, we have some nice statistics about Wikimedia compared to other orgs. The best news for me is that not only we involved many students with easy beginner tasks, but they go farther from there: we're the third org with most students with 3+ tasks completed. You can still become a mentor, or add new tasks if you're already one: https://www.mediawiki.org/wiki/Google_Code-in_2015#Mentors.27_corner If you don't know what tasks to mentor, I just added ~50 suitable reports you can pick from (mostly MediaWiki, so any MediaWiki dev can help): https://phabricator.wikimedia.org/tag/google-code-in-2015/ The more mentors we have, the less worries about making the 36 hours deadline for reviews. :-) Nemo -------- Messaggio inoltrato -------- Il giorno giovedì 7 gennaio 2016 01:42:11 UTC+1, Robert Spier ha scritto: Hi Org Admins and Mentors, Here are some interesting statistics about task completion counts. Thanks to Freso for suggesting some metrics. Thanks to Google Sheets for making the analysis easy. As of 1/6/2016 15:47:58 TZ=America/Los_Angeles #students >= 1 task completed #students >= 3 tasks completed #tasks completed by 1st place student #tasks completed by 10th place student Apertium 20 10 22 3 Copyleft Games 61 5 7 1 Drupal 23 4 11 1 FOSSASIA 286 87 40 21 Haiku 43 10 15 3 KDE 33 11 19 5 MetaBrainz Foundation 70 11 17 3 OpenMRS 48 9 16 2 RTEMS Project 47 11 30 3 Sugar Labs 98 17 38 4 Sustainable Computing Research Group ( SCoRe ) 32 7 14 2 Systers, an Anita Borg Institute Community 23 6 13 2 Ubuntu 194 35 26 6 Wikimedia 91 18 28 8 -R

3 2

Part 2: The right way to inject JavaScript?
by Daniel Barrett 08 Jan '16

08 Jan '16

Last week, I asked the right way to inject raw JavaScript so that "mw" and "jQuery" were defined. I was helpfully pointed to ResourceLoader::makeInlineScript(), which wraps the JS in the appropriate magic: https://lists.wikimedia.org/pipermail/wikitech-l/2015-December/084408.html Now, what is the right way to include a remote JavaScript file? If I simply use OutputPage::addScript() like this: $myOutputPage->addScript('<script src="http://remote.com/myfile.js"></script>') it fails because the remote JavaScript file references the "jQuery" object like this: function ($) { //... code here }(jQuery)); I get "ReferenceError: jQuery is not defined" on the last line. I guess the remote script is getting evaluated before ResourceLoader brings in jquery.js...? Thanks very much for any advice. DanB

2 1

Trouble while setting up mediawiki-vagrant
by Devang Gaur 08 Jan '16

08 Jan '16

Hi, I've been trying to set up mediawiki-vagrant on my machine.But Vagrant crashes everytime. It says that vagrant home directory(address) has spaces, even though I've installed C:\HashiCorp\Vagrant . and cloned medaiwiki-vagrant at C:/myMediawiki/vagrant. Need help.

3 4

Raw notes from Wikimedia Developer Summit 2016
by Joel Aufrecht 06 Jan '16

06 Jan '16

The index of notes for the Wikimedia Developer Summit 2016 <https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit_2016> is located here: https://etherpad.wikimedia.org/p/WikiDev16-AllNotes. If you are aware of notes that aren't indexed here, please add them. Because Etherpad is not the preferred permanent medium for Wikimedia notes, please consider migrating your notes to mediawiki.org and linking them from the session calendar (first link). Thanks, *--Joel Aufrecht* Team Practices Group Wikimedia Foundation

1 0

Knight Foundation grant for search and discovery
by Wes Moran 06 Jan '16

06 Jan '16

Hello everyone, I’m happy to announce that the John S. and James L. Knight Foundation has awarded an exploratory grant of $250,000 to the Wikimedia Foundation’s Discovery department [1], in order to conduct research and prototyping to improve how people discover and engage with information on Wikipedia and Wikimedia projects. The Discovery team has begun six months of research and prototyping, with the goal of building better experiences to help people discover knowledge. You can learn more about the team’s work here <http://blog.wikimedia.org/2015/12/23/search-and-discovery-on-wikipedia/>. Our deliverables include: - User testing and research on current user flows to understand the search and discovery experience - Creation and maintenance of a dashboard of core metrics to use in product development - Research on search relevancy and the possibility of integrating open data sources - Open discussion with the Wikimedia community of volunteer editors - Creation of sample prototypes to showcase discovery possibilities The need to improve our search experience has long been recognized across the Wikimedia projects. We need better ways to help everyone discover the most relevant, reliable information on Wikipedia and its sister projects. For example, while people can search within one project (like Wikipedia or Wikimedia Commons), they can’t easily search across the different projects. Some people still receive zero results if they search and do not include the right words in a search. There are open data sources that have the potential to improve how people find information, and that should be explored. We look forward to discussing these projects with communities and anyone with an interest. You can collaborate with the Discovery department in the following ways: - Subscribe <https://lists.wikimedia.org/mailman/listinfo/discovery> to the Discovery team’s public mailing list - Read about these projects and others at the MediaWiki Discovery <https://www.mediawiki.org/wiki/Wikimedia_Discovery> page - Reach out to the Discovery team on their IRC channel: #wikimedia-discovery on Freenode <https://freenode.net/>. A press release and blog post will follow shortly, and more information in the form of an FAQ has been posted here [2]. Wes Moran, VP of Product User: WMoran_(WMF) [1]: https://www.mediawiki.org/wiki/Wikimedia_Discovery [2]: https://www.mediawiki.org/wiki/Wikimedia_Discovery/KnightFAQ

1 0

[INFO] wfMsg*() was removed
by Florian Schmidt 06 Jan '16

06 Jan '16

Hello readers of this list :) tl;dr MediaWiki's wfMsg*() functions were removed in MediaWiki 1.27. Long version: Maybe someone has already seen the work on the wfMsg*() deprecation task: https://phabricator.wikimedia.org/T70750 <https://phabricator.wikimedia.org/T70750> A little bit of background: MediaWiki provides different functions to get a localised message string, the one you normally choose is wfMessage, which creates a Message object. However, there are other global functions (including wfMsg(), wfMsgForContent(), wfMsgHtml() and so on), too, which was deprecated in MediaWiki 1.18 (with deprecating notification in 1.21) in favour of wfMessage. Unfortunately, a lot of (maybe unmaintained) extensions still used the old deprecated functions to get a localised message. After a huge amount of changes to these extensions (tracked in the linked task), we now hope, that all usages of these functions are replaced by it's modern wfMessage-counterpart, at least we did our best to find affected extensions :) Now, the time has come, that the change to mediawiki/core, which removes the old deprecated functions[1], was merged. This notification is mostly for people, who still use these functions, if you're sure you don't, you can stop reading here :P If you're a maintainer of an extension, please make sure, that you don't use these wfMsg*() functions anymore (if your extension is hosted in Wikimedia Gerrit, you probably mentioned a change named "Remove wfMsg* calls", so we already did the work for you. If not, please take some minutes to find out, how you can migrate to the new wfMessage function to keep compatibility with newer MediaWiki releases. If you want to replace your usage of wfMsg* functions your best friend (mostly) is the documentation page[2], which describes appropriate replacements with the actual message functions. However, it's possible, that your case of usage isn't mentioned there, and if so, you could first try to find a better approach using the Message object (returned by wfMessage()), which is documented on doc.wikimedia.org <http://doc.wikimedia.org> [3], or, if you really don't know, what to do, ask in #wikimedia-dev or on this mailing list :) I think you'll get help as soon as possible. I hope this answers all questions, if not, feel free to answer this e-mail :) Best, Florian [1] https://gerrit.wikimedia.org/r/#/c/262333 <https://gerrit.wikimedia.org/r/#/c/262333> [2] https://www.mediawiki.org/wiki/Manual:Messages_API#Help_ with_replacing_deprecated_wfMsg.2A_functions <https://www.mediawiki.org/wiki/Manual:Messages_API#Help_with_replacing_depr…> [3] https://doc.wikimedia.org/mediawiki-core/master/php/ html/classMessage.html# <https://doc.wikimedia.org/mediawiki-core/master/php/html/classMessage.html>

1 0

Fwd: [Wikimedia-l] Wikimania '16 Scholarship & Submission Deadlines are Approaching!
by Quim Gil 05 Jan '16

05 Jan '16

fyi ---------- Forwarded message ---------- From: Ellie Young <eyoung(a)wikimedia.org> Date: Mon, Jan 4, 2016 at 3:05 PM Subject: [Wikimedia-l] Wikimania '16 Scholarship & Submission Deadlines are Approaching! To: "Wikimania general list (open subscription)" < wikimania-l(a)lists.wikimedia.org>, Wikimedia Mailing List < wikimedia-l(a)lists.wikimedia.org> Hi all, Two important reminders concerning Wikimania 2016, which will be held in Esino Lario, Italy on June 22–27, 2016: The Submission deadline has been extended by the program committee to January 17th. See: https://wikimania2016.wikimedia.org/wiki/Submissions The deadline for applications for the WMF Scholarship program is approaching! Applications are open until Saturday, January 09 2016 23:59 UTC. Applicants will be able to apply for a partial or full scholarship. A full scholarship will cover the cost of an individual's round-trip travel, shared accommodation, and conference registration fees as arranged by the Wikimedia Foundation. A partial scholarship will cover conference registration fees and shared accommodation. To learn more about Wikimania 2016 scholarships, please visit: https://wikimania2016.wikimedia.org/wiki/Scholarships To apply for a scholarship, fill out the multi-language application form on: https://scholarships.wikimedia.org/apply It is highly recommended that applicants review all the material on the Scholarships page and the associated FAQ ( https://wikimania2016.wikimedia.org/wiki/Scholarships/FAQ ) before submitting an application. If you have any questions, please contact: wikimania-scholarships at wikimedia.org <wikimania-scholarships(a)wikimedia.org> or leave a message at: https://wikimania2016.wikimedia.org/wiki/Talk:Scholarships Ellie Young Events Manager Wikimedia Foundation _______________________________________________ Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines New messages to: Wikimedia-l(a)lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, <mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe> -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Randy Shoup on architecture experiences from Google and Ebay
by Gabriel Wicke 04 Jan '16

04 Jan '16

Many of you have already seen this when it came out, but I think it's worth re-posting Randy Shoup's summary of architecture experiences from his time at Google and Ebay: http://www.infoq.com/presentations/service-arch-scale-google-ebay For those interested in a quick summary of his key points, Todd Hoff has one at http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay… . Gabriel

1 0

Setting up Mediawiki-Vagrant for debugging
by Techman224 01 Jan '16

01 Jan '16

I am trying to link my vagrant instance with my php debugger, PhpStorm. I tried following the instructions at https://www.mediawiki.org/wiki/MediaWiki-Vagrant#Provisioning <https://www.mediawiki.org/wiki/MediaWiki-Vagrant#Provisioning> and https://www.mediawiki.org/wiki/MediaWiki-Vagrant/Advanced_usage#MediaWiki_d… <https://www.mediawiki.org/wiki/MediaWiki-Vagrant/Advanced_usage#MediaWiki_d…>, and installed XDebug in my chrome browser, but the connection isn’t happening. My debugger keeps saying “Waiting for incoming connection with ide key ‘#####’. Is there something missing here? Techman224

2 3

Phabricator monthly statistics - 2015-12
by communitymetrics＠wikimedia.org 01 Jan '16

01 Jan '16

Hi Community Metrics team, This is your automatic monthly Phabricator statistics mail. Accounts created in (2015-12): 358 Active users (any activity) in (2015-12): 882 Task authors in (2015-12): 478 Users who have closed tasks in (2015-12): 249 Projects which had at least one task moved from one column to another on their workboard in (2015-12): 177 Tasks created in (2015-12): 2791 Tasks closed in (2015-12): 2301 Open and stalled tasks in total: 27736 Median age in days of open tasks by priority: Unbreak now: 13 Needs Triage: 135 High: 190 Normal: 336 Low: 693 Lowest: 536 (How long tasks have been open, not how long they have had that priority) TODO: Numbers which refer to closed tasks might not be correct, as described in https://phabricator.wikimedia.org/T1003 . Yours sincerely, Fab Rick Aytor (via community_metrics.sh on iridium at Fri Jan 1 00:00:08 UTC 2016)

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l January 2016