The on-wiki version of this newsletter is available at
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-04-28
Wikimedia Endowment awards $1 Million grant to Abstract Wikipedia
<https://meta.wikimedia.org/wiki/File:Wikimedia_Endowment_logo.jpg>
<https://meta.wikimedia.org/wiki/File:Wikimedia_Endowment_logo.jpg>
Logo of the Wikimedia Endowment
We are happy to highlight the grant of one million US Dollar made by the
Wikimedia Endowment to support Abstract Wikipedia.
The Wikimedia Endowment <https://wikimediaendowment.org/> is an investment
fund which uses a part of its gains to fund Wikimedia projects and the free
knowledge movement. Launched in 2016 to support the future of Wikimedia
projects, the Wikimedia Endowment is a permanent fund that supports
Wikipedia and Wikimedia projects in times of uncertainty, and enables
long-term investments to support their growth and innovation. The endowment
is a safety net that helps protect Wikipedia now and into the future. The
Endowment was established as an independent organisation in 2022.
This year, for the first time, the Endowment is making some grants. We
congratulate the other recipients: Wikidata, the Machine Learning
programmatic work at the Wikimedia Foundation, and the offline reading
project Kiwix. The endowment made $3.2 million dollars available this year.
We express deep thanks to the Wikimedia Endowment for their support. You
can read more about the grant on a post on Diff
<https://diff.wikimedia.org/2023/04/13/launching-the-first-grants-from-the-w…>
by
Phoebe Ayers, Chair of the Grantmaking and Community Committee of the
Wikimedia Endowment Board of Trustees.
The team’s manifesto, OKRs, and communication principles
Currently, the Wikimedia Foundation is going through the process of annual
planning for the upcoming financial year
<https://meta.wikimedia.org/wiki/Wikimedia_Foundation_Annual_Plan/2023-2024>
(July
2023 to June 2024), receiving and incorporating feedback. We want to give a
huge shout out to the folks working on the process and implementing it. You
can join the conversation and the collaboration around the plan until
Friday 19 May 2023.
Our team is slightly outside of this process, since we already have a
development
plan <https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Plan> that we are
following. Adding to this plan we now also published our team’s manifesto
<https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Single-page_manifesto>,
including our Objectives and Key Results (OKRs
<https://en.wikipedia.org/wiki/OKR>), and our communication principles
<https://www.mediawiki.org/wiki/Abstract_Wikipedia_team/Communication_princi…>
.
The manifesto summarises the why and what of our team and project. It is a
good, succinct summary of the work we are doing, and the motivation behind
the work. As we say in conclusion:
*“The ultimate objective of the Abstract Wikipedia effort is to make
knowledge more accessible and usable for everyone, regardless of their
language or background.”*
The objectives and key results that we have set ourselves define a number
of concrete metrics which we hope to achieve with Wikifunctions. They cover
the growth of the community, the usage and maintenance of the content on
Wikifunctions, and the diversity of contributors and multilinguality of
content. It feels very difficult to come up with meaningful numbers here,
but we have tried our best. We are sharing those numbers to keep ourselves
accountable, and we would be .
Finally, the Abstract Wikipedia and Wikifunctions team is a distributed
team, and thus communication plays a heightened role for the success of our
team. The communication principles arise from the team’s values, and make
explicit the commitments we share for communicating with each other.
Although the communication principles only apply to our team and our
interactions with the community, we hope that by modelling our interactions
and by listing them publicly, we will also lead the Wikifunctions community
to adopt similar principles. We are hoping that the community that will be
participating on Wikifunctions will assume good faith, allow for an
environment where people can safely raise ideas and concerns, and where we
all remember to consider the human behind the user account. We have no
claim to novelty on these principles.
Volunteer’s Corner on Monday 8 May
Usually, the Volunteer’s Corner is on the first Monday of the month. Given
that this falls on May Day, the International Workers’ Day, we have decided
to move it to May 8th, at the usual time, instead. Bring your questions and
ideas!
The next Volunteer’s Corner will be on May 8th, 2023, at 17:30 UTC
<https://zonestamp.toolforge.org/1683567008> on Jitsi at
meet.jit.si/AWVolunteersCorner
Oleg Parashchenko’s presentation on his experience implementing a natural
language generation system from earlier this week can be found recorded here
<https://drive.google.com/file/d/1ilzQV1TNeh3qtUdLqBC5-RVcvD8IitXD/view>.
Hello all,
Next week, Tuesday April 25, 16:30-17:30 UTC [1], we are having a public
NLG SIG meeting. In this one, Oleg Parashchenko will share his experience
and thoughts about implementing a multilingual NLG system. The meeting can
be joined using Jitsi at https://meet.jit.si/AWVolunteersCorner
The NLG SIG (Natural Language Generation Special Interest Group) is the
continuation of the NLG workstream (which was the last remaining
workstream).
Oleg is a software developer living in Germany. Oleg's work on Github can
be found here: https://github.com/olpa/multi-nlg
Oleg
[1] https://zonestamp.toolforge.org/1682440203
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2023-04-19
--
Selecting the right implementation
Functions in Wikifunctions can have more than one implementation. For
example, if we have a function that capitalizes the first letter
<https://wikifunctions.beta.wmflabs.org/wiki/Z10577> of a word, we can have
several implementations, e.g. one
<https://wikifunctions.beta.wmflabs.org/wiki/Z10711> or two in Python
<https://wikifunctions.beta.wmflabs.org/wiki/Z10713>, one in JavaScript
<https://wikifunctions.beta.wmflabs.org/wiki/Z10712>, and one using
composition <https://wikifunctions.beta.wmflabs.org/wiki/Z10579>. You might
find some of the implementations surprising. We previously discussed why we
made the design choice to allow multiple implementations
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-17> for
a single function.
Until recently, Wikifunctions selected an implementation at random.
Meaning, whenever someone was calling a function and there were multiple
implementations available, Wikifunctions would select the implementation to
be used randomly.
Implementations of the same function can have wildly different runtime
behavior. Some can be very slow, and others can be very fast: sorting a
list of 100,000 random numbers using bubble sort
<https://en.wikipedia.org/wiki/Bubble_sort> can take a minute on a current
processor, but with quicksort <https://en.wikipedia.org/wiki/Quicksort> the
same list of numbers can be sorted in less than two hundredth of a second -
faster than the blink of an eye. Much faster.
In Wikifunctions, functions should be accompanied by testers. The
capitalization function we talked about earlier has only one tester
<https://wikifunctions.beta.wmflabs.org/wiki/Z10578> as this is being
written, that checks that capitalizing the word “test” returns “Test”. If
all goes well, Wikifunctions will run each tester on each implementation.
The results of these tests are stored: does the implementation pass, how
many resources does it require, and other meta-data. This run-time
information is also shown to the user in a pop-up on request, for people
interested in the back-end details.
Wikifunctions now ranks the implementations based on this meta-data, and
updates the internal order of the implementations. Test failures result in
downgrades, and quick results lead to a better ranking. And so, for the
last few weeks, instead of selecting an implementation at random, we now
select the first implementation based on that ranking. Here is an example
of that reordering
<https://wikifunctions.beta.wmflabs.org/w/index.php?title=Z10577&diff=prev&o…>
working
in practice (but alas, diffs are not implemented yet).
This should lead to a considerable reduction in used resources, and to a
more consistent behavior of Wikifunctions. Function calls should produce
timeouts less often. This should also relieve the Wikifunctions community
from worrying about inefficient implementations and whether we should
accept them or not. Often, algorithms which are simpler are easier to read
and verify, but are slower: bubble sort is a good example of this, compared
with quicksort. Bubble sort is generally regarded to be much easier to
explain and understand than quicksort. Having both allows for the results
of the simpler implementation to be compared to results of the more complex
implementation, with both passing the same suite of testers, and thus
increase our confidence in the overall system. At the same time, we can in
practice use the more efficient implementation and thus reduce overall
resource usage.
With this, the first version of a major element that will work behind the
scenes of Wikifunctions has been put into place, and we have delivered
another goal of the current phase.
Maria Keet’s reflection on Abstract Wikipedia so far
Maria Keet <http://www.meteck.org/> has been an active and central part of
the Natural Language Generation Workstream. She is a professor at the
University of Cape Town, South Africa, and her collaboration with Ariel
Gutman
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-12-19> on
the template language
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Template_Language_for_Wi…>
and
her arguments have been mentioned in the fellows’ evaluation
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Google.org_Fellows_evalu…>
and
the answer
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Google.org_Fellows_evalu…>.
Maria has now written down her own reflections and published them on her
blog:
keet.wordpress.com/2023/03/14/some-reflections-on-designing-abstract-wikipe…
The text is very accessible, gives context, and explains some of the issues
that low resource languages face, and makes suggestions on how to proceed.
Maria also describes some of the frustrating challenges she encountered in
having her voice heard and recognized. That part makes for a painful read,
and points to necessary changes.
To repeat her closing words:
The mountain we’ll keep climbing, be it with or without the Abstract
Wikipedia project. If Abstract Wikipedia is to become a reality and
flourish for many languages soon, it needs to allow for molehills,
anthills, dykes, dunes, and hills as well, and with whatever flowers
available to set it up and make it grow.
We are thankful to Maria for her ongoing contributions. We hope that we can
achieve a more inclusive space, with the goal to have contributing become a
more wholesome experience.
Talk about Abstract Wikipedia in Sweden
Professor Aarne Ranta <https://www.cse.chalmers.se/~aarne/> will give a
talk on Natural Language Generation and Abstract Wikipedia on Thursday,
April 20th, 2023 at 17:30 local time, in the Maritime Museum and Aquarium
<https://sv.wikipedia.org/wiki/Sj%C3%B6fartsmuseet_Akvariet> in Göteborg,
Sweden. The in-person event is free for the public. The talk will be given
in Swedish.
You can find more information about the talk in Swedish here:
https://www.vetenskapsfestivalen.se/for-alla/kunskap-utan-granser-abstract-…
