Two weeks ago we held an internal planning meeting to sketch out what we want to work on in the current quarter. Last week we collected and wrote down the results, and we want to share those results with you.
Our team's overarching goal is to work towards supporting the pieces needed for Abstract Wikipedia.
As this was our first planning effort for such a cadence, part of it is also learning to pick the right size of work. At the end of the quarter we will look back at what we actually achieved, and will learn from that for the next quarter.
Nick "Quiddity" Wilson at Wikimania 2023Last week saw Nick Wilson’s last day on the Abstract Wikipedia team, before he heads into a well-deserved break. Nick may to some of you be better known under his wikinym “Quiddity”. Nick was part of the Abstract Wikipedia project from the very beginning, set up and organized the naming contest for Wikifunctions, and set up most of our communication structures.
Here are a few words by Nick as a good bye message:
Thank you, all!
It has been fascinating, humbling, motivating, and deeply inspiring to be a part of these complex projects. I've appreciated getting to know (or become more deeply familiar with) so many aspects of our movement and our mission, and more of the people that steadily help everything to move forwards.
As always, I wish I could clone myself in order to continue focusing on this project forever, in addition to working in new areas. I'm eagerly looking forward to a function-powered future, and I hope to continue helping in a volunteer capacity after I take a short wikibreak.‘
Luca, who joined us in early 2022, will continue in the role of Community Relations Specialist on the project and take over Nick’s responsibilities. Please join me in thanking Nick for his work!
As discussed above, part of our bigger work this quarter is type support leading to Wikidata support. As part of this, we've fixed and now re-enabled validation for types (T352295), which shouldn't have any visible effect yet but will unlock the ability to tell the user their input is wrong when trying to use a type (such as saying that a natural number cannot have non-digits in it, or a date in February cannot be on the 30th day).
We've now made a small tweak to the display of strings returned from functions, wrapping them in double-quotes, which makes it possible to distinguish "" and " " as different responses. This does not fix all issues with spaces in inputs, as the nature of HTML makes some possible return values hard to cope with in a scalable way that doesn't break other use cases. We plan to come back to this area with further improvements, and would love your thoughts on improvements you'd like to see.
We've also fixed the interface breaking when using a language that MediaWiki doesn't support, such as https://www.wikifunctions.org/view/elx/Z10000 – previously you would end up in a broken state, but now things work as designed (phab:T356428). This also means that if you try to use a language that even Wikifunctions doesn't know about, such as https://www.wikifunctions.org/view/hellothisisnotalanguage/Z10000, the system will fall back to English (like the rest of MediaWiki) rather than mysteriously providing a mixture of English and mostly bugs.
In smaller changes, one is a follow-up to last week's change to remove the noindex directive from our pages so that Google and other search engines see them (phab:T355441). Alongside the main links like https://wikifunctions.org/view/ar/Z801, we still have some URLs that also work due to how MediaWiki controls pages, like …/wiki/Z801?uselang=ar, or …/wiki/Special:ViewObject/ar/Z801; these will now no longer claim to be "canonical" (T355546). Another is that we've moved all the linked software help pages on MediaWiki.org to be in the same place, in the "Help:Wikifunctions" hierarchy. We've also made a tweak to the UX of the language selector on a page when it has a number of translations already – the padding is now in line with the rest of the form, instead of much wider (T355946).
We also added two new languages that MediaWiki supports: Ebira (Z1920) and Petjo (Z1921). These are added manually in production.
On the code side, we've made some minor improvements to our PHP code's coverage of the critical ZObject classes, edging up towards 100% (T302599). We've made a series of clean-ups to our front-end code following-on from previous work, removing unused components (T301868) and generally improving our data store code (T329107). This week is a "Fix It" week for the team, so we'll make further such improvements that will ship next week.
For this week’s Function of the Week I asked Nick for a favorite function, and he immediately answered that he loves lists and the unusual, and so he would like to choose an unusual function that deals with lists. Looking at the catalog of list functions, most of them were what you would expect from list operations, but one of them struck us as unusual in the sense that most programming languages would not have support for that functionality out of the box: is permutation (please feel free to correct us).
Permutations of three colorsA permutation of a list is a second list that has exactly the same elements, but possibly in a different order. The function is permutation takes two lists and checks if they are permutations of each other. The function returns a Boolean value: true if the two lists are permutations of each other, and false if they are not.
In general, I have a bit of an issue with a function like this one: the function is defined on lists of objects, and not on lists of a specific type, such as a list of strings, or a list of Booleans. But not all types will necessarily have a function to check for equality, which will be a necessary prerequisite for this function to work. So this might lead to problems down the road. I am not sure how to handle this best.
The function currently has five tests: three pairs that are not permutations – (a, a, a) / (a, b, c), (b,c) / (a,b,c), and (b,b,a) / (a,a,b) – and two pairs that are permutations, (b,c,a) / (a,b,c) and (a,b,a) / (a,a,b). It’s great to see five tests! I would also go for some edge cases (what about empty lists?) and, given that the function is defined on lists of any type, also for lists that have more than single-character strings as elements. But again, yay for five tests! With five tests, the function is in the top 10% of functions per number of tests.
The function currently has three implementations, one in Python and two compositions. The Python implementation has two steps: it first does a short-cut, checking if the two lists have different lengths. If they do, it stops the implementation and returns False: two lists that have different lengths can never be permutations of each other. Once we know they have the same length, we compare whether the two lists, when sorted, are the same. If they are, the two lists are permutations of each other, if not, they are not. The sorting turns each of the input lists into a canonical version with regards to its elements that is independent of the order, which is why this implementation works. In theory, we could also drop the first step from this implementation, but having the check probably allows for some speed-up.
One of the compositions works by using supersets: we have a function, is superset, that checks whether one list is a superset of the other. The composition here uses is superset to check whether the first list is a superset of the second, and the second is a superset of the first. If both conditions are fulfilled (we check that by using and), we know that both lists contain all the elements of the other list, and therefore contain the same elements, and thus they must be permutations of each other. Two of the tests time out, but unfortunately with an unusable error message. A bug has been reported (T356556).
The other composition is more elaborate:
In this last step we remove the same element from both lists, and are thus left with two shorter lists. If those are permutations of each other, the two lists with the removed elements would also be permutations of each other, no matter where those two elements are added in those lists.
If the first element of the second list does not exist in the first list, the first list remains unchanged, a condition checked by this test on remove first matching element function.
The two compositions illustrate how different two compositions can be in terms of complexity: the composition using superset is a very simple composition, almost like a definition, combining just two existing functions. The other composition is much more elaborate, combining quite a number of different functions, using nested if conditions, and a recursive call. The latter composition is probably about half-way through the complexity level I would expect us to support for function compositions: I wouldn’t expect much more complex compositions than that in Wikifunctions at all. But, in the end, both compositions are great examples of how to use composition for creating higher-level functions.