Wikitech-l February 2016

wikitech-l@lists.wikimedia.org

103 participants
107 discussions

Please Welcome Guillaume Lederrey to the WMF
by Tomasz Finc 02 Feb '16

02 Feb '16

I am pleased to announce that Guillaume Lederrey joins WMF this week as Operation Engineer in the Discovery team. Guillaume will work closely with our operations team to support Elastic Search, Maps, and WDQS along with strengthening our experience with Java based services. Guillaume will be working remotely from Lausanne (Switzerland) where he lives with his 4 month old son and his mother. Guillaume has previous experience with non profits, having worked for a year in Rwanda for an NGO. Working to make the world a better place is what motivates him to join WMF. For the last 5 years, Guillaume has been working for Nespresso, taking care of all things from performance and stability of the e-commerce and backend stacks, challenging agile practices and introducing Puppet as the main configuration tool to managing build tools, improving automated code quality and bringing coffee to his coworkers. On his free time, Guillaume is the maintainer of JmxTrans [1], the missing piece to monitor JVM based applications. Guillaume can be found on IRC under the nickname 'gehel'. Please join me in welcoming him! --tomasz [1]: https://github.com/jmxtrans/jmxtrans

4 3

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

01 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

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

01 Feb '16

Hi Luigi, On Fri, Jan 29, 2016 at 12:31 PM, Luigi Assom <itsawesome.yes(a)gmail.com> wrote: > - how to extract _ID from ETag in headers: > GET /page/title/{title} the page id is indeed not directly exposed in the HTML response. However, the revision number is exposed as part of the ETag. This can then be used to request revision metadata including the page id at https://en.wikipedia.org/api/rest_v1/?doc#!/Page_content/get_page_revision_…. This is admittedly not very convenient, so I created https://phabricator.wikimedia.org/T125453 for generally improved page id support in the REST API. > - how to ensure > GET /page/title/{title with different char encoding or old titles are always > resolved to last canonical version} The storage backing this end point is automatically kept up to date with edits and dependency changes. Edits in particular should be reflected within a few seconds. >> 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). > > > Oh very interesting! > So basically html markup can be extended ? > Would it be possible to share json objects as html5 markup and embed them in > wiki pages? The graph extension is using the regular MediaWiki tag extension mechanism: https://www.mediawiki.org/wiki/Manual:Tag_extensions Graphs are indeed defined using JSON within this tag. > I want to avoid to update my graph just because titles changes: entities are > always the same. Makes sense. The current API is optimized for the common case of access by title, but we will consider adding access by page ID as well. > I still don't know what parsoid is. Parsoid is the service providing semantic HTML and a bi-directional conversion between that & wikitext: https://www.mediawiki.org/wiki/Parsoid Gabriel

1 0

Status and plan of SessionManager and 1.27-wmf.11 and wmf.12
by Greg Grossmeier 01 Feb '16

01 Feb '16

Hello, As you know we had to rollback 1.27-wmf.11 a few times in the last two weeks due to issues in the new SessionManager code base. The last time was this weekend (Saturday) and thus right now (Monday Feb 1st and 18:00 UTC) Wikimedia production is running only[0] wmf.10. After discussions with Brad (Anomie), Bryan (bd808), Dan (marxarelli), Antoine (hashar), and myself we decided on this plan moving forward: 1) Stay at wmf.10 everywhere today/Mon Feb 1st 2) Brad/Bryan prepare master *without* SessionManager 3) Brad to prepare session invalidation improvement (speed up the invalidation process) 4) Tomorrow/Tuesday Feb 2nd: cut wmf.12 (without SessionManager) 5) Roll wmf.12 as normal this week (ie: skip wmf.11 entirely) 6) Rest of week: Brad and Bryan to get some more end-to-end tests running with Dan 7) Next week: Hopefully get SessionManager back into wmf.13 (with session invalidation improvement incorporated) Apologies to all for the issues we've been having and apologies to Bryan, Brad, and Gergo for delaying the rollout of SessionManager (and probably AuthManager). I think this is the best solution we have right now given the situation. Best, Greg [0] If you care about relatively tiny details, the mw1017 appserver is running wmf.11, but the only users that get that server set a special debug header. This is for the team to test/debug what they can. -- | Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E | | identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |

1 0

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

RFC: Expiring watchlist entries
by Daniel Kinzler 01 Feb '16

01 Feb '16

Hi all! At Wednesday's RFC session on IRC, we will be talking about allowing watchlist entries to expire, as described here: <https://phabricator.wikimedia.org/T124752>. The current RFC as submitted by Addshore focusses on managing the expiry data in the database, but we would also like to shed some light on the UX implications this has. If you are interested, please go ahead and comment on Phabricator. We (ArchCom) are trying to encourage more discussion before the "live" IRC meeting, to make sure everyone interested can participate in the discussion, even if they can't make it to the live meeting. -- Daniel Kinzler Senior Software Developer Wikimedia Deutschland Gesellschaft zur Förderung Freien Wissens e.V.

1 0

Phabricator monthly statistics - 2016-01
by communitymetrics＠wikimedia.org 31 Jan '16

31 Jan '16

Hi Community Metrics team, This is your automatic monthly Phabricator statistics mail. Accounts created in (2016-01): 292 Active users (any activity) in (2016-01): 892 Task authors in (2016-01): 508 Users who have closed tasks in (2016-01): 253 Projects which had at least one task moved from one column to another on their workboard in (2016-01): 199 Tasks created in (2016-01): 2653 Tasks closed in (2016-01): 2235 Open and stalled tasks in total: 28268 Median age in days of open tasks by priority: Unbreak now: 9 Needs Triage: 141 High: 197 Normal: 354 Low: 705 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 Mon Feb 1 00:00:09 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 February 2016