The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-02-11?venot…
--
Today we want to share three artifacts we have been building on our way to
Wikifunctions.
<https://meta.wikimedia.org/wiki/File:Wikifunctions_-_early_rough_mockup_-_E…>
<https://meta.wikimedia.org/wiki/File:Wikifunctions_-_early_rough_mockup_-_E…>
Early rough mockup of the edit function journey
Aishwarya, our designer, is currently working on the screen for viewing a
function. Viewing and understanding a function will be one of our central
experiences. It should invite the user to learn about the function, to use
the function, and to contribute to it.
Here is a video exploring the design of the page. Note that this is an
early exploration.
She created the following user flow chart. The chart captures what actions
can be done from the view function page.
<https://meta.wikimedia.org/wiki/File:Wikifunctions_flowchart_-_View_functio…>
<https://meta.wikimedia.org/wiki/File:Wikifunctions_flowchart_-_View_functio…>
Wikifunctions flow chart for viewing a function
You can click on it to get a higher resolution image.
We also published a list of launch requirements
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Launch_requirements> for
Wikifunctions. These will help us to not forget important steps as we get
ready for launch and as development progresses. As it is easy to get too
deep into the weeds of daily work, it is good to be able to step back and
see what other tasks still need to be done.
Enjoy exploring the artifacts! As always, feedback is very welcome.
Development update
- Phase η (covers the work of the actual Wikifunctions system) is still
in progress
- A lot of bugs have been fixed during the previous Fix-it week
- In parallel, the team is also focus on building the user interface.
The primary focus of the UX work is on things we expect most users to use.
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-02-04
--
Originally, the proposal for Wikifunctions was made under the name
“Wikilambda”. After the community decided to use Wikifunctions as the name
for the project, we adopted WikiLambda as the name for the MediaWiki
extension that will allow the creation and maintenance of a library of
functions in a MediaWiki system.
But what’s up with the lambda? Lambda is the 11th letter of the Greek
alphabet, and was a predecessor to the letter L in the latin alphabet.
Lambda is written in uppercase as Λ, and in lowercase as λ.
But what does it have to do with Abstract Wikipedia and Wikifunctions?
The early prototypes to implement the idea of Abstract Wikipedia (from
2013-2017) were aiming for a much simpler system: one in which we could
directly create and edit “meanings”, and then have the system take care of
translating those meanings into natural language texts. An early draft
<https://meta.wikimedia.org/wiki/A_proposal_towards_a_multilingual_Wikipedia>
describes the implementation of the system with templates based on language.
But none of these simple systems worked, as they wouldn’t scale to the
needs of generating even simple fluent natural language texts in many
different languages. The resulting templates or modules would have quickly
become too complex, and so their editing and maintenance would have been
restricted to a far too small community to be viable in the languages that
need it the most. As the system implementing the natural language grew in
expected complexity, it became clear that a different approach would be
required: instead of building a system that tries to hide the complexity of
natural language generation from the community working on it, and having
the community get stuck in the limitations of that system, let’s design a
platform that would allow us to work together on these complex tasks, and
allow the community to create layers of hidden complexity and abstraction
instead.
Instead of having a development team deciding what set of functions would
be required for the community's tasks, we create a platform where the
community can create and maintain those functions themselves.
This very quickly turned into a generic platform for creating all kinds of
functions. The next question became: how do we implement those functions?
In order to allow for a multilingual approach to function implementation,
we adopted the idea of composing (combining) existing functions.
Composing functions is an old idea. In fact, it is one of the most
foundational ideas in all of computer science: giving names to and using
functions, i.e. function abstraction and application. That is exactly what
the lambda calculus <https://en.wikipedia.org/wiki/Lambda_calculus> does.
Lambda calculus was developed by Alonzo Church
<https://en.wikipedia.org/wiki/Alonzo_Church> in the 1930s.
The 1930s were a turbulent time in many ways, and also in Mathematics: the
decade saw the dream of Mathematics and Logic being shattered, and its
foundation completely rebuilt. The comic Logicomix
<https://en.wikipedia.org/wiki/Logicomix> retells the dramatic story of
those events.
There were two main results: first, that not every mathematical question
can be answered
<https://en.wikipedia.org/wiki/G%C3%B6del%27s_incompleteness_theorems>; and
second, that every mathematical question that can be answered at all can be
answered by using a combination of a surprisingly simple and small
foundation. And not only that: there are many such foundational systems!
Lambda calculus is one, but so are Turing machines
<https://en.wikipedia.org/wiki/Turing_machine>, cellular automata
<https://en.wikipedia.org/wiki/Cellular_automaton> (such as Conway’s Game
of Life <https://en.wikipedia.org/wiki/Conway%27s_Game_of_Life>), unrestricted
grammars <https://en.wikipedia.org/wiki/Unrestricted_grammar>, even simple
marble and lever games such as Turing Tumble <https://www.turingtumble.com/>
without any electric components are each capable of performing any possible
calculation there could ever be.
So lambda calculus was a main inspiration for how composition works in
Wikfunctions. But that’s not all!
In the 1960s, Richard Montague
<https://en.wikipedia.org/wiki/Richard_Montague> pioneered the linguistic
theory that was later called Montague grammar
<https://en.wikipedia.org/wiki/Montague_grammar>, an approach to formally
represent the meaning of natural language expressions. Montague took
inspiration in the lambda calculus, and since then the lambda calculus also
became a mainstay in linguistics. In this approach, the meaning of words
such as “some” or “every” are captured with simple expressions in lambda
calculus. You can read more about the use of lambda calculus in linguistics
in this introduction aiming at “absolute dummies”
<http://palmstroem.blogspot.com/2012/05/lambda-calculus-for-absolute-dummies…>.
Or in this comic <https://imgur.com/a/XBHub> aimed at linguists.
Let me quote the words
<https://allthingslinguistic.com/post/95678520747/the-lambda-calculus-for-ab…>
of linguist Gretchen McCulloch
<https://en.wikipedia.org/wiki/Gretchen_McCulloch> about the use of lambda
calculus in linguistics:
“The Lambda Calculus is often used in semantics as a way of representing
meaning in a manner more independent of the specific words used in a
particular language.”
That is exactly what we are aiming for with Abstract Wikipedia!
The abstract content that will make up Abstract Wikipedia is basically
“just” a user-friendly and community-editable layer over lambda notation,
used to express the meaning of the Wikipedia articles. In a second step, we
then use lambda-calculus based compositions to transform these expressions
of meaning into natural language text that is then presented to the readers
of Wikipedia.
Which brings us to another connotation that lambda has: Λ or λ both look a
whole lot like the Chinese character 人, which can mean “human” or “person”
or “everybody” <https://en.wiktionary.org/wiki/%E4%BA%BA#Definitions>. And
that really represents for whom we are doing this work.
The lambda in WikiLambda is a conscious reference to both these bodies of
research. The new thing in WikiLambda is not the "Lambda" — it is the
"Wiki". It is this idea of bringing together a group of remarkable people
to see if they could build something new, something that can take us a step
closer to a world where everyone can share in the sum of all knowledge.
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-01-28
--
Since the start of the project, we have published the function model for
Wikifunctions
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Function_model>, but
the description is rather technical and uninviting. In these newsletters,
we have previously described parts of the function model in a more
accessible way: what is an object
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-11-10>, what
are functions good for
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-10-07>, labels
and documentation
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-10-22>,
what are generic types
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-01-21>,
and why we allow for multiple implementations per function
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-17>.
Today, let’s dive into a core concern: how do we represent a function?
*What is a function?* The term “function” is used in various different
disciplines, and the English Wikipedia offers articles on functions in computer
science <https://en.wikipedia.org/wiki/Subroutine>, mathematics
<https://en.wikipedia.org/wiki/Function_(mathematics)>, linguistics
<https://en.wikipedia.org/wiki/Functional_linguistics>, biology
<https://en.wikipedia.org/wiki/Function_(biology)>, engineering
<https://en.wikipedia.org/wiki/Function_(engineering)>, and sociology
<https://en.wikipedia.org/wiki/Structural_functionalism>. All of these
notions are related and interesting, and for Wikifunctions we use the
following, specific definition: a function takes some input and responds
with an output. The input affects the output in a predictable way.
*What are functions good for?* We previously discussed the general
motivation for functions
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-10-07>:
functions answer questions, and answering questions is a crucial part of
allowing everyone access to the sum of all knowledge. Functions will be the
central type of objects in Wikifunctions . Users of Wikifunctions will be
able to “call” or use functions to answer their questions. Contributors to
Wikifunctions will be able to define new functions and create the related
supporting objects.
*How do we represent a function?* Here’s the overview of how a function is
represented in Wikifunctions and the related objects supporting it (we’ll
go into these in detail below): a function has labels, aliases,
documentation, a return type and a list of arguments, a list of testers, a
list of implementations, and an identity. (We will not discuss identity
today, as this is rather technical)
*Labels*. We define a function by giving it a label, a name. The label
depends on the language: a function that adds up two numbers may be called
“Addition” in English, “Zbrajanje” in Croatian, “Сложе́ние” in Russian,
“যোগ” in Bangla, etc. It might also have aliases that will help people to
find the right function: “Add”, “Sum”, or “Plus” might be good aliases in
English, “прибавле́ние” might be an alias in Russian, and “+” might be an
alias that works in many languages.
*Documentation*. A function will also often have documentation – some text
that describes what the function does and how it does it. This should help
people with differentiating the function from similar functions, and for
allowing users to understand what the function call will result in and how
that answers their questions. We have previously discussed labels, aliases,
and documentations
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2020-10-22>.
*Return type*. The return type tells us what type of object the answer of
the function will be. For example: “number”, “boolean” for true/false,
“string” for words, etc. This can be helpful in many ways: it can help when
browsing the available functions, as we sometimes know that our answer will
be a number; it can help when combining functions together, because we know
that an argument can only take a specific type, and that we can compose it
with a function that returns the required type. The return type can also
help us with understanding the function and what exactly it returns. For
the two “divide” functions mentioned above, one will return a number, and
the other a list of strings. Even if we don’t have any documentation for
the function in our language, this will give us strong hints about what it
might do.
*List of arguments*. A function takes some input. The input is given as one
or more arguments. Each argument can have a label/name (again, given in
each of the languages we support), and the type of object we expect this
argument to be. The type is important: say you have a function called
“divide”, which takes a string and a number, and divides the given string
into equally sized parts. So you call “divide “Wikipedia” into 3 parts” and
the function answers with “Wik”, “ipe”, and “dia”. Separately, there is
another function, also called “divide”, that takes two numbers, to
determine how many times the first goes into the second. These are two very
different functions, and the result of “divide(333, 3)” could either be 111
or 3, 3, and 3 — depending on which function you picked, and what types the
values had.
The numerical division function also illustrates the need for names for the
arguments: in that case, it is important which argument is the number by
which we divide and which is the number that is being divided. In other
cases, the name of the arguments are less important: for the “divide a
string into equal parts” function, the types are sufficient to know which
argument does what.
*List of testers*. Testers will play a crucial role in Wikifunctions, and
not only by fulfilling the standard role of tests. Traditionally, a test
aims to give the user some confidence that a function indeed returns with
the correct answer. When a function passes its tests, it is likely that the
function will return the right answer also for other arguments. A
well-designed set of tests can explore the “edge cases” of what is expected
when you call a function with a surprising input.
But in Wikifunctions, the testers will do so much more! When a contributor
creates the function that divides a string into equally long parts, they
could immediately give examples of what they intended: they can create a
tester that, given that we want to turn “Wikipedia” in three equal parts,
we want to get a result that is a list of three strings, “Wik”, “ipe”, and
“dia”. No matter what language they speak, every other contributor can see
the expected results in a well-defined way, and can help with creating
implementations that pass the testers.
The testers act as a means to hammer out agreement between the contributors
to Wikifunctions about what a function does exactly, no matter the language
they speak. The testers are where edge cases (and how they should be
resolved) can be suggested, and agreed or rejected. The testers ultimately
constrain what the “correct” implementations of the function are, and thus
precisely what the function is intended to do.
This also means that the testers are a form of language-independent
documentation, as they provide examples of how the function is called and
what results are expected. So even if there is no documentation available
in your language, the testers might still allow you to guess what a
function does, and use it productively.
*List of implementations*. An implementation makes it possible to actually
run the function on the given arguments, and to produce a result to answer
the function call with. In Wikifunctions, implementations can be given in
three different ways: either as a built-in, as code in a specific
programming language, or as a composition of other functions. We have
talked about these before, and we have discussed why we are going the unusual
way of allowing for multiple implementations
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-06-17> for
a function.
We hope that helps with understanding functions, testers, and
implementations better.
The on-line version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-01-21
--
This week we are happy to welcome Luca Martinelli on the team!
Here is Luca's introduction in his own words:
Hello, I’m Luca (aka Sannita). I've been a Wikipedian since Jan 15, 2006
(yep, it’s been 16 years!), and also a Wikidatan since the inception of the
project back in 2012. I also served as a Board member for Wikimedia Italy
from 2014 to 2017.
I was born in Benevento, Italy, but moved to Rome when I was almost 17. I
have lived there since (except for a year abroad in wonderful Ljubljana,
Slovenia), as well as working there as journalist and communications
manager.
From 2014 to 2019, I worked as webmaster and later Wikipedian in Residence
at the Central Institute for the Union Catalog
<https://www.wikidata.org/wiki/Q3803707>, that manages Italy’s National
Library Service (SBN). Finally, I joined Wikimedia Foundation in January
2021 as a contractor, first working on the Universal Code of Conduct, then
as a Community Relations Specialist.
In my free time, I enjoy mostly watching movies or series, reading or
spending time with my friends. I also enjoyed traveling around the world,
attending Wikimania and/or other wiki-related events (and waiting to start
doing it again).
Luca will work together with Quiddity on Community Communications (both
part-time), strengthening our team's capacity here and covering more time
zones. As the launch of Wikifunctions comes closer, it is important that we
have sufficient resources available to support the new community that will
emerge around Wikifunctions. Starting a new project is something the
Wikimedia movement does rarely, and we believe that the initial start of a
community has a long-term effect on how the project and the community will
evolve. You can find Luca on the wikis as User Sannita
<https://meta.wikimedia.org/wiki/User:Sannita_(WMF)>.
We are very excited to have Luca on board, and invite you to give him a
warm welcome!
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-01-13
--
Happy New Year, and welcome to the first newsletter of 2022!
When we started work on Wikifunctions, we divided the work into eleven
functional phases
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Phases>, named after
the first eleven letters of the Greek alphabet (a naming scheme that has
received notoriety recently). We are currently working on Phase η (eta),
with the goal of entirely re-doing the function model of Wikifunctions by
allowing for generic types and functions.
Following discussions within the team, we are refining the completion
criteria for the current phase, in order to make it more tangible. The
original idea of how to show that we had completed the phase was that we
would do a lot of very deep static validation, so that a function call such
as:
(1) if(head([true]), false, true)
would validate, but
(2) if(head(["text"]), false, true)
would not. To explain: the if function requires a Boolean as the first
argument, but head is currently defined as head(List) → Object. So in a
static analysis, if requires a Boolean but gets an Object. But if we would
say that this is OK, the static analysis for both (1) and (2) would pass -
and (2) shouldn’t pass.
On the other hand, as well as static analysis we have dynamic analysis,
which happens when running the code. In that one, (1) should pass and
return false, whereas (2) should raise a type error during evaluation
(something such as “if expects a Boolean on the first argument, but got a
String”).
We decided to de-scope the deep static analysis for now. This is something
that we can add later, possibly after launching Wikifunctions.org. As you
can see, users would get error messages one way or the other: it is just a
question of when exactly the error is raised. Also, if you are interested
in working on these or similar topics, please reach out. We are always
happy to integrate the work of volunteers and other external partners.
Instead of this static analysis, we decided to focus on the following
capabilities as examples of how the phase will have been completed:
- Being able to implement curry as a composition on the wiki, but
without requiring strict static analysis
- Making it possible to create the following three 'user-defined' types
on the wiki: positive integer, sign, and integer
- Being able to make a generic wrapper type through composition on the
wiki
- Providing a re-designed function editor (though this might be pushed
into the next phase)
Let’s dive deeper into each of these capabilities.
Curry
For this to work, a user must be able to use a function as an argument, and
use that function for a function call in the implementation of curry. What
is curry? Curry <https://en.wikipedia.org/wiki/Currying> is a standard
function in computer science that takes a function f and another object x
and runs the function on the object. The standard form is that the function
f has two arguments, the first one being of the type of x, and the 'output'
is a call to the function f with the second argument preset to the value x.
Example: given a function that appends a string to another string, I could
create a new function “add s to end” by calling curry(append, "s"). We want
to make it possible to define and call such a function.
User-defined typesPositive Integer
The following things will need to be possible:
- Create a new type, Positive Integer, with a single key value of type
String
- Create a function to validate Positive Integer
- If value contains a character which is not a digit (0-9), the
validator raises a user-created error with the non-digit character
- If value contains leading zeros and is not just a single zero, the
validator raises a user-created error
- If value is an empty string, the validator raises a user-created
error
- Connect the validator to the Positive Integer type
- Create the following eight functions:
- Is zero: Positive Integer → Boolean (returns True if the argument
is zero and False otherwise)
- Successor: Positive Integer → Positive Integer (returns the
argument increased by one)
- Provide implementations in JavaScript (BigInt) and Python (bignum
)
- Predecessor: Positive Integer → Positive Integer (returns the
argument decreased by one, raises an error in case the argument is zero)
- Provide implementations in JavaScript (BigInt) and Python (bignum
)
- Positive Integer: String → Positive Integer (constructor)
- Positive Integer as String: Positive Integer → String
(deconstructor)
- Equal Positive Integer: Positive Integer, Positive Integer →
Boolean (whether
the two numbers have the same value)
- Greater Than: Positive Integer, Positive Integer → Boolean (whether
the first number is bigger than the second)
- Lesser Than: Positive Integer, Positive Integer → Boolean (whether
the second number is bigger than the first)
Sign
The following things will be possible, related to the mathematics term
"sign":
- Create a new type, Sign, with a single key identity of type Sign
- Create the three possible values of type Sign, i.e. positive, negative,
and neutral
- Create a function to validate Sign
- If the value is not one of the expected three values, raise an error
- Connect the validator to the Sign type
- Create the following function:
- Equal sign: Sign, Sign → Boolean (returns True if the two arguments
have the same value)
Integer
The following things will be possible:
- Create a new type, Integer, with two keys, absolute value of type Positive
Integer and sign of type Sign
- Create a function to validate Integer
- Ensure that both keys are validated
- If sign is neutral and absolute value is not zero, or *vice versa*,
raise an error
- Connect the validator with the Integer type
- Create the following six functions:
- Integer: Positive Integer, Sign → Integer (constructor)
- Absolute value: Integer → Positive Integer (deconstructor)
- Sign: Integer → Sign (deconstructor)
- Equal Integer: Integer, Integer → Boolean (whether the two numbers
have the same value)
- Greater Than: Integer, Integer → Boolean (whether the first number
is bigger than the second)
- Lesser Than: Integer, Integer → Boolean (whether the second number
is bigger than the first)
Generic wrapper
A generic wrapper is a function that takes a type and returns a newly
constructed type that has a single key with a value of that type. Wrappers
may be useful for example to make sure that we don’t accidentally treat
something as a number that looks a lot like a number. It is also useful as
a test case because it is a rather simple generic type.
- Create a function that creates the generic type, i.e. Wrap Type: Type
→ Type
- Create a generic constructor function, i.e. Wrap: Type T → Function which
is a function that returns a function of signature T → Wrap Type(T)
- Create a generic deconstructor function, i.e. Unwrap: Type T →
Function which
is a function that returns a function of signature Wrap Type(T) → T
- Store a literal of type Wrap Type(Boolean) as an object on the wiki
- Write a generic function that creates a function that works with Wrap
Type(T), e.g. Wrapped Equality: Type T → λ: Wrap(T), Wrap(T) → Boolean
- Note that all these functions should be possible to be written
entirely in user space
- Test by calling something like Unwrap(Boolean)(Wrap(Boolean)(True)) and
get True back
Where to next?
There are still quite a few tasks to be done in this phase, but many of the
pieces are almost in place for it. Once this phase is complete, we will
focus on getting the beta cluster ready for you to play with.
We wish you all the best for the New Year!
Abstract Wikipedia,
Hello. I am pleased to share a new project proposal: Wikianswers (https://meta.wikimedia.org/wiki/Wikianswers).
Like similar projects, users will be able to receive one or more answers to their questions from artificial intelligence question-answering systems, but, unlike other projects, they will subsequently be able to edit these answers and any provided justifications using wiki technology. User-corrected content could later be utilized to retrain consulted question-answering systems, resulting in continual improvement.
The proposed project would greatly benefit end-users and would create a valuable resource for the training of artificial intelligence systems.
As broached in the proposal’s technical discussion section (https://meta.wikimedia.org/wiki/Wikianswers#Technical_discussion), components and features which could add value to Wikianswers could also add value to Wikifunctions: server-side document-processing, annotations, and client-side user interface topics. With these components and features, in a manner resembling an IDE, users could receive informational, warning, and error messages when working with source code, e.g., Python, in a wiki document context.
Thank you for any ideas, comments, questions, or suggestions with which to improve the project proposal.
Thank you for taking the time to express your support for or opposition to the newly proposed project.
Best regards,
Adam Sobieski
http://www.phoster.com
भारत बर्षा: अस्माकं देशः अस्ति l अस्य भूमिः बिबिधसंतान जननि अस्ति l अस्य प्राकुतिकी शोभा अनुपमा अस्ति l हिमालयः अस्य प्रहरी अस्ति l एषः उतरे मुकुतमनिः इब शोभते l सागरः अस्य चरनोउ प्रख्यालयति l अनेकाः पबित्रतमः नद्यः अत्र बहन्ति l गङ्गा, गोदबरि, सरस्वोति, यमुना प्रभुतयः नद्यः अस्य सोभां बर्धयति l अयं देशः सर्बासं बिधानं केन्द्रं अस्ति l अयं अनेक प्रदेससु बिभक्तः l अत्र बिबिध धर्मबलंबिनः संप्रदायिनः जनाः निबसन्ति l अस्य संस्कृतिः धर्म परम्परा च श्रेस्था अस्ति l अयं भू - स्वोर्गः अपि बर्तते l इश्वोरस्य अबताराः अस्मिन् देशे संजाताः l संकट काले बयं खुद्रभेदन परित्यज्य देसहितम् चिन्तयामः l
बिसाल भूमण्डलं ब्याप्य अयं देशः एसिया महाद्विपस्य अन्यतमः रस्त्रः संजाताः l बयं सदा स्वोरास्त्रस्य रख्याम कर्तुं उद्यताः स्याम l
कथित मस्ति -' जननि जन्म भूमिश्च सवोर्गादापि गरीयसि l ' यस्मिन् देशे यस्य जन्म तं देशं प्रति तदीया भक्तिः देसभक्तिः l यः मानबः यत्र जन्म लभते सैब तस्य जन्मभूमिः कथ्यते l अस्मिन् जगति समेसाम् बहुमूल्य बस्तुनां मध्ये माता मत्रुभुमिस्च एब एते द्वे स्रेस्थे l असारे खलु संसारे अलव्याः अपि पदार्थः परिस्रमेन लब्धुं सक्यन्ते l परं माता पिता जन्म भूमिश्च न केनापि यत्नेन प्राप्यते l मनुस्यानं मनसि जाते देसभक्ति प्रबेसे तदियं जिबन्मेब स्वोदेसस्य कृते भबति l तदारभ्य मनबः तदियं स्थितम् उनेतुं एब प्रयतते l सत्यं अबस्यकतायां ते प्राणानपि त्यक्तुं कृतसंकल्पः तिष्ठन्ति l
The on-wiki version of this newsletter can be found here:
https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-21
--
As planned, we are closing the licensing discussion. The decision,
summarizing the will of the community, is as follows:
- All contributions to Wikifunctions and the wider Abstract Wikipedia
projects will be published under free licenses.
- Textual content on Wikifunctions will be published under CC BY-SA 3.0.
- Function signatures and other structured content on Wikifunctions will
be published under CC 0.
- Code implementations in Wikifunctions will be published under the
Apache 2 license.
- Abstract Content for Abstract Wikipedia will be published under CC
BY-SA 3.0.
We proposed a summary last week
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2021-12-16>,
and we heard your feedback. During Monday’s office hour, which was also
used to officially close the discussion, we incorporated two more points of
feedback:
- First, we will leave the question about the license of the generated
content from the abstract content open for now. We will re-visit this
question when we discuss the location of the abstract content for Abstract
Wikipedia next year.
- Second, we will write a document with the Legal department about how
people can re-use code from Wikifunctions as painlessly as possible, while
adhering to the license.
We also published the complete logs of Monday’s office hour
<https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/Office_hours_202…>
.
We couldn’t really reach consensus on the questions (which probably had to
be expected), so we followed the !votes and arguments raised. Thanks to
everyone who participated in the discussion, thank you for the lively
arguments, and thank you for working through the complicated situation. I
want to particularly thank Stephen LaPorte
<https://meta.wikimedia.org/wiki/User:Slaporte_(WMF)> for his support, and
Quiddity <https://meta.wikimedia.org/wiki/User:Quiddity_(WMF)> for
facilitating the work.
--
The team, together with a few volunteers, had the opportunity to reflect on
our wishes and hopes for Wikifunctions in 2022. I wanted to use the chance
of this year’s final newsletter to let you know about some of these hopes.
Our plan is to launch Wikifunctions in 2022. And our expectation is that in
the first few weeks and months after launch we will discover many bugs and
issues, and we will rely on your patience and help with those. We will
switch from a team developing a product into a team maintaining and
expanding a product, reacting to bug reports and issues. We will need to
balance the issues of an on-going project with the need to develop new
features beyond those with which we will launch.
One thing that was mentioned several times was that we look forward to
being surprised. Surprised by the creativity of the community, and what
they will do with this new project. We hope for a number of communities to
grow around parts of Wikifunctions, and that Wikifunctions will be used in
novel and unexpected ways.
Particularly high on our wishlist was the hope that smaller, underserved
communities will find their way to Wikifunctions, and that Wikifunctions
will be one way for achieving more balanced and representative communities
within current Wikipedias and the Wikimedia movement as a whole. We hope
that the functions in Wikifunctions will be requested and used by a great
diversity of contributors and users, and that Wikifunctions will start
contributing to knowledge equity in our world sooner rather than later. We
hope to see the diversity of the world reflected in our usage, in our
users, in our contributors, and in the depth and breadth of our catalog of
functions.
We hope that Wikifunctions might have the opportunity to dispel the myth
that “programming is really hard”. WIkifunctions will let people ask their
questions and answer them using functions. But not just that: we will also
expose and make transparent how these functions work. Everyone will be able
to "peek behind the curtain" and see how the answers are being computed.
This is not only meant as a way to build trust in the results of
Wikifunctions, but also to show that these computations are not that
complicated. By showing how functions are composed from simpler functions,
and allowing people to read these compositions in their language, we hope
to democratize access to functions and the knowledge of their inner
workings, not just in Wikifunctions itself but in the computers that
surround us all.
We hope to overcome in a timely fashion any challenges of technical scaling
and our growing pains as we discover new use cases for Wikifunctions. We
have a lot of ideas on how to grow and improve the system and the services
that we will offer, and we hope that the usage patterns of Wikifunction and
discussions will guide us in picking the most productive areas for
improvement.
We hope to iterate and experiment with the Wikifunctions software, and over
time discover and implement a good experience and a good conceptual model
to make Wikifunctions widely usable for everyone. We hope that people will
discover the low hanging fruit with which Wikifunctions can help them, and
that we will quickly grow beyond that into the role of being an integral
part of tomorrow’s knowledge infrastructure.
The first newsletter of 2022 should be expected in the week of 10 January
2022. Happy holidays, and a great start into the new year 2022!
