Hello all,
The Technical Decision-Making Forum Retrospective team
<https://www.mediawiki.org/wiki/Technical_decision_making> invites you to
complete a survey about Wikimedia's technical decision-making processes.
While there will be more ways to participate, this is the first and most
important step in our data collection. It aims to gather information about
your experience, thoughts, and needs regarding the process of making
technical decisions across the Wikimedia technical spaces.
This survey will be used for gathering information about the process and
the needs around technical decision-making that touches our production
systems.
You can find the survey link here:
https://wikimediafoundation.limesurvey.net/885471?lang=en
Who should take this survey?
People who do technical work that relies on software maintained by the
Wikimedia Foundation (WMF) or affiliates. If you contribute code to
MediaWiki or extensions used by Wikimedia, or you maintain gadgets or tools
that rely on WMF infrastructure, this survey is for you.
What is the deadline?
*August 7th, 2023 *
What will the Retrospective team do with the information?
The retrospective team will synthesize the collected data and publish an
anonymized analysis that will help leadership make decisions about the
future of the process.
We will collect anonymized information that we will analyze in two main
ways:
-
Sentiments based on demographic information: these will tell us whether
there are different needs and desires from different groups of people.
-
General needs and perceptions about decision-making in our technical
spaces: This will help us understand what kind of decisions happen in
the spaces, who is involved, and how to adjust our processes accordingly.
Is the survey the only way to participate?
The survey is the most important way for us to gather information because
it helps us gather input in a structured manner. But it will not be the
only way you can share your thoughts with us - we will have more
information soon about upcoming listening sessions where you can talk with
us live. In the meantime, you are always welcome to leave feedback on the
talk page:
https://www.mediawiki.org/wiki/Talk:Technical_decision_making/Technical_Dec…
Where can I see more information?
There are several places where you can find more information about the
Technical Decision-Making Process Retrospective:
-
The original announcement about the retrospective from Tajh Taylor:
https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…
-
The Technical Decision-Making Process general information page:
https://www.mediawiki.org/wiki/Technical_decision_making
-
The Technical Decision-Making Process Retrospective on MediaWiki:
https://www.mediawiki.org/wiki/Technical_decision_making/Technical_Decision…
-
Phabricator ticket: https://phabricator.wikimedia.org/T333235
How to contact the retrospective core team:
-
Write to the core team mailing list: tdf-retro-2023(a)lists.wikimedia.org
-
The Technical Decision-Making Process Retrospective on MediaWiki talk
page:
https://www.mediawiki.org/wiki/Talk:Technical_decision_making/Technical_Dec…
Thank you,
Moriel, on behalf of the TDMP Retro Core Group
Core group:
-
Moriel Schottlender (chair)
-
Daniel Kinzler
-
Chris Danis
-
Kosta Harlan
-
Temilola Adeleye
--
Moriel Schottlender (she/her <https://pronoun.is/she>)
Principal Software Engineer
Wikimedia Foundation https://wikimediafoundation.org/
Hello folks!
does anybody know if this extension is still maintained? The latest
commit is from May 16, 2020.
There are older tickets about SCI being not compatible with SWM 4.0.0
(and therefore not compatible with MW1.39 which will become EOL end of
2023).
Sorin
Yesterday there was a conversation about code review on irc and among other
things, how sometimes patches can get "stuck".
I had an idea for a way to improve things. I'm not sure if it is a good
idea, but there's only one way to find out.
So without further ado, announcing the Code Review Patch Board:
https://www.mediawiki.org/wiki/Code_review/patch_board
In short - each person is allowed to list one of their patches on the board
that they would really like to see reviewed. You can only list one patch at
a time, and it should be a patch that you have been unable to get review
for for at least a week through normal means. See the page for the full
list of guidelines.
I encourage people to give it a try. Add a patch you wrote that you cannot
get a review for. Or if you have +2 rights, try giving some love to these
underloved patches.
I would also love to hear feedback on the general idea as well as the
current guidelines.
To repeat, the url is:
https://www.mediawiki.org/wiki/Code_review/patch_board
Thanks,
bawolff
Hello all!
The Search Platform Team usually holds an open meeting on the first
Wednesday of each month. Come talk to us about anything related to
Wikimedia search, Wikidata Query Service (WDQS), Wikimedia Commons Query
Service (WCQS), etc.!
Feel free to add your items to the Etherpad Agenda for the next meeting.
Details for our next meeting:
Date: Wednesday, October 4, 2023
Time: 15:00-16:00 UTC / 08:00 PT / 11:00 EDT / 17:00 CET
Etherpad: https://etherpad.wikimedia.org/p/Search_Platform_Office_Hours
Google Meet link: https://meet.google.com/vgj-bbeb-uyi
Join by phone: https://tel.meet/vgj-bbeb-uyi?pin=8118110806927
Have fun and see you soon!
Guillaume
--
*Guillaume Lederrey* (he/him)
Engineering Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi all! This is an announcement for a new developer feature in MediaWiki.
If you don’t develop MediaWiki core, extensions or skins, you can stop
reading :)
MediaWiki interface messages are generally “safe” to edit: when they
contain markup, it is either parsed (as wikitext), sanitized, or fully
HTML-escaped. For this reason, administrators are allowed to edit normal
messages on-wiki in the MediaWiki: namespace, while editing JS code (which
is more dangerous) is restricted to interface administrators. (A few
exceptions, messages that are not escaped and which can only be edited by
interface administrators, are configured in $wgRawHtmlMessages
<https://www.mediawiki.org/wiki/Special:MyLanguage/Manual:$wgRawHtmlMessages>.)
Occasionally, a bug in the software means that a message isn’t properly
escaped, which can in theory be abused by administrators to effectively
gain interface administrator powers (by editing a MediaWiki: page for a
message to contain <script> tags, or onclick="" attributes, or whatever).
Such bugs are usually considered low-severity security issues; some of them
are tracked in T2212 <https://phabricator.wikimedia.org/T2212>. (The
general issue is known as cross-site scripting
<https://www.mediawiki.org/wiki/Special:MyLanguage/Cross-site_scripting>
and can be much more severe when it’s not limited to interface messages.)
Previously, checking for these issues as a developer was tedious: if you
suspected that a message was vulnerable to HTML injection, you had to
create a page for it in the MediaWiki: namespace, or edit the corresponding
en.json file on disk (and potentially rebuild the localisation cache). The
recently merged “xss language code” feature simplifies this process. If the
developer setting $wgUseXssLanguage is set to true, then an “x-xss”
language code becomes available and can be selected with *?uselang=x-xss*
in the URL. When using this language code, all messages become “malicious”:
every message is replaced by a snippet of HTML that tries to run alert('
*message-key*'). If everything is implemented correctly, all of those HTML
snippets should be escaped, and no alerts should fire, although the wiki
will look quite strange:
If you see any alert, then that means that a message has not been escaped
correctly; use the message key shown in the alert to hunt down the buggy
code (or add the message key to $wgRawHtmlMessages). This feature is
intended to be especially useful during code review: check out the change,
load a page with ?uselang=x-xss, and see if any alerts come up.
Miscellaneous notes:
- This is a developer-only feature. I strongly recommend against
setting $wgUseXssLanguage
= true; in any production setting. (It will be added to
DevelopmentSettings.php soon.)
- Above, I focused on the possibility to abuse unescaped messages via
the MediaWiki: namespace. You might also be thinking about the potential
for translatewiki.net contributors to inject malicious HTML into message
translations; however, the translation exports from translatewiki.net to
the JSON files automatically check for any HTML in translations, and flag
suspicious cases for human review. Therefore, it’s much harder to exploit
an unescaped message via translatewiki.net than via the MediaWiki:
namespace.
- Finally, I should mention that we already found several
vulnerabilities using this feature, which will be fixed with the upcoming
security release
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>.
If you try out this feature now, and find a vulnerable message, I suggest
you wait until then, and check whether it’s still vulnerable, before
reporting it.
Cheers,
Lucas
--
Lucas Werkmeister (he/er)
Software Engineer
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0)30-577 11 62-0
https://wikimedia.de
Imagine a world in which every single human being can freely share in the
sum of all knowledge. Help us to achieve our vision!
https://spenden.wikimedia.de
Wikimedia Deutschland — Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Charlottenburg, VR 23855 B.
Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin,
Steuernummer 27/029/42207.
Hello folks!
For some years now, I've been the main or only point of contact for the
Wiki project sql/xml dumps semimonthly, as well as for a number of
miscellaneous weekly datasets.
This work is now passing to Data Platform Engineering (DPE), and your new
points of contact, starting right away, will be Will Doran (email:wdoran)
and Virginia Poundstone (email:vpoundstone). I'll still be lending a hand
in the background for a little while but by the end of the month I'll have
transitioned into a new role at the Wikimedia Foundation, working more
directly on MediaWiki itself.
The Data Products team, a subteam of DPE, will be managing the current
dumps day-to-day, as well as working on a new dumps system intended to
replace and greatly improve the current one. What formats will it produce,
and what content, and in what bundles? These are all great questions, and
you have a chance to help decide on the answers. The team is gathering
feedback right now; follow this link [
https://docs.google.com/forms/d/e/1FAIpQLScp2KzkcTF7kE8gilCeSogzpeoVN-8yp_S…]
to give your input!
If you want to follow along on work being done on the new dumps system, you
can check the phabricator workboard at
https://phabricator.wikimedia.org/project/board/6630/ and look for items
with the "Dumps 2.0" tag.
Members of the Data Products team are already stepping up to manage the
xmldatadumps-l mailing list, so you should not notice any changes as far as
that goes.
And as always, for dumps-related questions people on this list cannot
answer, and which are not covered in the docs at
https://meta.wikimedia.org/wiki/Data_dumps or
https://wikitech.wikimedia.org/wiki/Dumps you can always email ops-dumps
(at) wikimedia.org.
See you on the wikis!
Ariel Glenn
ariel(a)wikimedia.org
Hello All,
Welcome to the second edition of the monthly MediaWiki Insights
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports> email!
Since the beginning of July, the Foundation has dedicated MediaWiki product
leadership and a new MediaWiki engineering group
<https://www.mediawiki.org/wiki/MediaWiki_Engineering_Group>.
In August
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/August_20…>,
we’ve shared a broad overview on the focus for the next few quarters:
1. Building up the new MW Engineering group and MW Product function
2. Developing a strategy for MediaWiki - by June 30th, 2024 [WMF Annual
Plan, WE3
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/…>
]
3. Reaching a 20% increase of authors to selected MediaWiki repositories
deployed in Wikimedia production - by June 30th, 2024 [WE3.2]
4. Investing in developer experiences and reduce fragmentation of
developer workflows [WE 3.1] - continuous work with specific deliverables
in 2023/24
5. Exploring and resolving a set of questions around stewardship and
Open Source strategy (goes beyond MediaWiki) [WE3.3]
We’re still in the process of “settling in” (1.), but also made progress on
a few things that we wanted to start tackling early:
Stewardship
We’ve had conversations within the MediaWiki Engineering group
<https://www.mediawiki.org/wiki/MediaWiki_Engineering_Group> on which
components we should prioritize initially/own directly and what the things
are that we’d primarily provide guidance on. While this is work in progress
and also touches on bigger questions, one notable decision is that MW
Engineering takes on stewardship for the authentication-related components
(in MW core and extensions), with support from the Security team. We’ve
resolved outstanding code stewardship requests for the CentralAuth
<https://phabricator.wikimedia.org/T252244> and Oauth
<https://phabricator.wikimedia.org/T224919> extensions as a consequence of
this decision. These changes and other updates are reflected on the developers
and maintainers page <https://www.mediawiki.org/wiki/Developers/Maintainers>
on MW.org.
MediaWiki within Wikimedia’s ecosystem: Update on interviews
So far we’ve interviewed about 40 people on their experiences with
MediaWiki within Wikimedia’s ecosystem and plan a few more interviews. We
expect to be able to wrap up this first round of research in October and to
share the outcome and conclusions in November. These conversations have
been incredibly helpful - many thanks to all the people who took the time
to share their thoughts or still will do so <3
You can find a tentative timeline and overview on research planned
throughout the next few quarters on this page
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights#Research_pillars_…>
.
Project snapshot: Source Maps and top-level autologin
Over the past few weeks, the MediaWiki Engineering group has been working
on a mix of onboarding tasks (i.e. ResourceLoader, ActionAPI, CentralAuth),
production errors, long term initiatives (Parsoid Read Views, RESTBase
deprecation), consultancy, code review for staff and volunteers’ patches,
and completed projects that had been in the making for a while. A few
snapshots:
Source Maps <https://web.dev/source-maps/> aim to make debugging in web
development easier. It’s a technique for mapping combined and minified
JavaScript back to the original files. Support for source maps is now
implemented in ResourceLoader
<https://www.mediawiki.org/wiki/ResourceLoader>, to aid with debugging
ResourceLoader in production. You can learn more about this work in this
ticket. <https://phabricator.wikimedia.org/T47514> <3 to Tim, Timo and
others for their work on this!
Browsers increasingly roll out anti-tracking measures and limitations on
third-party cookie use. An unfortunate side effect of this is that it also
impacts CentralAuth autologin. One way to mitigate the effects and to allow
auto-login when the browser blocks third-party cookies is to attempt
central auto-login via top-level navigation. This has been enabled in
September. You can learn more about this work in this ticket
<https://phabricator.wikimedia.org/T326281>. <3 to Gergö and others for the
work on this!
Onboarding, among other means, has continued via the weekly Code Mob
sessions: Check out the recordings on this page
<https://meta.wikimedia.org/wiki/User:BPirkle_(WMF)/Code_Mobs_2023> if you
want to follow along.
Next: Enable more people to know MediaWiki and contribute effectively
A key question this year is how we can grow the number of people willing
and able to contribute to MediaWiki. So far we’ve explored approaches and
focus areas, turned some aspects of this already into active practice
through code review and consultancy for teams whose projects touch
MediaWiki core; and came up with first ideas that may help new MediaWiki
contributors (example <https://phabricator.wikimedia.org/T347347>).
We’ll be sharing more about this work and possible initiatives in October,
which is when we “officially” start with working towards an increase of
authors across a specific set of MW repositories that are deployed to
production (WMF Annual Plan, WE3.2
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024/…>
).
Thanks all for reading! - Have a great weekend,
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>
>
> If the developer setting $wgUseXssLanguage is set to true, then an “x-xss”
> language code becomes available and can be selected with *?uselang=x-xss*
> in the URL. When using this language code, all messages become “malicious”:
> every message is replaced by a snippet of HTML that tries to run alert('
> *message-key*').
Clever feature - this will be great for testing. Thank you!
-Yaron
--
WikiWorks · MediaWiki Consulting · http://wikiworks.com