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,
We are now only three weeks away from the Wikimedia Wishathon! Exciting
news - User:Lucas Werkmeister has signed up to host a piano concert during
a social hour 🎉
Join us and contribute to the development of community wishes between March
15th and 17th! Participate in discussion sessions and work on user scripts,
gadgets, extensions, tools and more!
The full event schedule is available here: <
https://meta.wikimedia.org/wiki/Event:WishathonMarch2024>.
Explore the event wiki for project ideas and keep an eye out for
non-technical tasks (documentation and design-related) that will soon be
added to the Wishathon workboard: <
https://phabricator.wikimedia.org/project/view/5906/>. Project breakouts
will also be added to the schedule, where you can participate in wish
development or explore innovative solutions as a user, developer, or
designer.
We are seeking volunteers to assist with a wide range of activities such as
monitoring discussion channels during hacking hours, answering technical
queries, and helping with session note-taking. Check out the Help desk
schedule and add yourself to a slot where you are available and interested
in providing assistance: <
https://meta.wikimedia.org/wiki/Event:WishathonMarch2024/Help_desk>.
If you have any questions about the Wishathon, reach out via Telegram: <
https://t.me/wmhack>.
Cheers,
Srishti
On behalf of the Wishathon organizing committee
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
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 next language community meeting is coming up in a few weeks - *February
21st, 12:00 pm UTC*.
If you're interested, you can sign up on this wiki page: <
https://www.mediawiki.org/w/index.php?title=Wikimedia_Language_engineering/…
>.
This meeting is for individuals involved in creating content or managing
technical aspects across different language communities. This will be a
participant-driven meeting, where we collectively discuss specific
technical issues related to language wikis and work together to find
possible solutions. This could involve anything from fixing a broken
template on the Kurdish wiki to brainstorming ideas for growing content on
the Tulu Wiktionary, currently in the Wikimedia Incubator, or celebrating
the creation of Fon Wikipedia, to using MinT for content translation.
Feel free to add any *technical updates* related to your project or ideas
for *problem-solving* discussion that you would like to share during the
meeting to the notes document here: <
https://etherpad.wikimedia.org/p/language-community-meeting-february-2024>.
If you need interpretation support from English to another language, please
let us know by sending an email to ssethi(a)wikimedia.org.
Looking forward to your participation!
Cheers,
Jon, Mary & Srishti
*Srishti Sethi*
Senior Developer Advocate
Wikimedia Foundation <https://wikimediafoundation.org/>
*(apologies for cross-posting)*
Hello,
This is a significant change announcement relevant for some Wikibase API
users.
What's Changing?
Over the coming weeks, most Wikibase API modules will gain three new
parameters: returnto, returntoquery, and returntoanchor. Additionally,
these API modules may return tempusercreated and tempuserredirect fields in
their responses. These parameters are being added to support user
interaction flows related to IP Masking
<https://meta.wikimedia.org/wiki/IP_Editing:_Privacy_Enhancement_and_Abuse_M…>
.
Who’s Affected?
Only users who use the API to make anonymous edits are affected. If you
don’t use the API to make edits, or if you only make authenticated edits,
you can safely ignore these changes, and disregard the additional API
parameters and response data.
What You Need to Do
If you use the API to make anonymous edits, the response may contain a
tempusercreated string indicating the name of the temporary account that
was created, and a tempuserredirect nullable string. If the tempuserredirect
is not null, you should redirect the user to that URL to complete the setup
for the temporary account. Afterwards, the user will automatically be
returned to the current wiki; you can use the returnto, returntoquery,
and/or returntoanchor parameters in your original API request to control
the title, query, and anchor where the redirect returns to.
If you have any questions or concerns about this change, please don’t
hesitate to reach out to us in this ticket (T357024
<https://phabricator.wikimedia.org/T357024>).
Cheers,
--
Mohammed S. Abdulai
*Community Communications Manager, Wikidata*
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0) 30 577 116 2466
https://wikimedia.de
Grab a spot in my calendar for a chat: calendly.com/masssly.
A lot is happening around Wikidata - Keep up to date!
<https://www.wikidata.org/wiki/Wikidata:Status_updates> Current news and
exciting stories about Wikimedia, Wikipedia and Free Knowledge in our
newsletter (in German): Subscribe now <https://www.wikimedia.de/newsletter/>
.
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. Geschäftsführende Vorstände: Franziska Heine,
Dr. Christian Humborg
(This announcement is relevant for all Wikidata users working with Labels
and Aliases.)
Hello,
We're excited to invite you to participate in the community testing of the
“default values for labels and aliases” feature. Based on a long-standing
community request around language fallback (T285156
<https://phabricator.wikimedia.org/T285156>), and based on your feedback
from our previous announcement
<https://lists.wikimedia.org/hyperkitty/list/wikidata@lists.wikimedia.org/me…>,
we are currently testing this feature on https://test.wikidata.org
<https://test.wikidata.org/wiki/Q42> with the release planned for Q1 2024.
What is coming?
1.
Default values for labels and aliases (mul): Items that repeat the same
label and aliases over and over are hard to maintain and can strain our
infrastructure, especially the Wikidata Query Service. As a solution, we
are introducing the option for default values in the termbox. The
default values are considered in the language fallback chain (language code
“mul”).
1.
Visualisation of the language fallback chain: Previously, Wikidata’s
fallback chain was not visible in the user interface, making it challenging
to determine if additional information was needed. As a first step toward
improvement, we will now clearly show what content is already available via
language fallback in the placeholders for labels (including default values).
We need your feedback
Please leave your feedback on Help talk:Default values for labels and
aliases
<https://www.wikidata.org/w/index.php?title=Help_talk:Default_values_for_lab…>.
Your feedback will play a crucial role in verifying if the current version
is ready for Wikidata. Additionally, you can find some test Items, known
limitations and open questions there for you to review. We will analyze
your feedback one week after today's announcement.
The next steps
After you have left your feedback, please make sure that the
guidelines on Help:Default
values for labels and aliases
<https://www.wikidata.org/wiki/Help:Default_values_for_labels_and_aliases>
are ready for the launch. You can also already plan bot-runs for mul, but
please be sure to start with uncontroversial cases. If there are no
blockers, we will then prepare a limited release on Wikidata in the coming
weeks. The limited release will only be visible if you put mul in your
Babel boxes. We will use this limited release to test the performance and
verify that everything works as planned. Please don’t start any bot-runs
for mul during the limited release. A full release will follow a few weeks
later, displaying default values for everyone by default, and featuring an
onboarding element that will guide people to the help page. Bot-runs for mul
can commence at this stage.
Do not hesitate to reach out with questions or concerns in the talk page of
the help page
<https://www.wikidata.org/wiki/Help_talk:Default_values_for_labels_and_alias…>
and for technical details in this Phabricator ticket (T356169
<https://phabricator.wikimedia.org/T356169>).
Thank you for your support!
Cheers,
--
Mohammed Sadat Abdulai
*Community Communications Manager, Wikidata*
Wikimedia Deutschland e. V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Phone: +49 (0) 30 577 116 2466
https://wikimedia.de
Grab a spot in my calendar for a chat: calendly.com/masssly.
A lot is happening around Wikidata - Keep up to date!
<https://www.wikidata.org/wiki/Wikidata:Status_updates> Current news and
exciting stories about Wikimedia, Wikipedia and Free Knowledge in our
newsletter (in German): Subscribe now <https://www.wikimedia.de/newsletter/>
.
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. Geschäftsführende Vorstände: Franziska Heine,
Dr. Christian Humborg
Hello all!
We have been hard at work on our Graph Split experiment [1], and we now
have a working graph split that is loaded onto 3 test servers. We are
running tests on a selection of queries from our logs to help understand
the impact of the split. We need your help to validate the impact of
various use cases and workflows around Wikidata Query Service.
**What is the WDQS Graph Split experiment?**
We want to address the growing size of the Wikidata graph by splitting it
into 2 subgraphs of roughly half the size of the full graph, which should
support the growth of Wikidata for the next 5 years. This experiment is
about splitting the full Wikidata graph into a scholarly articles subgraph
and a “main” graph that contains everything else.
See our previous update for more details [2].
**Who should care?**
Anyone who uses WDQS through the UI or programmatically should check the
impact on their use cases, scripts, bots, code, etc.
**What are those test endpoints?**
We expose 3 test endpoints, for the full, main and scholarly articles
graphs. Those graphs are all created from the same dump and are not live
updated. This allows us to compare queries between the different endpoints,
with stable / non changing data (the data are from the middle of October
2023).
The endpoints are:
* https://query-full-experimental.wikidata.org/
* https://query-main-experimental.wikidata.org/
* https://query-scholarly-experimental.wikidata.org/
Each of the endpoints is backed by a single dedicated server of performance
similar to the production WDQS servers. We don’t expect performance to be
representative of production due to the different load and to the lack of
updates on the test servers.
**What kind of feedback is useful?**
We expect queries that don’t require scholarly articles to work
transparently on the “main” subgraph. We expect queries that require
scholarly articles to need to be rewritten with SPARQL federation between
the “main” and scholarly subgraphs (federation is supported for some
external SPARQL servers already [3], this just happens to be for internal
server-to-server communication). We are doing tests and analysis based on a
sample of query logs.
**We want to hear about:**
General use cases or classes of queries which break under federation
Bots or applications that need significant rewrite of queries to work with
federation
And also about use cases that work just fine!
Examples of queries and pointers to code will be helpful in your feedback.
**Where should feedback be sent?**
You can reach out to us using the project’s talk page [1], the Phabricator
ticket for community feedback [4] or by pinging directly Sannita (WMF) [5].
**Will feedback be taken into account?**
Yes! We will review feedback and it will influence our path forward. That
being said, there are limits to what is possible. The size of the Wikidata
graph is a threat to the stability of WDQS and thus a threat to the whole
Wikidata project. Scholarly articles is the only split we know of that
would reduce the graph size sufficiently. We can work together on providing
support for a migration, on reviewing the rules used for the graph split,
but we can’t just ignore the problem and continue with a WDQS that provides
transparent access to the full Wikidata graph.
Have fun!
Guillaume
[1]
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_graph_split
[2]
https://www.wikidata.org/wiki/Wikidata:SPARQL_query_service/WDQS_backend_up…
[3]
https://www.mediawiki.org/wiki/Wikidata_Query_Service/User_Manual#Federation
[4] https://phabricator.wikimedia.org/T356773
[5] https://www.wikidata.org/wiki/User:Sannita_(WMF)
--
Guillaume Lederrey (he/him)
Engineering Manager
Wikimedia Foundation