Croissance/Premier jour personnalisé/Tâches structurées
Cette page décrit le travail de l'équipe Croissance (Growth team) sur le projet « tâches structurées », qui est lié aux projets « tâches des nouveaux arrivants » et « page d'accueil des nouveaux arrivants ». Cette page contient les principaux atouts, les conceptions, les questions ouvertes et les décisions. La plupart des mises à jour progressives sur l'état d'avancement des projets sera affichée sur la page générale des mises à jour de l'équie Croissance, avec certaines mises à jour importantes ou détaillées affichées ici.
|
Newcomer tasks
 Recommend tasks to newcomers that help them start editing
|
Cette page décrit le concept général de tâche structurée avec quelques discussions à propos des types particuliers de tâches que nous pourrions réaliser. Après cette discussion générale, l'équipe a commencé à concevoir et à développer ces types particuliers de tâches. Ils ont leur propre page de projet où la plupart des dernières informations sont affichées:
Statut actuel
- 2020-05-01: planification et documentation des notes initiales
- 2020-05-17: commencer la discussion avec la communauté
- 2020-05-29: structures initiales
- 2020-08-24: semaine des réunions d'avancement
- 2020-09-08: appel aux commentaires de la communauté sur les dernières architectures
- 2020-10-21: test des utilisateurs des versions pour ordinateur de bureau
- 2021-05-27: Nous avons déployé la fonctionnalité « ajouter un lien » sur nos quatre Wikipedias pilotes (arabe, tchèque, vietnamien et bengali).
- 2021-07-21: étendre « ajouter un lien » sur davantage de Wikipedias (T304110)
- 2022-08-20: commencer le travail pour obtenir les commentaires des patrouilleurs à propos des tâches structurées (T315732)
- 2022-09-02: publier l'analyse sur les types de tâches d'édition des nouveaux venus
Résumé
L'équipe Croissance a déployé le projet des "Tâches des nouveaux venus" en novembre 2019; il suggère aux nouveaux arrivants un flux d'articles à modifier sur leur page d'accueil des nouveaux venus. Depuis avril 2020, les articles suggérés proviennent uniquement d'articles auxquels les modèles de maintenance ont été appliqués par des éditeurs expérimentés, qui ne donnent pas aux nouveaux arrivants d'indications particulières sur les phrases, les mots ou les sections qui nécessitent une attention particulière. Malgré ce manque d'orientation, nous sommes heureux de constater que les nouveaux venus ont fait des suggestions d'édition productives.
Bien que les modèles de maintenance offrent divers types de modifications à effectuer par les nouveaux arrivants, il se peut qu'ils soient trop vastes et trop ouverts pour que les nouveaux arrivants puissent réaliser leurs modifications avec succès. Et sur les appareils mobiles, les éditeurs visuels ou de wikicode peuvent surcharger les nouveaux arrivants qui ont un petit écran.
C'est pourquoi nous voulons expérimenter une idée appelée tâches structurées. Ceci concerne le découpage du flux de travail de l'édition en une série d'étapes que les nouveaux arrivants peuvent faire facilement. Suite aux exemples positifs résultant du travail de l'équipe Android et Langage, nous pensons que ces types d'éditions seraient plus faciles à faire par des nouveaux arrivants, et ce, dans la version pour mobiles, ce qui leur permettra de faire davantage de modifications. Ces tâches structurées seront accessibles aux nouveaux venus comme faisant partie du projet des tâches pour les nouveaux arrivants.
Contexte
Modifier, c'est compliqué
Grâce à l'expérience de l'équipe Croissance, nous en sommes venus à penser que les premiers moments d'un nouveau venu sur le wiki peuvent rapidement déterminer s'il veut rester ou partir. Nous pensons que les nouveaux arrivants veulent rester dès qu'ils peuvent rapidement faire une modification et en tirer une expérience positive. Mais contribuer à Wikipedia -- pratiquement pour tous les types de contribution -- est une chose difficile, et c'est ce qui rend la tâche ardue pour réussir rapidement. Par exemple, une douzaine d'étapes est nécessaire pour faire quelque chose de simple comme l'ajout d'une seule phrase dans un article :
- rechercher le bon article
- voir si l'information que vous souhaitez ajouter est déjà présente dans l'article
- choisir une section dans laquelle ajouter la phrase
- cliquer pour commencer à modifier.
- taper la phrase à la bonne place.
- cliquer sur le bouton « Sourcer ».
- retourner sur la source pour en avoir le lien ou pour citer l'information.
- remplir et valider le formulaire de référence.
- cliquer pour publier la modification.
- remplir le résumé de modification.
- publier.
Les nouveaux arrivants qui ouvrent l'éditeur visuel ou l'éditeur de wikitexte pour la première fois ne savent pas quelles sont ces étapes, dans quel ordre les faire, ni sur quels boutons cliquer pour les réaliser. En d'autres termes, leur expérience n'est pas structurée. Ils peuvent simplement être surchargés et quitter. Ou ils peuvent faire un essai avec faute(s), faire une erreur, et obtenir un commentaire négatif de la part des contributeurs expérimentés. C'est de tout cela que le projet doit traiter : comment pourrions nous aider les nouveaux venus à progresser dans ces flux de travail et dans le bon ordre ?
Utiliser la connaissance des autres équipes pour avancer
Ajouter une structure aux flux du travail d'édition a fait partie de tout temps des projets Wikimedia. Quelques exemples comprennent :
- HotCat: permet en quelques clics aux utilisateurs de choisir des catégories pour ajouter des articles, au lieu d'éditer manuellement le wikicode.
- Assistant de téléversement de Commons : divise le processus de téléversement sur Commons en plusieurs étapes simples.
- Citoid : disponible dans l'Editeur Visuel, décompose le processus d'ajout de citation en étapes contenant les algorithmes pour produire automatiquement le texte de la citation et le modèle.
Récemment, l'idée de tâches structurées a bien fonctionné sur l'application Android de Wikipedia et dans l'outil de traduction de contenu. Nous sommes inspirés par leur travail.
Avec son projet Editions suggérées, l'Equipe Android a réduit le processus d'ajout d'une description de titre à un article Wikipedia à une étape simple consistant à saisir le texte dans une boîte. Ils ont depuis fait la même chose en traduisant les descriptions des titres à travers les langues. Pour réaliser les mêmes tâches sans flux de travail structuré, les utilisateurs devaient aller dans Wikidata et passer par plusieurs étapes pour faire ces mêmes modifications. L'équipe a appris que cette méthode fonctionne : beaucoup d'utilisateurs de Android font des centaines de ces petites contributions.
L'équipe des Langues a construit l'outil de traduction de contenu Content Translation, qui réalise plusieurs fonctions pour structurer le processus de traduction d'un article. Il offre une interface côte à côte construite pour les traductions, il décompose la traduction en sections et applique automatiquement des algorithmes de traduction automatique. Bien que les Wikipédiens pouvaient traduire les articles avant l'existence de l'outil, le nombre d'étapes manuelles nécessaires le rendaient trés difficile. Cet outil est efficace et comporte des centaines de milliers de traductions réalisées. Nous avons appris que lorsque la traduction d'un article est divisée en étapes, avec des pièces de base (par exemple la traduction automatique) prises en charge automatiquement, davantage d'articles sont traduits.
L'équipe Croissance envisage d'appliquer ces mêmes principes aux modifications de contenu dans les articles, comme ajouter des liens, ajouter des images, ajouter les références et ajouter des phrases.
-
L'application Android Wikipedia propose des éditions suggérées telles que la traduction de la description des titres que les utilisateurs peuvent réaliser en une étape facile au lieu de naviguer dans Wikidata. -
L'outil de traduction de contenu décompose le processus de traduction d'un article en différentes sections successives avec une assistance automatique fournie par les algorithmes de traduction automatique.
Schéma d'une tâche structurée
La meilleure façon d'expliquer comment nous envisageons les tâches structurées peut être de montrer un rapide croquis. La première tâche structurée à laquelle nous avons pensé est « ajouter un lien wiki » (lien interne). Mais les mêmes idées pourraient s'appliquer aux tâches structurées pour « ajouter une image », « ajouter une référence », ou même « ajouter un fait ».
Dans la fonctionnalité des tâches pour les nouveaux venus, beaucoup d'entre-eux terminent les tâches « ajouter un lien wiki » -- où ils ajoutent des liens internes bleus dans les articles qui n'en ont pas beaucoup. On dirait qu'il s'agit d'une simple tâche d'édition à démarrer. Mais nous pensons que beaucoup de nouveaux arrivants ne comprennent peut-être pas comment passer par les étapes de l'ajout d'un lien et ne savent peut-être même pas quel texte mettre dans les liens. Nous imaginons un flux de travail qui les guide, étape par étape, avec l'aide d'un algorithme qui peut deviner quels mots ou phrases pourraient constituer les meilleurs liens.
Dans le schéma ci-dessous, le nouveau venu arrive sur un article, et se voit suggérer un mot qui pourrait avoir un bon lien interne. S'ils conviennent qu'il faut créer un lien, ils sont guidées dans les étapes de la création du lien. Cela les apprendra nous l'espérons à ajouter des liens eux-mêmes à l'avenir, et peut-être qu'ils apprécieront de continuer à recevoir ces suggestions de liens algorithmiques. Si nous considérons l'algorithme, l'équipe de recherche de la WMF a réalisé un travail préparatoire qui nous permet de dire qu'un tel algorithme est possible.
En réfléchissant, nous avons esquissé une deuxième idée. Au lieu d'enseigner au nouveau venu à ajouter des liens en utilisant l'éditeur visuel, ce prochain flux de travail permet à l'utilisateur de confirmer ou de rejeter rapidement les recommandations de l'algorithme, en éditant directement l'article. Bien qu'il ne leur apprenne pas à ajouter des liens via l'éditeur, il pourrait aider un nouvel arrivant à éditer un volume élevé, et pourrait être mieux adapté pour un utilisateur qui essaie d'être productif avec des tâches simples pendant qu'il est dessus. Ou peut-être conviendrait-il au mieux aux utilisateurs qui sont intéressés uniquement à faire des éditions très simples, comme avec les applications Android où beaucoup d'éditeurs veulent seulement rédiger la descriptios des titres.
En ce qui concerne les tâches structurées, il semble que la question suivante se pose : les flux de travail doivent-ils être davantage axés sur la formation des nouveaux arrivants à l'utilisation des outils traditionnels, ou sur la capacité des nouveaux arrivants à effectuer des modifications faciles à un volume plus important ?
Pourquoi cette idée est prioritaire
Nous pensons que la rapidité avec laquelle on peut modifier est ce qui conduit au succès des nouveaux arrivants. Une fois qu'ils ont fait quelques modifications, le reste de l'expérience wiki devient rapidement plus riche. Les nouveaux arrivants peuvent alors voir leur impact, recevoir des remerciements, poser des questions éclairées à leurs mentors, créer leur page d'utilisateur, etc. Par conséquent, nous voulons que beaucoup de nouveaux arrivants fassent leurs premières éditions le plus tôt possible. Nous avons aussi vu à partir du projet des tâches de nouveaux venus que beaucoup d'entre eux cherchent des tâches faciles à réaliser. Mais nous avons aussi observé ces éléments :
- Seuls 25% des nouveaux venus qui cliquent sur une suggestion complètent actuellement la modifcation.
- Seuls 25% des contributeurs qui font une modification suggérée, en font une autre après.
- Mais il y a aussi une bonne poignée de nouveaux venus accros aux éditions suggérées qui en réalisent des dizaines chaque jour. Cela montre le potentiel disponible pour que les nouveaux venus puissent réaliser un travail conséquent sur le wiki.
- Dans les tests utilisateurs en direct, lorsque les nouveaux arrivants sont invités à copier et à modifier un article ou à ajouter des liens à un article, ils veulent souvent savoir exactement quelle phrase ou quelles mots ont besoin de leur attention. En d'autres termes, essayer de modifier l'article complet est trop limité.
En prenant ces points et les expériences des équipes de traduction de contenu et d'Android décrites ci-dessus, nous pensons que nous pourrions augmenter le nombre de nouveaux arrivants qui éditent et continuent à éditer, en structurant certains des flux de travail d'édition de contenu dans Wikipedia.
Opportunités avec les tâches structurées
Quand nous décomposons les flux de travail d'édition en étapes, nous les appelons des tâches structurées. Voici d'après nous quelques-uns des avantages possibles que les tâches structurées peuvent apporter :
- Facilite les débutants pour faire des contributions significatives.
- Développer des flux de travail d'édition qui ont du sens pour les mobiles. Les principes de conception pour mobile nous disent que les utilisateurs devraient voir un pas à la fois, et non pas tout un espace de travail compliqué.
- Laissez les nouveaux arrivants augmenter leurs compétences progressivement. Ils pourraient alors réussir à s'acquitter de tâches plus difficiles.
- Laissez les personnes trouver une expérience d'édition qui leur convient. En donnant aux nouveaux arrivants un flux de tâches structurées, ils pourraient trouver le type de tâches qu'ils préfèrent.
- Des flux de travail similaires pourraient à l'avenir peut être aussi être ouverts aux contributeurs expérimentés.
Problèmes et conséquences des tâches structurées
Chaque fois que nous ajoutons de nouvelles façons possibles pour modifier Wikipédia, il y a beaucoup de choses qui peuvent aller mal :
- En rendant l'édition trop rapide et facile, nous pouvons attirer des vandales, ou des utilisateurs qui ne font pas assez attention à leurs modifications.
- Donner aux nouveaux arrivants des flux de travail simples peut les empêcher d'apprendre les outils d'édition traditionnels qui sont essentiels pour faire un travail le plus efficace sur le wiki.
- Les tâches structurées peuvent ne pas être bonnes pour tenir compte des différences entre les langues, des idiosyncrasies avec le wikicode et peuvent causer d'autres types de bogues.
- Les algorithmes qui superposent des tâches structurées peuvent ne pas être assez précis et encourager faussement les nouveaux arrivants à effectuer des modifications qu'ils ne devraient pas faire.
Discussion de la communauté
En mai 2020, nous avons mené des discussions avec des membres de la communauté en six langues (anglais, français, coréen, arabe, vietnamien, tchèque) sur les idées ci-dessus pour des tâches structurées. La discussion en anglais se passe le plus souvent sur la page de discussion ici avec les autres conversations sur la Wikipedia anglophone; en ce qui concerne les langues locales de conversation, elle a lieu sur les cinq autres Wikipedia. Nous avons écouté 35 membres de communautés et cette section résume quelques unes des idées les plus rencontrées et les plus intéressantes. Ces discussion ont beaucoup influencé notre ensemble suivant d'architectures.
- Les membres de la Communauté ont généralement été positifs quant au potentiel des tâches structurées pour aider les nouveaux arrivants à commencer à éditer. Mais il y avait aussi une opinion largement exprimée selon laquelle il est important que les nouveaux arrivants soient introduits à la source conventionnelle et aux éditeurs visuels pendant le processus. Les membres de la communauté veulent s'assurer que les nouveaux arrivants ne sont pas isolés dans une expérience d'édition distincte et qu'ils peuvent retrouver leur chemin dans les éditions plus usuelles.
- La communauté tchèque a discuté d'idées concernant l'intégration des tâches structurées dans l'éditeur visuel de sorte à ce que les nouveaux venus puissent commencer en étant familiarisé avec l'éditeur. Peut-être les outils d'édition qui ne sont pas nécessaires à la tâche structurée pourraient être grisés.
- Les membres de la Communauté ont demandé pourquoi nous avons choisi ajouter un lien comme première tâche structurée plutôt que des types de modifications à plus grande valeur. Nous avons parlé de la façon dont cette tâche était l'une des plus faciles à construire, ce qui nous aida à prototyper et à apprendre sur les tâches structurées plus tôt, et comment par comparaison c'est une tâche à faible risque relatif avec moins de possibilités pour les nouveaux arrivants d'endommager les articles.
- Plusieurs communautés ont mentionné que les corrections orthographiques seraient une tâche particulièrement utile, et nous avons discuté des options techniques sur le moyen de générer des listes d'erreurs d'orthographe potentielles. Voir ces notes pour les détails supplémentaires.
- Nous avons aussi discuté de la question de savoir si la réversion du vandalisme est appropriée pour les nouveaux arrivants. La réponse ne semble pas claire, et cela devra être discuté plus tard.
- Une idée qui a été mentionnée à plusieurs reprises est de savoir comment faire progresser les nouveaux arrivants pour des tâches progressivement plus difficiles, peut-être en leur donnant des récompenses pour avoir réussi à accomplir des tâches plus faciles.
Types de tâches
Il existe beaucoup de flux de travail d'édition différents qui ont le potentiel de devenir structurés. Nous avons commencé par lister les flux de travail avec ici le flux de travail des tâches pour les nouveaux venus, et depuis nous avons rétréci jusqu'à obtenir une liste plus courte de types de tâches qui semblent le mieux adaptés à la structuration. Le tableau ci-dessous contient une courte liste rangée par ordre de priorité potentielle.
| Priorité potentielle | Type de tâche | Comment il pourrait fonctionner | Avantages | Inquiétudes |
|---|---|---|---|---|
| 1 | Add a link | For articles without enough wikilinks, an algorithm (existing) suggests words or phrases that should become wikilinks, and the newcomer accepts or rejects the suggestions. | Linking is a quick and easy way to edit, and has low potential to damage articles. | Understanding when to add a link takes judgment, and we don't want articles to be overlinked. It is also not the most valuable type of edit. |
| 2 | Add an image | For articles without an illustration, an algorithm (potential) suggests an image from Commons. This might be a simple algorithm that just looks at what images are used on that article in other languages. The newcomer decides if the image belongs, and where in the article to add it. | Good images make a big difference in an article, and newcomers are interested in adding images. | Adding the wrong image to an article could damage the article in a very visible way. |
| 3 | Add a reference | Some sentences or paragraphs clearly need citations. An algorithm (in development) would point out which sentences likely need suggestions, and the newcomer would seek sources to add as citations in a step-by-step workflow. | References are of clear importance to the core of the encyclopedia. | This task may not be exciting to newcomers. They may also struggle to find and use sources without guidance. |
| 4 | Copyedit | Using open-source spellcheck dictionaries and code, or using Wiktionary, identify likely misspelled words, and point them out to newcomers, who can use the visual editor or wikitext editor to fix them one at a time. | Clearly valuable and needed in any wiki, satisfying to newcomers. Helps them start editing the main text of articles, as opposed to peripherals parts of the article. | Scaling to any language may be difficult, depending on the availability of good spellchecking algorithms. |
| 5 | Add a section | An algorithm detects when an article could use additional sections, based on the kinds of section headers that similar articles have (e.g. all biographies of scientists tend to have "Publications" sections). The newcomer is walked through producing a well-referenced paragraph. | Real content additions that could help close knowledge gaps. | A much more challenging task than the others, requiring many wiki skills to be used together. May produce low-quality content. |
Prioritizing "add a link"
The Growth team currently (May 2020) wants to prioritize the "add a link" workflow over the other ones listed in the table above. Although other workflows, such as "copyedit", seem to be more valuable, there are a set of reasons we would want to start first with "add a link":
- In the near term, the most important thing we would want to do first is to prove the concept that "structured tasks" can work. Therefore, we would want to build the simplest one, so that we can deploy to users and gain learnings, without having to invest too much in the first version. If the first version goes well, then we would have the confidence to invest in types of tasks that are more difficult to build.
- "Add a link" seems to be the simplest for us to build because there already exists an algorithm built by the WMF Research team that seems to do a good job of suggesting wikilinks (see the Algorithm section).
- Adding a wikilink doesn't usually require the newcomer to type anything of their own, which we think will make it particularly simple for us to design and build -- and for the newcomer to accomplish.
- Adding a wikilink seems to be a low-risk edit. In other words, the content of an article can't be as compromised through adding links incorrectly as it could through adding references or images incorrectly.
Notes on "copyedit"
In conversations with community members on this project's discussion page, many people brought up the question of how to make a structured task around copyediting. Correcting spelling, grammar, punctuation, and tone seemed to everyone to be a clearly useful task that should be prioritized. The Growth team initially shied away from this workflow because of scaling concerns: even if we were able to find or develop an algorithm that could reliably find copyedits in one language, would we be able to do that in dozens of other languages?
We began to learn more about this by talking with User:Beland, who developed the "moss" script for English Wikipedia's Typo Team. We wanted to understand how the process works, and what it might look like to do something similar in other languages. In short, it sounds like the most promising avenue is through existing open-source spellcheckers and dictionaries. Two examples are the aspell and hunspell libraries. Below are our notes from learning about "moss" with User:Beland.
- Prospects for doing something similar in other languages
- A process like this should theoretically work in other languages, given that other languages also have Wiktionaries and open-source spellcheckers.
- But it would not be possible to deploy in a new language without native speakers validating it. There would likely need to be customization for many languages.
- Likely more challenges for languages without word segmentation (e.g. Japanese).
- Likely more challenges for agglutinative languages.
- Different projects have differing manuals of style, which may cause issues.
- If an algorithm is performing poorly, it should always be possible to change its thresholds so that it identifies fewer potential errors, but with higher confidence.
- How does moss work?
- Download the dump files of all of English Wikipedia every two weeks.
- In order to cut down on false positives, remove templates and everything inside quotation marks, etc. Only want to work on the main text in the article: the things written “in Wikipedia’s voice”.
- Check that every word is in English Wiktionary.
- Uses Python NLTK (natural language toolkit) for word segmentation.
- Looks at edit distance to classify misspellings. e.g. “T1” is one edit distance (95% precision). Also classifies “TS” whitespace errors.
- Also includes an English open-source spellchecker to narrow the search space so that the algorithm can run faster.
- He has also started trying to add grammar rules (e.g. identifying passive voice), but that’s more experimental, and much more difficult than spelling.
- At the end of the process, it produces a list of articles and likely typos. The user opens the article and searches for the likely typo.
Many copyedit requests are also editors whose native language is not English, asking for English polishing. See WikiProject Guild of Copy Editors.