Hello everyone,
Wikimedia is gearing up to apply as a mentoring organization for Google
Summer of Code 2024 <
https://www.mediawiki.org/wiki/Google_Summer_of_Code/2024>[1] and Outreachy
Round 28 <https://www.mediawiki.org/wiki/Outreachy/Round_28> [2].
Currently, we're crafting a list of exciting project ideas for the
application. If you have any suggestions for projects, whether coding or
non-coding (design, documentation, translation, outreach, research), please
share them by February 5th via this Phabricator task: <
https://phabricator.wikimedia.org/T354734> [3]. Note that for non-coding
projects eligible for Outreachy, slots are limited and will be allocated to
mentors on a first-come, first-serve basis.
Timeline
In your role as a mentor, your involvement spans the application period for
both programs, taking place from March to April. During this time, you'll
guide candidates in making small contributions to your project and address
any project-related queries they may have. As the application period
concludes, you'll further intensify your collaboration with accepted
candidates throughout the coding period, which extends from May to August.
Your support and guidance are crucial to their success in the program.
Guidelines for Crafting Project Proposals:
-
Follow this task description template when you propose a project in
Phabricator: <
https://phabricator.wikimedia.org/tag/outreach-programs-projects> [4].
You can also use this workboard to pick an idea if you don't have one
already. Add #Google- Summer-of-Code (2024) or #Outreachy (Round 28) tag.
-
Project should require an experienced developer ~15 days and a newcomer
~3 months to complete.
-
Each project should have at least two mentors, including one with a
technical background.
-
Ideally, the project has no tight deadlines, a moderate learning curve,
and fewer dependencies on Wikimedia's core infrastructure. Projects
addressing the needs of a language community are most welcome.
* Learn more about the roles and responsibilities of Mentors for both
programs:*
-
Outreachy: <https://www.mediawiki.org/wiki/Outreachy/Mentors> [5]
-
Google Summer of Code: <
https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors> [6]
Thank you,
Links:
[1] https://www.mediawiki.org/wiki/Google_Summer_of_Code/2024
[2] https://www.mediawiki.org/wiki/Outreachy/Round_28
[3] https://phabricator.wikimedia.org/T354734
[4] https://phabricator.wikimedia.org/tag/outreach-programs-projects
[5] https://www.mediawiki.org/wiki/Outreachy/Mentors
[6] https://www.mediawiki.org/wiki/Google_Summer_of_Code/Mentors
--
*Onyinyechi Onifade *
Technical Community Program Manager
Wikimedia Foundation <https://wikimediafoundation.org/>
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/
(If you don’t work with pagelinks table, feel free to ignore this message)
Hello,
Here is an update and reminder on the previous announcement
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>
regarding normalization of links tables that was sent around a year ago.
As part of that work, soon the pl_namespace and pl_title columns of
pagelinks table will be dropped and you will need to use pl_target_id
joining with the linktarget table instead. This is basically identical to
the templatelinks normalization that happened a year ago.
Currently, MediaWiki writes to both data schemes of pagelinks for new rows
in all wikis except English Wikipedia and Wikimedia Commons (we will start
writing to these two wikis next week). We have started to backfill the data
with the new schema but it will take weeks to finish in large wikis.
So if you query this table directly or your tools do, You will need to
update them accordingly. I will write a reminder before dropping the old
columns once the data has been fully backfilled.
You can keep track of the general long-term work in T300222
<https://phabricator.wikimedia.org/T300222> and the specific work for
pagelinks in T299947 <https://phabricator.wikimedia.org/T299947>. You can
also read more on the reasoning in T222224
<https://phabricator.wikimedia.org/T222224> or the previous announcement
<https://lists.wikimedia.org/hyperkitty/list/wikitech-l@lists.wikimedia.org/…>
.
Thank you,
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
Hi everyone,
tl;dr The tools we use to document Wikimedia JavaScript code are changing.
In the short term, you can read the complete MediaWiki core JavaScript docs
using the 1.41 version[0] while we migrate to the new system[1]. If you use
JavaScript documentation on doc.wikimedia.org, please share your feedback
on wiki[2].
Wikimedia JavaScript codebases are switching from using JSDuck[3] to
JSDoc[4] for documentation. Started in 2016, this migration is necessary
because JSDuck is currently unmaintained and does not support the ES6
standard[5]. Several Wikimedia JavaScript codebases, including Vector and
GlobalWatchlist, already use JSDoc, while several others, such as
VisualEditor and MediaWiki core, still use JSDuck.
The migration project consists of two parts: changing the codebases to
support JSDoc and improving the usability of the JSDoc WMF theme. For more
information, see phab:T138401[6].
== Migrating MediaWiki core to JSDoc ==
We are migrating MediaWiki core to JSDoc incrementally. While the migration
is in progress, the master branch docs will be incomplete, containing only
those modules that have been migrated. To read the old JSDuck docs, see the
MediaWiki 1.41 docs[0].
To help with migration, choose a module from the list in phab:T352308[7],
and follow the guide on phab:T138401[6] to translate the tags from JSDuck
to JSDoc.
== Migrating other codebases ==
You can find a list of codebases that use JSDuck on phab:T138401[6].
(Please add any that are missing.) To help migrate a codebase that uses
JSDuck, follow the instructions to set up JSDoc[8], and use the guide in
phab:T138401[6] to translate the tags from JSDuck to JSDoc.
== Improving the JSDoc WMF theme ==
One of the biggest differences between JSDuck and JSDoc is the HTML
interface for reading the docs. The WMF theme for JSDoc is not as
full-featured as the JSDuck theme, but to support this migration, the
Wikimedia Foundation Web, Design Systems, and Technical Documentation teams
are working to prioritize and complete a set of improvements to the JSDoc
theme, with the goal of releasing version 1 of jsdoc-wmf-theme in 2024.
If you use JavaScript documentation on doc.wikimedia.org, please leave a
comment on the JSDoc WMF theme talk page[2] and let us know how you use the
docs and which features of the theme are the most important to you.
Thank you for reading!
Alex, Kamil, Jon, Roan, and Anne
[0]: https://doc.wikimedia.org/mediawiki-core/REL1_41/js/
[1]: https://doc.wikimedia.org/mediawiki-core/master/js/
[2]: https://www.mediawiki.org/wiki/Talk:JSDoc_WMF_theme
[3]: https://github.com/senchalabs/jsduck
[4]: https://en.wikipedia.org/wiki/JSDoc
[5] https://en.wikipedia.org/wiki/ECMAScript
[6]: https://phabricator.wikimedia.org/T138401
[7]: https://phabricator.wikimedia.org/T352308
[8]: https://www.mediawiki.org/wiki/JSDoc
--
Alex Paskulin
Technical Writer
Wikimedia Foundation
Hello,
For many years, some classes in MediaWiki implemented the IDBAccessObject
interface (which only provides several public constants) and then would
call them indirectly (e.g. self::READ_NORMAL). Since these constants were
public, other parts of MediaWiki started to call them through the
implementing class as well (e.g. calling User::READ_LATEST).
This is inconsistent with the access pattern of other constants in
MediaWiki. it's also confusing (e.g. it's unclear to a newcomer why
UserFactory is implementing IDBAccessObject) and it's prone to clashes
(e.g. BagOStuff class has a clashing constant).
Since it's not possible to trigger a deprecation warning in such cases, It
can't follow the usual stable interface policy path [1] and here is the
email to wikitech-l as required by the policy.
In three weeks we will remove indirect access to these constants by
removing IDBAccessObject from implementation. This will take effect from
1.42 release.
Classes that won't have those constants anymore are including but not
limited to:
* User
* WikiPage (and its subclasses)
* File (and its subclasses)
* Title
* ActorStore
* RevisionStore
* UserOptionsManager
* And more.
To find such cases in extensions you maintain, you can search for
"(?<!IDBAccessObject)::READ_" (regex) and check if the constant being used
is an indirect call to IDBAccessObject. Be careful that there might be some
false positives such as custom defined constants, constants referring to
BagOStuff ones and similar cases like that.
We have already removed all cases in core and extensions deployed to
Wikimedia production.
You can follow the work and see examples of how the migration is done in
extensions (for example gerrit:993112
<https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Echo/+/993112>) in
T354194 <https://phabricator.wikimedia.org/T354194>.
[1] From the policy
<https://www.mediawiki.org/wiki/Stable_interface_policy#Hard_deprecation>:
"If it is not reasonably possible for the deprecated code to emit
deprecation warnings, hard deprecation can be applied by announcing the
removal on wikitech-l in a timely manner."
Thank you and sorry for the inconvenience,
--
*Amir Sarabadani (he/him)*
Staff Database Architect
Wikimedia Foundation <https://wikimediafoundation.org/>
Tomorrow at 8.30am PST / 4.30pm UTC there will be an expected downtime of
https://gitlab.wikimedia.org services for a few minutes.
A server is physically moving to a new rack. We expect maximum 10 minutes
but more likely just 5 minutes of downtime.
Nothing will change about the software or data itself. Just don't plan a
deployment during this time please. Thank you
--
Daniel Zahn <dzahn(a)wikimedia.org>
Site Reliability Engineer
Hi.
The definition of revision databases was published and also
demonstrated. It was demonstrated on file
"skwiki-20240101-pages-meta-history.xml.bz2". It might be interesting
for you. More: https://archive.org/details/revision-database
Dušan Kreheľ
We have changed the name of API Platform to MediaWiki Interfaces Team
<https://www.mediawiki.org/wiki/MediaWiki_Interfaces_Team> (MWI). Our aim
is to better align the branding of the team with the work we do and expand
the scope of the work we will do within MediaWiki Engineering
<https://www.mediawiki.org/wiki/MediaWiki_Engineering_Group>.
MediaWiki Interfaces aligns with our efforts to work on APIs (Action and
REST), Hooks, and some extensions - the systems that individuals and teams
use to interface with MediaWiki. We also support teams looking to build
features and fixes atop MediaWiki in coordination with our sibling teams,
MediaWiki Platform and Content Transform. Use the #mw-interfaces-team
*How do I reach your team on Phabricator?*
Use the #mw-interfaces-team
<https://phabricator.wikimedia.org/tag/mw-interfaces-team/> tag to get
items onto our radar. If you're unsure, use the #mediawiki-engineering tag
and we will look at it as a group and determine the best team to own the
issue.
What happens to the API Platform Phab tag?
We will keep the #api_platform phabricator tag
<https://phabricator.wikimedia.org/tag/api_platform/>, The type has changed
from “group” to “umbrella”. MWI will continue to monitor the board for the
next 2 quarters for incoming issues and triage them.
What happened to the MediaWiki-Interface Phab tag?
Since this tag is related to the UI of MediaWiki, we have renamed the tag
to #mediawiki-ui <https://phabricator.wikimedia.org/tag/mediawiki-ui/> to
be more in line with its purpose. The #mediawiki-interface tag will remain
as a way to redirect to the UI workboard.
--
Frantz Joseph
Sr. Engineering Manager | MediaWiki Engineering