Greetings, MediaWiki users and developers!
We are now accepting contributions for the 2024 MediaWiki Users and
Developers Conference [0], which will be held April 17-19 in Portland, OR,
USA. The deadline to submit a proposal is March 22. Sign up as soon as
possible at [1].
This will primarily be an in-person conference, however we will consider
remote presentations on a case-by-case basis.The first two days of the
conference will be reserved for presentations. The third day of the
conference will be a Create Camp, which will include tutorials, hands-on
presentations, and small group hacking sessions.
The MediaWiki Users and Developers Conference, formerly EMWCon, brings
together the community that makes up MediaWiki – those who develop for
MediaWiki, those who deploy MediaWiki, and those who use MediaWiki and are
enthusiastic about the software. MediaWiki is used every day in a variety
of contexts – educational projects, corporate knowledge bases, even online
hobbyist communities – all valuing MediaWiki for its flexibility and its
openness. By meeting together we can learn from our experiences and
continue to build a true community of support for MediaWiki.
Looking forward to seeing you in Portland!
- The MediaWiki Users and Developers Conference Organizing Committee:
James Hare - Conference Chair
Cindy Cicalese - Program Chair
Bryan Hilderbrand - Registration Chair
Jeffrey Wang - Social Chair
Ike Hecht - Sponsor Chair
Ryan Schmidt - Technology Chair
[0]
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…
[1]
https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_20…
As per the MediaWiki version lifecycle[1], I would like to announce the
formal end of life (EOL) of MediaWiki 1.38 as of today, Friday June 28,
2024.
1.40.4 is expected to be the last release for this branch.
This means that MediaWiki 1.40 will no longer receive maintenance or
security backports. It is therefore strongly discouraged that you continue
to use it.
It is recommended to upgrade either to MediaWiki 1.41, which will be
supported until December 2024, or 1.42, which will be supported until June
2025.
Thanks!
[1] https://www.mediawiki.org/wiki/Version_lifecycle
I've installed, ConfirmAccount, but what I really need is a bigger
stick: remove all occurrences of the link "Request Creation", so I
don't have to deal with the email messages associated with
ConfirmAccount. It's a Special page, so it's not something I can edit.
I expect disabling that page to be temporary. If I need to, I can
create an account as an administrator, so it's not a total loss.
Please help.
--
_______________________________________________________________
Bob Smith - bsmith(a)sudleyplace.com
http://www.sudleyplace.com - http://www.nars2000.org
Hello all,
The Code of Conduct Committee is a team of five trusted individuals (plus
five auxiliary members) with diverse affiliations responsible for general
enforcement of the Code of conduct for Wikimedia technical spaces.
Committee members are in charge of processing complaints, discussing with
the parties affected, agreeing on resolutions, and following up on their
enforcement. For more on their duties and roles, see
https://www.mediawiki.org/wiki/Code_of_Conduct/Committee.
This is a call for community members interested in volunteering for
appointment to this committee. Volunteers serving in this role should be
experienced Wikimedians or have had experience serving in a similar
position before.
The current committee is doing the selection and will research and discuss
candidates. Six weeks before the beginning of the next Committee term, they
will publish their candidate slate (a list of candidates) on-wiki. The
community can provide feedback on these candidates, via private email to
the group choosing the next Committee. The feedback period will be two
weeks. The current Committee will then either finalize the slate, or update
the candidate slate in response to concerns raised. If the candidate slate
changes, there will be another two week feedback period covering the newly
proposed members. After the selections are finalized, there will be a
training period, after which the new Committee is appointed. The current
Committee continues to serve until the feedback, selection, and training
process is complete.
If you are interested in serving on this committee or like to nominate a
candidate, please write an email to techconductcandidates AT wikimedia.org
with details of your experience on the projects, your thoughts on the code
of conduct and the committee and what you hope to bring to the role and
whether you have a preference in being auxiliary or main member of the
committee. The committee consists of five main members plus five auxiliary
members and they will serve for a year; all applications are appreciated
and will be carefully considered. The deadline for applications is *the end
of day on June 25, 2024*.
Please feel free to pass this invitation along to any users who you think
may be qualified and interested.
Best,
Amir Sarabadani, on behalf of the Code of Conduct Committee
Hi All -
Welcome to the monthly MediaWiki Insights email!
We’re beginning this edition with a big thanks to Sportzpikachu, Bill
(Wbm1058), xtex, Suffusion of Yellow, TuukkHa, theknightwho, Akiel,
Maunikashekar, DreamRimmer, Seawolf35, Likibp, NicoleLBee, SIri and Weebney who
got their first patch in MW core or Wikimedia deployed extensions and
services merged during the month of May! Congratulations :-)
Goal accomplished: 20% increase in numbers of authors who have submitted
more than 5 patches to MediaWiki core
A key goal in this years’ annual plan of the Wikimedia Foundation is
to increase
the number of authors
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>
who have committed more than 5 patches to MediaWiki core. In May 2024, we
crossed the magic bar of a 20% increase (baseline = 70, the number of
authors who have submitted more than 5 patches to MediaWiki core between
July 2022 and June 2023).
At the end of May, we were at 86 people with more than 5 patches
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>
- which is a 22.85% growth!
The push to the finish line came at the MediaWiki track
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024/MediaWiki_Track>
at the Wikimedia Hackathon in Tallinn
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024>. Some people
contributed to MediaWiki core for the first time, other people came back to
MediaWiki after a pause. The Wikimedia train stats show an impressive
increase of patches for the week after the hackathon (481 patches in 70
repos by 106 authors
<https://www.mediawiki.org/wiki/MediaWiki_1.43/wmf.4/Changelog> vs 318
patches in 76 repos by 75 authors
<https://www.mediawiki.org/wiki/MediaWiki_1.43/wmf.3/Changelog> in the week
before the Hackathon), and about 200 out of the 481 patches were for
MediaWiki core alone. Deep appreciation for Jeena Huneidi, who was the train
conductor
<https://www.mediawiki.org/wiki/Wikimedia_Release_Engineering_Team/Roles#Tra…>
that week! You can learn more about the MediaWiki work done during the
Hackathon under the corresponding Phabricator project
<https://phabricator.wikimedia.org/project/profile/7117/>.
We also continued to observe an impressive decrease in median (>30%) and
average time to first review data (>50%), and an increase in the number of
patches to MediaWiki core compared to last fiscal year. All of these data
points
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>
are the best that we have had in years and are strong indicators that our
development process around MediaWiki is improving.
The health of our platform relies on our ability to maintain the platform,
and a key part of that is to share knowledge and enable people in making
improvements to the core software.
A big thanks to all the people who contribute to MediaWiki core and invest
time in code review and consultancy! Turning the curve around from a
decrease to an increase for the first time in years is such a great
success, which was only possible thanks to all of you
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>.
<3
MediaWiki as a product: Reflections and questions
As shared in the previous MediaWiki Insights
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/April_2024>
email, we wanted to come back with some reflections and insights on the
direction of MediaWiki after the presentations given at the Wikimedia
Hackathon
<https://www.mediawiki.org/wiki/Wikimedia_Hackathon_2024/Program#Saturday,_4…!>
in May and the MediaWiki users and developers conference
<https://www.mediawiki.org/wiki/MediaWiki_Users_and_Developers_Conference_Sp…>
in April. To get more information, you can go over the slides
<https://commons.wikimedia.org/wiki/File:MediaWiki_product_-_direction_and_p…>
as well as the notes in this ticket
<https://phabricator.wikimedia.org/T363972>.
The MediaWiki product strategy is anchored in the larger strategy of the
Wikimedia Foundation
<https://diff.wikimedia.org/2024/04/12/wikimedia-foundation-draft-annual-pla…>,
which is all about the question of how we can sustain the success of the
Wikimedia projects into the future – while the Internet around us is
changing.
MediaWiki, the software platform and interface that allows Wikipedia and
other projects to function, is at the heart of that question. What
decisions and platform improvements can we make to ensure that the
MediaWiki platform is sustainable and can support the creation, moderation,
storage, discovery, and consumption of open, multilingual content at scale
for the next decade?
This means, for example: the platform needs to scale for very high global
read traffic (billions of page views/month) and high global edit traffic
(millions of edits/month), which may coincide and spike when there is a current
event <https://en.wikipedia.org/wiki/Template:Current>. It means the
platform needs to support a large contributor base and the creation,
moderation and discovery of open content in more than 300 languages –
content is not only text, but also data, images, or compositions of
different types of content. Last, the platform needs to enable teams and
technical contributors in a way that we can balance platform and feature
needs, and in a way that the customization offering is curated and thus
manageable and useful to its users. The use cases and scale of Wikipedia
<https://commons.wikimedia.org/w/index.php?title=File%3AMediaWiki_product_-_…>
guide the design goal and platform mission.
Manual:What is MediaWiki?
<https://www.mediawiki.org/wiki/Manual:What_is_MediaWiki%3F> describes some
of that well: MediaWiki has been built to support and scale for Wikipedia’s
needs and use cases (and then all the Wikimedia projects) and decisions are
made with that in mind. The flip-side of this is that there are things
MediaWiki does not do so well - because it’s not designed for those. One
thing we need to get better at is providing clarity about that to users –
so that people can make informed decisions whether the software is right
for their use case. The release cycles and related communication present an
opportunity to do so. And one thing we need to ask ourselves is what our
core software architecture should look like and what core concepts the
platform needs to support inherently to effectively serve as the knowledge
production platform for Wikipedia’s scale and use cases. What can we learn
from the use cases served through the extension ecosystem? Are there
patterns in what people have tried to enable? Which of those patterns may
be something we should enable differently, and what may not be in scope?
The magnitude of the challenges we’re tackling is huge. We started this
journey by learning about people's experiences, challenges and hopes
<https://commons.wikimedia.org/w/index.php?title=File:MediaWiki_product_-_di…>,
and continue to talk and learn. Explorations around questions such as how
Wikipedia’s essential workflows are currently supported
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/Unravel…>
through the MediaWiki software ecosystem, or what is our understanding of
the purpose of each of the mechanisms available to customize MediaWiki
<https://commons.wikimedia.org/wiki/File:MW_customization_interfaces_-_Prope…>
have likewise helped us gain a better sense for challenges and
opportunities of the platform. Last, it has been insightful to go back in
time and reflect on how it all started (and whether and how we lost focus
and track).
Turning lessons learned into actions
A key early decision has been to set a focus on platform sustainability: We
invested in contributor retention and growth
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Contributor_reten…>,
allocated a product manager focused on sustainability (Mateus Santos),
prioritized work on several multi-year initiatives
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/February_…>
that are critical for platform sustainability and evolution, designed
sustainability goals for the Foundation’s next annual plan (Wiki
Experiences key results 5.1 and 5.4
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…>),
and are currently preparing for the handover of the release responsibility
to MediaWiki Engineering. There is a deep correlation between platform
sustainability and release cycles, and an opportunity to align better with
other infrastructure management tasks (e.g. PHP upgrades) and product
strategy.
As we’re making this transition, it is also time to “release” James
Forrester and Sam Reed from the release responsibility: A big shoutout to
James and Sam for all the work they have done around the releases over the
past years and many thanks for all their support, kindness and knowledge
transfer as they are handing things over! <3 The security releases will
continue to be handled by the Security team.
Building on the research from this year, we also plan to start exploring
how we can clarify the relationship of core and extensions better, what
should exist (or not) within core, extensions, or the interfaces between
them, and how that may translate into architectural needs and decisions.
This in itself is a big question and scope, so we’re trying to approach it
with small steps – and conduct more research and experiments first (KR
5.2).
As part of KR 5.3, we want to leverage Parsoid's capabilities which
implicitly models a page as a composition of well-structured fragments. We
aim to use this capability to derive speedy HTML updates on edits to
templates and pages, as well as unblock WikiFunctions' integration on wikis
whose page renderings are served by Parsoid.
Getting ready for next year’s work: A database to query dependencies in
MediaWiki and an overview on MediaWiki’s customisation interfaces
In an earlier MW Insights email
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Reports/January_2…>,
we talked about our work to explore how the MediaWiki software ecosystem
currently supports essential workflows on Wikipedia and Wikidata. While
we’re still working on another report about this exploration, we want to
share two other pieces of work that we believe to be very helpful for the
MediaWiki goals under the Foundation’s annual plan 2024/2025 (WE5.1-5.4)
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2024-2025/…>
:
Amir Sarabadani surprised us with a wonderful project at the Wikimedia
Hackathon: Huma – a bird’s eye view of MediaWiki is a postgreSQL database
that allows querying dependencies and usage of certain methods in
MediaWiki. Want to know which are the most implemented hooks in MediaWiki?
- ask Huma. Interested in cycle dependencies? - ask Huma. You can find more
information on the project on this page
<https://www.mediawiki.org/wiki/MediaWiki_Product_Insights/Artifacts/Huma:_B…>
.
MediaWiki’s customisation interfaces: Earlier this year, we started talking
about all the different ways that users can build software on top of
MediaWiki, and which technique is best suited for what purpose - from
templates to Toolforge and from extensions to gadgets. We tried to capture
our thoughts with sticky notes and arrows on the wall, to create a “feature
development map”. Daniel Kinzler then picked up the ball and started a
spreadsheet with all the interfaces we have for customization and
automation, and the capabilities and properties each of them offers. After
many improvements by engineers and product managers from MediaWiki
Engineering, we now have a concise chart that can serve as an overview of
the different customization mechanisms, and provide guidance on the
advantages and disadvantages of each approach. The chart is available as a
PDF on Commons
<https://commons.wikimedia.org/wiki/File:MW_customization_interfaces_-_Prope…>,
and as a spreadsheet on Google Drive
<https://docs.google.com/spreadsheets/d/10sUXrXylT8dlUcBgSJLlgutjqqA1llUh3UK…>
.
My apologies for the length of this email – there was a lot to share this
time! And please join me in thanking all the wonderful contributors and
code reviewers in MediaWiki core! :-)
Thanks all for reading!
Birgit
--
Birgit Müller (she/her)
Director of Product, MediaWiki and Developer Experiences
Wikimedia Foundation <https://wikimediafoundation.org/>