Wikitech-l March 2016

wikitech-l@lists.wikimedia.org

109 participants
102 discussions

ArchCom RFC update
by Gabriel Wicke 17 Mar '16

17 Mar '16

Hi, I am writing to give you a quick summary of which RFCs we are currently working on in the ArchCom. Each RFC has the name of its 'shepherd' listed next to it. A shepherd is responsible for working with the RFC author to move the RFC forward, publicize it, and represent it in the architecture committee. Please have a look, and join the conversation on the RFCs that are of interest to you. Gabriel New RFCs: T129435 RFC: drop support for running without mbstring <https://phabricator.wikimedia.org/T129435> (Gabriel): New, very focused RFC by Max, discussion started. Upcoming IRC sessions: T124792 Service Locator for MediaWiki core <https://phabricator.wikimedia.org/T124792> (Daniel): Introduce a service locator (aka DI container) to allow code in mediaWiki core to make use of the Dependency Injection (DI) and Service Locator (SL) patterns. Under discussion: T108655 Standardise on how to access/register JavaScript interfaces <https://phabricator.wikimedia.org/T108655> (Roan): Considering to split out contentious part (file-based require, or something like it; to support embedding libraries), move forward on less controversial part (basic module-name-based require infrastructure) T18691 RFC: Section headings should have a clickable anchor <https://phabricator.wikimedia.org/T18691> (Timo): Reworking proposal with designers & Volker T124504 Transition WikiDev '16 working areas into working groups <https://phabricator.wikimedia.org/T124504> (RobLa) Finding folks to fully assume ownership on following up from each session has been difficult T128351 RfC: Notifications in core <https://phabricator.wikimedia.org/T128351> (Brion): Discussed last week, now clarifying interfaces & scope. T66214 Use content hash based image / thumb URLs & define an official thumb API <https://phabricator.wikimedia.org/T66214> (Brion): Discussion last & this week. T118517 [RFC] Use <figure> for media <https://phabricator.wikimedia.org/T118517> (Brion): Revisit soon. T124752 [RFC] Expiring watch list entries <https://phabricator.wikimedia.org/T124752> (Daniel): Iterating on the design, discussion on the task. T113034 RFC: Overhaul Interwiki map, unify with Sites and WikiMap <https://phabricator.wikimedia.org/T113034> (Daniel): Has been discussed before, needs somebody to actually take this on. T114444 [RFC] Introduce notion of DOM scopes in wikitext <https://phabricator.wikimedia.org/T114444> (Tim): Under discussion in the parsing team, early stage.

1 0

Scrum of Scrums - 2016-03-16
by Greg Grossmeier 16 Mar '16

16 Mar '16

on wiki: https://www.mediawiki.org/wiki/Scrum_of_scrums/2016-03-16 = 2016-03-16 = == Product == === Reading === ==== iOS ==== * '''Updates''': ** 5.0.0 was released - all the new things ** 5.0.1 was submitted - fix all the new things that crashed * '''Upcoming''': ** 5.0.1 - release (blocked on Apple review) ** 5.0.2 - a little bit of this and that, second round of bug fixes, some small functionality tweaks ** 5.1.0 - still in planning stage for some larger adjustments to some of the new 5.0.0 functionality * '''Blocking''': ** nothing comes to mind atm * '''Blocked''': ** 5.0.1 - release (blocked on Apple review) ** "mw-mobilefrontend-leadsection" leaking in to mobileview lead section (broke our transform but we pushed a workaround in 5.0.1) ** powering through 5.0.0 OTRS feedback firehose (not so much blocked as just time consuming) - digesting this feedback will inform what goes into 5.0.2 and 5.1.0 ** this also isn't really a blocker, just something we'll need to do sometime in the future - audit mobile content service output for any android-specific bits which may need to be tweaked before iOS can adopt - i doubt there will be issues, but we'll need to check ==== Mobile Content Service ==== * '''Blocking''': ** None * '''Blocked''': ** potential blocker: https://phabricator.wikimedia.org/T118306 "File: pages of images stored on commons result in 404s". Would be really nice to get that one fixed before we roll out MCS usage to Android production app. ** We need a new Android prod app release for the roll out of MCS usage in Android production app * '''Updates''': ** Considering starting roll out of MCS usage to Android production app next week since DC-switchover test is delayed until mid April. Might as well do it now. ** Working on fixing lead paraph transformation in the service. ==== Reading Infrastructure ==== * AuthManager is still coming! (see two weeks ago for details) ** Behind schedule though. ==== Android ==== * 2.1.143 beta coming soon. === Community Tech === * Numerical category sorting - Need to get https://gerrit.wikimedia.org/r/#/c/272416/ merged * Pageview stats tool is basically finished, going to add support for redirects as well * Deadlink logging interface for internet archive - http://tools.wmflabs.org/deadlinks/ === Editing === ==== Collaboration ==== * '''Blocking''': ** External Store - Continuing work. Some local stuff merged that will help with testing. * '''Blocked''': ** No new blockers. Work on dump continues * '''Updates''': ** Good feedback from cross-wiki notification roll out some far. ** Some small issues, e.g. people feeling spammed by welcome bots from wikis they visited one time (or maybe just a load.php reference). ==== Language ==== * '''Blocking''': ** None * '''Blockers''': ** None * '''Updates''' ** Work on improving ContentTranslation continue. ==== Multimedia ==== * '''Blocking''' ** None * '''Blockers''' ** None * '''Updates''' ** Another A/B test for the core upload dialog (esp. regarding VisualEditor uploads) to be released soon in an effort to reduce garbage uploads, heads up == Discovery == * '''Blocked''': ** Security: SVG sanitizer * '''Updates''': ** Completion suggester deployed on all wikis as default starting March 16th ** New portal improvements deployed ** Started weekly status updates: https://www.mediawiki.org/wiki/Discovery/Status_updates ** Working on enabling encryption for search traffic ** Preparing for A/B test of phrase match boost for search == Technology == === Security === * Deploying 2FA to wikis next week (disabled for almost all users initially) * Tarball release planned for next week === Research === * Blocking: none * Blocked: none * Updates: none === RelEng === * Blocking: ** Security wants to do a release of MW, working on timing ** Fundraising tech needs patch merged for jjb config, gerrit 277563 * Blocked: None * Updates: ** Code freeze is not happening next week, April 18th instead. See wmfall, wikitech-l announcement coming today too. === Technical Operations === * Blocking: Research on ORES, started assigning LVS this week * Blocked: none * Updates: ** Jobqueue woes https://phabricator.wikimedia.org/T129517 ** Got minor services (citoid, cxserver, mathoid, graphoid, apertium, zotero) working in CODFW === Fundraising Tech === * need one patch merged by RelEng: https://gerrit.wikimedia.org/r/277563 * tested backup credit card processor for an hour ** fixing the bugs that shook out * burst of DonationInterface refactoring * draining some molasses out of the CentralNotice campaigns page * testing strategies to make contact merges reversable in CiviCRM === Services === * Going to set up redirects for commons image description pages (blocker for mobile apps deployment): https://phabricator.wikimedia.org/T118306 * DC switch-over for RESTBase, node services happening tomorrow European morning (3 hours): https://phabricator.wikimedia.org/T127974 ** Services already running in Dallas, Cassandra master-master replication ** No user impact expected * REST API CDN caching: Most entry points now purged & cached in Varnish. Going to redirect titles with spaces to underscores next week. * EventBus multi-DC support discussion wrapping up: https://phabricator.wikimedia.org/T127718 * "Pageviews" turns out to be disliked by ad blockers; working on alternative URLs for pageview API with analytics: https://phabricator.wikimedia.org/T126947 === Analytics === * Working on goals for next quarter: will share soon with dependencies * Finishing up work on the request breakdown reports to replace wikistats reports: OS and Browser breakdowns -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

RFC meeting (E148): Review backlog, Thumb API
by Daniel Kinzler 16 Mar '16

16 Mar '16

Hi everyone, We plan to discuss two RFCs at the 2016-03-16 RFC Meeting (21:00 UTC on Wednesday, that's 2pm Pacific, 22:00 CET, beware the DST shift between US and Europe!): * Use content hash based image / thumb URLs & define an official thumb API <https://phabricator.wikimedia.org/T78639> * How to address the long tail of low priority tasks in active projects <https://phabricator.wikimedia.org/T66214> See also: - Define potential actions to reduce code review queues and waiting times <https://phabricator.wikimedia.org/T101686> - Make code review not suck <https://phabricator.wikimedia.org/T114419> Details about the meeting are in Phabricator: https://phabricator.wikimedia.org/E148 Hope to see y'all there! Daniel _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

2 1

How to find pages using the Score extension?
by Daniel Mietchen 16 Mar '16

16 Mar '16

Hi, I want to get an idea how many times the Score extension is invoked but could find no way to go about that, nor to get a list of pages using <score> or variants thereof on a per-wiki or per-category basis. Any pointers? Thanks, d.

4 4

Re: [Wikitech-l] [Wikimedia-l] Wikipedia.org portal page update!
by Sam Klein 16 Mar '16

16 Mar '16

I'm using the portal much more these days! Two thoughts, a few days in: = Is there a way to turn on thumbnailing on the individual language wikis too? = Auto-suggesting language based on charset would be nice. when searching in multiple languages I always forget once to switch to the target language and end up getting search results for kanji on he.wp or for hebrew on ja.wp Thanks, SJ On Tue, Mar 15, 2016 at 4:25 AM, Michael Jahn <michael.jahn(a)wikimedia.de> wrote: > I've played around a bit. Feels very cool! > Michael > > 2016-03-11 3:27 GMT+01:00 Deborah Tankersley <dtankersley(a)wikimedia.org>: > > > Hello! > > > > I'm very pleased to announce that we've updated the Wikipedia.org > > <http://wikipedia.org/> portal page with a brand new search box that is > > more prominent and will now display meta data with images (as available) > in > > the search results (see attached image). > > > > This was a large effort by the Discovery Portal team to develop a > > JavaScript-only version of the language picker, so that JavaScript > enabled > > browsers will see all the new meta data. Alongside that effort, we also > > ensured that in JavaScript (JS) disabled browsers (or older Internet > > Explorer versions), our visitors won't have a bad experience when > choosing > > a language to search in. (Note: in older IE versions and JS disabled > > browsers, the type-ahead and meta data search results information will > not > > be displayed.) > > > > We also implemented a shorter language code (ie: EN for English, ES for > > Spanish, etc) to allow for more characters to be typed into the search > box. > > When a user toggles the language selector, the full language name will be > > displayed in the dropdown for easy finding of the language you prefer to > > search in. For the more technical minded - I've attached a screenshot of > > one of the ways we test our code, visually. > > > > We're interested in hearing your feedback or if you have any questions! > > > > On behalf of the very happy Wikipedia.org Portal Team, > > > > Deb > > > > -- > > Deb Tankersley > > Product Manager, Discovery > > 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> > > > > > -- > Leiter Kommunikation > Head of Communications > > Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin > Tel. (030) 219 158 260 > > http://wikimedia.de <http://www.wikimedia.de> > > Stellen Sie sich eine Welt vor, in der jeder Mensch freien Zugang zu der > Gesamtheit des Wissens der Menschheit hat. Helfen Sie uns dabei! > > Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. > Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter > der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für > Körperschaften I Berlin, Steuernummer 27/029/42207. > _______________________________________________ > 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> > -- Samuel Klein @metasj w:user:sj +1 617 529 4266

2 1

REST API soon redirecting to canonical URLs
by Gabriel Wicke 16 Mar '16

16 Mar '16

Hi, this is to let you know that we will start redirecting GET requests with non-canonical titles to their canonical equivalent next week. This is done to improve caching, and to ensure reliable purging of cached responses. The vast majority of clients handle redirects transparently, so at most this will lead to a small slow-down from the redirect. To avoid being redirected, make sure to use underscores instead of spaces, as in "Main_Page". Thanks, Gabriel Wicke

1 0

User interaction on Wikipedia --call for submissions
by Moushira Elamrawy 16 Mar '16

16 Mar '16

Greetings, Following up on the reading strategy. <https://www.mediawiki.org/wiki/Reading/Strategy/Strategy_Process/Testing> The reading team is launching an experiment that supports early engagement in ideation phase, with a wide variety of users. This aims at allowing a public space, where editors, staff and readers, can submit and discuss ideas around our how to enhance user interaction with content and with each other on Wikipedia. We plan to run this for 4 weeks, where after two weeks we can start to narrow down ideas and discuss them in details. Please check the link below, and feel free to submit ideas, ask questions or leave a comment, and help us spread the word. https://www.mediawiki.org/wiki/User_Interaction_Consultation Best, Moushira

1 0

extension.json schema validation is now voting for extensions
by Legoktm 15 Mar '16

15 Mar '16

Hi, With [1] now merged, the extension phpunit tests that are run by jenkins will also validate loaded extension.json and skin.json files against the formal JSON schema (docs/extension.schema.json in core). To validate locally, you can either run the structure phpunit tests or use the validateRegistrationFile.php maintenance script. [1] https://gerrit.wikimedia.org/r/#/c/273751/ -- Legoktm

2 1

Re: [Wikitech-l] extension.json schema validation is now voting for extensions
by Florian Schmidt 15 Mar '16

15 Mar '16

Thanks for the information lego and thanks for everyone involved getting all extensions pass the schema :) Gesendet mit meinem HTC ----- Nachricht beantworten ----- Von: "Legoktm" <legoktm.wikipedia(a)gmail.com> An: "Wikimedia developers" <wikitech-l(a)lists.wikimedia.org> Betreff: [Wikitech-l] extension.json schema validation is now voting for extensions Datum: Di., März 15, 2016 01:02 Hi, With [1] now merged, the extension phpunit tests that are run by jenkins will also validate loaded extension.json and skin.json files against the formal JSON schema (docs/extension.schema.json in core). To validate locally, you can either run the structure phpunit tests or use the validateRegistrationFile.php maintenance script. [1] https://gerrit.wikimedia.org/r/#/c/273751/ -- Legoktm _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

Minor REST API cleanup: Remove experimental listings, make timeuuid parameter mandatory for data-parsoid
by Gabriel Wicke 14 Mar '16

14 Mar '16

tl;dr: You are *very* likely not affected. We are planning two changes in the REST API: 1) Remove the experimental /page/html/ and /page/data-parsoid/ listings [1][2]. Our metrics show that these are essentially unused. The same title listing remains available at /page/title/ [3]. 2) Make the `tid` path parameter in the unstable /page/data-parsoid/{title}/{revision}/{tid} [4] end point mandatory. Data-parsoid is tied to a specific HTML render, and only requests with an explicit timeuuid from the corresponding HTML response are guaranteed to get the correct data-parsoid version. If things go to plan, we will deploy these changes sometime next week. Thank you for your understanding, Gabriel Wicke for the Services team [1]: https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_html [2]: https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_data_pars… [3]: https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_title [4]: https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_data_pars…

3 2

← Newer
1
2
3
4
5
6
7
8
9
10
11
Older →

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 March 2016