Wikipédia abstraite/Tâches

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 :

1. 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.
2. 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.
3. 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.

<span id="_Part_P1:_Wikifunctions">

Partie P1 : Wikifonctions

<span id="_Task_P1.1:_Project_initialization">

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.

<span id="_Task_P1.2:_Initial_development">

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.

<span id="_Task_P1.3:_Set_up_testing_infrastructure">

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.

<span id="_Task_P1.4:_Launch_public_test_system">

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.

<span id="_Task_P1.5:_Server-based_evaluator">

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.

<span id="_Task_P1.6:_Function_composition">

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.

<span id="_Task_P1.7:_Freeze_and_thaw_entities">

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.

<span id="_Task_P1.8:_Launch_beta_Wikifunctions">

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.

<span id="_Task_P1.9:_Launch_Wikifunctions">

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.

<span id="_Task_P1.10:_Test_type">

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.

<span id="_Task_P1.11:_Special_page_to_write_function_calls">

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.

<span id="_Task_P1.12:_JavaScript-based_implementations">

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.

<span id="_Task_P1.13:_Access_functions">

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.

<span id="_Task_P1.14:_Create_new_types">

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.

<span id="_Task_P1.15:_Lua-based_implementations">

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).

<span id="_Task_P1.16:_Non-functional_interfaces">

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.

<span id="_Task_P1.17:_REST_calls">

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.

<span id="_Task_P1.18:_Accessing_Wikidata_and_other_WMF_projects">

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é.

<span id="_Task_P1.19:_Monolingual_generation">

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.

<span id="_Part_P2:_Abstract_Wikipedia">

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.

<span id="_Task_P2.1:_Constructors_and_Renderers">

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.

<span id="_Task_P2.2:_Conditional_rendering">

Tâche P2.2 : rendu conditionnel

Il est rare qu'un moteur de rendu soit en mesure de restituer le contenu dans son intégralité. Nous devrons prendre en charge la dégradation gracieuse : si un contenu ne s'affiche pas, mais que d'autres le sont toujours, nous devons afficher la partie qui a été restituée. Mais il est parfois nécessaire, sur le plan narratif, de restituer certains contenus uniquement si d'autres contenus seront définitivement restitués. Dans cette tâche, nous allons implémenter la prise en charge d'un tel rendu conditionnel, qui permettra aux petites communautés de développer leurs Wikipédias en toute sécurité.

<span id="_Task_P2.3:_Abstract_Wikipedia">

Tâche P2.3 : Wikipédia abstraite

Créez un nouvel espace de noms dans Wikidata et autorisez la création et la maintenance de contenu à cet endroit. Réutilisez les éléments de l'interface utilisateur et adaptez-les à la création de contenu. Le travail sur l'interface utilisateur sera précédé par un travail de recherche sur la conception qui peut commencer avant le lancement de la partie P2. Quelques réflexions importantes sur cette conception sont ici. Cette tâche permettra également de décider si nous avons besoin de nouveaux mots magiques (F5, F6 et F7) ou si nous pouvons éviter leur introduction.

<span id="_Task_P2.4:_Mobile_UI">

Tâche P2.4 : interface utilisateur pour mobiles

La création et l'édition du contenu seront les tâches les plus fréquentes dans la création d'une Wikipédia multilingue. Nous voulons donc nous assurer que cette tâche offre une expérience utilisateur agréable et accessible. Nous souhaitons consacrer une tâche explicite à la création et à la maintenance du contenu dans une interface mobile. L'hypothèse est que nous pouvons créer une interface qui permette une meilleure expérience que l'édition de wikitexte.

<span id="_Task_P2.5:_Integrate_content_into_the_Wikipedias">

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

Activez le mot magique Résumé de Wikipédia. Autorisez ensuite la création d'articles explicites, et enfin la création d'articles implicites (F1, F2, F3, F4, F5, F6).

<span id="_Task_P2.6:_Regular_inflection">

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

Les lexèmes de Wikidata contiennent les formes fléchies d’un lexème. Ces formes sont souvent régulières. Nous allons créer une solution qui génère des inflexions régulières grâce aux fonctions Wiki et nous discuterons avec la communauté de la manière d’intégrer cela aux lexèmes existants.

<span id="_Task_P2.7:_Basic_Renderer_for_English">

Tâche P2.7 : rendu basique en anglais

Nous partons du principe que la création initiale de moteurs de rendu sera difficile. Étant donné le statut de l'anglais en tant que langue largement utilisée dans la communauté, nous utiliserons l'anglais comme première langue pour démontrer la création d'un moteur de rendu et le documenter correctement. Nous intégrerons l'aide de la communauté. Cela inclut également une fonctionnalité permettant d'afficher des références.

<span id="_Task_P2.8:_Basic_Renderer_for_a_second_language">

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

En fonction des retours de la communauté, des intérêts et de l'expertise des linguistes travaillant dans l'équipe, nous sélectionnerons une deuxième grande langue pour laquelle nous créerons le moteur de rendu de base avec la communauté. Il serait intéressant de choisir une langue pour laquelle la communauté de la Wikipédia locale a déjà confirmé son intérêt à intégrer Abstract Wikipedia.

<span id="_Task_P2.9:_Renderer_for_a_language_from_another_family">

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

Comme il est probable que la langue de P2.8 soit une langue indo-européenne, nous allons également créer avec la communauté un moteur de rendu de base pour une langue d'une autre famille de langues. Le choix de cette langue se fera en fonction de l'expertise dont dispose l'équipe et des intérêts de la communauté. Il serait intéressant de choisir une langue pour laquelle la communauté sur la Wikipédia locale a déjà confirmé son intérêt à intégrer Abstract Wikipedia.

<span id="_Task_P2.10:_Renderer_for_an_underserved_language">

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

Comme il est probable que les langues des P2.8 et P2.9 soient des langues qui sont déjà bien desservies par des communautés Wikipédia actives et importantes, nous sélectionnerons également une langue mal desservie, une langue qui a actuellement un grand nombre de lecteurs potentiels mais seulement une petite communauté et peu de contenu. Le choix de cette langue se fera en fonction de l'expertise dont dispose l'équipe et des intérêts de la communauté. Il est ici crucial de sélectionner une langue dans laquelle la communauté de la Wikipédia locale s'est déjà engagée à soutenir l'intégration de la Wikipédia abstraite.

<span id="_Task_P2.11:_Abstract_Wikidata_Descriptions">

Tâche P2.11 : descriptions Wikidata abstraites

Les descriptions Wikidata semblent particulièrement adaptées à la création via les fonctions Wiki. Elles se composent souvent de simples phrases nominales courtes. Dans cette tâche, nous prenons en charge le stockage et la maintenance des descriptions abstraites dans Wikidata, ainsi que leur génération pour Wikidata. Nous devons également nous assurer que le résultat de cette opération conduit à des combinaisons uniques d'étiquettes et de descriptions.

Voir Résumé Wikipedia/Updates/2021-07-29 pour plus de détails et de discussion.

<span id="_Task_P2.12:_Abstract_Glosses">

Tâche P2.12 : gloses abstraites

Les lexèmes Wikidata ont des sens. Les sens sont capturés par des gloses. Les gloses sont disponibles par langue, ce qui signifie qu'elles ne sont généralement disponibles que dans quelques langues. Afin de soutenir un dictionnaire véritablement multilingue, nous suggérons de créer des gloses abstraites. Bien que cela semble beaucoup plus facile que de créer des articles Wikipédia à part entière, nous pensons que cela pourrait être une tâche beaucoup plus difficile en raison de la nature des gloses.

<span id="_Task_P2.13:_Support_more_natural_languages">

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

Soutenez d’autres communautés linguistiques dans la création de moteurs de rendu, en mettant l’accent sur les langues mal desservies.

<span id="_Task_P2.14:_Template-generated_content">

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

Certaines Wikipédias contiennent actuellement beaucoup de contenu généré par des modèles. Identifiez ce contenu et discutez avec les Wikipédias locaux pour savoir s'ils souhaitent le remplacer par une solution basée sur Wikifunctions, où le modèle est dans Wikifunctions et le contenu est fourni dans la Wikipédia locale ou dans la Wikipédia abstraite. Cela conduira à des solutions plus durables et plus faciles à maintenir qui ne nécessitent pas de s'appuyer sur un seul contributeur. Notez que cela n'a pas besoin d'être multilingue et pourrait être beaucoup plus simple que de passer par une abstraction complète.

<span id="_Task_P2.15:_Casual_comments">

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

Permettez aux contributeurs occasionnels de faire des commentaires sur le texte rendu et créez des mécanismes pour capturer ces commentaires et les canaliser vers un mécanisme de tri qui permet de les diriger soit vers le contenu, soit vers les moteurs de rendu. Il est important de ne pas perdre les commentaires des contributeurs occasionnels. Idéalement, nous leur permettrions d'écraser explicitement une partie de la sortie rendue et de considérer cela comme une demande de modification, puis nous aurons davantage de contributeurs impliqués qui travailleront à transformer l'intention du contributeur occasionnel en modifications correspondantes dans le système.

<span id="_Task_P2.16:_Quick_article_name_generation">

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

Le grand public accède à Wikipédia principalement en tapant les noms des éléments qu'il recherche dans sa langue dans les moteurs de recherche courants. Cela signifie que les éléments Wikidata devront être traduits dans une langue pour pouvoir utiliser la création d'articles implicite. Cela peut probablement être réalisé en traduisant des millions d'étiquettes Wikidata. Parfois, cela peut être fait par des robots ou par l'IA, mais ce n'est pas totalement fiable et évolutif, il faut donc faire appel à des humains.

Les outils actuels de traduction massive et participative des libellés Wikidata ne sont pas à la hauteur de la tâche. Il existe deux manières principales de le faire : l'édition des libellés dans Wikidata lui-même, ce qui est parfait pour ajouter peut-être une douzaine de libellés, mais devient rapidement fatigant, et l'utilisation de Tabernacle, qui semble plus orienté vers les traductions massives par lots, mais qui est trop compliqué à utiliser pour la plupart des gens.

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.

<span id="_Non-core_tasks">

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.

<span id="_Task_O1:_Lambda_calculus">

Tâche O1 : lambda-calcul

Il est possible d'héberger entièrement soi-même des fonctions Wiki sans s'appuyer sur des fonctions intégrées ou des implémentations dans d'autres langages de programmation, en implémentant un calcul Lambda dans Wikifunctions (c'est de là que vient la proposition de nom). Cela peut être utile pour permettre l'évaluation sans aucun support de langage, et ainsi faciliter le démarrage du développement des évaluateurs.

<span id="_Task_O2:_CLI_in_a_terminal">

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

De nombreux développeurs aiment utiliser une interface de ligne de commande pour accéder à un système comme Wikifunctions. Nous devrions en fournir une, avec les caractéristiques habituelles telles que l'autocomplétation, l'historique, l'intégration de la coquille, etc.

<span id="_Task_O3:_UIs_for_creating,_debugging_and_tracing_functions">

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

L'objectif de Wikifunctions est de permettre une compréhension rapide et le développement des fonctions dans Wikifunctions. Compte tenu de l'approche fonctionnelle, il devrait être possible de créer une expérience utilisateur qui permet une évaluation partielle, un déploiement, un débogage et un suivi d'un appel à fonction.

<span id="_Task_O4:_Improve_evaluator_efficiency">

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

Il existe de nombreuses façons d'améliorer l'efficacité des évaluateurs et de réduire ainsi l'utilisation des ressources, en particulier la mise en cache ou la sélection appropriée d'une stratégie d'évaluation. Nous devrions consacrer un certain temps à ce travail pour les évaluateurs en général et noter les résultats, afin que différents évaluateurs puissent utiliser ces connaissances, mais aussi nous assurer que les évaluateurs gérés par l'équipe de base utilisent la plupart des meilleures pratiques.

<span id="_Task_O5:_Web_of_Trust_for_implementations">

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

Afin d'assouplir les conditions d'implémentation dans les langages de programmation, nous pourrions introduire une solution basée sur le Web of Trust, qui permettrait aux contributeurs d'examiner les implémentations existantes et de marquer explicitement leur approbation, ainsi que de marquer les autres contributeurs comme dignes de confiance. Ces approbations pourraient alors être prises en compte lors du choix ou de la préparation d'une stratégie d'évaluation.

<span id="_Task_O6:_Python-based_implementations">

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

Python est un langage de programmation largement utilisé, notamment pour les apprenants et dans certains domaines tels que l'apprentissage automatique. La prise en charge de Python peut ouvrir un écosystème riche à Wikifunctions.

<span id="_Task_O7:_Implementations_in_other_languages">

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

Nous nous efforcerons d'appeler d'autres communautés de langages de programmation à les intégrer dans Wikifunctions et à les soutenir. Les candidats à l'implémentation sont Web Assembler, PHP, Rust, C/C++, R, Swift, Go et d'autres, mais cela dépend de l'intérêt de l'équipe principale et des communautés externes pour créer et soutenir ces interfaces.

<span id="_Task_O8:_Web-based_REPL">

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

Un REPL basé sur le Web peut apporter les avantages de l'interface de ligne de commande O2 au Web, sans avoir besoin d'installer un CLI dans un environnement local, ce qui est parfois impossible.

<span id="_Task_O9:_Extend_API_with_Parser_and_Linearizer">

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

Il peut y avoir différents analyseurs et linéarisateurs utilisant Wikifunctions. L'API Wikifunctions peut être plus facile à utiliser si l'appelant pouvait les sélectionner explicitement, au lieu de les encapsuler manuellement, ce qui permettrait l'utilisation de Wikifunctions avec différents dialectes de surface.

<span id="_Task_O10:_Support_talk_pages">

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

Afin de soutenir les discussions sur les pages de discussion de Wikifunctions, développer et intégrer un mécanisme qui permet des discussions (au départ) simples, et d'augmenter progressivement leur complexité en fonction des besoins des communautés.

<span id="_Task_O11:_Legal_text_creation">

Tâche O11 : création de textes juridiques

Une application intéressante de Wikifunctions est la création de textes juridiques de manière modulaire et avec différents niveaux (jargon juridique vs lisible par l'homme), similaires aux différents niveaux de description des différentes licences Creative Commons.

<span id="_Task_O12:_Health_related_text_creation">

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

Une application intéressante de Wikifunctions est la création de textes liés à la santé pour différents niveaux de lecture. Cette initiative devrait être portée par le WikiProject Medicine et son travail fructueux, qui pourrait toucher beaucoup plus de personnes grâce à la coopération avec Wikifunctions.

<span id="_Task_O13:_NPM_library">

Tâche O13 : bibliothèque NPM pour Javascript

Nous allons créer une bibliothèque Wikidata pour NPM qui permet l'utilisation simple des fonctions de Wikifunctions dans un programme JavaScript. La même syntaxe doit être utilisée pour permettre aux implémentations JavaScript dans Wikifunctions d'accéder à d'autres fonctions Wikifunctions. Notez que cela peut être fait en appelant un évaluateur Wikifunctions ou en compilant les fonctions requises dans la base de code donnée.

<span id="_Task_O14:_Python_library">

Tâche O14 : bibliothèque Python

Nous allons créer une bibliothèque Python qui permet l'utilisation simple de fonctions de Wikifunctions dans un script Python. La même syntaxe doit être utilisée pour permettre aux implémentations Python dans Wikifunctions d'accéder à d'autres fonctions Wikifunctions. Notez que cela peut être fait en appelant un évaluateur Wikifunctions ou en compilant les fonctions requises dans la base de code donnée.

<span id="_Task_O15:_Libraries_for_other_programming_languages">

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

Nous ferons appel aux communautés de plusieurs langages de programmation pour nous aider à créer des bibliothèques permettant l'appel simple de fonctions Wikifunctions à partir de programmes dans leur langage. Notez que cela peut être réalisé en faisant appel à un évaluateur Wikifunctions, ou en compilant les fonctions requises dans la base de code donnée.

<span id="_Task_O16:_Browser-based_evaluator">

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

L’un des avantages de Wikidata est que l’évaluation d’un appel de fonction peut se faire dans différents évaluateurs. L’évaluateur principal de Abstract Wikipedia sera basé sur un serveur et géré par la Wikimedia Foundation, mais afin de réduire la charge de calcul, nous devrions également fournir des évaluateurs exécutés dans le client de l’utilisateur (probablement dans un thread Worker).

<span id="_Task_O17:_Jupyter-_and/or_PAWS-based_evaluator">

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

Un évaluateur intéressant est celui d'un notebook Jupyter ou PAWS, permettant ainsi les avantages habituels de ces notebooks mais intégrant également les bénéfices des fonctions Wiki.

<span id="_Task_O18:_App-based_evaluator">

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

Un évaluateur doit fonctionner de manière native sur des appareils Android ou iOS, et ainsi permettre à l'utilisateur d'utiliser la puissance de calcul considérable dont il dispose.

<span id="_Task_O19:_P2P-based_evaluator">

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

De nombreux évaluateurs pourraient se relier entre eux et s'autoriser mutuellement à utiliser des ressources informatiques inactives dans leur réseau. Cela peut nécessiter ou non des protections entre les nœuds participants qui garantissent la confidentialité des calculs individuels.

<span id="_Task_O20:_Cloud-based_evaluator">

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

Un moyen évident d'obtenir des ressources de calcul consiste à autoriser l'utilisation d'un fournisseur de cloud. Alors qu'il serait possible d'exécuter simplement l'évaluateur basé sur un serveur sur une infrastructure basée sur le cloud, il est probable que les fournisseurs de cloud bénéficieront d'une interface plus fine vers un évaluateur plus personnalisé.

<span id="_Task_O21:_Stream_type">

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.

<span id="_Task_O22:_Binary_type">

Tâche O22 : type de données binaires

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

<span id="_Task_O23:_Integration_with_Commons_media_files">

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.

<span id="_Task_O24:_Integrate_with_Machine_Learning">

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.

<span id="_Task_O25:_Integrate_into_IDEs">

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.

<span id="_Task_O26:_Create_simple_apps_or_Websites">

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.

<span id="_Task_O27:_Display_open_tasks_for_contributors">

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.

<span id="_Task_O28:_Active_view">

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.

<span id="_Task_O29:_Implementation_compilation">

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.

<span id="_Task_O30:_Integrate_with_Code_examples_on_Wikipedia,_Wikibooks,_etc.">

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.