Wikitech-l September 2014

wikitech-l@lists.wikimedia.org

129 participants
127 discussions

Open issues for next MediaWiki maintenance releases
by Markus Glaser 17 Sep '14

17 Sep '14

Hello everyone, next week on September, 24th, there will be another set of security and maintenance releases for MediaWiki. There are still some unresolved bugs and changes that are wating to be +2'ed. So if you feel like improving MediaWiki tarball releases in the upcoming days, you could have a look at these lists: Open bugs for MW 1.23: https://bugzilla.wikimedia.org/buglist.cgi?action=wrap&list_id=331203&produ… Fixes that need to be backported: https://bugzilla.wikimedia.org/buglist.cgi?f1=flagtypes.name&list_id=331206… Changes in Gerrit that are waiting to be merged: https://gerrit.wikimedia.org/r/#/q/status:open+project:mediawiki/core+branc… Thanks for your help! Markus (mglaser) Wiki Release Team

2 2

Maintainers (was Re: Who maintains ConfirmEdit core part?)
by Quim Gil 17 Sep '14

17 Sep '14

On Tuesday, September 16, 2014, Jon Robson <jdlrobson(a)gmail.com> wrote: > > In the past when I've needed changes merged in this codebase I've had > to actively search out people who feel comfortable reviewing it and > +2ing it. (snip) > I personally think the idea of a code maintainer is outdated, Then let's call them 'people who feel comfortable reviewing and +2ing' patches in a repository. :) Or first points of contact that can help you adding reviewers. Knowing who might be good reviewers for a patch is not simple even for those developers working full time at the Foundation. Imagine the situation of the rest of contributors. > we should all be maintaining the code in the MediaWiki world. Nice thought, but still not helpful for someone like Florian wondering who should review his patch. Looking at https://www.mediawiki.org/wiki/Developers/Maintainers and looking at http://phabricator.wikimedia.org/T340 ( Start the process of expanding the arch committee), one idea could be to organize all those components in areas, nominating "meta-maintainers" for each area. This way, if a specific component doesn't have any maintainers assigned, at least someone like Florian could check with the related meta-maintainer. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

3 2

Dynamically generating files from Scribunto
by Jackmcbarn 17 Sep '14

17 Sep '14

I'm interested in adding the ability to generate files via Scribunto. The first major decision that we need to make is how we'd use these files from a wiki page. I talked with TimStarling and Carmela on IRC about this, and here's some of the ideas we came up with: 1. [[File:Module:Foo|bar=baz|width=200px]] - Module:Foo gets called to generate the file 2. [[DynamicFile:Foo|bar=baz|width=200px]] - Module:DynamicFile/Foo gets called to generate the file 3. [[File:Any file that doesn't exist.svg|bar=baz|width=200px]] - Module:FileHandlers/Any file that doesn't exist.svg gets called to generate the file 4. {{#invokefile:Foo|main|bar=baz}} Module:Foo's main function gets called to generate the file 5. No use directly from wikitext. A Lua function mw.makeFile() would take file content as a parameter and emit (stripped) HTML to display it. Advantages: 1. Works everywhere that normal files work without any modifications. 2. As #1, but not quite everywhere. No clashes with existing files. 3. Works everywhere, and no clashes. 4. Consistency with {{#invoke:}} and doesn't cause confusion with "real" files. 5. Simple. Disadvantages: 1. Clashes with existing files already named File:Module:Foo. 2. Adding a second namespace that works like File is pretty much impossible. 3. Can't think of any right now. 4. Incompatible with things that expect filenames, which is a lot of on-wiki templates, and things like Extension:ImageMap 5. Wikis would probably build a wrapper module around it, making it equivalent to #4 At the moment, I'm leaning towards option 3. Are there any other thoughts on these, or any additional ideas? Jackmcbarn

4 3

Re: [Wikitech-l] DB performance review: Wikibase Usage Tracking
by Nikolas Everett 17 Sep '14

17 Sep '14

I can't access those links! On Tue, Sep 16, 2014 at 11:14 AM, Daniel Kinzler < daniel.kinzler(a)wikimedia.de> wrote: > Hi all! > > The Wikibase team would like to allow data from any item to be used on any > client page. To do this, we need to track which item is being used where, > so we > can purge the appropriate pages when the item changes. We would like to > have > people with database experience to look at our proposal and let us know > about > any concerns, especially wrt performance. > > Here you find a proposal for two database tables for tracking the usage of > entities across wikis: > > > https://gerrit.wikimedia.org/r/#/c/158078/9/usagetracking/includes/Usage/Sq… > > > https://gerrit.wikimedia.org/r/#/c/158078/9/subscription/includes/Subscript… > > > The "entity_usage" table would be on every client, recording wich entity > is used > on which page (kind of like the iwlinks table). The "entity_per_client" > table > would be on the repo, and track which wiki ("client") is interested in > changes > to which entity. > > Please have a look and let me know if you have any questions or > suggestions, > especially with regards to the following use cases: > > The following would happpen when editing/re-parsing a page on a client wiki > (e.g. wikipedia): > * get all entities used on a given page from entity_usage > * delete rows based on a page id and a list of entity ids from entity_usage > * insert rows for a page / entity pair into entity_usage > * queriy rows for a set of entities from entity_usage (with no page id > specified). > * add rows for a set of (newly used) entites to the entity_per_client table > * remove rows for a set of (no longer used) entites from the > entity_per_client table > > The following would happen when dispatching a change from wikibase: > * looking up interested wikis for a list of entities from the > entity_per_client > table. > * (notification via the job queue) > * looking up pages to be purged/updated based on a list of entity ids (and > possibly an aspect id) in the entity_usage table. > > -- daniel > > -- > Daniel Kinzler > Senior Software Developer > > Wikimedia Deutschland > Gesellschaft zur Förderung Freien Wissens e.V. >

1 0

Update: Standardizing icons across projects
by Tomasz Finc 17 Sep '14

17 Sep '14

Several front end engineers, designers, and others got together again to update on their progress to standardize icons across projects today. This was a follow to the previous conversation on 8/27 [1]. Big take aways: * Monte iterating and almost completing his SVG->Font python scripts * Trevor & Bartosz finalizing an npm module for customizing SVG generation * Jon needing additional support from Sam to move forward on mw ui icon markup Notes from the discussion can be found on etherpad [2] Follow up items: * Finish up SVG2FONT2SVG script (hopefully done in a week) (Monte) ** Create manifest for padding and other small options (Trevor) * Review Trevor's SVG/PNG generation (Everyone present once its out) * Followup with Sam for standard icon html mark-up (Matt) * Schedule team discussion follow up (Tomasz) Please update as necessary if you attended and I've forgotten or misrepresented anything. thanks all --tomasz [1] - https://lists.wikimedia.org/pipermail/mobile-l/2014-August/007922.html [2] - http://etherpad.wikimedia.org/p/IconStandardization

1 0

Best method to flag wiki pages based on rendered HTML
by Gergo Tisza 16 Sep '14

16 Sep '14

Hi, I would like to flag a large number of wiki pages based on whether their HTML passes a certain test, so that failing pages can be easily listed and counted. The flags should adapt when pages are created or modified. (The specific use case is collecting file pages which do not have machine-readable author and license information embedded.) I have been thinking of adding such pages to a maintenance category from a parser hook (the test logic is already part of the imageinfo/extmetadata API and would be easy to reuse), is that a good way to do this? If so, what's the best way to achieve it? Is it OK to just add categories as needed via $parser->getOutput()->addCategory() or can that mess up internal state such as the categorylinks table? Alternatively, the Cite extension just parses and appends a message to the end of the text on ParserBeforeTidy when it encounters an error, and the message contains wikitext to include a category. That seems like a clever way of maintaining flexibility so it is easy to change the category name or add extra text for a call to action without any need for a code change. Is that approach safe/cheap? thanks Gergő

2 2

Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
by Tilman Bayer 16 Sep '14

16 Sep '14

Minutes and slides from the recent quarterly review of the Foundation's Language Engineering team are available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote: > > Hi folks, > > to increase accountability and create more opportunities for course > corrections and resourcing adjustments as necessary, Sue's asked me > and Howie Fung to set up a quarterly project evaluation process, > starting with our highest priority initiatives. These are, according > to Sue's narrowing focus recommendations which were approved by the > Board [1]: > > - Visual Editor > - Mobile (mobile contributions + Wikipedia Zero) > - Editor Engagement (also known as the E2 and E3 teams) > - Funds Dissemination Committe and expanded grant-making capacity > > I'm proposing the following initial schedule: > > January: > - Editor Engagement Experiments > > February: > - Visual Editor > - Mobile (Contribs + Zero) > > March: > - Editor Engagement Features (Echo, Flow projects) > - Funds Dissemination Committee > > We’ll try doing this on the same day or adjacent to the monthly > metrics meetings [2], since the team(s) will give a presentation on > their recent progress, which will help set some context that would > otherwise need to be covered in the quarterly review itself. This will > also create open opportunities for feedback and questions. > > My goal is to do this in a manner where even though the quarterly > review meetings themselves are internal, the outcomes are captured as > meeting minutes and shared publicly, which is why I'm starting this > discussion on a public list as well. I've created a wiki page here > which we can use to discuss the concept further: > > https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r… > > The internal review will, at minimum, include: > > Sue Gardner > myself > Howie Fung > Team members and relevant director(s) > Designated minute-taker > > So for example, for Visual Editor, the review team would be the Visual > Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. > > I imagine the structure of the review roughly as follows, with a > duration of about 2 1/2 hours divided into 25-30 minute blocks: > > - Brief team intro and recap of team's activities through the quarter, > compared with goals > - Drill into goals and targets: Did we achieve what we said we would? > - Review of challenges, blockers and successes > - Discussion of proposed changes (e.g. resourcing, targets) and other > action items > - Buffer time, debriefing > > Once again, the primary purpose of these reviews is to create improved > structures for internal accountability, escalation points in cases > where serious changes are necessary, and transparency to the world. > > In addition to these priority initiatives, my recommendation would be > to conduct quarterly reviews for any activity that requires more than > a set amount of resources (people/dollars). These additional reviews > may however be conducted in a more lightweight manner and internally > to the departments. We’re slowly getting into that habit in > engineering. > > As we pilot this process, the format of the high priority reviews can > help inform and support reviews across the organization. > > Feedback and questions are appreciated. > > All best, > Erik > > [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus > [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Wikimedia-l mailing list > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB

1 0

Who maintains ConfirmEdit core part?
by Florian Schmidt 16 Sep '14

16 Sep '14

Hello together! I have a short question: There is a changeset in gerrit[1] for ConfirmEdit, which enables to show a Captcha directly after the Edit click, instead of a first Save click (see Commit Msg and the Bug report[2] for more details). This change was uploaded on May 30, 2014, unhappily without any review until now. The list of maintainers for Wikimedia extensions [3] lists only Emufarmers as a maintainer. Unhappily he/she only maintains the FancyCaptcha module of ConfirmEdit (iirc the irc talk). So, my question: Ist here anyone who maintains the core part of ConfirmEdit? Is there anyone who can/want give the change a review? Thanks in advance! [1] https://gerrit.wikimedia.org/r/136323 [2] https://bugzilla.wikimedia.org/show_bug.cgi?id=19648 [3] https://www.mediawiki.org/wiki/Developers/Maintainers Freundliche Grüße / Kind regards Florian

2 1

User Group Proposal: MediaWiki Cooperation
by Markus Glaser 16 Sep '14

16 Sep '14

Dear Wikitech-l Readers, spreading open knowledge is not just about content, but also about tools. That's the reason we provide MediaWiki as an open source product. Fortunately, MediaWiki is used widely outside the Wikimedia world, so the mission is fulfilled, right? Well, not quite... Third party users of MediaWiki do have very specific needs that are naturally not in the primary focus when running Wikimedia sites. Over the past few weeks, a group of people has been working on a proposal for a User Group that tackles exactly these issues: "We will advocate the needs of all users of MediaWiki. Our primary focus will be those who use MediaWiki outside the Wikimedia Foundation (WMF). We are a group of MediaWiki enthusiasts who care about the development and evolution of the MediaWiki as a tool for everyone." [1] We have gathered quite a number of supporters and members. There were some meetings where we discussed the mission of this group and its purpose. Now we are ready to take the next step and apply for official recognition. Before we actually start, we are seeking your feedback. Any comments are welcome, here on the list and on the discussion page of the group [2]. Cheers, Markus (mglaser) and Mark (hexmode) [1] https://www.mediawiki.org/wiki/Groups/Proposals/MediaWiki_Cooperation [2] https://www.mediawiki.org/wiki/Talk:Groups/Proposals/MediaWiki_Cooperation

1 0

Jeff Hobson joins the Wikipedia Zero Engineering Team
by Tomasz Finc 16 Sep '14

16 Sep '14

Greetings All, I'm very happy to welcome Jeff Hobson to the Wikimedia Foundation and the Wikipedia Zero Engineering team. He'll be joining Yuri, Adam, and Dan Foy to continue the great work that the Zero team has been working on and focusing on building our carrier portal first. Today will be his first day. Jeff will be working remotely from Blacksburg, VA, but hopes to eventually venture out to the west coast to join us locally. Jeff has been building websites for over 12 of his 22 years and practically weeped tears of joy when HTML5 was first released. Aside from web development, he's dabbled in Parallel Computing, AI, and even some robotics. But the ever-changing nature of web development has kept him coming back and he's excited to join WMF to work with all the challenges mobile brings. In his free time Jeff enjoys skiing, riding roller coasters, speed running, and playing the drums. Please join me in welcoming Jeff --tomasz

1 0

JuryTool
by Oscar Costero 15 Sep '14

15 Sep '14

Hi all, We're having a little problem to manage the jury tool app and I was wondering if someone else besides David Narvaez have the know-how to help us? This problem is not related with WLM, we're working with another contest. Kind Regards, -- Oscar Costero (+58) 0412-9161792 Presidente | Wikimedia Venezuela J-40129321-2 http://wikimedia.org.ve <http://wikimedia.org.ve/index.php/P%C3%A1gina_principal> | @wikimedia_ve <http://twitter.com/wikimedia_ve>

2 1

Re: [Wikitech-l] want to pair program more often?
by Jaime Schatz 15 Sep '14

15 Sep '14

Sumana, this is awesome! o/ In case you're keeping track, I'm at the n00b end of the experience spectrum. :D

1 0

Upstream gerrit fixed: Bug 35534 - Free-form tagging
by Federico Leva (Nemo) 15 Sep '14

15 Sep '14

!!! https://bugzilla.wikimedia.org/show_bug.cgi?id=35534#c19 Nemo

5 5

Re: [Wikitech-l] [Wikitech-ambassadors] Roadmap and deployment highlights - week of Sept 15th
by Greg Grossmeier 15 Sep '14

15 Sep '14

cc'ing wikitech-l for your questions to get answers direct from the source instead of me playing telephone :) <quote name="billinghurst" date="2014-09-16" time="00:53:18 +1000"> > Thanks Greg. There was nothing mentioned in today's Tech news, so I have > just appended some information to enWS. At the WSes we load some big > transcluded pages and I have set a little challenge for users to make some > comparisons. Are you going to be running data comparisons? Is this > something that user (anecdotal) semi-quantitative data is of value? If > yes, to the last point, what sort of direct data comparison might be of > value? > > Regards, Billinghurst > > On Fri, 12 Sep 2014 17:42:14 -0700, Greg Grossmeier <greg(a)wikimedia.org> > wrote: > > <quote name="billinghurst" date="2014-09-13" time="09:38:47 +1000"> > >> > * There will be a method to opt-in to using the new HHVM-powered > >> > backend > >> > for all WMF wikis. It'll be implemented via a BetaFeature to make > it > >> > as easy as possible for people to participate. There should be no > >> > noticeable negative impact and hopefully only positive impacts. > >> > > >> Greg, > >> > >> The last dot point. Is it there against Thursday 18th? Is it to mark it > >> against another point? The HHVM component sits against next month on > the > >> deployment page, so the uncertainty. > > > > To answer all of your questions I'll try to rephrase things in a > > different manner and add some more details. It might be a little too > > detailed at first, I'll try to tl;dr at the end: > > > > HHVM is a virtual machine for PHP which improves the performance of the > > servers by... a lot. We're a little shy of sharing predictions of how > > improved the performance will be, but it'll be worth the effort. > > > > Thus far HHVM has been deployed to the Beta Cluster, which is our > > testing environment based in WMF Labs. It has been running there for > > about a month so far. > > > > Along side that we have a few servers in the production cluster that > > have been migrated to HHVM. These servers are only sent user traffic if > > and only if the user sets a cookie in their browser. > > > > In addition to that there are safe-guards in place where if a request to > > an HHVM server fails, our Varnish layer will take note of that and > > resend requests to a normal (non-HHVM) server. > > > > The confusion you have regarding HHVM being in the "Next Month" section > > is because this work is on-going. There were more bullets in that list > > initially and we will work through them as we get closer to the full > > rollout/completion. > > > > What is happening next week is this: There will be a new Beta Feature > > available to all users that will allow them to opt-in to using the HHVM > > servers by default (the Beta Feature simply sets the cookie I mentioned > > above). That will happen on Thursday after the normal MediaWiki deploy. > > > > If things go well, users who opt-in will have a better experience: pages > > should load faster and edits should save faster, for example. > > > > If things don't go well, users who opt-in shouldn't see anything worse > > than normal (given that safe-guard I mentioned above in the Varnish > > layer). > > > > tl;dr: > > > > HHVM, an improved (faster) php server, is in the process of being tested > > at scale and rolled out. We are still at the beginning stages but we > > feel comfortable enough with the stability we've gained in the Beta > > Cluster to open it up to more users through a Beta Feature. This Beta > > Feature will be available for all users on Thursday afternoon (Pacific > > timezone). Users who opt-in should have a faster wiki experience and in > > the worst case will not see anything different than normal. > > > > I hope that helps. If you have any more questions please don't hesitate > > to reply and cc wikitech-l, where the experts on the matter can answer > > more questions. > > > > Best, > > > > Greg > > _______________________________________________ > Wikitech-ambassadors mailing list > Wikitech-ambassadors(a)lists.wikimedia.org > https://lists.wikimedia.org/mailman/listinfo/wikitech-ambassadors -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

want to pair program more often?
by Sumana Harihareswara 15 Sep '14

15 Sep '14

You should probably pair program more often. Here's why. 1) learning Every single time I've pair programmed with someone, one of us has learned stuff. About our tools, about a new way to look at a problem, about a language feature, or something. Sometimes I've paired explicitly as a teaching or learning technique, sometimes on more equal footing ("I'm the domain expert for the problem but you're better at $framework than I am"), or just to brainstorm or troubleshoot. At least one of us always comes out smarter. 2) the tools are better than ever https://lists.wikimedia.org/pipermail/teampractices/2014-July/thread.html has some resources; don't dismiss pair programming just because you don't live near other programmers. 3) pairing makes better code "Pair Programming" by Laurie Williams (Ch. 17 in _Making Software: What Really Works, and Why We Believe It_, ed. Andy Oram & Greg Wilson, O'Reilly 2011) reviews recent studies and finds that pair programming leads to higher-quality code, and "reduced product risk due to improved knowledge management". Some teams even tried pair programming as a replacement for code review. 4) it's more egalitarian As this list of status play behaviors points out https://web.archive.org/web/20070216200742/http://greenlightwiki.com/improv… , judging someone else's work -- even favorably! -- is a move that raises your status and lowers theirs. This is one reason I have encouraged EVERYONE who writes MediaWiki code to try their hand at code review, so everyone can take turns -- everyone can be a teacher and critic.[0] If you have found that code review feels adversarial or hierarchical, try switching it up by asking to pair with a more experienced programmer, getting your code review while you work together. People who want to pair program more often on Wikimedia-related code: want to use this thread to raise your hand? If people like the idea, we could start doing something like http://www.pairprogramwith.me/ or http://pear.growstuff.org/ to connect people up. Sumana Harihareswara Senior Technical Writer Wikimedia Foundation [0] By the way, this great blog post http://www.wordyard.com/2014/08/10/doing-is-knowing-sweet-jane-and-the-web/ makes a very strong point about how trying out an activity - like writing, music, or coding - gives you more expertise, empathy, and ability to define yourself, and to judge the work of other people who do that activity. I would argue this applies to code review as well.

1 0

Bugzilla Weekly Report
by reporter＠zirconium.wikimedia.org 15 Sep '14

15 Sep '14

1 0

Sudden growth of unreviewed changesets in Gerrit
by Quim Gil 14 Sep '14

14 Sep '14

Hi, our metrics are reflecting a sudden growth of unreviewed changes in Gerrit. Your attention and interpretations are welcome. http://korma.wmflabs.org/browser/gerrit_review_queue.html Look at the green line in the first graph, "Volume of open changesets". It shows the number of open changesets waiting for a review (WIP and -1 are excluded). In the last months, the number of changesets waiting for review has gone from 311 (June) to 529 (July) and 790 (August). The increase is so high that first I thought the problem was in the metric, but Alvaro has reviewed the raw data and says that the metric is legit. https://bugzilla.wikimedia.org/show_bug.cgi?id=70278 Trying to find an explanation, I went to the MediaWiki Core repository, and there are some inusual curves there as well: http://korma.wmflabs.org/browser/repository.html?repository=gerrit.wikimedi… However, not even these numbers alone would explain the increase. Has there been an unusual activity (or lack of reviews) in Gerrit or are we missing an important detail in the metrics? (pause) In any case, in the past weeks I have been chasing old open reviews and in general I get the impression that developers/maintainers are too busy to review so many contributions. The tricky part is that many (most?) of those contributions come from the same developers/maintainers... Simplifying a lot the picture, it looks as if we can't review code because we are busy writing code that won't be reviewed because we are busy writing code that won't be reviewed because... I'm sure this representation is unfair, but you get the point. In many cases, unreviewed patches rotting mean real resources put into waste -- right? Maybe teams should prioritize the attention to open changesets at the expense of writing new code themselves? It's a real question and I won't pretend to have an answer. Different teams and repositories probably have different answers. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

8 11

Roadmap and deployment highlights - week of Sept 15th
by Greg Grossmeier 14 Sep '14

14 Sep '14

Hello and welcome to the latest edition of the WMF Engineering Roadmap and Deployment update. The full log of planned deployments next week can be found at: <https://wikitech.wikimedia.org/wiki/Deployments#Week_of_September_15th> A quick list of notable items... == Monday == * Revert Wikidata to a known-good version due to issues that were found on Thursday's deploy * Update CentralNotice to remove dependency on jquery.json ** <https://gerrit.wikimedia.org/r/158103> * Japanese Wikipedia to get Cirrus Search as the primary search experience == Tuesday == * Commons to will get the new CirrusSearch as the primary search engine * MediaWiki deploy ** group1 to 1.24wmf21: All non-Wikipedia sites (Wiktionary, Wikisource, Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites) ** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf21> == Wednesday == * Russian Wikipedia to get Cirrus Search as the primary search experience == Thursday == * MediaWiki deploy ** group2 to 1.24wmf21 (all Wikipedias) ** group0 to 1.24wmf22 (test/test2/testwikidata/mediawiki) * There will be a method to opt-in to using the new HHVM-powered backend for all WMF wikis. It'll be implemented via a BetaFeature to make it as easy as possible for people to participate. There should be no noticeable negative impact and hopefully only positive impacts. Thanks and as always, questions and comments welcome, Greg -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

2 2

FOSS Outreach Program for Women round 9
by Quim Gil 12 Sep '14

12 Sep '14

FOSS Outreach Program for Women round 9 will be announced officially today by the GNOME Foundation. Wikimedia will participate again, and our landing page is located at https://www.mediawiki.org/wiki/FOSS_Outreach_Program_for_Women/Round_9 If you have a project proposal with two mentors and community consensus, then you can add it under "Featured project ideas" here: https://www.mediawiki.org/wiki/Mentorship_programs/Possible_projects#Featur… Transclusion magic will do the rest. On the other hand, if you proposed one of the projects featured in the previous OPW and GSoC round and for some reason you don't want to push it now, please remove it. You can either move it under the Raw section (if you want to bring it back next year) or remove it completely from the page. Questions? Just ask. -- Quim Gil Engineering Community Manager @ Wikimedia Foundation http://www.mediawiki.org/wiki/User:Qgil

1 0

Developers wanted - OSMdata: a Wikidata-like editor for OpenStreetMap
by Cristian Consonni 12 Sep '14

12 Sep '14

Hello, I am forwarding this email to this list because I think this is a place where I may be able to find somebody interested with the required skills, sorry if this is not the case and/or this is not the right place. I would like to hear your fefedback (but please consider to use the discussion page on meta for that). Thanks, Cristian ---------- Forwarded message ---------- From: Cristian Consonni <kikkocristian(a)gmail.com> Date: 2014-09-12 11:41 GMT+02:00 Subject: OSMdata: a Wikidata-like editor for OpenStreetMap To: OSM <talk(a)openstreetmap.org> Hi all The (long) discussion about importing Wikidata tags in OSM has prompted this idea into my mind: https://wiki.openstreetmap.org/wiki/OSMdata I have also describe here in the IdeaLab on meta-wiki: https://meta.wikimedia.org/wiki/Grants:IdeaLab/OSMdata:_a_Wikidata-like_edi… Here's a quick summary: == What == * using a MediaWiki + Wikibase - let's call it OSMdata[*] - install to host an item about every single object in OSM (following this schema Nxxx for nodes, Wxxx for ways, Rxxx for relations). * claims in a OSMdata page about an item map exactly to key, values pairs for the same object in OSM. * OSMdata is synchronized and kept up-to-date with the OSM database (read) * users can login in OSMdata with their OSM account and contribute, adding new claims this are saved back automatically in the OSM database (write) == Rationale == * it seems awesome (!) * the OSM community gains a new editor for OpenStreetMap, an editor which use a well known interface and which can get all the benefits of MediaWiki+Wikibase software development * Wikibase is tested at 60x its current scale * Wikibase is used in another big project Let me stress again that I see OSMdata as being an editor, not a repository for OSM, in fact I image in it to be a specialized editor to be used for editing tags. In my view the idea is to provide a well known interface to edit OSM (both manually and automatically with bots, using the same bot frameworks already available for editing Wikidata). I have described this idea in the talk-it malling list (in Italian) and a (at least conceptual) similarity has been pointed out towards the textual editor Level0[2]. I would like to know your opinion, and I would also like to set up some prototype with a small subset of the data. I tried to set up this myself but, unfortunately, I am blocked on the first obstacle, i.e.: how can I tell Wikibase to let me create items with names Nxxx, Wxxx and Rxxx instead of Qxxx? I do not know enough PHP (nor MediaWiki or Wikibase) to do this myself. Any help in this direction would be much appreciated. Ciao, Cristian [*] any reference to Wikidata is purely intentional [1] https://lists.openstreetmap.org/pipermail/talk-it/2014-September/044540.html

1 0

Disabling JS support in additional browsers
by Erik Moeller 12 Sep '14

12 Sep '14

Following up on disabling JavaScript support for IE6 [1], here is some additional research on other browsers. I'd appreciate if people with experience testing/developing for/with these browsers would jump in with additional observations. I think we should wait with adding other browsers to the blacklist until the IE6 change has been rolled out, which may expose unanticipated consequences (it already exposed that Common.js causes errors in blacklisted browsers, which should be fixed once [2] is reviewed and merged). As a reminder, the current blacklist is in <resources/src/startup.js>. As a quick test, I tested basic browsing/editing operation on English Wikipedia with various browsers. Negative results don't necessarily indicate that we should disable JS support for these browsers, but they do indicate the quality of testing that currently occurs for those browsers. Based on a combination of test results, unpatched vulnerabilities and usage share, an initial recommendation for each browser follows. Note that due to the heavy customization through gadgets/site scripts, there are often site-specific issues which may not be uncovered through naive testing. == Microsoft Internet Explorer 7.x == Last release in series: April 2009 - Browsing: Most pages work fine (some styling issues), but pages with audio files cause JavaScript errors (problem in TMH). - Editing: Throws JS error immediately (problem in RefToolbar) Both of these errors don't occur in IE8. Security vulnerabilities: Secunia reports 15 out of 87 vulnerabilities as unpatched, with the most serious one being rated as "moderately critical" (which is the same as IE6, while the most serious IE8 vulnerability is rated "less critical"). Usage: <1% Recommendation: Add to blacklist == Opera 8.x == Last release in series: September 2005 Browsing/editing: Works fine, but all JS fails due to a script execution error (which at least doesn't cause a pop-up). Security: Secunia reports 0 unpatched vulnerabilities (out of 26). Usage: <0.25% Recommendation: Add to blacklist == Opera 10.x-12.x == Last release in series: April 2014 Browsing/editing: Works fine, including advanced features like MediaViewer (except for 10.x) Security: No unpatched vulnerabilities in 12.x series according to Secunia, 2 unpatched vulnerabilities in 11.x ("less critical") and 1 unpatched vulnerability in 10.x ("moderately critical") Usage: <1% Recommendation: Maintain basic JS support, but monitor situation re: 10.x and add that series to blacklist if maintenance cost too high == Firefox 3.6.* == Last release in series: March 2012 Browsing/editing: Works fine (MediaViewer disables itself) Security: 0 unpatched vulnerabilities according to Secunia Recommendation: Maintain basic JS support == Firefox 3.5.* == Last release in series: April 2011 Browsing/editing: Works fine (MediaViewer disables itself) Security: 0 unpatched vulnerabilities according to Secunia Recommendation: Maintain basic JS support == Safari 4.x == Last release in series: November 2010 Browsing/editing: Works fine Security: 1 unpatched "highly critical" vulnerability according to Secunia ("exposure of sensitive information") Recommendation: Maintain basic JS support, but monitor == Safari 3.x == Last release in series: May 2009 Browsing/editing: Completely messed up, looks like CSS doesn't get loaded at all Security: 2 unpatched vulnerabilities, "highly critical" Usage share: Usage reports for Safari in [3] are broken, all Safari versions are reported as "0.0". However, [4] suggests that Safari 3 usage is negligible/non-existent. Recommendation: Styling issue may be worth investigating in case it affects other browsers and/or is JS-caused. Otherwise probably can be safely ignored. [1] http://lists.wikimedia.org/pipermail/wikitech-l/2014-August/077952.html [2] https://gerrit.wikimedia.org/r/#/c/152122/ [3] http://stats.wikimedia.org/wikimedia/squids/SquidReportClients.htm [4] http://stackoverflow.com/questions/12655363/what-is-the-most-old-safari-ver… -- Erik Möller VP of Engineering and Product Development, Wikimedia Foundation

7 9

Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
by Tilman Bayer 12 Sep '14

12 Sep '14

Minutes and slides from last week's quarterly review of the Foundation's Release Engineering and QA team are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote: > Hi folks, > > to increase accountability and create more opportunities for course > corrections and resourcing adjustments as necessary, Sue's asked me > and Howie Fung to set up a quarterly project evaluation process, > starting with our highest priority initiatives. These are, according > to Sue's narrowing focus recommendations which were approved by the > Board [1]: > > - Visual Editor > - Mobile (mobile contributions + Wikipedia Zero) > - Editor Engagement (also known as the E2 and E3 teams) > - Funds Dissemination Committe and expanded grant-making capacity > > I'm proposing the following initial schedule: > > January: > - Editor Engagement Experiments > > February: > - Visual Editor > - Mobile (Contribs + Zero) > > March: > - Editor Engagement Features (Echo, Flow projects) > - Funds Dissemination Committee > > We’ll try doing this on the same day or adjacent to the monthly > metrics meetings [2], since the team(s) will give a presentation on > their recent progress, which will help set some context that would > otherwise need to be covered in the quarterly review itself. This will > also create open opportunities for feedback and questions. > > My goal is to do this in a manner where even though the quarterly > review meetings themselves are internal, the outcomes are captured as > meeting minutes and shared publicly, which is why I'm starting this > discussion on a public list as well. I've created a wiki page here > which we can use to discuss the concept further: > > https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r… > > The internal review will, at minimum, include: > > Sue Gardner > myself > Howie Fung > Team members and relevant director(s) > Designated minute-taker > > So for example, for Visual Editor, the review team would be the Visual > Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. > > I imagine the structure of the review roughly as follows, with a > duration of about 2 1/2 hours divided into 25-30 minute blocks: > > - Brief team intro and recap of team's activities through the quarter, > compared with goals > - Drill into goals and targets: Did we achieve what we said we would? > - Review of challenges, blockers and successes > - Discussion of proposed changes (e.g. resourcing, targets) and other > action items > - Buffer time, debriefing > > Once again, the primary purpose of these reviews is to create improved > structures for internal accountability, escalation points in cases > where serious changes are necessary, and transparency to the world. > > In addition to these priority initiatives, my recommendation would be > to conduct quarterly reviews for any activity that requires more than > a set amount of resources (people/dollars). These additional reviews > may however be conducted in a more lightweight manner and internally > to the departments. We’re slowly getting into that habit in > engineering. > > As we pilot this process, the format of the high priority reviews can > help inform and support reviews across the organization. > > Feedback and questions are appreciated. > > All best, > Erik > > [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus > [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Wikimedia-l mailing list > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB

1 0

Re: [Wikitech-l] [Wikimedia-l] Quarterly reviews of high priority WMF initiatives
by Tilman Bayer 12 Sep '14

12 Sep '14

Minutes and slides from the first ever quarterly review of the Foundation's Technical Operations team (held on August 28) are now available at https://meta.wikimedia.org/wiki/WMF_Metrics_and_activities_meetings/Quarter… . On Wed, Dec 19, 2012 at 6:49 PM, Erik Moeller <erik(a)wikimedia.org> wrote: > Hi folks, > > to increase accountability and create more opportunities for course > corrections and resourcing adjustments as necessary, Sue's asked me > and Howie Fung to set up a quarterly project evaluation process, > starting with our highest priority initiatives. These are, according > to Sue's narrowing focus recommendations which were approved by the > Board [1]: > > - Visual Editor > - Mobile (mobile contributions + Wikipedia Zero) > - Editor Engagement (also known as the E2 and E3 teams) > - Funds Dissemination Committe and expanded grant-making capacity > > I'm proposing the following initial schedule: > > January: > - Editor Engagement Experiments > > February: > - Visual Editor > - Mobile (Contribs + Zero) > > March: > - Editor Engagement Features (Echo, Flow projects) > - Funds Dissemination Committee > > We’ll try doing this on the same day or adjacent to the monthly > metrics meetings [2], since the team(s) will give a presentation on > their recent progress, which will help set some context that would > otherwise need to be covered in the quarterly review itself. This will > also create open opportunities for feedback and questions. > > My goal is to do this in a manner where even though the quarterly > review meetings themselves are internal, the outcomes are captured as > meeting minutes and shared publicly, which is why I'm starting this > discussion on a public list as well. I've created a wiki page here > which we can use to discuss the concept further: > > https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings/Quarterly_r… > > The internal review will, at minimum, include: > > Sue Gardner > myself > Howie Fung > Team members and relevant director(s) > Designated minute-taker > > So for example, for Visual Editor, the review team would be the Visual > Editor / Parsoid teams, Sue, me, Howie, Terry, and a minute-taker. > > I imagine the structure of the review roughly as follows, with a > duration of about 2 1/2 hours divided into 25-30 minute blocks: > > - Brief team intro and recap of team's activities through the quarter, > compared with goals > - Drill into goals and targets: Did we achieve what we said we would? > - Review of challenges, blockers and successes > - Discussion of proposed changes (e.g. resourcing, targets) and other > action items > - Buffer time, debriefing > > Once again, the primary purpose of these reviews is to create improved > structures for internal accountability, escalation points in cases > where serious changes are necessary, and transparency to the world. > > In addition to these priority initiatives, my recommendation would be > to conduct quarterly reviews for any activity that requires more than > a set amount of resources (people/dollars). These additional reviews > may however be conducted in a more lightweight manner and internally > to the departments. We’re slowly getting into that habit in > engineering. > > As we pilot this process, the format of the high priority reviews can > help inform and support reviews across the organization. > > Feedback and questions are appreciated. > > All best, > Erik > > [1] https://wikimediafoundation.org/wiki/Vote:Narrowing_Focus > [2] https://meta.wikimedia.org/wiki/Metrics_and_activities_meetings > -- > Erik Möller > VP of Engineering and Product Development, Wikimedia Foundation > > Support Free Knowledge: https://wikimediafoundation.org/wiki/Donate > > _______________________________________________ > Wikimedia-l mailing list > Wikimedia-l(a)lists.wikimedia.org > Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l -- Tilman Bayer Senior Operations Analyst (Movement Communications) Wikimedia Foundation IRC (Freenode): HaeB

1 0

OPW final report and thanks to you all
by Frances Hocutt 11 Sep '14

11 Sep '14

My (belated) final report for my OPW project is up on my progress reports page: https://www.mediawiki.org/wiki/Evaluating_and_Improving_MediaWiki_web_API_c… . Thank you to everyone who has helped me learn as much and contribute as much as I have this summer, and special thanks to my mentors and technical advisers. This has been a great experience, and I'm happy to be leaving API:Client code in better shape than I found it! I hope to stick around the MediaWiki development community as I move on in my career as a software developer. I've applied for the January batch of Hacker School. Until that starts, I'll be working on API applications for Growstuff (http://growstuff.org): a gardening site that collects crowdsourced data from local gardeners around the world and freely licenses the resulting data. Wherever I end up after this, I'm glad to have gotten my start on MediaWiki. -Frances

3 2

Closure creation benchmark
by Daniel Kinzler 11 Sep '14

11 Sep '14

Hi all. During the RFC doscussion today, the question popped up how the performance of creating closures compares to creating objects. This is particularly relevant for closures/objects created by bootstrap code which is always executed, e.g. when registering with a CI framework. Attached is a benchmark I quickly hacked up. It indicates that creating objects is about 40% slower on my setup (PHP 5.4.9). I'd be curious to know how it compares on HHVM. In absolute numbers though, creating an object seems to take about one *micro*second. That seems fast enough that we don't really have to care, I think. Anyone want to try? Cheers, daniel

2 2

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 September 2014