Croissance/Premier jour personnalisé/Tâches structurées
|
Newcomer tasks
 Recommend tasks to newcomers that help them start editing
|
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 seront affichées sur la page générale des mises à jour, certaines mises à jour importantes ou détaillées étant affichées ici.
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 chargée de la croissance a déployé le projet "newcomer tasks" en novembre 2019, qui suggère aux nouveaux arrivants un flux d'articles à modifier sur leur page d'accueil personnelle. Depuis avril 2020, les articles suggérés proviennent uniquement d'articles dont 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, mots ou 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 wikitexte peuvent submerger les nouveaux arrivants qui tentent de les faire sur 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.
Most recently, the idea of "structured tasks" has been working well on the Wikipedia Android app and in the Content Translation tool. We're inspired by their work.
With their "suggested edits" project, the Android team broke down the process of adding a title description to a Wikipedia article into one easy step of typing into a text box. 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 devraient 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. It offers a side-by-side interface built for translations, it breaks the translation down into sections, and it automatically applies machine translation algorithms. Though Wikipedians could translate articles before the existence of the tool, the number of manual steps required made it very difficult. Cet outil est efficace et comporte des centaines de milliers de traductions réalisées. We learned that when translating an article is broken down into steps, with rote parts (e.g. running machine translation) taken care of automatically, more articles get translated.
The Growth team is thinking about applying these same principles to content edits in articles, like adding links, adding images, adding references, and adding sentences.
-
The Wikipedia Android app offers "suggested edits", such as translating title descriptions, which users can do in one easy step, instead of going through Wikidata. -
The Content Translation tool breaks down the process of translating an article into one section at a time, with automated assistance from machine translation algorithms.
Une esquisse de 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 wikilien » (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 de nouveaux venus effectuent des tâches « ajouter un (wiki)lien » -— dans lesquelles ils ajoutent des liens bleus internes dans les articles qui n'en ont pas beaucoup. On dirait qu'il s'agit d'une simple tâche d'édition à démarrer. But we think that many newcomers may not understand how to go through the steps of adding a link and may not know which words to make into links. We're imagining a workflow that walks them through it, step-by-step, with the assistance of an algorithm that can guess which words or phrases might make the best links.
Dans le schéma ci-dessous, le nouveau venu arrive sur un article, et se voit suggérer un mot qui pourrait faire un bon lien (interne). If they agree that it should be made a link, they are walked through the steps of making the link. This will hopefully teach them to add links on their own in the future -- and perhaps they'll enjoy continuing to receive these algorithmic link suggestions. 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 y réfléchissant, nous avons esquissé une deuxième idée. Instead of being aimed toward teaching the newcomer to add links using the visual editor, this next workflow lets the user quickly confirm or reject recommendations from the algorithm, directly editing the article. While it does not teach them how to add links via the editor, it might help a newcomer edit at high volume, and might be a better fit for a user who is trying to be productive with simple tasks while they are on the go. Or perhaps might be a good fit for users who only are interested in very simple edits, similarly to how the Android app has many editors who only want to write title descriptions.
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
We think that quickly making productive edits is what leads to newcomer success. Once they've done some edits, the rest of the wiki experience quickly becomes richer. Newcomers can then see their impact, get thanked, ask informed questions to their mentors, create their userpage, etc. Therefore, we want lots of newcomers to make their first edits as soon as 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.
- There are a handful of newcomers who really thrive on suggested edits, doing dozens of them every day. This shows the potential for newcomers to accomplish a lot of wiki work.
- In live user tests, when newcomers are told to copyedit an article or add links to an article, they frequently want to know exactly which sentence or words need their attention. In other words, attempting to edit the full article is too open-ended.
Taking these points along with the experiences described above of the Android and Content Translation teams, we think we could increase the number of newcomers editing and continuing to edit by structuring some of the content editing workflows in Wikipedia.
Opportunités avec les tâches structurées
When we break down editing workflows into steps, we call them "structured tasks". Here are some of the possible benefits we think could come from structured tasks:
- Facilite les débutants pour faire des contributions significatives.
- Develop editing workflows that make sense for mobile. Mobile design principles tell us that users should see one step at a time, not a complicated workspace.
- Let newcomers increase their skills incrementally. They could take on successfully more challenging types of tasks.
- Let people find an editing experience that fits them. By giving newcomers a feed of structured tasks, they could find the type of tasks that they prefer.
- 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
Whenever we add new ways for people to edit Wikipedia, there are many things that can go wrong:
- By making editing too quick and easy, we may attract vandals, or users who don't apply enough care when editing.
- Giving newcomers simple workflows may keep them from learning the traditional editing tools, which are essential for doing the most impactful wiki work.
- Structured tasks may not be good at accounting for differences across languages, idiosyncrasies with wikitext, and could cause other kinds of bugs.
- Algorithms that surface structured tasks may not be accurate enough, and falsely encourage newcomers to complete edits they shouldn't.
Discussion de la communauté
In May 2020, we conducted discussions with community members in six languages (English, French, Korean, Arabic, Vietnamese, Czech) about the above ideas for structured tasks. The English discussion mostly took place on the discussion page here, with other conversations on English Wikipedia, and local language conversations on the other five Wikipedias. 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.
- Community members were generally positive about the potential for structured tasks to help newcomers start editing. But it was also a widely expressed view that it's important for newcomers to be introduced to the conventional source and visual editors during the process. Community members want to make sure that newcomers are not siloed in a separate editing experience, and that they can find their way to more valuable edits.
- The Czech community talked about ideas for how the structured tasks can place inside the visual editor, so that newcomers can start getting used to being in the editor. Perhaps the editing tools that are not needed for the structured task can be grayed-out.
- Community members asked why we are choosing "add a link" as our first structured task, as opposed to higher-value types of edits. We talked about how this task is one of the easiest for us to build, which will help us prototype and learn from structured tasks sooner, and how it is a comparatively low-risk task, with fewer opportunities for newcomers to damage articles.
- Several communities mentioned that spelling corrections would be a particularly valuable task, and we talked about technical options for how to generate lists of potential spelling mistakes. See these notes for more details.
- We also talked about whether reverting vandalism is a good fit for newcomers. It doesn't seem like the answer is clear, and this will have to be discussed more in the future.
- An idea that was mentioned multiple times is how to "step newcomers up" to progressively more challenging tasks, perhaps while giving them rewards for successfully completing easier ones.
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.