Hello all,
As you may know, every year around October 29th we're celebrating Wikidata's
birthday <https://www.wikidata.org/wiki/Wikidata:Eighth_Birthday> with
various events, presents and wishes. This year, you can find a calendar of
various events
<https://www.wikidata.org/wiki/Wikidata:Eighth_Birthday/Organise>, most of
them taking place online. You can still organize one, find more information
here <https://www.wikidata.org/wiki/Wikidata:Eighth_Birthday/Organise>. You
can also prepare a birthday present and add it to this page
<https://www.wikidata.org/wiki/Wikidata:Eighth_Birthday/Presents>.
The year 2020 is special in many ways, for example because most of the
international events where we normally gather, meet and have informal time
together have been cancelled. I definitely miss these events and the
possibility to chat with some of you, discuss the projects you're working
on and discover what's new on Wikiprojects.
There's no formal program during the meetup, and people are invited to chat
about anything related to the main theme. However, we're inviting people to
sign up as a *facilitator for a one-hour slot*: you can find a second
person to co-facilitate with you, sign up in the schedule
<https://www.wikidata.org/wiki/Wikidata:Eighth_Birthday/24-hours_meetup>,
and add an optional topic to the slot. This opportunity is great if there's
a topic you'd like to discuss with the community.
As we're an international crowd, the discussions will mostly take place in
English. However, it is possible to include other languages: for example, a
slot in French has already been added. Please also note that the meetup is
covered by the code of conduct for technical spaces
<https://www.mediawiki.org/wiki/Code_of_Conduct>.
So, feel free to note down the date in your calendars, don't hesitate to
sign up to facilitate a slot! The link to the event (we will use the
software BigBlueButton) will be added shortly before the date.
If you have any questions, feel free to ask them on the related talk page
<https://www.wikidata.org/wiki/Wikidata_talk:Eighth_Birthday>.
See you there!
--
Léa Lacroix
Community Engagement Coordinator
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
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
Hi all,
Join the Research Team at the Wikimedia Foundation [1] for their monthly
Office hours on 2020-10-13 at 16:00-17:00 PM UTC.
To participate, join the video-call via this Wikimedia-meet link [2]. There
is no set agenda - feel free to add your item to the list of topics in the
etherpad [3] (You can do this after you join the meeting, too.), otherwise
you are welcome to also just hang out. More detailed information (e.g.
about how to attend) can be found here [4].
Through these office hours, we aim to make ourselves more available to
answer some of the research related questions that you as Wikimedia
volunteer editors, organizers, affiliates, staff, and researchers face in
your projects and initiatives. Some example cases we hope to be able to
support you in:
-
You have a specific research related question that you suspect you
should be able to answer with the publicly available data and you don’t
know how to find an answer for it, or you just need some more help with it.
For example, how can I compute the ratio of anonymous to registered editors
in my wiki?
-
You run into repetitive or very manual work as part of your Wikimedia
contributions and you wish to find out if there are ways to use machines to
improve your workflows. These types of conversations can sometimes be
harder to find an answer for during an office hour, however, discussing
them can help us understand your challenges better and we may find ways to
work with each other to support you in addressing it in the future.
-
You want to learn what the Research team at the Wikimedia Foundation
does and how we can potentially support you. Specifically for affiliates:
if you are interested in building relationships with the academic
institutions in your country, we would love to talk with you and learn
more. We have a series of programs that aim to expand the network of
Wikimedia researchers globally and we would love to collaborate with those
of you interested more closely in this space.
-
You want to talk with us about one of our existing programs [5].
Hope to see many of you,
Martin (WMF Research Team)
[1] https://research.wikimedia.org/team.html
[2] https://meet.wmcloud.org/ResearchOfficeHours
[3] https://etherpad.wikimedia.org/p/Research-Analytics-Office-hours
[4] https://www.mediawiki.org/wiki/Wikimedia_Research/Office_hours
[5] https://research.wikimedia.org/projects.html
--
Martin Gerlach
Research Scientist
Wikimedia Foundation
Hello all,
As you may know, over the past months we’ve been struggling with more and
more bots editing Wikidata at a very high rate, causing infrastructure
issues having an impact on the Query Service that couldn’t keep up with the
changes and on tools such as Pywikibot
<https://phabricator.wikimedia.org/T242081>.
Over the years, we tried different things (like Add Wikidata query service
lag to Wikidata maxlag <https://phabricator.wikimedia.org/T221774>, increase
maxlag or factor <https://phabricator.wikimedia.org/T243701#5864130>, limit
the edit rate for all accounts <https://phabricator.wikimedia.org/T184948>).
Wikidata admins also approached individual bot owners to ask them to comply
with the bot policy’s limit, sometimes without success.
Recently, we discussed removing the noratelimit feature for the bots group
<https://phabricator.wikimedia.org/T258354>. This would have as an effect
to *limit the edits to 90 edits/min for most of the bots* ; the few bots
that need an unlimited rate to function (for example MassMessage) can be
added to the existing accountcreator group (with the possibility to rename
this group).
Many thanks to bot owners who gave input in the comments of the ticket
<https://phabricator.wikimedia.org/T258354> and helped us frame this
solution. If you want to continue the discussion, please have a look at
these comments, so we can build from them and avoid restarting the
discussion from scratch.
We hope that this solution will allow a fair access to mass editing
Wikidata, while preserving the existing infrastructure and avoiding hitting
too hard on the Query Service. In the meantime we are working together with
the Search Team at the WMF and others on improvements to the Query Service
scalability and alternatives to it so some load can be redirected to other
systems, as well as general infrastructure improvements.
Unless there’s a strong opposition from the community to this change, we
will implement it on October 20th.
If you have any questions or need more information, feel free to add a
comment in the ticket <https://phabricator.wikimedia.org/T258354> or onwiki
<https://www.wikidata.org/wiki/Wikidata:Project_chat#Remove_noratelimit_for_…>
to avoid too many messages on these mailing-lists.
Thanks,
--
Léa Lacroix
Community Engagement Coordinator
Wikimedia Deutschland e.V.
Tempelhofer Ufer 23-24
10963 Berlin
www.wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 Nz. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/029/42207.
Hello all!
Here are a few updates from Wikidata Query Service:
* We are getting close to full functional coverage of our Flink based
Streaming Updater [1]. We are starting to work on productionizing it and
having a deployment strategy. The current goal is deploy on top of
Kubernetes.
* We've been reviewing how we log queries and we've been adding some
context to the logs. In particular, we are adding CPU load and query
concurrency [2], with the hope that we can normalize our analysis: a query
that takes time because the server is overload does not have the same
meaning as a query that takes time because it is intrinsically expensive.
* We've been exploring our assumption that expensive queries are more
likely to be human generated queries (via the UI) than bots [3]. That
assumption seems to be wrong.
* We are looking into upgrading to JDK11. We are currently running on JDK8,
we have some time before it is truly end of life. Blazegraph itself has a
number of issues with JDK11.
* We had a few issues with data reload on Wikimedia Commons Query Service.
We are now doing those data reload without interruption, so future issues
should not result in any downtime, but just delays in getting the new data.
The data size of WCQS is growing faster than we expected. We are
tentatively planning on working on a streaming updater for WCQS early 2021.
Have fun!
Guillaume
[1] https://phabricator.wikimedia.org/T244590
[2] https://phabricator.wikimedia.org/T261937
[3] https://phabricator.wikimedia.org/T261841#6532765
--
Guillaume Lederrey
Engineering Manager, Search Platform
Wikimedia Foundation
UTC+1 / CET