Hello,
This email contains updates for the last two weeks - August 5 and 12, 2020.
For the HTML versions, see:
https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-08-05https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-08-12
Cheers,
Deb
------------------------
*= 2020-08-05 =*
== Callouts ==
* FYI: Removing our old helm charts endpoint (<nowiki>
https://releases.wikimedia.org/charts</nowiki>) and moving to a new one,
powered by chartmuseum. <nowiki>https://helm-charts.wikimedia.org/</nowiki>.
if you are using helm locally with the old repo, you will have to switch to
the new one. On the plus side, this is integrated with our CI now and no
longer requires manually creating helm chart artifacts. Docs at <nowiki>
https://wikitech.wikimedia.org/wiki/ChartMuseum</nowiki>
== Product ==
=== iOS native app ===
* Blocked by:
* Blocking:
* Updates:
** Continuing development on [[phab:project/view/4661/|6.7 release]].
*** "Article as a living document" experiment
*** Event Platform Client MVP
*** iOS14 widgets & bug fixes
=== Web ===
* Updates:
**'''Summary''': Desktop Improvements Project's (DIP) deployment continues;
continuing WVUI Vector integration and the network client now has a
MediaWiki REST API implementation in review.
** [[Reading/Web/Desktop_Improvements|Desktop Improvements Project (Vector
/ DIP)]]:
*** [[phab:T250968|[ShoutWikiAds] Replace use of deprecated hook
VectorBeforeFooter]]
*** [[phab:T254227|Switch test wikis to new version of vector by default]]
*** [[phab:T253842|Fix the printable versions of modern Vector]]
*** [[phab:T250851|Allow skins to override mediawiki.page.ready
initialisation to enable search JavaScript to be swapped]]
*** [[phab:T249363|Move the existing search to the header in preparation
for Vue.js search development]]
*** [[phab:T259372|Refactor: Move PHP logic into JS for collapsing tabs
under more menu]]
*** [[phab:T257647|Integrate WVUI into Vector for Vue.js search]]
*** [[phab:T251212|[Dev] Drop VectorTemplate usage in Vector]]
*** [[phab:T248399|Document Skin API and their stability, if any (including
Vector)]]
*** [[phab:T247790|wgLogos follow up work]]
*** [[phab:T255319|Eventually deprecate SkinTemplateNavigation::SpecialPage
and SkinTemplateNavigation hooks in favor of
SkinTemplateNavigation::Universal]]
*** [[phab:T244392|Vue.js search case study]]:
**** See [[Reading/Web/Desktop Improvements/Vue.js case study/Status
log|weekly status updates]].
** Mobile website (MinervaNeue / MobileFrontend):
*** [[phab:T259080|Minerva bundle checks are broken]]
*** [[phab:T257872|Uncaught Error: Set map center and zoom first on mobile
domain Android]]
*** [[phab:T258096|Regression: Nested references do not open if user clicks
on [ or ] (which are wrapped in span)]]
** Standardization
*** [[phab:T250762|UsersMultiselectWidget not announcing status message]]
*** [[phab:T248062|Deprecate and remove `.background-image-svg()` mixin
from 'mediawiki.mixins.less']]
*** [[phab:T259086|Remove obsolete 'set-graphics'/'svg2png'/'imagemin'
tasks and Less background-image raster fallback for former Grade C browser
support]]
*** [[phab:T254195|Implement a core 'clearfix' mixin in mediawiki.mixin and
evaluate deprecation/removal of 'visualClear' class]]
*** [[phab:T258752|Unify `line-height` to `20px` in widgets to simplify
code and better i18n]]
*** [[phab:T257279|Standardize 'mediawiki.ui' variables to CSS variables
naming scheme in preparation for WikimediaUI Base variables takeover]]
*** [[phab:T247033|Add 'i18n-directionality.less' file to core and extract
overarching theme styles from legacy.less]]
** Portals
*** [[phab:T128546|[Recurring Task] Update Wikipedia and sister projects
portals statistics]]
** Miscellaneous
*** [[phab:T258256|<nowiki>OOUI window management broken on pages with with
additional frames, due to cross document access</nowiki>]]
*** [[phab:T255913|Document tagline and icon options of $wgLogos by putting
them in the installer]]
*** [[phab:T253047|TypeError: undefined is not an object (evaluating
'mw.config.get('wgFormattedNamespaces')[namespace].replace')]]
*** [[phab:T257877|MediaWiki installer appears unstyled]]
== Technology ==
=== Site Reliability Engineering ===
* Blocked by:
** None
* Blocking:
** None
* Updates:
** Removing our old helm charts endpoint (<nowiki>
https://releases.wikimedia.org/charts</nowiki>) and moving to a new one,
powered by chartmuseum. <nowiki>https://helm-charts.wikimedia.org/</nowiki>.
if you are using helm locally with the old repo, you will have to switch to
the new one. On the plus side, this is integrated with our CI now and no
longer requires manually creating helm chart artifacts. Docs at <nowiki>
https://wikitech.wikimedia.org/wiki/ChartMuseum</nowiki>
------------------------
*= 2020-08-12 =*
== Product ==
=== Web ===
* Updates:
** '''Summary''': WVUI Vector integration in Vector, Vue.js-focused week
starting.
** [[Reading/Web/Desktop Improvements|Desktop Improvements Project (Vector
/ DIP)]]:
*** [[phab:T258493|[Spike 8hrs] "Use Legacy Vector" is not working as a
global preference]]
*** [[phab:T254227|Switch test wikis to new version of vector by default]]
*** [[phab:T250851|Allow skins to override mediawiki.page.ready
initialisation to enable search JavaScript to be swapped]]
*** [[phab:T249363|Move the existing search to the header in preparation
for Vue.js search development]]
*** [[phab:T248399|Document Skin API and their stability, if any (including
Vector)]]
*** [[phab:T244392|Vue.js search case study]]:
**** See [[Reading/Web/Desktop Improvements/Vue.js case study/Status
log|weekly status updates]].
** Mobile website (MinervaNeue / MobileFrontend):
*** [[phab:T240622|[Technical debt payoff] Remove InlineDiffFormatter and
InlineDifferenceEngine from MobileFrontend]]
** Standardization
*** [[phab:T248062|Deprecate and remove `.background-image-svg()` mixin
from 'mediawiki.mixins.less']]
*** [[phab:T259086|Remove obsolete 'set-graphics'/'svg2png'/'imagemin'
tasks and Less background-image raster fallback for former Grade C browser
support]]
*** [[phab:T257279|Standardize 'mediawiki.ui' variables to CSS variables
naming scheme in preparation for WikimediaUI Base variables takeover]]
** Portals
*** [[phab:T128546|[Recurring Task] Update Wikipedia and sister projects
portals statistics]]
** Miscellaneous
*** [[phab:T259955|Skin hooks should not have unexpected side effects to
OutputPage]]
*** [[phab:T259630|TypeError: results.error is undefined]]
*** [[phab:T259400|Drop MonoBookAfterContent hook]]
*** [[phab:T259193|[betalabs] FF only - Notifications - vertical scrolling
in the header]]
*** [[phab:T258488|MenuTagMultiselectWidget removes selected tag if invalid
input is entered]]
*** [[phab:T258420|MenuTagMultiselect adds items twice if specified as
options and selected options]]
*** [[phab:T258256|<nowiki>OOUI window management broken on pages with with
additional frames, due to cross document access</nowiki>]]
*** [[phab:T250968|[ShoutWikiAds] Replace use of deprecated hook
VectorBeforeFooter]]
*** [[phab:T203023|skins.monobook.mobile.uls dependency doesn't do mobile?]]
*** [[phab:T259354|ActionField + dropdown styling issues]]
*** [[phab:T259316|Drop Monobook/resources/screen-desktop.css from
Monobook]]
*** [[phab:T258752|Unify `line-height` to `20px` in widgets to simplify
code and better i18n]]
*** [[phab:T257015|Redeploy quicksurvey on enwiki (for a Growth study)]]
Hi Everyone,
Mark your calendars! Wikimedia Tech Talks 2020 Episode 6 will take
place on Wednesday
on 12 August 2020 at 17:00 UTC.
Title: Retargeting extensions to work with Parsoid
Speaker: Subramanya Sastry
Summary:
The Parsing team is aiming to replace the core wikitext parser with Parsoid
for Wikimedia wikis sometime late next year. Parsoid models and processes
wikitext quite differently from the core parser (all that Parsoid
guarantees is that the rendering is largely identical, not the specific
process of generating the rendering). So, that does mean that extensions
that extend the behavior of the parser will need to adapt to work with
Parsoid instead to provide similar functionality [1]. With that in mind, we
have been working to more clearly specify how extensions need to adapt to
the Parsoid regime.
At a high level, here are the questions we needed to answer:
1) How do extensions "hook" into Parsoid?
2) When the registered hook listeners are invoked by Parsoid, how do they
process any wikitext they need to process?
3) How is the extension's output assimilated into the page output?
Broadly, the (highly simplified) answers are as follows:
1) Extensions now need to think in terms of transformations (convert this
to that) instead of events (at this point in the pipeline, call this
listener). So, more transformation hooks, and less parsing-event hooks.
2) Parsoid provides all registered listeners with a ParsoidExtensionAPI
object to interact with it which extensions can use to process wikitext.
3) The output is treated as a "fully-processed" page/DOM fragment. It is
appropriately decorated with additional markup and slotted into place into
the page. Extensions need not make any special efforts (aka strip state) to
protect it from the parsing pipeline.
In this talk, we will go over the draft Parsoid API for extensions [2] and
the kind of changes that would need to be made. While in this initial
stage, we are primarily targeting extensions that are deployed on the
Wikimedia wikis, eventually, all MediaWiki extensions that use parser hooks
or use the "parser API" to process wikitext will need to change. We hope to
use this talk to reach out to MediaWiki extension developers and get
feedback about the draft API so we can refine it appropriately.
[1] https://phabricator.wikimedia.org/T258838
[2] https://www.mediawiki.org/wiki/Parsoid/Extension_API
The link to the Youtube Livestream can be found here:
<https://www.youtube.com/watch?v=jNNy8ALGjaE>
https://www.youtube.com/watch?v=lS1xPkERWCM
During the live talk, you are invited to join the discussion on IRC at
#wikimedia-office
You can browse past Tech Talks here:
https://www.mediawiki.org/wiki/Tech_talks
If you are interested in giving your own tech talk, you can learn more here:
https://www.mediawiki.org/wiki/Project:Calendar/How_to_schedule_an_event#Te…
Kindly,
Sarah R. Rodlund
Senior Technical Writer, Developer Advocacy
<https://meta.wikimedia.org/wiki/Developer_Advocacy>
srodlund(a)wikimedia.org
Hi,
we've released v0.40.0 and follow-up hot fix v0.40.1 of OOUI library
last Friday.
It will rollout on the normal train tomorrow, Tuesday, 11 August.
Highlights in this release:
- Removal of Internet Explorer 8 specific code and fallbacks, largely
reducing size of CSS (~800+ lines on all icons) due to removal of PNG
fallback images, relying only on SVG icons from here on. This is going
to have a positive performance impact for all other users of the
library.
This is in alignment with approved RFC on removing IE 8 Basic support
for MediaWiki core.[0]. Hence, this release is a breaking release. If
you need continuous support in your environment for IE 8 you need to
stick with v0.39.3.
You can find details on additional new features, code-level, styling
and interaction design amendments, and all improvements since v0.38.0
in the full changelog[1].
If you have any further queries or need help dealing with breaking
changes, please let me know.
As always, interactive demos[2] and library documentation is available
on mediawiki.org[3], there is comprehensive generated code-level
documentation and interactive demos and tutorials hosted on
doc.wikimedia.org[4].
OOUI version: 0.40.1
MediaWiki version: 1.36.0-wmf.4
Date of deployment to production: Regular train, starting Tuesday 11 August
[0] - https://phabricator.wikimedia.org/T248061
[1] - https://gerrit.wikimedia.org/g/oojs/ui/+/v0.40.1/History.md
[2] - https://doc.wikimedia.org/oojs-ui/master/demos/#widgets-mediawiki-vector-ltr
[3] - https://www.mediawiki.org/wiki/OOUI
[4] - https://doc.wikimedia.org/oojs-ui/master/
Best,
Volker
Hi All
tl;dr: Don't deploy on Thursday except for emergencies; the deployment
calendar on Wikitech
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_August_10> is
up-to-date.
Friday of next week (2020-08-14) is a wmf holiday. As such, Thursday should
be treated as Friday for the purposes of deployment; that is, no
deployments on Thursday except for emergencies
<https://wikitech.wikimedia.org/wiki/Deployments/Emergencies>.
This has implications for the (1.36.0-wmf.4) train—we'll be going to all
wikis on Wednesday evening UTC rather than Thursday evening UTC:
- Tue, 11 Aug, EU Train Window, 13:00 UTC: Group0
- Wed, 12 Aug, EU Train Window, 13:00 UTC: Group1
- Wed 12 Aug, US Train Window, 19:00 UTC: All Wikis
Hopefully, this will allow time for manual testing on Group0 wikis, and
allow us to complete the train on time.
<3
-- Tyler
Hey,
I have an ethical question that I couldn't answer yet and have been asking
around but no definite answer yet so I'm asking it in a larger audience in
hope of a solution.
For almost a year now, I have been developing an NLP-based AI system to be
able to catch sock puppets (two users pretending to be different but
actually the same person). It's based on the way they speak. The way we
speak is like a fingerprint and it's unique to us and it's really hard to
forge or change on demand (unlike IP/UA), as the result if you apply some
basic techniques in AI on Wikipedia discussions (which can be really
lengthy, trust me), the datasets and sock puppets shine.
Here's an example, I highly recommend looking at these graphs, I compared
two pairs of users, one pair that are not sock puppets and the other is a
pair of known socks (a user who got banned indefinitely but came back
hidden under another username). [1][2] These graphs are based one of
several aspects of this AI system.
I have talked about this with WMF and other CUs to build and help us
understand and catch socks. Especially the ones that have enough resources
to change their IP/UA regularly (like sock farms, and/or UPEs) and also
with the increase of mobile intern providers and the horrible way they
assign IP to their users, this can get really handy in some SPI ("Sock
puppet investigation") [3] cases.
The problem is that this tool, while being built only on public
information, actually has the power to expose legitimate sock puppets.
People who live under oppressive governments and edit on sensitive topics.
Disclosing such connections between two accounts can cost people their
lives.
So, this code is not going to be public, period. But we need to have this
code in Wikimedia Cloud Services so people like CUs in other wikis be able
to use it as a web-based tool instead of me running it for them upon
request. But WMCS terms of use explicitly say code should never be
closed-source and this is our principle. What should we do? I pay a
corporate cloud provider for this and put such important code and data
there? We amend the terms of use to have some exceptions like this one?
The most plausible solution suggested so far (thanks Huji) is to have a
shell of a code that would be useless without data, and keep the code that
produces the data (out of dumps) closed (which is fine, running that code
is not too hard even on enwiki) and update the data myself. This might be
doable (which I'm around 30% sure, it still might expose too much) but it
wouldn't cover future cases similar to mine and I think a more long-term
solution is needed here. Also, it would reduce the bus factor to 1, and
maintenance would be complicated.
What should we do?
Thanks
[1]
https://commons.wikimedia.org/wiki/File:Word_distributions_of_two_users_in_…
[2]
https://commons.wikimedia.org/wiki/File:Word_distributions_of_two_users_in_…
[3] https://en.wikipedia.org/wiki/Wikipedia:SPI
--
Amir (he/him)
I'm pleased to announce the immediate availability of MediaWiki
1.35.0-rc.1, the second release candidate for 1.35.x, the next LTS version
to replace 1.31 which is due to go end of life in June 2021. Download links
at the end of the e-mail. The tag has been signed and pushed to Git.
Please note that the PHP version requirement has been raised from 7.2.9 in
MediaWiki 1.34 (and 7.0 in MediaWiki 1.31), to 7.2.22 (this may change
further, see below).
This is not a final release and should not be used for production websites.
Known issues are tracked in Phabricator on the release workboard [1]. As
always please do try out the release candidate in a test environment and
report any issues that you discover. Please use the #MW-1.35-Release [2]
tag in Phabricator when reporting issues specific to this release.
It is expected that MediaWiki 1.35 will become final in late August 2020,
and will be supported for 3 years after that.
Known/outstanding issues/things to test:
* It has been proposed to require PHP 7.3 for MediaWiki 1.35, please
discuss at <https://phabricator.wikimedia.org/T257879>.
* Both the Vector skin and the underlying skin infrastructure are
undergoing numerous changes, so there might be things broken that are
already fixed in master and as such need backporting.
* VisualEditor and Parsoid are now bundled in the tarball and no longer
need a separate nodejs service. The documentation for this still needs to
be updated, and in some cases, users are reporting HTTP 500 errors from
RestBase <https://phabricator.wikimedia.org/T259693>.
* Watchlist expiry (behind the $wgWatchlistExpiry flag) is currently
experimental. It should be finished for the 1.35.0 final release.
* If you're on Windows and use 7zip, you may experience issues extracting
the tarball. This was noted in the last set of security releases. Try using
a different decompression tool <https://phabricator.wikimedia.org/T257102>.
Changes since 1.35.0-rc.0:
* (T252136) Fix RecentChanges watchlist filters when WatchlistExpiry is off.
* (T258662) Update time period for watchlist expiry pop-up.
* (T258443) Fix expiry dropdown not getting disabled on edit page.
* (T259398) Add license information for promise-polyfill.
* Remove executable bit from scripts without shebang.
* (T256526) Fix bold of watched items on Special:RecentChangesLinked.
* (T259060) Edit page expiry dropdown should keep state after
disabling/enabling.
* (T259009) Translate expiry period in pop-up message for watchlist expiry.
* (T258310) Add watchlist clock icon to RecentChanges.
* (T259362) Permit temporary table writes on replica DB connections.
* (T250214) Add UI support in Special:EditWatchlist for watchlist expiry.
* (T72470) Disable wgLegacyJavaScriptGlobals by default.
* (T130906) Add Edge to MediaWiki:Clearyourcache.
* (T257279) Add mediawiki.ui Less variable deprecation note.
* (T249521) Fixed reassignEdits.php to work with anonymous users.
* (T259448) Fix Circular dependency when creating service in
DBLoadBalancerFactory.
* (T257259) Default to using watchlist expiry of old page when moving pages.
Preliminary release notes:
https://phabricator.wikimedia.org/source/mediawiki/browse/REL1_35/RELEASE-N…https://www.mediawiki.org/wiki/Release_notes/1.35
Open Bugs:
[1] https://phabricator.wikimedia.org/project/board/4035/
Bug report form:
[2]
https://phabricator.wikimedia.org/maniphest/task/edit/form/1/?tags=MW-1.35-…
**********************************************************************
Download:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0-rc.1.tar.gz
Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0-rc.1.ta…
Patch to previous version (1.35.0-rc.0):
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0-rc.1.patch.gz
GPG signatures:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0-rc.1.ta…https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0-rc.1.tar.gz.…
Public keys:
https://www.mediawiki.org/keys/keys.html
Hello,
can you check last two patches from this URL:
https://gerrit.wikimedia.org/r/q/status:open+owner:zorandori4444%2540gmail.…
?
As tests pass now, I believe that they are good to get +2 now.
Best regards,
Zoran Dori
volunteer, Wikimedia Serbia
s: kizule.xyz e: zorandori4444(a)gmail.com
*Imagine a world in which every single human being can freely share inthe
sum of all knowledge.*
The 1.36.0-wmf.3 version of MediaWiki is currently blocked at group0.[0]
The new version can proceed no further until these issues are resolved
or appropriately triaged:
* Uncaught ArgumentCountError: Too few arguments to function
OOUI\Tag::appendContent(), 0 passed
- https://phabricator.wikimedia.org/T259745
* Argument 3 passed to
CachingFallbackLabelDescriptionLookup::buildCacheKey() must be of the
type string, null given
- https://phabricator.wikimedia.org/T259744
Thanks for any help resolving these issues. If they're handled by
roughly 14:30 PDT / 21:30 UTC today, the train can roll forward.
Otherwise it can resume during US working hours on Thursday.
-- Your typical train temporizer
[0]. <https://phabricator.wikimedia.org/T257971>
[1]. <https://tools.wmflabs.org/versions/>
