Hello all,
I am pleased to announce that the GitLab consultation is now open.
The open discussion period is set to run for 4 weeks, starting today.
Please see the consultation page for all of the details regarding how
the consultation will work:
https://www.mediawiki.org/wiki/GitLab_consultation
And the associated talk page where we welcome and encourage your engagement:
https://www.mediawiki.org/wiki/Talk:GitLab_consultation
Thank you,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| Dir. Engineering Productivity A18D 1138 8E47 FAC8 1C7D |
Dear all,
We’re really happy to announce the second edition of the Coolest Tool Award
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award>!
Tools play an essential role at Wikimedia, and so do the many volunteer
developers who experiment with new ideas, develop & maintain local & global
solutions and enhance the experience for Wikimedia communities.
There are incredible many great tools out there. It’s time to celebrate
this & to make the great work volunteer developers do more visible to
everyone :-)
The Coolest Tool Award ceremony will take place virtually this year, given
the current circumstances around events and travel. We will provide more
details soon about the specific logistics and dates.
The award is organized & selected by the *Coolest Tool Academy 2020*
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award#Coolest_Tool_Award_2020>.
We plan to recognize the greatest tools in a variety of categories, for
examples you can look at last year’s categories
<https://meta.wikimedia.org/wiki/Coolest_Tool_Award/2019>.
As no one can possibly know all the cool tools out there, we’re looking for
some help & inspiration: Please point us to the tools that you think are
great - out of any reason you can think of!
Please use this form:
https://docs.google.com/forms/d/e/1FAIpQLSf5ZmXXamn9sRsagEiiZcUZDn1Ga0sF3Xm…
to recommend tools *by October 14, 2020*. You can nominate as many tools as
you want by filling out the form multiple times.
This survey will be conducted via a third-party service, which may subject
it to additional terms. For more information on privacy and data-handling,
see the survey privacy statement:
https://foundation.wikimedia.org/wiki/Coolest_Tool_Award_2020_Survey_Privac…
Thank you very much for your ideas & recommendation(s)!
We will continue to spread the word over the next 1-2 days, but if you get
the chance, please feel welcome to share this information with others too!
Thanks :-)
Joaquin, for the Coolest Tool Academy 2020
--
Joaquin Oltra Hernandez
Developer Advocate - Wikimedia Foundation
[crosspost from Maps-l]
Today the Wikimedia Foundation is announcing the deprecation of the public
API for Wikimedia map tiles. Around mid October the Foundation will end
support for the Wikimedia Maps Service API [1]. This change affects people
using Wikimedia maps on their own website or app. Maps on the Wikimedia
sites, in Wikimedia-hosted tools and gadgets, and on maps.wikimedia.org
won't be affected.
This decision was made based on recent outage incidents, primarily due to
spikes in third party usage, along with an analysis showing that more than
a third of maps provided are to non-Wikimedia services (including many to
for-profit organizations).
After the most recent incident [2], the service was limited so that only
cached maps tiles would be available. While this protected the servers, it
made the service unpredictable and highlighted the unsustainability of our
tile service. So, we have made the decision to discontinue the maps APIs
for non-Wikimedia users.
This change will allow our teams working on Maps to focus on the
sustainability of the maps used within Wikimedia projects.
You can follow the implementation of this change on Phabricator [3].
Best,
Erica Litrenta
[1] https://maps.wikimedia.org/osm-intl/
[2] https://wikitech.wikimedia.org/wiki/Incident_documentation/20200204-maps
[3] https://phabricator.wikimedia.org/T261424
--
Erica Litrenta
Manager, Community Relations Specialists
https://meta.wikimedia.org/wiki/User:Elitre_(WMF)
Hello,
This email contains updates for September 30, 2020. For the HTML version,
see: https://www.mediawiki.org/wiki/Scrum_of_scrums/2020-09-30
Cheers,
Deb
------------------------
*= 2020-09-30 =*
== Product ==
=== iOS native app ===
* Updates:
** Released minor bug fix version [[phab:project/view/4831/|6.7.1]]
*** Widgets bugs/polish and Chinese variant fix
** In development on [[phab:project/view/4992/|6.7.2]]
*** Article as a Living Document experiment
=== Structured Data ===
* Updates: "beta" milestone for mediasearch
** A/B testing of the mediasearch algorithm in Special:Search on commons
showed a strong preference for the new search, so we're all v pleased about
that \o/
=== Abstract Wikipedia ===
* Updates:
** Voting in the
[[metawiki:Abstract_Wikipedia/Wiki_of_functions_naming_contest|community
naming contest]] for what to call the central wiki of functions is underway.
** Initial Vue rich editing interface has landed, with huge thanks to
Arthur P. Smith.
** Currently working on using ZType data to enforce structure when editing
ZObjects.
** Next up, converting the Vue editing interface into a hybrid view/edit
mode.
== Technology ==
=== Site Reliability Engineering ===
* Updates:
** Almost all services now behind TLS and the services proxy for talking to
each other. A minor outage for citoid, but otherwise going pretty well.
--
deb tankersley (she/her)
sr program manager, engineering
Wikimedia Foundation
I am happy to announce the belated availability of the general release of
MediaWiki 1.35!
Tarballs have already been uploaded, and the git tag has been pushed.
Thanks to everyone who helped out with this release, especially thanks to
those who tested out the release candidates and provided feedback, as well
as the developers who worked hard to get several important fixes merged in
time for the 1.35 final release. To see what's changed in 1.35, see the
release notes below.
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.3.19.
MediaWiki 1.35 is an LTS and is due to be supported until the end of
September 2023.
As a reminder, 1.31 is due to become end of life in June 2021. 1.34 is due
to become end of life in November 2020.
As per the pre-release announcement, 1.35.0 also includes some security
fixes that weren't in the release candidates, which came out yesterday for
the ther supported MediaWiki branches.
Known/outstanding issues:
* VisualEditor and Parsoid are now bundled in the tarball and no longer
need a separate Node.js service. The documentation for this still may still
require some updates. Please report any bugs [2] if this affects you.
* (T259685) Zeroconf (zero-configuration) VisualEditor/Parsoid doesn't work
using SQLite as the database backend for MediaWiki. This is due to the lack
of write concurrency in SQLite. If you wish to use this feature, it is
recommended to use MySQL/MariaDB rather than SQLite.
* Watchlist expiry (behind the $wgWatchlistExpiry flag) is currently still
experimental. It should become stable in a later point release. Please
report any issues/bugs [3].
== Security fixes ==
* (T232568, CVE-2020-25813) SECURITY: SpecialUserrights: If a viewer lacks
`hideuser`, ignore hidden users.
* (T255918, CVE-2020-25812) SECURITY: Unescaped message used in HTML on
Special:Contributions.
* (T256171, CVE-2020-25815) SECURITY: Unescaped message used in HTML within
LogEventsList.
* (T258763, CVE-2020-17367, CVE-2020-17368) SECURITY: Prevent invoking
firejail's --output functionality.
* (T86738, CVE-2020-25814) SECURITY: mediawiki.jqueryMsg: Sanitize URLs and
'style' attribute.
* (T115888, CVE-2020-25828) SECURITY: mediawiki.js: Escape HTML in
mw.message( ... ).parse().
* (T260485, CVE-2020-25869) SECURITY: ActorMigration: Load user from the
correct database.
* (T260485, CVE-2020-25869) SECURITY: ensure actor ID from correct wiki is
used.
* (T251661, CVE-2020-25827) SECURITY: TOTP throttle not enforced cross-wiki.
== Links to all mentioned tasks ==
* https://phabricator.wikimedia.org/T232568
* https://phabricator.wikimedia.org/T255918
* https://phabricator.wikimedia.org/T256171
* https://phabricator.wikimedia.org/T258763
* https://phabricator.wikimedia.org/T86738
* https://phabricator.wikimedia.org/T115888
* https://phabricator.wikimedia.org/T260485
* https://phabricator.wikimedia.org/T251661
=== Changes since MediaWiki 1.35.0-rc.3 ===
* (T261258) Remove checks for ancient ImageMagick versions in BitmapHandler.
* (T260232) Don't include null page ids in query list for category dumps.
* (T260009) Check existing watchitem when saving action=watch.
* (T259055) Correct success messages for action=watch.
* mediawiki.page.ready: Simpler tablesorter/makeCollapsible call.
* mediawiki.page.ready: Fix skin override config flags, wrong way round.
* (T262175, T248512) Remove requirement for ApiWatchlistTrait to be in
ApiBase.
* (T259053, T260434) Watchlist: Fix updateWatchLink removing css class when
action=watch.
* (T261901, T261476) mediawiki.notification: Don't close notif when
clicking <select> element.
* (T251506) Sanitizer: Truncate IDs to a reasonable length.
* (T259452) Parsoid updated to v0.12.0.
* (T261970) watch.ajax: Add expiry support to watchpage.mw event.
* (T262900) Fix failure of rebuildLocalisationCache.php due to
ResourceLoader hook.
* (T263014) Hard deprecate File::userCan() with $user=null.
* (T262547) Use localized success message after watching via action=watch.
* (T201491) Fix typo 'Watchlst' in `apihelp-edit-param-watchlistexpiry`.
* (T261081) Installer: consistently reset Language objects.
* (T250449, T250450) Installer: consistently reset Language objects.
* Explicitly wrap some XML calls in libxml_disable_entity_loader().
* (T262934) Ensure dropdown label is always on its own line.
* (T246855) resourceloader: Use a local HookRunner.
* (T263604) Have findBadBlobs.php require Maintenance.php rather than
cleanupTable.inc.
* (T263606) Set fake time, to avoid flaky tests.
* (T261325) Add FindMissingActors script.
* (T262364) shell: Don't blacklist /run/firejail.
* (T263655) NewPagesPager: Ignore nonexistent namespaces.
* Update specialPageAliases and magicWords for Egyptian Arabic (arz).
* (T261347) ParserOutput: don't throw on bad editsection.
* (T255918, CVE-2020-25812) SECURITY: Unescaped message used in HTML on
Special:Contributions.
* (T256171, CVE-2020-25815) SECURITY: Unescaped message used in HTML within
LogEventsList.
* (T258763, CVE-2020-17367, CVE-2020-17368) SECURITY: Prevent invoking
firejail's --output functionality.
* (T86738, CVE-2020-25814) SECURITY: mediawiki.jqueryMsg: Sanitize URLs and
'style' attribute.
* (T115888, CVE-2020-25828) SECURITY: mediawiki.js: Escape HTML in
mw.message( ... ).parse().
* (T260485, CVE-2020-25869) SECURITY: ActorMigration: Load user from the
correct database.
* (T260485, CVE-2020-25869) SECURITY: ensure actor ID from correct wiki is
used.
* Add Finnish special page aliases.
* Fix GuzzleHttpRequest request headers.
* Fix description for pruneFileCache.php.
* emptyUserGroup.php: handle more than 5000 users.
* Make ApiSandbox copyable URL absolute.
* (T261087) Add a link from a deleted page to that page's logs.
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-…
[3]
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.tar.gz
Download without bundled extensions:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0.tar.gz
Patch to previous version (1.35.0-rc.3):
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.patch.gz
GPG signatures:
https://releases.wikimedia.org/mediawiki/1.35/mediawiki-core-1.35.0.tar.gz.…https://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.tar.gz.sighttps://releases.wikimedia.org/mediawiki/1.35/mediawiki-1.35.0.patch.gz.sig
Public keys:
https://www.mediawiki.org/keys/keys.html
Release Notes
https://www.mediawiki.org/wiki/Release_notes/1.35
This is the weekly TechCom board review in preparation of our meeting. If
there are additional topics for TechCom to review, please let us know by
replying to this email. However, please keep discussion about individual
RFCs to the Phabricator tickets.
Activity since Monday 2020-09-21 on the following boards:
https://phabricator.wikimedia.org/tag/techcom/https://phabricator.wikimedia.org/tag/techcom-rfc/
Committee inbox:
- T263904 <https://phabricator.wikimedia.org/T263904>: Are traits part
of the stable interface?
- New question by @DannyS712.
Committee board activity:
- T227776 <https://phabricator.wikimedia.org/T227776>: General
ParserCache service class for large "current" page-derived data
- @daniel's team will soon start work on this project.
- T244058 <https://phabricator.wikimedia.org/T244058>: Strategy for
storing old revisions in ParserCache.
- @daniel analyzed various code paths relating to this.
New RFCs:
- T263841 <https://phabricator.wikimedia.org/T263841>: RFC: Expand API
title generator to support other generated data
- @matthiasmullie started an RFC with interest from Structured Data
and Search Platform teams.
Phase progression:
- T240775 <https://phabricator.wikimedia.org/T240775>: RFC: Support PHP
7.4 preload
- Moves to P3.
- Interest from the Performance Team.
- T260714: <https://phabricator.wikimedia.org/T260714> RFC: Parsoid
Extension API
- Moves to Last Call to be *Approved* on 7 Oct.
- T487 <https://phabricator.wikimedia.org/T487>: RFC: Associated
namespaces
- Moves to Last Call to be *Declined* on 7 Oct.
- @tgr mentions that Bask Wikipedia (eu.wikipedia.org) has a "
Txikipedia <https://eu.wikipedia.org/wiki/Txikipedia:Azala>"
namespace that could benefit from this.
IRC meeting request: (none)
Other RFC activity:
- T260330: <https://phabricator.wikimedia.org/T260330> RFC: PHP
microservice for containerized shell execution
- @tstarling wrote an example to demonstrate how the Score extension
could work.
- T250406 <https://phabricator.wikimedia.org/T250406>: RFC: Hybrid
extension management
- @RHeigl asks about next steps.
- T120085 <https://phabricator.wikimedia.org/T120085>: RFC: Serve Main
Page of Wikimedia wikis from a consistent URL
- @bblack indicates their team considers this an Epic Idea™. Thank
you Brandon.
-- Timo
Hi all,
> *Summary *Push Notifications are now available to enable on all wikis for
> Android & iOS Wikipedia apps
*Background:*
- Wikimedia Product teams needed a new way to drive user engagement and
retention for features like "Thank You's" and "Edit Reminders"
- Similar to web and email notifications, editors receive quick
notifications outside of using the native apps
- Push notifications are a way to send messages to user devices without
the user engaging with the application
- The Product Infrastructure team[1] designed and built the underlying
infrastructure[2] to provide the push notification capability for other
product teams to leverage
- This first release of v1.0.0 provides the following features:
- App users can now receive notifications sooner, even when the app
is not currently running
- App users can subscribe and unsubscribe to receive Echo
notifications
- Echo can send messages to the user via native Wikipedia apps for
Android and iOS
- The system can limit the rate and volume of messages to prevent
server overload
- Invalid subscriptions are automatically removed from the system
upon notification request failure
- You can find more information on our MediaWiki[2] and WikiTech
pages[3]
[1]
https://www.mediawiki.org/wiki/Wikimedia_Product/Wikimedia_Product_Infrastr…
[2]
https://www.mediawiki.org/wiki/Wikimedia_Product_Infrastructure_team/Push_N…
[3] https://wikitech.wikimedia.org/wiki/Push_notifications
Best,
--
Seve Kim *(he/him)*
Sr. Technical Product Manager
<https://wikimediafoundation.org/>
*"Imagine a world in which every single human being can freely share in the
sum of all knowledge. That's our commitment."*
Hello Everyone,
TL;DR:
New mailing list for local dev discussion ->
https://lists.wikimedia.org/mailman/listinfo/local-dev
New wiki page for updates ->
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Local_Dev…
This year’s developer satisfaction survey[0] revealed that many people felt
there wasn’t enough communication around local dev improvement efforts. In
fact, some people didn’t even know that there were any. The following is a
brief history of those efforts and an update on what we have in progress,
as well as some ways for us to communicate and keep informed about the
local development space.
A little under 2 years ago, I took on the task of developing a
container-based development environment for mediawiki and services,
partially since our production deployments are moving in that direction. As
someone who had never done development on Mediawiki and its surrounding
extensions and services, and whose job was not to do that development, this
was (and is) a challenge. Here’s a quick outline of what I, with other
contributors, did since then:
1. Coded and analyzed the 2019 developer satisfaction survey[1] and did
one on one interviews with developers to understand the problems faced by
developers.
- This research provided insights into areas in and out of the scope
of local development that probably deserve more attention
2. Created a prototype in minikube[2]
- Brennen Bearnes created the dev-images repo to support this work
- Demonstrated at the Prague Hackathon in 2019
- Did not generate much interest
- Confirmed suspicions that kubernetes is not an ideal tool for
developing
3. Led local-dev work group meetings
4. Presented findings and ideas at Tech Conf in 2019[3] with Brennen
- Together with session attendees, decided to create
mediawiki-docker[4], a lightweight dev solution for pure mediawiki
developers.
- Had another session to attempt to figure out what kinds of services,
etc, could be grouped together for more complex development environments,
but didn’t explain this in a way that session attendees understood, and
they probably left frustrated
5. Continued work on mediawiki-docker, and a cli[5] to simplify
repetitive docker commands
- Kosta Harlan, along with Brennen, Mukunda Modell, and James
Forrester headed this up
- Zeljko Fillipin (and a bunch of other people!) worked on
documentation of setting up a number of extensions to use with
mediawiki-docker, which indicates some adoption of mediawiki-docker
You can collaborate with us or track our progress by visiting our
phabricator work board[6]. Tasks welcome :)
As a preview, some open tasks are:
- Command-line wrapper for interacting with core's docker-compose stack -
https://phabricator.wikimedia.org/T246111
- Tasks under this task to make the CLI more useful
- Set up distribution of MediaWiki-Docker CLI -
https://phabricator.wikimedia.org/T250241
- Accomplishing this means devs can use cli commands to interact with
mediawiki-docker without cloning the cli repo and building the project
- Set up CI for mediawiki-docker -
https://phabricator.wikimedia.org/T248779
- So we can avoid regressions
We’re still exploring the best way to manage docker-compose files for
different extensions and services for a more complex development
environment.
To address the concerns about lack of communication in a more consistent
manner, I’d like to introduce a long-overdue way for us to have discussion
on local dev topics through a new local-dev mailing list:
https://lists.wikimedia.org/mailman/listinfo/local-dev. I’ve also created
this wiki page for updates about local-dev:
https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Local_Dev….
Since I’ve recently created this page, there is not much to see there at
the moment.
If you've made it this far, thanks for reading! I hope these changes will
help improve communication and collaboration with everyone who wants to
participate.
[0] https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey/2020
[1] https://www.mediawiki.org/wiki/Developer_Satisfaction_Survey/2019
[2] https://gerrit.wikimedia.org/g/releng/local-charts
[3]
https://docs.google.com/presentation/d/1ZuQGkzXylvJnPSmP4epKjsS7TghXvK99AwX…,
https://docs.google.com/presentation/d/15a5yxOyPGlOADIQ6D4MmxM7ucvkec2ySpeR…
[4] https://www.mediawiki.org/wiki/MediaWiki-Docker
[5] https://gerrit.wikimedia.org/g/mediawiki/tools/cli
[6] https://phabricator.wikimedia.org/tag/mediawiki-docker/
--
Jeena Huneidi
Software Engineer, Release Engineering
Wikimedia Foundation