I agree this makes sense.

One quick thought that seems to reduce the stakes significantly, to my mind, is that unlike Wikipedia, where there can only be *one* article about a given topic, and where therefore a lot of conflict centers around what that one article should or should not say, WikiFunctions can naturally have redundant functions achieving (or alleging to achieve) the same goals.

Thus, if X really hates Y's implementation of a factorial function, X can write their own (or fork!), and both can live side by side, and re-users will get to choose which implementation they prefer. That alone can significantly pre-empt a lot of potential conflict.

Of course, conflict will still happen precisely at the point of re-use, i.e. should some highly-reused function itself use implementation X or Y. Additionally, due to the unfortunate fact WikiFunctions still relies on humans, there will also be conflict around *conduct*, like every other wiki.

A.

Asaf Bartov (he/him/his)

Senior Program Officer, Emerging Wikimedia Communities

Wikimedia Foundation https://wikimediafoundation.org/

Imagine a world in which every single human being can freely share in the sum of all knowledge. Help us make it a reality! https://donate.wikimedia.org

On Tue, Sep 27, 2022 at 9:43 PM Denny Vrandečić dvrandecic@wikimedia.org wrote:

The on-wiki version of this newsletter can be found here: https://meta.wikimedia.org/wiki/Abstract_Wikipedia/Updates/2022-09-27 --

Right from the start, Wikifunctions will be somewhat more complex than many other Wikimedia projects. Sure, over time many of the Wikimedia projects have accrued a lot of complexity: just think about Lua modules https://www.mediawiki.org/wiki/Lua, conditional templates https://www.mediawiki.org/wiki/Template:If, or the sophisticated use of MediaWiki features to support the workflows of the community.

These complexities, however, have grown in scale alongside their wikis' communities, and all of the projects have started out with a very simple workflow. Wikifunctions will not. Though we are trying our best to make the project as accessible and usable as possible, we also want to help the community as best as possible to get the project off the ground.

In order to do so, we at the Wikimedia Foundation want to do something that we usually don’t: directly support the community by contributing on-wiki to the main namespace of Wikifunctions in our capacity as staff, from our staff accounts.

Usually, edits to the main namespace for staff accounts are limited to exceptional circumstances. This is primarily to make it very clear that the content of each of the projects belongs to its community. This is particularly important for projects like Wikipedia, where sometimes subtle changes in wording can be very important and have significant real-world consequences, as we were just reminded again recently https://en.wikipedia.org/wiki/Talk:Recession.

Wikifunctions is different. Its content will be functions, their implementations, and other supporting objects. We would like to be able to work together with the community, in our paid time as staff members. This means working on functions, helping to improve implementations, showing exemplary cases of how to use new features, and also speeding up the creation of implementations for functions requested by the community.

One particular domain where we are planning to contribute is for functions around natural language generation. I think that, without staff support, the necessary functions to make Abstract Wikipedia possible might take a long time to develop, and that support by staff can speed up that key area considerably.

Despite this approach, we also want to make sure that Wikifunctions remains under the full ownership of the community. Whereas in the beginning our staff accounts might have certain special rights on Wikifunctions (e.g. the right to create instances of certain types), we want these roles to be transferred to the community sooner rather than later. We don’t want to be the ones making policy decisions beyond what is technically necessary (e.g. for platform performance or code-security reasons). We don’t want to be assigning sysop rights or other community leadership positions. We don’t want to make policy decisions about which functions, implementations, or which test cases are deemed necessary, valuable, or acceptable. All of these areas, and more, should be fully owned by the Wikifunctions community.

It seems prudent and necessary, in order to be transparent, that the community drafts a policy together with us in order to define how we will be editing the Wikifunctions main namespace as staff. Since we will need this policy to be in place from the beginning of Wikifunctions, we are proposing to go the unusual path of creating a preliminary policy here on Meta with interested community members, which we will then transfer to Wikifunctions upon launch. That policy should be revisited once the Wikifunctions community has formed, and once we have hands-on experience with such edits.

*Request*: We are calling for contributors to lead the creation of this preliminary policy, and asking everyone to comment and contribute to the policy. If no contributors step forward, the Abstract Wikipedia team will take the lead on drafting the preliminary policy. The policy will be drafted at Abstract Wikipedia/Staff editing https://meta.wikimedia.org/w/index.php?title=Abstract_Wikipedia/Staff_editing&action=edit&redlink=1 and discussed at Talk:Abstract Wikipedia/Staff editing https://meta.wikimedia.org/w/index.php?title=Talk:Abstract_Wikipedia/Staff_editing&action=edit&redlink=1 .

There are many questions to be answered: what limitations should staff accounts face, if any? What about staff who are also volunteers? Should staff also apply for sysop rights and other roles, or should they automatically have certain rights and thus also responsibilities? How should staff engage in debates, if at all? These are difficult questions that would benefit from a preliminary answer, given to staff by the community.

Note that all of this is strictly regarding Wikifunctions, and does not have any implications for the other Wikimedia projects.

We are looking forward to working together! _______________________________________________ Abstract-Wikipedia mailing list -- abstract-wikipedia@lists.wikimedia.org List information: https://lists.wikimedia.org/postorius/lists/abstract-wikipedia.lists.wikimed...