Wikipédia abstraite/Tâches

This page is a translated version of the page Abstract Wikipedia/Tasks and the translation is 70% complete.

Ceci fait partie du plan de développement de la Wikipédia abstraite.

Fait suite aux Composants de la Wikipédia abstraite.

Le développement est divisé en deux parties principales. La partie P1 est destinée à mettre en place Wikifonctions, le faire fonctionner, afin qu’il soit suffisamment développé pour soutenir la création de contenus requise pour la partie P2. La partie P2 concerne alors la création de contenu dans Wikidata et à permettre aux éditions de Wikipédia d’accéder à ce contenu. Après ceci, le développement se poursuivra pour améliorer à la fois Wikifonctions et la Wikipédia abstraite. La poursuite de ce développement n’est pas couverte par ce plan. Notez que tout le calendrier dépend de la quantité de ressources humaines avec laquelle nous pourrons travailler.

Dans la première année, nous travaillerons exclusivement sur la partie P1. La partie P2 ne démarrera que dans la deuxième année et demandera d’affecter des ressources supplémentaires au projet. Les parties P1 et P2 pourront être développées en parallèle durant les 18 mois qui suivent. Selon les résultats et succès du projet, le personnel affecté au développement ultérieur sera décidé autour du 24^e mois, puis réévalué régulièrement à partir de cette date.

Ce plan couvre les 30 premiers mois de développement. Les principaux produits livrables seront :

Wikifonctions, un nouveau projet et wiki de la Fondation Wikimédia, avec sa propre communauté et sa propre mission, qui vise à fournir un catalogue de fonctions et à permettre à chacun de partager dans ce catalogue et à lui donner du pouvoir en démocratisant l’accès à la connaissance informatique.
Un dépôt interwiki pour partager des modèles et modules entre les projets de la Fondation Wikimédia, ce qui répondra au souhait longtemps attendu des communautés. Ceci fera partie de Wikifonctions.
La Wikipédia abstraite, un projet inter-wiki qui permet de définir du contenu dans Wikidata, indépendamment de toute langue humaine, et qui est intégré dans diverses éditions locales de Wikipédia, afin d’accroître considérablement la quantité de connaissances que les locuteurs de langues actuellement mal servies pourront partager.

Partie P1 : Wikifonctions

Tâche P1.1 : initialisation du projet

Nous configurerons des pages wiki sur Méta, des composants de suivi d’anomalies, des listes de discussion, un bureau consultatif et d’autres moyens appropriés de discussion avec la communauté la plus large. Nous commencerons à en discuter, déciderons des noms pour Wikifonctions et la Wikipédia abstraite et lancerons un concours pour les logos, organiserons la création d’un code de conduite et effectuerons les étapes nécessaires pour une saine communauté.

Il nous faudra démarrer le processus communautaire pour définir le choix de licence pour les différentes parties du projet : le contenu abstrait dans Wikidata, les fonctions et autres entités dans Wikifonctions, ainsi que le statut légal du texte généré à afficher dans Wikipédia. Ceci devra être terminé avant la tâche P1.9. Cette décision nécessitera l’avis d’un conseiller juridique.

Tâche P1.2 : développement initial

La première étape de développement est de créer le wiki pour Wikifonctions avec un espaces de noms Fonction qui permettra le stockage et la modification des Objets Z (plus contraints que les objets JSON – en fait nous pourrions commencer avec les extensions JSON existantes et bâtir dessus). Le jalon initial vise à avoir :

Les types initiaux : chaîne Unicode, entier positif jusqu’à N, booléen, liste, couple, langue, texte monolingue, texte multilingue, type, fonction, mise en œuvre intégrée et erreur.
Un ensemble initial de constantes pour les types.
Un ensemble initial de fonctions : si, tête, queue, est_zéro, successeur, prédécesseur, abstraire, réifier, chaîne_égale, non-et, constructeurs, probablement quelques autres fonctions, chacune avec une mise en œuvre intégrée.

Ceci permettra de commencer à développer les composants d’interface utilisateur pour les appels de fonctions et de créer un premier ensemble d’outils et d’interfaces pour afficher les différents types d’Objets Z, mais aussi les Z Objets génériques. Ceci inclut également un premier évaluateur qui s’exécute sur les serveurs de Wikimédia.

Notez que les mises en œuvre initiales des vues, des interfaces de modification et des validateurs seront probablement jetées graduellement après P1.12 une fois que tous ceux-ci seront internalisés. Internaliser des éléments de code signifie les sortir du noyau pour les placer dans l’espace utilisateur, c’est-à-dire les mettre en œuvre à nouveau dans Wikifonctions et les appeler depuis ce dernier.

Tâche P1.3 : mise en place de l’infrastructure de test

Wikifonctions nécessitera plusieurs systèmes de test. Un pour tester le noyau, un pour tester l’interface utilisateur sur le web, un pour tester le contenu de Wikifonctions lui-même. Ceci sera une tâche poursuivie qui devra être intégrée avec le système de contrôle de version.

Tâche P1.4 : lancement du système public de test

Nous installerons un système de test visible publiquement et un système de test modifiable qui exécute les bords saillants du code (avec au moins un déploiement par journée de travail). Nous inviterons la communauté à y venir pour tenter de casser des fonctionnalités. Nous pourrions utiliser ce système pour des tests d’intégration continue.

Tâche P1.5 : évaluateur hébergé sur le serveur

Alors que le développement initial a créé un évaluateur simple qui ne fonctionne qu’avec les mises en œuvre intégrées et qui a donc un comportement très prévisible, la tâche P1.6 qui arrive pour la composition de fonction nécessitera que nous repensions l’évaluateur. Le premier évaluateur s’exécutera sur l’infrastructure de Wikimédia et nécessitera les capacités de suivi et de régulation, ainsi que potentiellement la possibilité d’allouer aux utilisateurs différentes quantités de ressources de calcul selon qu’ils sont connectés et identifiés ou pas.

Tâche P1.6 : composition de fonctions

Nous permettons la création de nouvelles interfaces de fonction et d’un nouveau type de mise en œuvre, qui sont composés d’appels de fonctions. Par ex. cela permet de mettre en œuvre

ajouter(x, y)

comme

si(est_zéro(y), x, ajouter(successeur(x), prédécesseur(y))

et le système pourra exécuter ceci. Cela permet aussi de multiples mises en œuvre.

Tâche P1.7 : gel et dégel des entités

Un niveau de protection qui permet de modifier les métadonnées d’une entité (nom, description, etc.), mais pas la valeur réelle. Cette fonctionnalité pourrait être également utile pour Wikidata. Une proposition plus élaborée du versionnement est suggérée ici.

Tâche P1.8 : lancement de Wikifonctions en version bêta

Le système bêta exécute l’itération suivante du code qui continue sur Wikifonctions avec le cycle suivant de développement, afin d’effectuer des tests.

Tâche P1.9 : lancement de Wikifonctions

Passer en revue la sécurité. Installer un nouveau wiki de projet Wikimédia. Déplacer certaines des pages wiki de Méta-Wiki à Wikifonctions.

Tâche P1.10 : type Test

Introduire un nouveau type pour l’écriture de tests des fonctions. Ceci est réalisé en spécifiant les valeurs d’entrée et une fonction qui vérifie la sortie. Au delà de l’introduction du type Test, les Fonctions et Mises en œuvre doivent aussi utiliser les Tests et les intégrer au développement d’une Mise en œuvre et aux vues d’Interface.

Tâche P1.11 : page spéciale pour écrire des appels de fonction

Nous avons besoin d’une page Spéciale qui permet et prend en charge l’écriture des Appels de fonctions, avec une vérification syntaxique de base, la complétion automatique, la documentation, etc. Un sous-ensemble de cette fonctionnalité sera également intégré aux pages des Fonctions et Mises en œuvre individuelles afin de les exécuter avec des valeurs plus complexes. Cette page Spéciale dépend de l’API simple initiale pour évaluer des Appels de fonction.

Tâche P1.12 : mises en œuvre basées sur JavaScript

Nous permettons un nouveau type de Mises en œuvre, qui sont celles écrites en JavaScript. Ceci nécessite de traduire les valeurs en JavaScript et à l’inverse en Objets-Z. Ceci nécessite également de penser à la sécurité, au moyen de l’analyse du code et d’un bac à sable, initialement enrichie par un passage en revue manuel et le gel (voir P1.7). Si le lambda-calcul (voir O1) n’a pas encore réussi ou a été sauté, nous pouvons également atteindre l’auto-hébergement pour Wikifonctions par cette tâche, qui permettrait d’internaliser la majeure partie du code.

Tâche P1.13 : fonctions d’accès

Ajouter le mot magique Lambda (voir F7) aux projets Wikimédia afin de pouvoir encoder des appels de fonctions vers Wikifonctions et d’intégrer le résultat dans la sortie du projet Wikimédia donné. Ceci créera en fait un système centralisé de modèles puisque les personnes réaliserons qu’elles peuvent désormais remettre en œuvre les modèles dans Wikifonctions et alors les appeler depuis leurs wikis locaux. Ceci sera précédé par une analyse des solutions existantes, telles que les TemplateData et les appels Lua via l’extension Scribunto.

Ceci pourrait conduire à demander aux communautés d’activer le langage des modèles de MediaWiki et Lua (voir P1.15) en tant que langages de programmation au sein de Wikifonctions. Ceci conduira probablement à des demandes pour une solution améliorée pour la liste de suivi, de façon similaire à ce qu’a fait Wikidata, et à des mises en œuvre basées sur les modèles de Mediawiki, ainsi que d’autres demandes de la communauté. Afin de compléter ces tâches, une personne supplémentaire sera utile pour répondre aux demandes de la communauté. Sinon la partie P2 pourrait ne commencer qu’un trimestre plus tard. Cette personne sera listée dans l’équipe de développement ci-dessus.

Tâche P1.14 : création de nouveaux types

Nous permettons la création de nouveaux types. Cela signifie que nous devrions être en mesure d'éditer et de créer de nouvelles définitions de type, et d'internaliser tout le code pour gérer les valeurs d'un type au sein de Wikifunctions. C'est-à-dire que nous aurons besoin de code pour valider les valeurs, les construire, les visualiser dans plusieurs environnements, etc. Nous devrions également les internaliser pour tous les types existants.

Tâche P1.15 : mises en œuvre basées sur Lua

Nous ajoutons Lua comme langage de programmation pris en charge pour les implémentations. L'importance de Lua est due à sa large utilisation dans les projets MediaWiki. De plus, si ce n'est pas déjà fait, la transformation des valeurs des wikifonctions en langage de programmation devrait être internalisée à ce stade (et également réalisée pour les implémentations JavaScript, qui utiliseront probablement des modules intégrés à ce stade).

Tâche P1.16 : interfaces non-fonctionnelles

Alors que Wikifunctions est construit sur des implémentations purement fonctionnelles, il existe certaines interfaces qui ne sont naïvement pas fonctionnelles, par exemple les nombres aléatoires, l'heure actuelle, les auto-incréments, ou de nombreux appels REST. Nous verrons comment les intégrer à Wikifonctions.

Tâche P1.17 : appels d’interfaces REST

Nous fournirons des modules intégrés pour appeler des interfaces REST sur le Web et ingérer le résultat. Cela s'appuierait de préférence sur P1.16. Notez que l'appel à des interfaces REST arbitraires pose des problèmes de sécurité. Ceux-ci doivent être pris en compte dans une conception appropriée.

Tâche P1.18 : accès à Wikidata et aux autres projets de la Fondation Wikimedia

Nous fournirons des fonctions permettant d'accéder aux articles et aux lexèmes de Wikidata, ainsi qu'à d'autres contenus des projets Wikimedia. Ceci s'appuiera de préférence sur P1.17, mais au cas où cela n'aurait pas encore réussi à ce stade, un intégré débloquera cette capacité.

Tâche P1.19 : génération monolingue

Le développement de ces fonctions se fait entièrement sur wiki. Cela inclut des tables et des enregistrements pour représenter les entités grammaticales telles que les noms, les verbes, phrases nominales, etc., ainsi que des fonctions pour travailler avec elles. Cela inclut l'implémentation du contexte afin que nous puissions générer des anaphores selon les besoins. Cela permet une génération concrète du langage naturel, c'est-à-dire pas encore abstrait.

Partie P2 : Wikipédia abstraite

Les tâches de cette partie commenceront après un an de développement. Toutes les tâches de la partie P1 ne sont pas sensées être terminées avant le début de la partie P2 car, en fait, les parties P1 et P2 continueront à être développées en parallèle. Seules certaines des tâches de la partie P1 sont nécessaires au démarrage de la partie P2.

Tâche P2.1 : constructeurs et moteurs de rendu

Ici nous introduisons les interfaces abstraites vers les générateurs concrets développés dans la tâche P1.19. Ceci nous conduit au développement initial des Constructeurs et de la fonction Rendu. Après cette tâche, la communauté devrait être en mesure de créer de nouveaux Constructeurs et d’étendre les Moteurs de rendu pour les prendre en charge.

Les Constructeurs sont utilisés pour la notation du contenu abstrait. Les Constructeurs sont indépendants de la langue et ne devraient contenir aucune logique conditionnelle.
Les Moteurs de rendu devraient détenir la logique conditionnelle effective (qui s’applique aux informations données aux constructeurs). Les rendus peuvent être définis selon la langue (mais peuvent également être partagés entre diverses langues).
La séparation entre les deux est analogue à la séparation dans d’autres systèmes de génération en langue naturelle, tel que Grammatical Framework.

Tâche P2.2 : rendu conditionnel

It will rarely be the case that a Renderer will be able to render the Content fully. We will need to support graceful degradation: if some Content fails to render, but other still renders, we should show that part that rendered. But sometimes it is narratively necessary to render certain Content only if other Content will definitely be rendered. In this task we will implement the support for such conditional rendering, that will allow smaller communities to grow their Wikipedias safely.

Tâche P2.3 : Wikipédia abstraite

Create a new namespace in Wikidata and allow Content to be created and maintained there. Reuse UI elements and adapt them for Content creation. The UI work will be preceded by Design research work which can start prior to the launch of Part P2. Some important thoughts on this design are here. This task will also decide whether we need new magic words (F5, F6, and F7) or can avoid their introduction.

Tâche P2.4 : interface utilisateur pour mobiles

The creation and editing of the Content will be the most frequent task in the creation of a multilingual Wikipedia. Therefore we want to ensure that this task has a pleasant and accessible user experience. We want to dedicate an explicit task to support the creation and maintenance of Content in a mobile interface. The assumption is that we can create an interface that allows for a better experience than editing wikitext.

Tâche P2.5 : intégration de contenus vers les éditions locales de Wikipédia

Enable the Abstract Wikipedia magic word. Then allow for the explicit article creation, and finally the implicit article creation (F1, F2, F3, F4, F5, F6).

Tâche P2.6 : inflexions régulières

Wikidata’s Lexemes contain the inflected Forms of a Lexeme. These Forms are often regular. We will create a solution that generates regular inflections through Wikifunctions and will discuss with the community how to integrate that with the existing Lexemes.

Tâche P2.7 : rendu basique en anglais

We assume that the initial creation of Renderers will be difficult. Given the status of English as a widely used language in the community, we will use English as a first language to demonstrate the creation of a Renderer, and document it well. We will integrate the help from the community. This also includes functionality to show references.

Tâche P2.8 : rendu basique dans une seconde langue

Based on the community feedback, interests, and expertise of the linguists working on the team, we will select a second large language for which we will create the basic Renderer together with the community. It would be interesting to choose a language where the community on the local Wikipedia has already confirmed their interest to integrate Abstract Wikipedia.

Tâche P2.9 : rendu basique dans une langue d’une autre famille

Since it is likely that the language in P2.8 will be an Indo-European language, we will also create a basic Renderer together with the community for a language from a different language family. The choice of this language will be done based on the expertise available to the team and the interests of the community. It would be interesting to choose a language where the community on the local Wikipedia has already confirmed their interest to integrate Abstract Wikipedia.

Tâche P2.10 : rendu dans une langue moins favorisée

Since it is likely that the languages in P2.8 and P2.9 will be languages which are already well-served with active and large Wikipedia communities, we will also select an underserved language, a language that currently has a large number of potential readers but only a small community and little content. The choice of this language will be done based on the expertise available to the team and the interests of the community. Here it is crucial to select a language where the community on the local Wikipedia has already committed their support to integrate Abstract Wikipedia.

Tâche P2.11 : descriptions Wikidata abstraites

Wikidata Descriptions seem particularly amenable to be created through Wikifunctions. They are often just short noun phrases. In this task we support the storage and maintenance of Abstract Descriptions in Wikidata, and their generation for Wikidata. We also should ensure that the result of this leads to unique combinations of labels and descriptions.

See Abstract Wikipedia/Updates/2021-07-29 for further details and discussion.

Tâche P2.12 : gloses abstraites

Wikidata Lexemes have Senses. Senses are captured by Glosses. Glosses are available per language, which means that they are usually only available in a few languages. In order to support a truly multilingual dictionary, we are suggesting to create Abstract Glosses. Although this sounds like it should be much easier than creating full fledged Wikipedia articles, we think that this might be a much harder task due to the nature of Glosses.

Tâche P2.13 : prise en charge de plus de langues humaines

Support other language communities in the creation of Renderers, with a focus on underserved languages.

Tâche P2.14 : contenu généré par modèle

Some Wikipedias currently contain a lot of template-generated content. Identify this content and discuss with the local Wikipedias whether they want to replace it with a solution based on Wikifunctions, where the template is in Wikifunctions and the content given in the local Wikipedia or in Abstract Wikipedia. This will lead to more sustainable and maintainable solutions that do not require to rely on a single contributor. Note that this does not have to be multilingual, and might be much simpler than going through full abstraction.

Tâche P2.15 : commentaires des cas d’utilisation

Allow casual contributors to make comments on the rendered text and create mechanisms to capture those comments and funnel them back to a triage mechanism that allows to direct them to either the content or the renderers. It is important to not lose comments by casual contributors. Ideally, we would allow them to explicitly overwrite a part of the rendered output and consider this a change request, and then we will have more involved contributors working on transforming the intent of the casual contributor to the corresponding changes in the system.

Tâche P2.16 : génération rapide de nom d’article

The general public comes to Wikipedia mostly by typing the names of the things they are looking for in their language into common search engines. This means that Wikidata items will need labels translated into a language in order to be able to use implicit article creation. This can probably be achieved by translating millions of Wikidata labels. Sometimes it can be done by bots or AI, but this is not totally reliable and scalable, so it has to involve humans.

The current tools for massive crowd-sourced translation of Wikidata labels are not up to the task. There are two main ways to do it: editing labels in Wikidata itself, which is fine for adding maybe a dozen of labels, but quickly gets tiring, and using Tabernacle, which appears to be more oriented at massive batch translations, but is too complicated to actually use for most people.

Cette tâche consiste à développer un outil de traduction d'étiquettes massif et intégré avec une interface simple et moderne, qui peut être utilisée par de nombreuses personnes.

Tâches non essentielles

Voici une liste entière de tâches avancées facultatives. Idéalement, celles-ci pourraient être menées par des communautés externes et développées en code source ouvert hors de l’équipe initiale de développement, mais certaines d’entre elles pourraient avoir besoin d’être commencées ou même développées entièrement par l’équipe principale.

Tâche O1 : lambda-calcul

It is possible to entirely self-host Wikifunctions without relying on builtins or implementations in other programming languages, by implementing a Lambda calculus in Wikifunctions (this is where the name proposal comes from). This can be helpful to allow evaluation without any language support, and so easier start up the development of evaluators.

Tâche O2 : interface en ligne de commande (CLI) dans un terminal

Many developers enjoy using a command line interface to access a system such as Wikifunctions. We should provide one, with the usual features such as autocompletion, history, shell integration, etc.

Tâche O3 : interfaces utilisateur (UIs) pour créer, déboguer et tracer les fonctions

Wikifunctions’s goal is to allow the quick understanding and development of the functions in Wikifunctions. Given the functional approach, it should be possible to create a user experience that allows for partial evaluation, unfolding, debugging, and tracing of a function call.

Tâche O4 : amélioration de l’efficacité de l’évaluateur

There are many ways to improve the efficiency of evaluators, and thus reduce usage of resources, particularly caching, or the proper selection of an evaluation strategy. We should spend some time on doing so for evaluators in general and note down the results, so that different evaluators can use this knowledge, but also make sure that the evaluators maintained by the core team use most of the best practises.

Tâche O5 : réseau de confiance (Web of Trust) pour les mises en œuvre

In order to relax the conditions for implementations in programming languages, we could introduce a Web of Trust based solution, that allows contributors to review existing implementations and mark their approval explicitly, and also to mark other contributors as trustworthy. Then these approvals could be taken into account when choosing or preparing an evaluation strategy.

Tâche O6 : mises en œuvre basées sur Python

Python is a widely used programming language, particularly for learners and in some domains such as machine learning. Supporting Python can open a rich ecosystem to Wikifunctions.

Tâche O7 : mises en œuvre dans d’autres langages

We will make an effort to call out to other programming language communities to integrate them into Wikifunctions, and support them. Candidates for implementations are Web Assembler, PHP, Rust, C/C++, R, Swift, Go, and others, but it depends on the interest of the core team and the external communities to create and support these interfaces.

Tâche O8 : environnement d’évaluation interactive (REPL) basé sur le web

A web-based REPL can bring the advantages of the O2 command line interface to the Web, without requiring to install a CLI in a local environment, which is sometimes not possible.

Tâche O9 : extension de l’API avec un analyseur et linéarisateur

There might be different parsers and linearizers using Wikifunctions. The Wikifunctions API can be easier to use if the caller could explicitly select these, instead of wrapping them manually, which would allow the usage of Wikifunctions with different surface dialects.

Tâche O10 : prise en charge de pages de discussions

In order to support discussions on talk pages of Wikifunctions, develop and integrate a mechanism that allows for (initially) simple discussions, and slowly raising their complexity based on the need of the communities.

Tâche O11 : création de textes juridiques

An interesting application of Wikifunctions is for the creation of legal text in a modular manner and with different levels (legalese vs human-readable), similar to the different levels of description for the different Creative Commons licenses.

Tâche O12 : création de textes relatifs à la santé

An interesting application of Wikifunctions is for the creation of health-related texts for different reading levels. This should be driven by WikiProject Medicine and their successful work, which could reach many more people through cooperation with Wikifunctions.

Tâche O13 : bibliothèque NPM pour Javascript

We will create a Wikidata library for NPM that allows the simple usage of Functions from Wikifunctions in a JavaScript program. The same syntax should be used to allow JavaScript implementations in Wikifunctions to access other Wikifunctions functions. Note that this can be done by virtue of calling to a Wikifunctions evaluator, or by compiling the required functions into the given code base.

Tâche O14 : bibliothèque Python

We will create a Python library that allows the simple usage of Functions from Wikifunctions in a Python script. The same syntax should be used to allow Python implementations in Wikifunctions to access other Wikifunctions functions. Note that this can be done by virtue of calling to a Wikifunctions evaluator, or by compiling the required functions into the given code base.

Tâche O15 : bibliothèques pour d’autres langages de programmation

We will call out to the communities of several programming languages to help us with the creation of libraries that allow the simple call of Wikifunctions functions from programs in their language. Note that this can be done by virtue of calling to a Wikifunctions evaluator, or by compiling the required functions into the given code base.

Tâche O16 : évaluateur basé sur le navigateur

One of the advantages of Wikidata is that the actual evaluation of a function call can happen in different evaluators. The main evaluator for Abstract Wikipedia will be server-based and run by the Wikimedia Foundation, but in order to reduce the compute load, we should also provide evaluators running in the user’s client (probably in a Worker thread).

Tâche O17 : évaluateur basé sur Jupyter ou PAWS

One interesting evaluator is from a Jupyter or PAWS notebook, and thus allowing the usual advantages of such notebooks but integrating also the benefits from Wikifunctions.

Tâche O18 : évaluateur basé sur une application native

One evaluator should be running natively on Android or iOS devices, and thus allow the user to use the considerable computing power in their hand.

Tâche O19 : évaluateur distribué (en pair-à-pair)

Many of the evaluators could be linking together and allow each other to use dormant compute resources in their network. This may or may not require shields between the participating nodes that ensure the privacy of individual computes.

Tâche O20 : évaluateur hébergé sur un serveur tiers (cloud)

One obvious place to get compute resources is by allowing to use a cloud provider. Whereas it would be possible to simply run the server-based evaluator on a cloud-based infrastructure, it is likely to be beneficial for the cloud providers to provide a thinner interface to a more custom-tailored evaluator.

Tâche O21 : type de données pour flux diffusé (stream)

Add support for a type for streaming data, both as an input as well as an output. Stream types means for example the recent changes stream on a Wikimedia wiki.

Tâche O22 : type de données binaires

Ajout de la prise en charge des fichiers binaires, tant en entrée qu'en sortie.

Tâche O23 : intégration avec les fichiers média de Wikimedia Commons

Allow direct access to files on Commons. Enable workflows with Commons that require less deployment machinery than currently needed. Requires O22.

Tâche O24 : intégration avec l’apprentissage par la machine

Develop a few example integrations with Machine Learning solutions, e.g. for NLP tasks or for work on image or video e.g. using classifiers. This requires how and where to store models, possibly also how to train them, and how to access them.

Tâche O25 : intégration dans les environnements interactifs de développement (IDEs)

Reach out to communities developing IDEs and support them in integrating with Wikifunctions, using type hints, documentation, completion, and many of the other convenient and crucial features of modern IDEs.

Tâche O26 : création d’applications ou de sites web simples

Develop a system to allow the easy creation and deployment of apps or Websites relying on Wikifunctions.

Tâche O27 : affichage des tâches ouvertes aux contributeurs

Abstract Wikipedia will require one Renderer for every Constructor for every language. It will be helpful if contributors could get some guidance to which Renderer to implement next, as this is often not trivially visible. Just counting how often a Constructor appears could be a first approximation, but if some Constructors are used more often in the lead, or in parts of the text that block other text from appearing, or in articles that are more read than others, this approximation might be off. In this task we create a form of dashboard that allows users to choose a language (and maybe a domain, such as sports, geography, history, etc., and maybe a filter for the complexity of the renderer that is expected) and then provide them with a list of unrendered Constructors ranked by the impact an implementation would have.

We could also allow contributors to sign up for a regular message telling them how much impact (in terms of views and created content) they had, based on the same framework needed for the dashboard.

This is comparable to seeing the status of translations of different projects on TranslateWiki.Net (for a selectable language), or the views on topics, organizations or authors in Scholia. For each project, it shows what % of the strings in it were translated and what % need update, and a volunteer translator can choose: get something from 98% to 100%, get something from 40% to 60%, get something from 0% to 10%, etc.

Tâche O28 : vue des activités

Whereas the default view of Rendered content would look much like static text, there should also be a more active view that invites contribution, based on existing Content that failed to render due to missing Renderers. In the simplest case this can be the creation of a Lexeme in Wikidata and connecting to the right Lexeme. In more complex cases that could be writing a Renderer, or offering example sentences as text, maybe using the Casual contribution path described in P2.15. This would provide an interesting funnel to turn more readers in contributors.

There are product and design decisions on how and where the active view should be used and whether it should be the default view, or whether it should be only switched on after an invitation, etc. There could also be mode where contributors can go from article to article and fill out missing pieces, similar to the more abstract way in O27.

It would probably be really useful that ensure that the active way and the contribution path it leads to work on mobile devices as well.

Tâche O29 : compilation des mises en œuvre

The function composition used for implementations should allow to create highly performant compilations of rather high-level functions in many different target programming languages, particularly Web Assembler and JavaScript. This should speed up evaluation by several orders of magnitude.

Tâche O30 : intégration avec des exemples de code sur Wikipédia, Wikibooks, etc.

Permettre à Wikipédia, à Wikilivres et aux autres projets d’intégrer leurs exemples de code directement dans le wiki des fonctions, afin que ceux-ci puissent s’exécuter en direct.

Ceci fait partie du plan de développement de la Wikipédia abstraite.

Partie P1 : Wikifonctions

Tâche P1.1 : initialisation du projet

Tâche P1.2 : développement initial

Tâche P1.3 : mise en place de l’infrastructure de test

Tâche P1.4 : lancement du système public de test

Tâche P1.5 : évaluateur hébergé sur le serveur

Tâche P1.6 : composition de fonctions

Tâche P1.7 : gel et dégel des entités

Tâche P1.8 : lancement de Wikifonctions en version bêta

Tâche P1.9 : lancement de Wikifonctions

Tâche P1.10 : type Test

Tâche P1.11 : page spéciale pour écrire des appels de fonction

Tâche P1.12 : mises en œuvre basées sur JavaScript

Tâche P1.13 : fonctions d’accès

Tâche P1.14 : création de nouveaux types

Tâche P1.15 : mises en œuvre basées sur Lua

Tâche P1.16 : interfaces non-fonctionnelles

Tâche P1.17 : appels d’interfaces REST

Tâche P1.18 : accès à Wikidata et aux autres projets de la Fondation Wikimedia

Tâche P1.19 : génération monolingue

Partie P2 : Wikipédia abstraite

Tâche P2.1 : constructeurs et moteurs de rendu

Tâche P2.2 : rendu conditionnel

Tâche P2.3 : Wikipédia abstraite

Tâche P2.4 : interface utilisateur pour mobiles

Tâche P2.5 : intégration de contenus vers les éditions locales de Wikipédia

Tâche P2.6 : inflexions régulières

Tâche P2.7 : rendu basique en anglais

Tâche P2.8 : rendu basique dans une seconde langue

Tâche P2.9 : rendu basique dans une langue d’une autre famille

Tâche P2.10 : rendu dans une langue moins favorisée

Tâche P2.11 : descriptions Wikidata abstraites

Tâche P2.12 : gloses abstraites

Tâche P2.13 : prise en charge de plus de langues humaines

Tâche P2.14 : contenu généré par modèle

Tâche P2.15 : commentaires des cas d’utilisation

Tâche P2.16 : génération rapide de nom d’article

Tâches non essentielles

Tâche O1 : lambda-calcul

Tâche O2 : interface en ligne de commande (CLI) dans un terminal

Tâche O3 : interfaces utilisateur (UIs) pour créer, déboguer et tracer les fonctions

Tâche O4 : amélioration de l’efficacité de l’évaluateur

Tâche O5 : réseau de confiance (Web of Trust) pour les mises en œuvre

Tâche O6 : mises en œuvre basées sur Python

Tâche O7 : mises en œuvre dans d’autres langages

Tâche O8 : environnement d’évaluation interactive (REPL) basé sur le web

Tâche O9 : extension de l’API avec un analyseur et linéarisateur

Tâche O10 : prise en charge de pages de discussions

Tâche O11 : création de textes juridiques

Tâche O12 : création de textes relatifs à la santé

Tâche O13 : bibliothèque NPM pour Javascript

Tâche O14 : bibliothèque Python

Tâche O15 : bibliothèques pour d’autres langages de programmation

Tâche O16 : évaluateur basé sur le navigateur

Tâche O17 : évaluateur basé sur Jupyter ou PAWS

Tâche O18 : évaluateur basé sur une application native

Tâche O19 : évaluateur distribué (en pair-à-pair)

Tâche O20 : évaluateur hébergé sur un serveur tiers (cloud)

Tâche O21 : type de données pour flux diffusé (stream)

Tâche O22 : type de données binaires

Tâche O23 : intégration avec les fichiers média de Wikimedia Commons

Tâche O24 : intégration avec l’apprentissage par la machine

Tâche O25 : intégration dans les environnements interactifs de développement (IDEs)

Tâche O26 : création d’applications ou de sites web simples

Tâche O27 : affichage des tâches ouvertes aux contributeurs

Tâche O28 : vue des activités

Tâche O29 : compilation des mises en œuvre

Tâche O30 : intégration avec des exemples de code sur Wikipédia, Wikibooks, etc.