[Wikitech-l] Comments and questions regarding VisualEditor, Citoid, and Parsoid

[Pine W]

I'd like to say thanks to the folks who have been working on VisualEditor,
Citoid, and Parsoid in the past few years.

When I first started to work in 2015 on what I eventually called the LearnWiki
project
,
I was a bit hesitant to recommend VisualEditor due to it having some rough
spots in performance and reliability, but I knew that VE was probably the
way of the future for new Wikipedia contributors. As I've been writing
scripts recently for a 2019 small pilot project that will teach users how
to create citations with VE
,
I've been impressed by how much has improved. The VE's performance seems to
be faster, the automatic citation tool can be easy and enjoyable to use,
and the system (VE + Parsoid + Citoid) seems to be generally stable on ENWP.

I think that you made the desktop user experience significantly better for
new contributors on ENWP who use VE.

While I'm writing, I'll ask a couple of related questions. If someone knows
of recent research that analyzes the productivity and longevity of new
users who try the VE and/or New Wikitext Editor ("NEWT") interfaces, I
would be appreciative if that information could be added to this project
talk page

so that I can take a look. Especially interesting would be research that
shows points in workflows on English Wikipedia where new editors who use VE
seem to become stuck. (The sticking points may have more to do with
policies than with interfaces.) Also, Guy Macon has asked some questions here
(a secton of the same talk page)

regarding the percentage of editors that use different editing interfaces.
Please participate on the talk page if you have the time and interest.

Thanks again for the good work on VisualEditor and related systems.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] OOUI question

[Moriel Schottlender]

Hi Huji,

I took a look, and it seems you're missing the command to actually open the
dialog. Your code builds the dialog correctly, and then attaches the
windowManager and adds the dialog to the window, but there's no command
telling the manager to open the dialog on click.

I tried to debug your code, so I copied it over and looked and I found that
if I changed this, it worked:

$(mw.util.addPortletLink( 'p-cactions', '#', 'تذکر', 'ca-warn',
'فرستادن سریع یک پیام یا تذکر مبتنی بر الگو', '*')).click(function(e)
{
  mw.loader.using(['oojs-ui-core', 'oojs-ui-widgets',
'oojs-ui-windows', 'mediawiki.api'])
.then(UMOptions.createWindow)
.then( function () {
windowManager.openWindow( UM );
} );

(notice the second 'then')
Basically, I tell the code that on click, after it is certain to have
created the dialog, it should open it :)

See documentation here: https://www.mediawiki.org/wiki/OOUI/Windows/Dialogs

I hope this helps!

Moriel

On Wed, Mar 20, 2019 at 7:22 PM Huji Lee  wrote:

> Hi everyone!
>
> I am pretty sure I am missing something obvious here, but I cannot spot it
> and I would appreciate a fresh set of eyes looking at it.
>
> The script at https://fa.wikipedia.org/wiki/User:Huji/UserMessages.js is
> the backbone of a OOUI-based tool. I have made quite a few of a these tools
> in the past with no problem. For now, this tool is only supposed to do two
> things: add a link to the "More" dropdown on the top of the page (only if
> it is a user talk page), and open a OOUI dialog once the link is clicked.
>
> The first part works and I have verified that the *createWindow* method is
> called when you click the link, but the dialog is not shown. Can someone
> kindly look at my code and tell me what I am missing?
>
> Thanks,
>
> Huji
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
Moriel Schottlender (she/her)
Senior Software Engineer
Tech Lead | Community Tech and Anti Harassment Tools
Wikimedia Foundation https://wikimediafoundation.org/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] OOUI question

[Huji Lee]

Hi everyone!

I am pretty sure I am missing something obvious here, but I cannot spot it
and I would appreciate a fresh set of eyes looking at it.

The script at https://fa.wikipedia.org/wiki/User:Huji/UserMessages.js is
the backbone of a OOUI-based tool. I have made quite a few of a these tools
in the past with no problem. For now, this tool is only supposed to do two
things: add a link to the "More" dropdown on the top of the page (only if
it is a user talk page), and open a OOUI dialog once the link is clicked.

The first part works and I have verified that the *createWindow* method is
called when you click the link, but the dialog is not shown. Can someone
kindly look at my code and tell me what I am missing?

Thanks,

Huji
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Nick Wilson (Quiddity)]

Pine,
please see the exact (quite precise) definition of
https://en.wiktionary.org/wiki/technical_debt
https://en.wikipedia.org/wiki/Technical_debt
https://martinfowler.com/bliki/TechnicalDebt.html
I.e. Technical debt is Not at all equivalent to "bugs". The topic is a
tangential one. Software can work perfectly fine for end-users even if it
has a lot of "technical debt", it is just a pain for developers to change
anything in it or connected to it because the code has complex issues (it's
a mess, or imperfectly architected at a higher-level, or "icky", or other
factors). It is not possible to measure, and is somewhat subjective in
nature.


Overall this thread is going in circles, and I recommend dropping it here.
There are several good suggestions above if anyone wants to put effort into
actual solutions.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Pine W]

:) Structured data exists regarding many other subjects such as books and
magazines. I would think that a similar approach could be taken to
technical debt. I realize that development tasks have properties and
interactions that change over time, but I think that having a better
quantitative understanding of the backlog would be good and would likely
improve the quality of planning and resourcing decisions.

To use an analogy, as far as I know there is no project management system
that reliably produces accurate estimates of the time and resources
required to complete large projects, but I think that attempting to use a
project management system is, in many cases, better than trying to execute
a large project without a project management system.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[David Barratt]

>
> I would prefer to have a way to measure technical debt and how it is
> changing.
>

I think the entire software industry would prefer to have that, but as far
as I know, that type of measurement does not exist.

On Wed, Mar 20, 2019 at 4:23 PM Pine W  wrote:

> On Tue, Mar 19, 2019 at 4:16 PM Gergő Tisza  wrote:
>
> > On Mon, Mar 18, 2019 at 3:01 PM Derk-Jan Hartman <
> > d.j.hartman+wmf...@gmail.com> wrote:
> >
> > > Last year has seen a lot of focus on Technical Debt. WMF also has a
> core
> > > platform team now, which finally allows a more sustainable chipping
> away
> > at
> > > some of the technical debt.
> >
> >
> > Yeah. Having tech debt is never great but what gets people concerned is
> > when it just grows and grows, and management dismisses concerns because
> it
> > is always more important to have the next feature out quickly. We used to
> > have a bit of that problem, but IMO there have been lots of positive
> > changes in the last two years or so, and there is now a credible
> > organization-wide effort now to get debt under control (mainly looking at
> > the Platform Evolution program here). Having the core platform team also
> > helped a lot, and in my impression some other teams that had in the past
> > focused on fast feature iteration have also been given more space to do
> > things right.
>
>
>
> Thanks very much for the explanations regarding that point.
>
> One of my continuing concerns is that, as far as I know, no one has a way
> of reliably quantifying the scale of the technical debt or measuring how it
> is changing over time. It sounds like the internal view in WMF is that the
> situation is improving, which is good to hear. However, I would prefer to
> have a way to measure technical debt and how it is changing. If that
> information is available then I think that making decisions about
> resources, priorities, etc. will involve less guesswork. I think that this
> proposal could align with WMF's work on code health.(See
> https://www.mediawiki.org/wiki/Code_Health).
>
> Pine
> ( https://meta.wikimedia.org/wiki/User:Pine )
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Question to WMF: Backlog on bugs

[Pine W]

On Tue, Mar 19, 2019 at 4:16 PM Gergő Tisza  wrote:

> On Mon, Mar 18, 2019 at 3:01 PM Derk-Jan Hartman <
> d.j.hartman+wmf...@gmail.com> wrote:
>
> > Last year has seen a lot of focus on Technical Debt. WMF also has a core
> > platform team now, which finally allows a more sustainable chipping away
> at
> > some of the technical debt.
>
>
> Yeah. Having tech debt is never great but what gets people concerned is
> when it just grows and grows, and management dismisses concerns because it
> is always more important to have the next feature out quickly. We used to
> have a bit of that problem, but IMO there have been lots of positive
> changes in the last two years or so, and there is now a credible
> organization-wide effort now to get debt under control (mainly looking at
> the Platform Evolution program here). Having the core platform team also
> helped a lot, and in my impression some other teams that had in the past
> focused on fast feature iteration have also been given more space to do
> things right.



Thanks very much for the explanations regarding that point.

One of my continuing concerns is that, as far as I know, no one has a way
of reliably quantifying the scale of the technical debt or measuring how it
is changing over time. It sounds like the internal view in WMF is that the
situation is improving, which is good to hear. However, I would prefer to
have a way to measure technical debt and how it is changing. If that
information is available then I think that making decisions about
resources, priorities, etc. will involve less guesswork. I think that this
proposal could align with WMF's work on code health.(See
https://www.mediawiki.org/wiki/Code_Health).

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit outage

[Lars Wirzenius]

On Wed, Mar 20, 2019 at 06:56:19PM +, Pine W wrote:
> I'd like to give a quick thanks to folks who have been dealing with
> turbulence.

Me too. It's inspirational and awe-inspiring to see people work on
this.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Gerrit outage

[Pine W]

I'd like to give a quick thanks to folks who have been dealing with
turbulence.

I think that short term mitigation measures sound reasonable, while longer
term improvements are planned and developed.

Pine
( https://meta.wikimedia.org/wiki/User:Pine )
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] 2019-03-20 Scrum of Scrums meeting notes

[Leszek Manicki]

Hi,

thanks for the notes, Željko.
A quick question about SRE callout: "Goal planning ongoing but inevitably
partly delayed, SRE asks for your requests for next quarter.".

Where those requests should be addressed to?

Regards,
Leszek Manicki


On Wed, 20 Mar 2019 at 17:28, Željko Filipin  wrote:

> For HTML version see
> https://www.mediawiki.org/wiki/Scrum_of_scrums/2019-03-20
>
> =2019-03-20=
>
> == Callouts ==
> * Fundraising campaigns
> https://meta.wikimedia.org/wiki/CentralNotice/Calendar
> * From RI, to RelEng(?): Does anyone know definitively whether enabling an
> extension in the Beta Cluster requires in practice that the extension
> submodule be present in all MW branches currently running in production?
> See discussion on
> https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/496577/ .
> * Parsing Team requesting SRE to take a look at
> https://phabricator.wikimedia.org/T213493
> * If your project is using RemexHtml, please update to the latest version
> (2.0.2). HTML parsing and DOM building is now 7x faster on large DOMs.
> * Vandalism fighting in gerrit is taking a toll on SRE, Releng, Security.
> Goal planning ongoing but inevitably partly delayed, SRE asks for your
> requests for next quarter.
> * Analytics: Research is starting data collection for CitationUsage schemas
> on enwiki on 03/21: https://phabricator.wikimedia.org/T213969
> * Performance, Readers Web: Research is running reader trust survey on
> enwiki during 03/18-03/21: https://phabricator.wikimedia.org/T217576
> * Release Engineering: train blocked, branch is cut but it's not even on
> group 0 yet, might be at groups 0 and 1 later today, depending on problems
> * RelEng: https://gerrit.wikimedia.org/r/c/integration/config/+/497600 and
> https://gerrit.wikimedia.org/r/c/integration/config/+/496843
> * From Performance to Security: Possible privacy issue in Chrome 73 on
> Android https://phabricator.wikimedia.org/T218618
>
> == Audiences ==
>
> === Contributors ===
>  Community Tech 
> * Blocked by:
> * Blocking:
> * Updates:
> **
>
>  Anti-Harassment Tools 
> * Blocked by:
> * Blocking:
> * Updates:
> **
>
>  Editing 
> * Blocked by:
> * Blocking:
> ** Updates:
> **
>
>  Growth 
> * Blocked by:
> * Blocking:
> * Updates:
> **
>
>  Language 
> * Blocked by:
> * Blocking:
> * Updates:
> **
>
> === Readers ===
>  iOS native app 
> * Blocked by:
> * Blocking:
> * Updates:
> **6.2.1 is in beta
> https://phabricator.wikimedia.org/tag/ios-app-v6.2.1-beluga-on-stilts/
> ***Find & Replace
> ***Editing onboarding
> ***Other bug fixes & editing enhancements
>
>  Android native app 
> * Blocked by:Android is ready with the ‘Suggested Edits’ for a beta
> release. Blocked by API production release.
> * Blocking:
> * Updates:
> **Ready for enhanced search feature in ‘My Lists’. Waiting for an upstream
> fix.
> **Minor enhancement on Tablet.
>
>  Readers Web 
> * Blocked by:
> * Blocking:
> * Updates:
> ** Summary: deploying advanced mobile contributions, planning for next
> year, and continuing the MobileFrontend architecture investment project.
> ** Responsive website (MinervaNeue / MobileFrontend):
> *** Advanced mobile contributions
> https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
>  Deploy to Arabic, Indonesian, and Spanish Wikipedias
>  Tag Thanks actions with AMC tag T215477
>  Cannot access user contributions when following red link to user page
> on mobile T201339
> *** Invest in the MobileFrontend & MinervaNeue frontend architecture
>
> https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture
>  Refactor ImageOverlay T216198
>  Refactor NotificationOverlay T217296
>  Refactor TalkSectionAddOverlay T217102
> *** QuickSurveys
>  Consultation and support for Research
> *** ExternalGuidance extension review and support
> *** Miscellaneous bug fixes and maintenance T218069 T218731 T198534 T218173
> ** Desktop website (Popups)
> *** Popups https://www.mediawiki.org/wiki/Page_Previews
>  WMDE reference previews review and support T67114
> https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/ReferencePreviews
>  Bugfix for double pokey on some page previews T204627
> ** Planning
> *** RFC: Section headings should have a clickable anchor T18691
> *** RFC: Add a frontend build step to skins/extensions to our deploy
> process T199004
> *** RFC: Let's stop using QUnit as a mechanism for integration tests
> T212521
> *** MobileFrontend & MinervaNeue frontend architecture planning for next
> fiscal year
>
>  Readers Infrastructure 
> * Blocked by: enabling the WikimediaEditorTasks extension in production is
> blocked on performance review (https://phabricator.wikimedia.org/T218087 )
> * Blocking: Android Suggested Edits feature final testing & rollout blocked
> on WikimediaEditorTasks APIs being available in production (see "Blocked
> By")
> * Updates:

Re: [Wikitech-l] [Wikimedia-l] Wikidata now officially has more total edits than English language Wikipedia

[Emilio J . Rodríguez-Posada]

El mié., 20 mar. 2019 a las 7:48, Ariel Glenn WMF ()
escribió:

> Only 45 minutes later, the gap is already over 2000 revsions:
>
> [ariel@bigtrouble wikidata-huge]$ python3 ./compare_sizes.py
> Last enwiki revid is 888606979 and last wikidata revid is 888629401
> 2019-03-20 06:46:03: diff is 22422
>
>
This is the escape velocity, I think that Wikipedia will never surpass
Wikidata again.

The singularity is near.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] 2019-03-20 Scrum of Scrums meeting notes

[Željko Filipin]

For HTML version see
https://www.mediawiki.org/wiki/Scrum_of_scrums/2019-03-20

=2019-03-20=

== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar
* From RI, to RelEng(?): Does anyone know definitively whether enabling an
extension in the Beta Cluster requires in practice that the extension
submodule be present in all MW branches currently running in production?
See discussion on
https://gerrit.wikimedia.org/r/#/c/mediawiki/core/+/496577/ .
* Parsing Team requesting SRE to take a look at
https://phabricator.wikimedia.org/T213493
* If your project is using RemexHtml, please update to the latest version
(2.0.2). HTML parsing and DOM building is now 7x faster on large DOMs.
* Vandalism fighting in gerrit is taking a toll on SRE, Releng, Security.
Goal planning ongoing but inevitably partly delayed, SRE asks for your
requests for next quarter.
* Analytics: Research is starting data collection for CitationUsage schemas
on enwiki on 03/21: https://phabricator.wikimedia.org/T213969
* Performance, Readers Web: Research is running reader trust survey on
enwiki during 03/18-03/21: https://phabricator.wikimedia.org/T217576
* Release Engineering: train blocked, branch is cut but it's not even on
group 0 yet, might be at groups 0 and 1 later today, depending on problems
* RelEng: https://gerrit.wikimedia.org/r/c/integration/config/+/497600 and
https://gerrit.wikimedia.org/r/c/integration/config/+/496843
* From Performance to Security: Possible privacy issue in Chrome 73 on
Android https://phabricator.wikimedia.org/T218618

== Audiences ==

=== Contributors ===
 Community Tech 
* Blocked by:
* Blocking:
* Updates:
**

 Anti-Harassment Tools 
* Blocked by:
* Blocking:
* Updates:
**

 Editing 
* Blocked by:
* Blocking:
** Updates:
**

 Growth 
* Blocked by:
* Blocking:
* Updates:
**

 Language 
* Blocked by:
* Blocking:
* Updates:
**

=== Readers ===
 iOS native app 
* Blocked by:
* Blocking:
* Updates:
**6.2.1 is in beta
https://phabricator.wikimedia.org/tag/ios-app-v6.2.1-beluga-on-stilts/
***Find & Replace
***Editing onboarding
***Other bug fixes & editing enhancements

 Android native app 
* Blocked by:Android is ready with the ‘Suggested Edits’ for a beta
release. Blocked by API production release.
* Blocking:
* Updates:
**Ready for enhanced search feature in ‘My Lists’. Waiting for an upstream
fix.
**Minor enhancement on Tablet.

 Readers Web 
* Blocked by:
* Blocking:
* Updates:
** Summary: deploying advanced mobile contributions, planning for next
year, and continuing the MobileFrontend architecture investment project.
** Responsive website (MinervaNeue / MobileFrontend):
*** Advanced mobile contributions
https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
 Deploy to Arabic, Indonesian, and Spanish Wikipedias
 Tag Thanks actions with AMC tag T215477
 Cannot access user contributions when following red link to user page
on mobile T201339
*** Invest in the MobileFrontend & MinervaNeue frontend architecture
https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture
 Refactor ImageOverlay T216198
 Refactor NotificationOverlay T217296
 Refactor TalkSectionAddOverlay T217102
*** QuickSurveys
 Consultation and support for Research
*** ExternalGuidance extension review and support
*** Miscellaneous bug fixes and maintenance T218069 T218731 T198534 T218173
** Desktop website (Popups)
*** Popups https://www.mediawiki.org/wiki/Page_Previews
 WMDE reference previews review and support T67114
https://meta.wikimedia.org/wiki/WMDE_Technical_Wishes/ReferencePreviews
 Bugfix for double pokey on some page previews T204627
** Planning
*** RFC: Section headings should have a clickable anchor T18691
*** RFC: Add a frontend build step to skins/extensions to our deploy
process T199004
*** RFC: Let's stop using QUnit as a mechanism for integration tests T212521
*** MobileFrontend & MinervaNeue frontend architecture planning for next
fiscal year

 Readers Infrastructure 
* Blocked by: enabling the WikimediaEditorTasks extension in production is
blocked on performance review (https://phabricator.wikimedia.org/T218087 )
* Blocking: Android Suggested Edits feature final testing & rollout blocked
on WikimediaEditorTasks APIs being available in production (see "Blocked
By")
* Updates:
** WikimediaEditorTasks
*** The extension is code-complete for launch but is blocked on a
performance review requested as an outcome of security review

 Multimedia 
* Updates
** adding 'depicts' statements almost ready - expecting to get onto
testcommons next week
** next release under way too - new Search UI for depicts statements
** working on qunit tests for MediaInfo extension

 Parsing 
* Blocked by:
** Parsing Team requesting SRE to take a look at
https://phabricator.wikimedia.org/T213493
* Blocking:
* Updates:
** 

[Wikitech-l] Small change to wmf apache log format

[Alexandros Kosiaris]

In light of the gerrit incidents these last few days, and as part of
the process of strengthening gerrit's operational security, we 've
just gone ahead and configured gerrit to add the User: HTTP header on
the response. To take advantage of that, we 've also amended the wmf
apache LogFormat directive to log that header if it exists. I 've
documented the change in
https://wikitech.wikimedia.org/wiki/Apache_log_format.

Note that the order of fields changes just a bit (the last field is
now 17 instead of 16, the 16th is now the User: HTTP header if it
exists, otherwise a -). If you are aware of anything that might break
because of that let us know.

Regards,

-- 
Alexandros Kosiaris
Senior Site Reliability Engineer
Wikimedia Foundation

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Wikidata now officially has more total edits than English language Wikipedia

[Ariel Glenn WMF]

Wikidata surpassed the English language Wikipedia in the number of
revisions in the database, about 45 minutes ago today.I was tipped off by a
tweet [1] a few day ago and have been watching via a script that displays
the largest revision id and its timestamp. Here's the point where Wikidata
overtakes English Wikipedia (times in UTC):

[ariel@bigtrouble wikidata-huge]$ python3 ./get_revid_info.py -d
www.wikidata.org -r 888603998,888603999,888604000
revid 888603998 at 2019-03-20T06:00:59Z
revid 888603999 at 2019-03-20T06:00:59Z
revid 888604000 at 2019-03-20T06:00:59Z
[ariel@bigtrouble wikidata-huge]$ python3 ./get_revid_info.py -d
en.wikipedia.org -r 888603998,888603999,888604000
revid 888603998 at 2019-03-20T06:00:59Z
revid 888603999 at 2019-03-20T06:00:59Z
revid 888604000 at 2019-03-20T06:01:00Z

Only 45 minutes later, the gap is already over 2000 revsions:

[ariel@bigtrouble wikidata-huge]$ python3 ./compare_sizes.py
Last enwiki revid is 888606979 and last wikidata revid is 888629401
2019-03-20 06:46:03: diff is 22422

Have a nice day!

Ariel

[1] https://twitter.com/MonsieurAZ/status/1106565116508729345
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l