Re: [Wikitech-l] The ref tag parameter follow in non wikisource wikis

[billinghurst]

Presumably because it is part of Extension:Cite, not part of 
Extension:Proofread; and the two extensions operate individually, and 
Cite is independent of any particular wiki.


-- billinghurst

-- Original Message --
From: "יגאל חיטרון" 
To: "Wikimedia developers" 
Sent: 13/12/2018 5:03:16 AM
Subject: [Wikitech-l] The ref tag parameter follow in non wikisource 
wikis



Hello.
Could you explain me, please, why the  tag parameter follow= is 
not
turned off in wiki sites that are not wikisource? Who needs it there at 
all?

Thank you,
Igal (User:IKhitron)




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

Re: [Wikitech-l] Life hack: Working with production content in your local wiki

[Jon Robson]

As an experiment (and be bold etc), I've enabled this for the mobile domain
on the enwiki beta cluster [1]. If you hit any problems with these please
let me know on the ticket [2] and I or somebody else can revert the
associated config change.

What this means, is live content from production wikis will now appear on
mobile beta cluster pages which do not have a beta cluster version. For
example, https://en.m.wikipedia.beta.wmflabs.org/wiki/Spain shows content
from the beta cluster, but
https://en.m.wikipedia.beta.wmflabs.org/wiki/Singapore shows content from
English Wikipedia. In the case of the latter a 404 response code is sent,
to ensure these pages do not get indexed by search engines. This means that
it shouldn't interfere with any browser tests (Minerva beta cluster tests
are still passing [3])

This is beneficial for testing out real world content within the context of
a skin e.g. timeless, vector or minerva. We have many frontend bugs that
were difficult to test before this technique. My team has been using this
on labs [4] for many months now and it's been pretty indefensible to us, so
my thinking is it will be useful to others working with skins.

If it's useful, in future this technique can be used for desktop and other
projects on the beta cluster e.g. wikivoyage BC [5] - just let me know!

In the unlikely event this breaks any kind of testing you are trying to do,
please point your frustrations at me via the ticket [2] and I'll roll this
experiment back immediately and you would have given me valuable insights
into ways to improve this tool!

[1] https://en.m.wikipedia.beta.wmflabs.org
[2] https://phabricator.wikimedia.org/T207508
[3]
https://integration.wikimedia.org/ci/view/Reading-Web/job/selenium-MinervaNeue/
[4] https://reading-web-staging.wmflabs.org
[5] https://en.wikivoyage.beta.wmflabs.org/

On Mon, Feb 5, 2018 at 10:57 AM Jon Robson  wrote:

> I've been meaning to document this for a while.
> If you're finding yourself visiting Special:Export/Import often for the
> purpose of MediaWiki development there is a much better way to get content
>  into your local wiki for testing purposes.
>
> This short video explains how MobileFrontend extension provides tooling to
> help you debug live on-wiki content via $wgMFContentProviderClass [1]
> https://youtu.be/uRQzjN0hBlY
>
> Hope it saves someone lots of time!
>
> [1]
> https://github.com/wikimedia/mediawiki-extensions-MobileFrontend/blob/master/README.md#wgmfcontentproviderclass
> --
> Jon Robson
> Senior Software Engineer
>
-- 
Jon Robson
Senior Software Engineer
twitter: @jdlrobson
linkedin: https://www.linkedin.com/in/jorobson/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Wikimedia production excellence (November 2018)

[Jon Robson]

On Tue, Dec 11, 2018, 9:18 PM Krinkle  wrote:

>  Read this post on Phabricator at
> https://phabricator.wikimedia.org/phame/live/1/post/129/
> ---
>
> How’d we do in our strive for operational excellence last month? Read on to
> find out!
>
> - Month in numbers.
> - Current problems.
> - Highlighted stories.
>
> ##  *Month in numbers*
>
> * 4 documented incidents in November 2018. [1]
> * 42 Wikimedia-prod-error tasks closed in November 2018. [2]
> * 36 Wikimedia-prod-error tasks created in November 2018. [3]
> * 165 currently open Wikimedia-prod-error tasks (as of 12 December 2018).
>
> Terminology:
> * An *Exception* (or fatal) causes user actions to be prevented. For
> example, a page would display  “Exception: Unable to render page”, instead
> the article content.
> * An *Error* (or non-fatal, or warning) can produce page views that are
> technically unaware of a problem, but may show corrupt, incorrect, or
> incomplete information.  Examples – an article would display the code word
> “null” instead of the actual content, a user looking for Vegetables may be
> taken to an article about Vegetarians, a user may receive a notification
> that says “*You have (null) new messages.*”
>
> With that behind us... Let’s celebrate this month’s highlights!
>
> ## *️⃣ *DB exception at wikitech.wikimedia.org
> *
>
> Quiddity reported that he was unable to disable a spam account, due to a
> fatal exception. Andre Klapper used the Exception ID to find the stack
> trace in the logs. The trace revealed that a table was missing in
> Wikitech’s database.
>
> The MediaWiki software was recently expanded with a “Partial blocking”
> ability. [4] This involved introducing a new database table that stores
> block metadata differently. This software update was deployed to Wikitech,
> but this new table was not created.
>
> @Marostegui (Database administrator) quickly applied the schema patches
> that create the missing table. Thanks Manuel, Andre, and Quiddity;
> Teamwork!
>
> – https://phabricator.wikimedia.org/T209674
>
> ## *️⃣ *Big-page Deletion Unleashed!*
>
> It had been known for years, [5] that users are unable to delete or restore
> pages with more than a few hundred revisions. Attempts to do so could fail,
> with a fatal “DBTransactionSizeError” exception. This error indicates that
> the change is too big or too slow. Such changes risk replication lag, and
> may impact the stability of the infrastructure.
>
> The database structure used by MediaWiki for page archives dates back to
> 2003 (over 15 years ago). I'll spare you the details, but it depends on
> database interactions that are inherently slow when applied to systems as
> big as Wikipedia! RFC T20493 intends to modernise this structure for the
> long-term.
>
> Then along came @BPirkle. Bill joined the WMF Core platform team earlier
> this year. He took on the challenge of making page deletion work for any
> size page, today.
>
> Previously, page deletion happened in a single step. This simple approach
> had the benefit of either succeeding in its entirety, or safely rolling
> back like nothing happened. It also meant that the database protected us
> against conflicting changes. In August, Bill started a two-month effort
> that carefully split the logic for “delete a page” into smaller steps that
> each are safe and quick. It now uses our JobQueue to schedule and run these
> steps, without the user waiting for it.
>
> –  https://phabricator.wikimedia.org/T198176 /
> https://gerrit.wikimedia.org/r/456035
>
> ##  *Current problems*
>
> Take a look at the workboard and look for tasks that might need your help.
> The workboard lists known issues, grouped by the week in which they were
> first observed.
>
> →  https://phabricator.wikimedia.org/tag/wikimedia-production-error/
>
> I’d like to draw attention to a subset of PHP fatal errors. Specifically,
> those that are publicly exposed (e.g. don’t require elevated user rights)
> and use an HTTP 500 status code.
>
> * CentralNotice: Some Special:CentralNoticeBanners urls fatal. –
> https://phabricator.wikimedia.org/T149240
> * Flow: Unable to view certain talk pages due to workflow
> InvalidDataException. – https://phabricator.wikimedia.org/T70526
> * JsonConfig: Unable to diff certain “.map” pages on Commons. –
> https://phabricator.wikimedia.org/T203063
> * MediaWiki (Parser): Parse API exposes fatal content model error. –
> https://phabricator.wikimedia.org/T206253
> * MediaWiki (Special-pages): Special:DoubleRedirects unavailable on ttwiki.
> – https://phabricator.wikimedia.org/T204800
> * MobileFrontend: Some Special:MobileDiff urls fatal. –
> https://phabricator.wikimedia.org/T156293



Note this is not a mobilefrontend issue but an issue with the MassMessage
extension - it impacts desktop too

See
https://www.mediawiki.org/w/index.php?title=User%3AQuiddity%2Fdemomodel=revision=2234116=2234115

>
> * ProofreadPage: Unable to edit certain pages on Wikisource. –
> 

[Wikitech-l] Wikistats2 - Metrics available for project families

[Nuria Ruiz]

Hello!

The Analytics team would like to announce that we have now in Wikistats2
metrics available for what we are calling (for the lack of a better name)
"project families". That is, "all wikipedias", "all wikibooks"..etc

See, for example, bytes added by users to all wikibooks in the last month:
https://stats.wikimedia.org/v2/#/all-wikibooks-projects/content/net-bytes-difference/normal|bar|1-Month|editor_type~user

And "all wikibooks top editors" [2]:

https://stats.wikimedia.org/v2/#/all-wikibooks-projects/contributing/top-editors/normal|table|1-Month|editor_type~user

Not all metrics are available per project, most notably we (yet) do not
have pageviews. As always please file bugs [2] if you find any, and let us
know what can we do better.

Thanks,

Nuria

[1] https://meta.wikimedia.org/wiki/Research:Wikistats_metrics/Top_editors
[2]
https://phabricator.wikimedia.org/maniphest/task/edit/?title=Wikistats%20Bug=Analytics-Wikistats,Analytics
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] The ref tag parameter follow in non wikisource wikis

[יגאל חיטרון]

Hello.
Could you explain me, please, why the  tag parameter follow= is not
turned off in wiki sites that are not wikisource? Who needs it there at all?
Thank you,
Igal (User:IKhitron)
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Old tiles.wfmlabs.org maps services need maintainers to keep them alive after december 18th

[Andre Klapper]

On Wed, 2018-12-12 at 14:39 +0100, Derk-Jan Hartman wrote:
> This is just another small reminder that, because the servers which host
> tiles.wmflabs.org and wma.wmflabs.org (wikiminiatlas)  and overpass-wiki
> run on a version of the OS (Ubuntu Trusty) that is no longer supported (and
> hasn't been available for new instances since november 2017).
> 
> These services need maintainers and support by community members in order
> to keep them alive after dec 18th (after which wmflabs will phase out those
> versions) and before the EOL of early 2019 of the OS. Unfortunately it
> seems no one is stepping up so far to convert these machines.

Quick grep for "MediaWiki:Wikiminiatlas" in gadgets across sites lists
209 matches. (A good number might be wrapped in 'if' clauses though or
could be false positives.) https://phabricator.wikimedia.org/P7911

Problem might welcome a heads-up on technical village pumps to reach a
broader audience (and reduce surprise if this wasn't working anymore)?

andre
-- 
Andre Klapper | Bugwrangler / Developer Advocate
https://blogs.gnome.org/aklapper/



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

[Wikitech-l] 2018-12-12 Scrum of Scrums meeting notes

[Grace Gellerman]

https://www.mediawiki.org/wiki/Scrum_of_scrums/2018-12-12

=*2018-12-12*=
== Callouts ==
* Fundraising campaigns
https://meta.wikimedia.org/wiki/CentralNotice/Calendar
* Dec 24th and Dec 31st are freeze weeks.
* Goal planning in progress. If you have requests from SRE, now is the time
to do so.
** Session Service RFC is heading to last call ending Wednesday December
12th 1pm PST https://phabricator.wikimedia.org/T206010
* Release Engineering: No Train weeks of December 24th and December 31st


== 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: None. Thanks to Editing for updates on Blocket tasks.
* Blocking:
* Updates:
**

=== Readers ===
 iOS native app 
* Blocked by:
* Blocking:
* Updates:
**

 Android native app 
* Blocked by:
* Blocking:
* Updates:
** Released minor update to production:
https://phabricator.wikimedia.org/diffusion/APAW/history/master/;r/2.7.268-r-2018-12-07


 Readers Web 
* Blocked by:
* Blocking:
* Updates:
** Summary: mostly MobileFrontend architecture project tasks and some
advanced mobile contributions planning.

** Mobile website (MinervaNeue / MobileFrontend):

*** Invest in the MobileFrontend & MinervaNeue frontend architecture
https://www.mediawiki.org/wiki/Reading/Web/Projects/Invest_in_the_MobileFrontend_%26_MinervaNeue_frontend_architecture
 MobileFrontend should not have a global event emitter T156186
 Collapse mobile.search* ResourceLoader modules into mobile.startup
T210207
 Reduce View inheritance and improve composition support T209007
 Add tests for Drawer and CtaDrawer T208920
 Webpackify watchstar T208921

*** Advanced mobile contributions
https://www.mediawiki.org/wiki/Reading/Web/Advanced_mobile_contributions
 Investigate opt-in audience and instrumentation T211195
 Team planning

*** Page issues
https://www.mediawiki.org/wiki/Reading/Web/Projects/Mobile_Page_Issues
 Distinct issues should not be grouped T202349
 Split pageIssues.js into smaller functions T211257
 Planning deployment to all wikis except enwiki on December 17th T210553

** Desktop website (Popups) https://www.mediawiki.org/wiki/Page_Previews
*** Maintenance T209314

** PDF rendering (Proton)
https://www.mediawiki.org/wiki/Reading/Web/PDF_Functionality
*** Remaining work tracked in deploy Proton T181084


 Readers Infrastructure 
* no updates this week

 Multimedia 
* Updates
**

 Parsing 
* Blocked by:
* Blocking:
* Updates:

 UI Standardization 
* Blocked by:
* Blocking:
* Updates:
** No OOUI release this week, work on scheduled last release of the year
next Tuesday ongoing.

== Technology ==
=== Analytics ===
* Blocked by:
* Blocking:
* Updates:
**

=== Cloud Services ===
* Blocked by:
* Blocking:
* Updates:
**

=== Fundraising Tech ===
* Blocked by:
* Blocking:
* Updates:
** Campaign going well so far
** FR-tech supporting the rest of the team with processor switching &
investigation
** CentralNotice tweaks such as reducing log spam for protection
** CiviCRM performance optimizations
** Getting new hire oriented
** Minor upgrades for CiviCRM components
** Still working on a form variant for payments-wiki

=== MediaWiki Core Platform ===
* Blocked by:
* Blocking:
* Updates:
**

=== Performance ===
* Blocked by:
**
* Blocking:
**
* Updates:
**

=== Release Engineering ===
* Blocked by:
* Blocking:
* Updates:
** Train Health:
*** Last week: No train due to the Release Engineering Offsite
*** This week: 1.33.0-wmf.8 deployment blockers
https://phabricator.wikimedia.org/T206662
 T211774 Full table scans on oldimage table - Anomie and Ladsgroup
probably fixed it, will move train forward after SoS and see
*** Next week: 1.33.0-wmf.9 deployment blockers
https://phabricator.wikimedia.org/T206663
*** No Train weeks of December 24th and December 31st

=== Research ===
* Blocked by: None
* Blocking: None
* Updates:
** Working on building a 'morelike' API for article recommendations:
*** https://phabricator.wikimedia.org/T201192 and subtasks
** Working on setting up a production pipeline for generating article
recommendations and importing them into the database:
*** https://phabricator.wikimedia.org/T208622
*** https://phabricator.wikimedia.org/T210844
** Research: Eliciting new editor interests:
***
https://meta.wikimedia.org/wiki/Research:Voice_and_exit_in_a_voluntary_work_environment/Elicit_new_editor_interests#Second_Online_Experiment
*** We had to delay sending out emails last week. We're sending them out
this week.

=== Scoring Platform ===
* Blocked by:
* Blocking:
* Updates:

=== Search Platform ===
* Blocked by:
* Blocking:
* Updates:
** Wikidata autocompletion A/B done, results positive, slight improvement
in click positions: 

[Wikitech-l] Old tiles.wfmlabs.org maps services need maintainers to keep them alive after december 18th

[Derk-Jan Hartman]

This is just another small reminder that, because the servers which host
tiles.wmflabs.org and wma.wmflabs.org (wikiminiatlas)  and overpass-wiki
run on a version of the OS (Ubuntu Trusty) that is no longer supported (and
hasn't been available for new instances since november 2017).

These services need maintainers and support by community members in order
to keep them alive after dec 18th (after which wmflabs will phase out those
versions) and before the EOL of early 2019 of the OS. Unfortunately it
seems no one is stepping up so far to convert these machines.

This issue is tracked at https://phabricator.wikimedia.org/T204506
As I was curious, I looked around on the tile server a bit and used what I
could find to update
https://wikitech.wikimedia.org/wiki/OSM_Tileserver#Technology_stack
This is all the information that I could gather, but i'm FAR from sure if
that is complete information and if I would break anything with a rebuild
basing myself on that info, so any information on missing elements etc.
would be appreciated. I've not gotten around to looking at wikiminiatlas.

If the services are not rebuild then likely they will just disappear at
some point for all layer variants. This includes the mapnik, black and
white, hill shading, hike bike layers. As I have no idea how many users of
these services there are, it is hard to say what the effect of that would
be.

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