Wikimedia Meta-Wiki

Wikipédia abstraite/Plan

< Abstract Wikipedia
This page is a translated version of the page Abstract Wikipedia/Plan and the translation is 100% complete.
Other languages:

Ceci est une version en une seule page des sections individuelles qui sont y incluses. Cliquez sur les titres pour aller vers les pages individuelles.

Résumé

Dans la Wikipédia abstraite, le « Contenu abstrait » est représenté dans un format indépendant de la langue qui est directement modifiable par la communauté. Les Wikipédias locales peuvent accéder et enrichir leur propre contenu contrôlé localement avec ce « Contenu abstrait » (de la Wikipédia abstraite). De cette façon, les éditions localisées de Wikipédia peuvent sans grand effort fournir davantage de contenu à leurs lecteurs, un contenu qui est davantage exhaustif, plus actualisé et mieux passé en revue que ce que la plupart des Wikipédias locales peuvent fournir.

Étant donné les résutlats de recherche et les prototypes dans le domaine de la génération automatique de textes, il est malheureusement vrai que la génération en langue naturelle à partir du “Contenu abstrait” indépendant de la langue nécessite un système “Turing-complet” pour fonctionner. Mais afin de couvrir le nombre de langues que doit couvrir Wikipédia, ce système doit être sourcé par le plus grand nombre. C’est pourquoi nous introduisons Wikifunctions, un projet pour créer, cataloguer et maintenir une bibliothèque (ou un dépôt) ouverte de « fonctions », qui a de nombreux cas d’utilisations possibles.

La principale motivation de la Wikifunctions est le développement de « moteurs de rendu » (c’est-à-dire une partie des fonctions référencées ou hébergées dans Wikifunctions) qui transforme le « Contenu abstrait » en langue humaine, en utilisant les connaissances linguistiques et ontologiques disponibles de Wikidata (ou les connaisances venant d’autres sources de données ouvertes ayant des conditions de licence compatibles et utilisables dans Wikipédia, y compris les possibles données des autres projets Wikimedia comme le Wiktionnaire ou Wikispecies).

Le projet commencera par créer le projet Wikifunctions, puis il l’utilisera afin de permettre la création de la Wikipédia abstraite. Wikifunctions sera lancé dans la première année et nous ajouterons le développement de la Wikipédia abstraite dans la seconde année. Après deux ans, nous aurons créé un écosystème qui permettra la création et la maintenance d’un « Contenu abstrait » et l’intégration de ce contenu dans les éditions de Wikipédia, ce qui accroîtra significativement l’étendue, l’actualité, la pertinence et la précision de nombreuses éditions individuelles de Wikipédia. Ceci nous rapprochera significativement d’un monde où chacun peut partager la somme de toutes les connaissances.


Nom

Tous les noms mentionnés ici – Wikipédia abstrait et Wikilambda – sont préliminaires et n’ont été principalement nécessaires que pour écrire cette proposition et en discuter.

Les noms actuels sont basés sur l’idée suivante :

  • Wikipédia abstraite : le contenu dans Wikipédia abstraite est formalisé loin de toute langue humaine concrète.
  • Wikilambda : ceci est basé sur la notion que toute fonction peut être fondée dans le lambda-calcul. Également, Wλ semble quelque peu technophile (geek), avec le risque d’être perçu comme ne visant pas à élargir le public attendu et qu’il ne soit géré avec un biais que par des spécialistes déjà favorisés par un accès aux connaissances les plus larges dans leur propre culture.

Notez que le nom "Wikipédia abstraite" ne sera pas, en fait, affiché partout. Quand le projet sera réalisé, la Wikipédia abstraite ne sera qu’une partie de Wikidata. Il s’agit juste d’un nom pour le travail de développement et, par conséquent, sno nommage n’est pas crucial. Wikilambda en revanche sera un nouveau projet Wikimedia et donc le nom aura une bien plus grande visibilité. Ce serait bien qu’il arrive sous un bon nom pour le désigner.

Objections

Il y a déjà eu trois bonnes raisons de s’opposer au nom Wikilambda jusqu’à présent :

  • C’est réellement dur à épeler (avec ou sans le b ?) pour de nombreuses personnes (dit Effeietsanders).
  • Certaines personnes continuent à le lire incorrectement comme Wikilambada (dit Jean-Frédéric).
  • Il est également lu incorrectement comme WikiIambda / Wikiiambda (c’est-à-dire, un autre i/I au lieu du l/L), aussi ce devrait être au moins WikiLambda avec un L majuscule (suggéré par Fuzheado).

Autres noms suggérés

D’autres noms ont alors été considérés ou suggérés :

Ceci est une archive. Les nouveaux noms devraient être proposés dans Concours de nom du wiki des fonctions.

D’autres suggestions sont bienvenues.

En fait la première tâche P1.1 pour le projet sera de décider ensemble avec la communauté d’un nom et d’un logo. Ceci a déjà prévalu pour de précédents projets (logo de Wikidata, nom de Wikivoyage).


Objectifs

Le projet s’est fixé d’ambitieux objectifs prioritaires et un large ensemble d’objectifs secondaires.

Objectifs prioritaires

  • Permettre à plus de personnes de lire davantage de contenu dans la langue qu’elles choisissent.
  • Permettre à plus de personnes de contribuer du contenu destiné à davantage de lecteurs et donc accroître la portée des contributeurs sous-représentés.

Objectifs secondaires

Les objectifs secondaires incluent, mais sans s’y limiter :

  • La génération de textes en langue humaine, réutilisable et bien testée.
  • Permettre aux communautés de Wikimedia et aux tierces parties de créer des contenus dans davantage de langues.
  • Améliorer la communication et l’accessibilité aux connaissances bien au delà des projets Wikipédia.
  • Développer une approche innovante et beaucoup plus exhaustive pour la représentation des connaissances.
  • Développer une approche innovante pour repésensenter le résultat de la compréhension des langues humaines.
  • Une bibliothèque de fonctions.
  • Permettre de développer et partager les fonctions dans les langues natives des utilisateurs, au lieu de leur demander d’apprendre l’anglais dabord.
  • Permettre à chacun de partager des fonctions et de les exécuter.
  • Introduire une nouvelle forme de bien de connaissance pour un projet Wikimedia à gérer.
  • Introduire des composants innovants dans Wikipédia et d’autres projets Wikimedia qui permettent des fonctionnalités interactives.
  • Créer des fonctions fonctionnant au dessus de la base de connaissances de Wikidata, donc ajouter une capacité d’inférence afin de considérablement accroître la couverture des données de Wikidata.
  • Catalyser la recherche et le développement en démocratisant les interfaces de codage.
  • Permettre aux scientifiques et analystes de partager et travailler collaborativement sur des modèles.
  • Partager les spécifications et tests pour les fonctions.
  • La possibilité de référencer la sémantique des fonctions par des identificateurs bien définis.
  • Développement plus rapide de nouveaux langages de programmation du fait de l’accès à une bibliothèque (ou un dépôt) plus large et standard de fonctions sur un nouveau wiki dédié.
  • Définir des algorithmes et approches pour les standards et descriptions techniques.
  • Fournir l’accès à des fonctions puissantes afin de les intégrer dans des systèmes innovants d’apprentissage par la machine.

La liste n’est pas exhaustive.


Organisation

Nous supposons une équipe de base, employée par une seule organisation d'hébergement, qui travaillera exclusivement sur Wikifunctions et la Wikipédia abstraite. Elle sera soutenue par d'autres départements de l'organisation d'hébergement, tels que les ressources humaines, le département juridique, etc.

L’équipe sera mise en place afin d’être ouverte et accueillante pour les contributions externes au code de base. Elles pourront être bénévoles ou payées (par ex. par des subventions aux corps du mouvement ou par d’autres organisations et sociétés). Nous visons à offrir aux bénévoles un traitement privilégié afin d’accroître les chances de créer les communautés saines de bénévoles dont nous avons besoin pour un projet d’une telle ambition.

Le projet sera développé en pleine transparence. Les canaux de communication de l’équipe seront publics autant que possible. Les lignes directrices de communication seront publiques. Ceci aidera à créer une équipe de développement qui communique publiquement et qui permet d’intégrer les contributions externes au code de base.


Prérequis

Les prérequis importants suivants sont basés sur les principes et pratiques du mouvement Wikimédia :

  1. La Wikipédia abstraite et Wikifunctions seront des projets Wikimédia, maintenus et gérés par la Fondation Wikimédia. Ceci impose que la Wikipédia abstract et Wikilambda suivront les principes fondateurs et les lignes de conduite du mouvement Wikimédia.
  2. Le logiciel pour exécuter la Wikipédia abstraite et Wikifunctions seront développés sous une licence de code source ouvert et ne dépendra que de logiciels en code source ouvert.
  3. L’installation de la Wikipédia abstraite et de Wikifunctions s’intégrera dans l’infrastructure Wikimédia abstraite aussi facilement que possible. Ceci signifie que nous devrions tenir aussi loin que possible dans la même infrastructure de déploiement, de maintenance et d’opérations.
  4. Tout le contenu de la Wikipédia abstraite et de Wikifunctions sera rendu disponible sous des licences libres.
  5. Le succès de la Wikipédia abstraite et de Wikifunctions sera mesuré pour la création de communautés saines et par la quantité de connaissance disponible dans des langues qui n’avaient auparavant pas accès à cette connaissance.
  6. La Wikipédia abstraite suivra les principes définis par de nombreuses éditions individuelles de Wikipédia : en particulier, la neutralité de point de vue, la vérifiabilité, la notoriété et l’absence de recherche originale (principes développés dans Développement de la capacité communautaire et par les communautés de chaque wiki local).
  7. La Wikipédia abstraite et Wikifunctions seront entièrement internationalisés et seront disponibles et modifiables dans toutes les langues des projets Wikimédia. Que ceux-ci soient entièrement localisés dépendra des communautés.
  8. Le principal objectif est de soutenir les éditions locales de Wikipédia, Wikidata et les autres projets Wikimédia, dans cet ordre. L’objectif secondaire est de faire croître nos propres communautés. Les derniers objectifs seront de soutenir le reste du monde.
  9. Les communautés Wikipédia locales doivent avoir le contrôle de l’étendue par laquelle la Wikipédia abstraite les affecte. Si elles ne veulent pas être affectées par ceci, elles peuvent l’ignorer entièrement et rien ne changera pour elles.

Les développeurs de la Wikipédia abstraite ne décident pas de son contenu, de même que les développeurs de MediaWiki ne décident pas du contenu de Wikipédia. Au contraire des autres projets Wikimédia, les développeurs prendront une part active dans l’installation et le démarrage du jeu initial de types et de fonctions, ainsi que dans la création des fonctions nécessaires dans Wikifunctions pour la Wikipédia abstraite et pour aider à faire démarrer les communautés pour le rendu linguistique. Au contraire des autres projets, l’équipe de développement de la Wikipédia abstraite et du wiki des fonctions sera au départ plus impliquée dans les projets mais visera à passer la main sur tout cela aux communautés le plus tôt possible.

Les prérequis suivants sont utilisés comme lignes directrices fortes que nous appliquerons dans la conception et le développement de la Wikipédia abstraite :

  1. La Wikipédia abstraite et Wikifunctions sont un système socio-technique. Au lieu de tenter de développer une intelligence excessive, nous dépendrons des communautés Wikimédia.
  2. L’objectif premier de la Wikipédia abstraite et de Wikifunctions est de servir des cas d’utilisation réelle dans Wikipédia, et non de permettre une certaine forme de perfection hypothétique dans la représentation de la connaissance ou pour représenter la totalité du langage humain.
  3. La Wikipédia abstraite et Wikifunctions devront garder l’équilibre entre la facilité d’utilisation et l’expressivité. L’interface utilisateur ne devrait pas être compliquée pour ne couvrir que quelques cas frontaliers exceptionnels d’utilisation.
  4. Ce qui relève de situations exceptionnelles sera défini en fonction de sa fréquence d’apparition dans Wikipédia. Plutôt que de s’appuyer sur des preuves anecdotiques ou des cas isolés nous analyserons Wikipédia et observerons la fréquence des cas spécifiques.
  5. Soyons pragmatique avant tout. Pouvoir déployer est préférable à chercher la perfection.
  6. La Wikipédia abstraite et Wikifunctions fourniront de nombreuses données innovantes qui pourront soutenir la recherche, les développements et les cas d’utilisation externes. Nous voulons nous assurer que cela sera facilement utilisable.
  7. Wikifunctions fournira une interface API pour appeler chacune des fonctions qui y sont définies. Mais il y aura une limite sur le coût en terme de capacité de calcul que cela offrira.
  8. La Wikipédia abstraite et Wikifunctions seront modifiables aussi bien par des humains que par des robots. Mais les personnes qui pilotent les robots doivent être conscientes de leur responsabilité plus élevée afin de ne pas surcharger la communauté.


Architecture

Les principaux composants du projets sont les trois suivants :

  1. Constructeurs – définitions des constructeurs et leurs emplacements, y compris ce qu’ils signifient et les restrictions sur les types pour les emplacements et le type de retour du constructeur (par ex. définir un constructeur rang qui prend un élément, un type d’élément, le rang en tant que nombre, selon quoi il est classé, et une contrainte locale).
  2. Contenu – appels abstraits aux constructeurs y compris les valeurs par défaut pour les emplacements (par ex. rang(San Francisco, ville, 4, population, Californie))
  3. Rendus – fonctions qui prennent un contenu et une langue et retourne un texte résultant dans la langue humaine donnée pour representer la signification du contenu (par ex. dans l’exemple donné, cela donne « San Francisco est la quatrième plus grande ville la plus peuplée en Californie. »)

 

Il existe quatre possibilités principales pour le lieu de mise en œuvre des trois différents composants principaux :

  1. Les constructeurs, le contenu et les rendus sont mis en œuvre dans Wikidata.
  2. Les constructeurs et les rendus sont mis en œuvre dans Wikifunctions, alorts que le contenu le sera dans Wikidata aux côtés de l’élément correspondant.
  3. Les constructeurs, le contenu et les rendus sont mis en œuvre dans Wikifunctions.
  4. Les constructeurs et le contenu sont mis en œuvre dans Wikidata, et les rendus dans les éditions locales de Wikipédia.

La solution 4 a le désavantage que de nombreuses fonctions peuvent être partagées enre les différentes langues : en déplaçant les rendus et fonctions vers les éditions locales de Wikipédia, nous retirons cette possibilité. Également, en relégant les moteurs de rendus vers les Wikipédias locales, nous passons à côté du potentiel qu’un catalogue indépendant de fonctions pourrait permettre.

Nous pensons qu’il est avantageux pour la communication et la construction communautaire d’introduire un nouveau projet, Wikifunctions, pour une nouvelle forme de biens de connaissance, les fonctions, qui incluent aussi les moteurs de rendus. Ceci milite alors en faveur des solutions 2 et 3.

La solution 3 nous demande de créer un nouvel emplacement pour chaque article Wikipédia possible dans le wiki des fonctions. Étant donné que la place naturelle pour ceci existe déjà dans Wikidata avec ses éléments , il serait plus pratique de l’utiliser et de stocker le contenu conjointement avec les éléments dans Wikidata.

Pour ces raisons, nous favorisons la solution 2 et la supposons pour le reste de la proposition. Si nous basculons à uneautre, le plan du projet peut facilement être accomodé (hormis pour la solution 4, qui nécessiterait nombre de réécritures). Notez que la solution 2 nécessite l’accord de la communauté de Wikidata avant de procéder. Si elle n’est pas daccord, la solution 3 est l’option de repli la plus proche.

L’architecture proposée pour la Wikipédia multilingue ressemble à ce qui suit. Wikipédia appelle le Contenu qui est scoaké dans Wikidata à côté des éléments. Nous appelons Wikipédia abstraite cette extension de Wikidata. Notez qu’il ne s’agit que d’un nom pour le projet de développement, et que ne s’attend pas à ce que ce soit un nom affiché un peu partout – il n’y aura pas un nouveau wikiprojet de ce nom. Avec un appel aux Rendus dans Wikifunctions, le Contenu abstrait est traduit en langue humaine. Les Rendus dépendent des autres Fonctions, Types, et Constructeurs dans Wikifunctions. Wikifunctions peut également se servir de la connaissance lexicographique présente dans les Lexèmes de Wikidata, qui peuvent être utilisés pour traduire le Contenu abstrait en texte. Wikifunctions sera un nouveau projet à part entière, au même titre que Commons, Wikidata ou Wikisource.

 

(Les composants nommés en italique doivent être ajoutés par cette proposition, les composants en gras existent déjà. Les boîtes du haut sont des projets Wikimedia, les boites internes sont des parties des projets Wikimedia indiqués.) ("Wikilambda" était le nom de travail de ce qui est maintenant connu sous le nom de "Wikifonctions").


Composants

Nous avons besoin d’étendre les wikis des projets de Wikimédia dans trois domaines :

  1. dans les éditions locales de Wikipédia et d’autres projets clients en utilisant les nouvelles capacités offertes,
  2. dans Wikidata pour créer le contenu (de la Wikipédia abstraite) et
  3. dans un nouveau projet, Wikifonctions (Wikifunctions en anglais), qui vise à créer une bibliothèque de fonctions.

Extensions pour les éditions locales de Wikipédia

Chaque édition locale de Wikipédia peut choisir, selon sa communauté locale, une des trois options suivantes :

  1. l’intégration implicite avec la Wikipédia abstraite ;
  2. l’intégration explicite avec la Wikipédia abstraite ;
  3. aucune intégration avec la Wikipédia abstraite.

L’extension pour les éditions locales de Wikipédia a les fonctionnalités suivantes : une nouvelle page spéciale, deux nouvelles fonctionnalités et trois nouveaux mots-clés magiques.

F1 : nouvelle page spéciale : Abstract

Une nouvelle page spéciale sera disponible sur chaque édition locale de Wikipédia, qui sera utilisée avec un Q-ID ou le nom de l’article locale et une langue facultative (qui sera par défaut la langue de l’édition locale de Wikipédia). Des exemples d’URL de page spéciale devraient ressembler à ce qui suit :

https://en.wikipedia.org/wiki/Special:Abstract/Q62
https://en.wikipedia.org/wiki/Special:Abstract/Q62/de
https://en.wikipedia.org/wiki/Special:Abstract/San_Francisco
https://en.wikipedia.org/wiki/Special:Abstract/San_Francisco/de

Si la page spéciale est appelée sans paramètres, alors un formulaire est affiché qui permet la sélection d’un Q-ID et d’une langue (préremplie avec la langue locale du wiki).

La page spéciale affiche le Contenu du Q-ID sélectionné ou au Q-ID lié au site de l’article respectif et en fait le rendu dans la langue sélectionnée.

F2 : création explicite d’un article

Si l’édition locale de Wikipédia choisit l’option d’intégrer la Wikipédia abstraite au moyen d’une création explicite d’article, c’est de cette façon qu’elle le fera.

Le contributeur va sur un élément de Wikidata qui n’a pas encore de lien de site vers l’édition locale de Wikipédia. Il ajout un lien vers une page qui n’existe pas encore. De cette façon, il spécifie le nom de l’article à créer. Par exemple, si Q62 n’a pas encore d’article en français, et donc aucun lien de site Wikipédia, il peut ajouter le lien de site San Francisco pour fr.wikipedia.

Sur l’édition locale de Wikipédia, ceci crée un article virtuel dans l’espace de noms principal. Cet article a le même contenu que la page spéciale décrite ci-dessus, mais il peut être trouvé par l’URL habituelle, par ex.

https://en.wikipedia.org/wiki/San_Francisco

Les liens vers cet article, qui utilisent le nouveau nom spécifié, ressemblent exactement aux autres liens, c’est-à-dire qu’un lien vers [[San Francisco]] pointera vers l’article virtual, sera bleu, etc. De tels articles sont indexés pour la recherche dans l’édition donnée de Wikipédia et également pour les recherches externes.

Si un utilisateur clique sur le lien pour modifier l’article, il peut choisir soit d’aller vers Wikidata et modifier le Contenu abstrait (méthode préférée), soit de démarrer un nouvel article dans la langue locale depuis rien, soit matérialiser la traduction actuelle en texte et alors commencer à le modifier localement.

Si un article local existant avec un lien de site est supprimé, un article virtuel est automatiquement créé (puisque nous connaissons le nom et pouvons conserver les liens).

Afin de supprimer un article virtuel, le lien de site dans Wikidata doit être supprimé.

Toutes les modifications dans l’édition locale de Wikipédia doivent être réalisées explicitement, c’est pourquoi nous appelons cette option la création explicite d’article. Nous nous attendons à faire de cette option celle par défaut pour les éditions locales de Wikipédia, à moins qu’elles choisissent soit la création implicite d’article, soit aucune intégration.

Voir également la discussion au sujet de l’intégration.

F3 : création implicite d’un article

Si une édition locale de Wikipédia opte pour la création implicite d’article depuis Wikidata, alors le résultat de l’appel de la page spéciale abstraite sur tout élément de Wikidata qui n’a pas de lien de site vers l’édition de Wikipédia donnée mais qui effectuerait le rendu du contenu dans la langue donnée sera indexé comme si l’article était présent dans l’espace de noms principal et rendu disponible lors de la recherche comme s’il était présent dans l’espace de noms principal.

Un nouveau mot-clé magique est introduit pour créer un lien vers des articles virtuels depuis des articles normaux, voir F6 LINK_TO_Q. Ceci peut être intégré de façon invisible dans l’éditeur visuel.

Ceci implique, et de loin, le moins d’effort pour la communauté afin de gagner de nombreux articles et ce serait une bonne option pour les petites communautés.

F4 : liens ou onglets

Chaque article sur une édition locale de Wikipédia qui est connectée à un élément sur Wikidata reçoit un nouveau lien, soit en tant qu’onglet en haut de l’article, soit comme un lien dans la barre latérale. Suivre ce lien affiche le Contenu pour l’élément de Wikidata connecté, rendu dans la langue locale. Les articles virtuels n’ont pas cet onglet, mais leur bouton Modifier va directement modifier le Contenu dans la Wikipédia abstraite.

F5 : nouveau mot-clé magique : ABSTRACT_WIKIPEDIA

Le mot-clé magique est remplacé par le wikitexte résultant du rendu du Contenu sur l’élément Wikidata connecté à cette page par les liens de site.

Le mot-clé magique peut être utilisé avec deux paramètres facultatifs, l’un étant un Q-ID, l’autre une langue. Si aucun Q-ID n’est donné, le Q-ID par défaut est l’élément Wikidata auquel cette page est connecté par les liens de sites. Si aucune langue n’est donnée, la langue par défaut est celle du wiki donné.

Exemples d’appels :

{{ABSTRACT_WIKIPEDIA}}
{{ABSTRACT_WIKIPEDIA:Q62}}
{{ABSTRACT_WIKIPEDIA:Q62/de}}

Si aucun Q-ID n’est donné ou choisi par défaut, un message d’erreur apparaît.

Plus tard, cela permettra de sélectionner des sections nommées du Contenu.

Les éditions de Wikipédia qui choisissent de n’avoir aucune intégration de la Wikipédia abstraite peuvent cependant utiliser ce nouveau mot-clé magique.

Notez que l’introduction d’un nouveau mot magique est un plan préliminaire. La tâche 2.3 étudiera si nous pouvons obtenir ces fonctionnalités sans avoir à le faire.

Ce mot-clé magique transformera un lien soit vers l’article local qui est lié au site pour le Q-ID donné, soit si aucun n’existe , vers la page spéciale abstraite pour le Q-ID donné. Ceci permettra d’écrire des articles avec des liens vers des articles virtuels, qui seront remplacés automatiquement une fois qu’un contenu local est créé.

Exemples d’appel :

{{LINK_TO_Q:Q62}}

ce qui résultera en :

[[San Francisco]]

si l’article existe, sinon cela produira :

[[Special:Abstract/Q62|San Francisco]]

Notez que l’introduction d’un nouveau mot magique est un plan préliminaire. La tâche 2.3 étudiera si nous pouvons obtenir ces fonctionnalités sans avoir à le faire.

F7 : nouveau mot-clé magique : LAMBDA

Ceci appelle une fonction spécifiée dans Wikidata en lui fournissant ses paramètres et effectue le rendu de la sortie sur la page.

Par exemple l’appel suivant :

{{LAMBDA:capitalize("san francisco")}}

produira la sortie de « San Francisco » sur la page (en supposant qu’il existe une fonction ayant la clé locale et avec la définition et la mise en œuvre attendues). Cela utilise la langue du wiki local pour analyser l’appel.

Nous devons également considérer l’option d’appel d’une version spécifique d’une fonction afin de réduire les dysfonctionnements ultérieurs.

Notez que l’introduction d’un nouveau mot magique est un plan préliminaire. La tâche 2.3 étudiera si nous pouvons obtenir ces fonctionnalités sans avoir à le faire.

Extensions pour Wikidata

Nous ajoutons un nouvel espace de noms auxiliaire à l’espace de noms principal de Wikidata. C’est-à-dire que chaque page d’élément sous la forme www.wikidata.org/wiki/Q62 recevra également une page de contenu accompagnante www.wikidata.org/wiki/Content:Q62. Cette page contient le contenu abstrait, indépendant de la langue, et permet sa modification et sa maintenance.

Des pages spéciales supplémentaires pourraient être nécessaires. Ceci sera étendu dans la seconde partie du projet. Ceci nécessite l’accord de la communauté Wikidata afin que le projet puisse être utilisé pour stocker le contenu abstrait, et un autre projet hôte sera utilisé si elle s’y oppose.

F8 : nouvel espace de nom : Content

Un nouvel espace de noms avec de nombreuses fonctionnalités complexes interactives pour la modification. Fournit des composants d’interface utilisateur et la mise en page permettant de créer et maintenir les contenus abstraits, de même que les fonctionnalités pour évaluer ces contenus (par ex. afficher quelle partie est affichée par langue, etc.) Ceci est essentiellement un sous-ensemble de la fonctionnalité F11 pour l’espace de noms Function.

F9 : nouveau type de données : Content

Un nouveau type de données qui contient un (court) Contenu. Le principal cas d’utilisation est pour les Descriptions dans les Éléments et pour les Gloses dans les Sens des Lexèmes.

F10 : indexation et utilisation des Descriptions dans les Éléments et des Gloses dans les Lexèmes

Indexer et surfacer les linéarisation des champs de Description pour les Éléments et les Gloses dans les Lexèmes, également s’assurer que pour les champs de Description des Éléments il n’y a pas paires Libellé / Description en doublon. Permettre de corriger celles-ci par des modifications manuelles.

Extensions pour les autres projets de Wikimédia

D’autres projets Wikimédia recevront aussi les mots-clés magiques F7 LAMBDA et F5 ABSTRACT_WIKIPEDIA, mais aucune des autres fonctionnalités, puisque cela ne leur semble pas particulièrement utile. Ceci pourrait changer à la demande des communautés données.

Extensions pour le nouveau wiki des fonctions

Wikifonctions (Wikifunctions) sera un nouveau projet Wikimédia sur un nouveau domaine. L’espace de noms principal sera le nouvel espace Function. Le reste de Wikifonctions sera un wiki traditionnel de Wikimédia.

F11 : nouvel espace de noms : Function

Cela doit permettre le stockage de fonctions, types, interfaces, valeurs, tests, etc. Il y a un unique espace de noms qui contient des constants (telles que des types ou des valeurs simples), des interfaces de fonction, des mises en œuvre de fonction et donc également des constructeurs et moteurs de rendu. Les entités dans cet espace de noms sont nommés par des Z-ID, semblables aux Q-ID des éléments de Wikidata, mais commençant par un Z et suivi d’un numéro.

Il y a de nombreux types différents d’entités dans l’espace de noms Z. Ceux-ci incluent des types et d’autres constantes (qui sont essentiellement des fonctions d’arité nulle, c’est-à-dire sans paramètre), ainsi que des fonctions classiques d’arité positive.

Les contributeurs peuvent créer de nouveaux types de fonctions dans l’espace de noms Function et ensuite les utiliser.

Les fonctions peuvent avoir des paramètres. Les fonctions avec leur paramètres donnés peuvent être exécutées et retourner une valeur dont le type est donné par la définition de la fonction.

L’espace de noms Function est complexe et aura des vues très différentes selon le type de la fonction, par ex. pour les interfaces, les mises en œuvre, les tests, les types, les valeurs, etc. Il y aura différentes interfaces utilisateur pour les représenter, même si elles sont toutes stockées en interne comme des Objets-Z. Éventuellement, les différentes vues seront toutes générées par des fonctions dans Wikifonctions.

Il sera possible de geler et dégeler des entités dans l’espace de nom Function. Ceci est similaire à une page protégée, mais ne restreint que la modification de la partie valeur de l’entité, par le libellé, la description, etc.

F12 : nouvelles pages spéciales et nouveaux modules d’API

De nouvelles pages spéciales et de nouveaux modules d’API seront créés pour prendre en charge le nouvel espace de noms Function. Ceci inclura, en particulier, une page spéciale et un module d’API qui permet d’évaluer des fonctions avec les paramètres données. À côté de ça, il inclura diverses pages spéciales et APIs qui soutiendront la maintenance du contenu (tels que les recherches par nombre et types de paramètres, des pages statistiques sur la fréquence d’appel de certaines mises en œuvre, des pages de test, etc.). L’objectif est de mettre en œuvre le plus possible de ces possibilités au sein de Wikifonctions.


Tâches

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 24e 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.


Phases de mise en œuvre

Le développement de la Wikipédia abstraite se déroulera en deux parties majeures, qui comprennent chacune un grand nombre de tâches. La première partie concerne le développement du wiki des fonctions, la seconde concerne le contenu abstrait et la génération en langue humaine. Sur cette page, nous redécoupons le début de la première partie en phases. Les phases sont reflétées dans Phabricator et liées depuis cette page, de même que les tâches et redécoupages des tâches.

Cette page pourrait rester inactive. L’emplacement canonique des informations concernant les tâches peut être trouvé dans Phabricator. Consultez l’état actuel dans Phabricator.

Nous nous attendons à environ dix phases avant le lancement du wiki des fonctions.

Toutes les tâches ci-dessous appartiennent à la tâche P1.2 : développement initial, sauf mention contraire.


Partie P1 : le wiki des fonctions

Article principal : Wikipédia abstraite/Tâches — § Partie P1 : Wikifonctions

Phase α (alpha) : stocker, afficher et modifier l’entête —   Terminé 2020-08-25

  1. Mise en place de l’environnement de développement réplicable. — tâche T258893
    •   Terminé Commencement de l’extension. — tâche T258893
    •   Terminé Travaux de configuration, téléversement du contenu de démarrage initial.
    •   Terminé Réutilisation du Gestionnaire de contenu JSON existant. — tâche T258893
    •   Terminé Permettre d’entrer des objets JSON par l’interface de modification brute. — tâche T258893
  2.   Terminé Extension et codage en dur des objets JSON pour vérifier qu’un Z-Objet est bien formé. Rien de ce qui n’est pas bien formé ne devrait être traité ou stocké. La forme correcte devrait probablement être vérifiée à la fois dans le code PHP et le code JavaScript (ce devrait de toute façon être facile à écrire).
    •   Terminé en PHP. — tâche T258894
    • Forme correcte : la syntaxe des clés, les clés autorisées, les valeurs sont des chaînes ou des proto-objets ou des listes de valeurs. — tâche T258894
  3.   Terminé Chaque Z-Objet de premier niveau stocké doit être un Z2/Objet persistant. — tâche T258897
  4.   Terminé Créer Z1/Objet, offrir une clé, Z1K1/type.
  5.   Terminé Étendre le validateur codé en dur pour vérifier Z1K1/type.
  6.   Terminé Créer Z2/Objet persistant. — tâche T258897
  7.   Terminé Z2/Objet persistant a les clés Z2K1/ID, Z2K2/valeur et Z2K3/proto-libellé, ce dernier étant contrefait, juste une simple chaîne sans information de langue. — tâche T258897
  8.   Terminé Étendre le validateur codé en dur pour Z2/Objet persistant jusqu’ici. — tâche T258897
  9.   Terminé Fournir l’affichage codé en dur pour Z2/Objet persistant (c’est-à-dire l’entête) (c’est une tâche assez large). — tâche T258898
  10.   Terminé Fournir une vue générique pour l’objet Z2K2/valeur. — tâche T258898
  11.   Terminé Transformer le Z2K3/proto-libellé en un Z2K3/libellé approprié pour du texte multilingue.
  12.   Terminé Étendre la vue pour Z2K3/libellé avec du texte multilingue.

Condition d’achèvement de la phase : en tant qu’utilisateur d’[un site avec l’extension MediaWiki installée], je peux créer et stocker une chaîne comme un nouveau Z-Objet, p.ex. « Bonjour au monde ! ».

Phase β (bêta) : création des types et des instances —   Terminé 2021-02-04

  1.   Terminé Validateurs codés en dur pour les Z4/proto-types et Z3/proto-clés. — tâche T258900
    • Un Z4 a un champ Z4K2/clés avec une Liste JSON de Z3.
    • Une proto-clé a un Z3K1/ID avec Z3K2/type et Z3K3/libellé (recopier le développement du libellé pour Z2K3 ?).
  2.   Terminé Créer Z4/Type et Z3/Clé (Task P1.14).
  3.   Terminé Recherche des Z-Objets par libellé. — tâche T260750
  4.   Terminé pour cette phase. Utiliser les données de type Z4 et les déclarations de clés pour valider les objets. — tâche T260861
  5.   Terminé Utiliser les données de type Z4 et les déclarations de clés pour une vue générique des objets. — tâche T258901
  6.   Terminé Utiliser les données de type Z4 et les déclarations de clés pour la modification ou la création des objets. — tâche T258903 & tâche T258904
  7.   Terminé Fournir un affichage codé en dur et une interface de modification pour le type Z4. — tâche T258900

Condition d’achèvement de la phase : en tant qu’utilisateur, je peux créer et stocker un objet qui met en œuvre tout type défini sur le wiki, p.ex. l’entier positif un.

Phase γ (gamma) : fonctions, mises en œuvre, erreurs —   Terminé 2021-04-02

  1.   Terminé Introduire un objet simple d’erreur. — tâche T261464
  2.   Terminé Introduire une fonction simple. — tâche T258957
  3.   Terminé Introduire une mise en œuvre simple, pour le moment seulement intégrée. — tâche T258958
  4.   Terminé Créer quelques fonctions et mise en œuvre intégrées. — tâche T261474
  5.   Terminé Introduire un appel de fonction simple. — tâche T261467
  6.   Terminé Type de test (Tâche P1.10). — tâche T261465

Condition d’achèvement de la phase : en tant qu’utilisateur, je peux stocker un appel de fonction, une fonction et un testeur (seulement les objets, pas encore leur évaluation réelle), p.ex. si(vrai, faux, vrai) (lire « si vrai alors faux sinon vrai », c.-à-d. la négation).

Phase δ (delta) : mises en œuvre intégrées —   Terminé 2021-05-11

  1.   Terminé Système d’évaluation pour les mises en œuvre intégrées. — tâche T260321
  2.   Terminé Permettre aux utilisateurs web d’appeler l’évaluation par un module d’API (Tâche P1.5). — tâche T261475
  3.   Terminé Page spéciale pour appeler l’évaluation (Tâche P1.11). — tâche T261471

Condition d’achèvement de la phase : en tant qu'utilisateur, je peux utiliser une page spéciale pour évaluer une fonction intégrée avec des entrées fournies, p.ex. pour vérifier si la liste vide est vide.

Phase ε (epsilon) : appels de fonction natifs —   Terminé 2021-06-30

  1.   Terminé Mises en œuvre en JavaScript (Tâche P1.12). — tâche T275944
  2.   Terminé Mises en œuvre en Python (Tâche O6). — tâche T273517
  3.   Terminé Permettre aux formulaires d’être inclus pour l’évaluation. — tâche T261472

Condition d’achèvement de la phase : en tant qu’utilisateur, je peux utiliser une page spéciale pour évaluer une fonction écrite par l’utilisateur dans l’un des langages pris en charge, p.ex. appeler une fonction écrite par l’utilisateur en Python pour additionner deux nombres.

Phase ζ (zêta) : composition —   Terminé 2021-08-27

  1.   Terminé Permettre les mises en œuvre par composition (Tâche P1.6). — tâche T261468

Condition d’achèvement de la phase :

  • en tant qu’utilisateur, je peux mettre en œuvre une fonction qui utilise la composition d’autres fonctions au lieu de l’écrire moi-même, p.ex. négation(Booléen → Booléen) ; —   Terminé
  • (condition étendue) en tant qu’utilisateur, je peux voir les résultats des testeurs sur la page appropriée de mise en œuvre d’une fonction. [Ceci pourrait nécessiter d’être remis à une phase ultérieure car tous les pré-requis pourraient ne pas encore être remplis à ce point. Cela devra être fait pour la phase ι (iota).] —   Terminé

Phase η (êta) : types génériques —   Terminé 2022-04-08

  1.   Terminé Permettre les types génériques, particulièrement pour Z10/Liste ou Z8/Fonction, et remplacer Z10/Liste et Z8/Fonction. ― tâche T275941
  2.   Terminé Les erreurs peuvent être traitées en tant que Z-Objets.
  3.   Terminé Les types définis par l’utilisateur fonctionnent avec les validateurs.

Condition d’achèvement de la phase :

  • être capable de mettre en œuvre la curryfication comme une composition sur the wiki, mais sans nécessiter une analyse statique stricte ; —   Terminé
  • rendre possible la création des trois types « définis par l’utilisateur » sur le wiki : entier positif, signe et entier ; —   Terminé
  • être capable de créer un type emballeur générique au moyen de la composition sur le wiki. —   Terminé

Voir également le bulletin d’actualité publié au sujet de cette phase.

Phase θ (thêta) : gel et dégel —   Terminé 2023-06-19

  1.   Terminé Gel et dégel de contenu (Tâche P1.7). ― tâche T275942
  2.   Terminé Tâche P1.9 : passage en revue de la sécurité. — tâche T274682, …
  3.   Terminé Lancement du système public de test (Tâche P1.4). — tâche T261469

Condition d’achèvement de la phase :

  • en tant qu’administrateur, je peux geler et dégeler tout objet écrit par l’utilisateur (apparenté à, ou peut-être la même chose que le système de protection de MediaWiki) ; tous les objets fournis par le système sont gelés de façon permanente ;
  • en tant qu’utilisateur modifiant une page gelée, je peux changer le libellé, mais pas la mise en œuvre, alors que sur une page non gelée, les deux sont possibles ;
  • les ZObjets sont stockés en utilisant la nouvelle forme canonique pour les listes typées et toutes les parties fonctionnent encore ;
  • la visualisation et la modification de fonction est mise en œuvre et testée avec succès ;
  • quand plusieurs mises en œuvre sont disponibles, la « meilleure » est choisie (la détermination de l’adéquation sera potentiellement modifiée ultérieurement) ;
  • nous mesurons l’utilisation du temps d’horloge et de la mémoire à chaque exécution de fonction et l’affichons sur les résultats d’exécution et dans le tableau des mises en œuvre et des tests ;
  • les modifications de ZObjets définis par le système sont restreintes aux seuls utilisateurs ayant les droits corrects ; des différences compréhensibles sont émises ; les résultats sont mis en cache ;
  • le texte avec repli, les références, les chaînes et les listes sont mis en œuvre et testés avec succès ;
  • une compréhension partagée avec la communauté sur la façon dont l’équipe contribuera à Wikifonctions, et pourquoi, est documentée ;
  • les conceptions pour la visualisation et la modification de la documentation multilingue sur les appareils mobiles et de bureau est approuvée ; l’expérience utilisateur est instrumentée et les données collectées.

Phase ι (iota) : documentation des objets

  1. Ceci est une affectation préliminaire, déplaçant les tâches de documentation ici.
  2. Fournir la modification pour l’entête (en plus de la modification du code brut complet) (ceci est une tâche assez large) – ceci ne se réfère qu’aux libellés, en fait.
  3. Étendre la modification pour Z2K3/libellé avec du texte multilingue.
  4. Étendre l’entête avec Z2K4/documentation. — tâche T260954 & tâche T260956
  5. Étendre la modification pour s’occuper de la Z2K4/documentation. — tâche T260955

Condition d’achèvement de la phase : en tant qu’utilisateur, je peux documenter un Z-Objet dans n’importe lequel des langages de programmation pris en charge, en utilisant du wikitexte.

Phase κ (kappa) : nettoyage

  1. Affinage et nettoyage des tâches, pour clôturer toutes les tâches de prélancement.

Condition d’achèvement de la phase : au sein de l’Équipe de la Wikipédia abstraite, nous nous sentons prêt au lancement, y compris avec l’approbation de tous les collègues concernés.

Phase λ (lambda) : lancement

  1. La phase λ (lambda) est destinée au lancement. S’il y a des tâches préalables au lancement qui empêche de le faire, il faudra que ce soit fait, évidemment.
  2. Mettre en place un nouveau projet Wikimédia.
  3. Déplacer certaines pages wiki de Méta-Wiki à Wikifunctions.

Condition d’achèvement de la phase : en tant que personne sur le Web, je peux visiter et utiliser Wikifunctions.org pour écrire et exécuter des fonctions directement sur le site.

Tâches hors phases

Les tâches préalables au lancement qui doivent arriver mais qui ne sont pas encore planifiées en phases :

Tâches postérieures au lancement de la première partie

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Abstract_Wikipedia/Plan/fr&oldid=26995366"