Növekedés/Személyre szabott első nap/Strukturált feladatok
Ez az oldal a Növekedés csapat munkáját írja le a "strukturált feladatok" projekten, amely az "újoncfeladatok" és az "újonc kezdőlap" projektekhez kapcsolódik. Ez az oldal tartalmazza a főbb eszközöket, terveket, nyitott kérdéseket és döntéseket. Az előrehaladásról szóló legtöbb apró frissítés az általános Növekedési csapat frissítések oldalára kerül, néhány nagyobb vagy részletes frissítés pedig ide.
|
Newcomer tasks
 Recommend tasks to newcomers that help them start editing
|
Ez az oldal az általános "strukturált feladat" koncepcióról szól, néhány konkrét feladattípus megvitatásával, melyeket megépíthetünk. Ezt az általános megbeszélést követően a csapat elkezdte a konkrét feladattípusok tervezését és kivitelezését. Ezeknek a feladattípusoknak saját projektoldaluk van, ahová a legtöbb új információ felkerül.:
Jelenlegi állapot
- 2020-05-01: kezdeti feljegyzések tervezése és dokumentálása
- 2020-05-17: közösségi megbeszélések megkezdése
- 2020-05-29: kezdeti wireframe-ek
- 2020-08-24: tervezési találkozók hete
- 2020-09-08: felhívás a legújabb tervek közösségi megvitatására
- 2020-10-21: az asztali tervek felhasználói tesztelése
- 2021-05-27: A "link hozzáadása" opciót a négy kísérleti Wikipédiánkon (arab, cseh, vietnámi, bengáli) alkalmaztuk.
- 2021-07-21: tovább lesznek bővítve a "link hozzáadása" funkció további Wikipédiákra (T304110)
- 2022-08-20: munka megkezdése a strukturált feladatokkal kapcsolatos járőrök visszajelzéseinek kezelésére (T315732)
- 2022-09-02: az új szerkesztők feladatainak szerkesztési típuselemzésének közzététele
Összefoglaló
A Növekedési csapat 2019 novemberében telepítette az "újoncfeladatok" projektet, mely az új szerkesztők számára az újonc kezdőlapján egy adag javasolt szócikket ad, melyet szerkeszthetnek. 2020 áprilisától kezdve a javasolt szócikkek csak olyan szócikkekből származnak, melyeken tapasztalt szerkesztők által alkalmazott karbantartási sablonok vannak, melyek nem adnak konkrét útmutatást az újaknak arra vonatkozóan, hogy mely mondatok, szavak vagy szakaszok igényelnek konkrétan figyelmet. Az iránymutatás hiánya ellenére örömmel látjuk, hogy az új szerkesztők eredményes javasolt szerkesztéseket végeznek.
Bár a karbantartási sablonok változatos típusú szerkesztési lehetőségeket kínálnak az új szerkesztők számára, lehet, hogy túl széles körűek és nyíltak ahhoz, hogy az újak sikerrel járjanak velük. Mobileszközökön pedig a vizuális vagy wikitext-szerkesztők túlterhelhetik az új belépőket a kis képernyőn.
Ezért egy "strukturált feladatok" nevű ötlettel szeretnénk kísérletezni. Ez a szerkesztési munkafolyamatok olyan lépések sorozatára való lebontásáról szól, melyeket az új szerkesztők is könnyen el tudnak végezni. Az Android és a nyelvi csoport sikeres példáit követve úgy gondoljuk, hogy az ilyen típusú szerkesztések könnyebbek lesznek az új szerkesztők számára, és könnyebben elvégezhetőek lesznek mobilon is, ami segít több új belépőnek több szerkesztést elvégezni. Ezek a strukturált feladatok az új szerkesztők számára az újoncok feladatai projekt részeként lennének elérhetőek.
Háttér
A szerkesztés bonyolult
A Növekedési csapat tapasztalatai alapján úgy véljük, hogy az új felhasználók első pillanatai a wikin gyorsan eldönthetik, hogy maradnak-e vagy távoznak. Úgy gondoljuk, hogy a frissen regisztráltak akkor akarnak maradni, ha gyorsan tudnak szerkeszteni, és pozitív élményben lehet részük. De a Wikipédiához való hozzájárulás -- szinte bármilyen típusú hozzájárulás -- bonyolult, és ez megnehezíti számukra a gyors sikert. Például körülbelül egy tucatnyi lépés szükséges ahhoz, hogy egy olyan egyszerű dolgot elvégezzünk, mint egy mondat hozzáadása egy szócikkhez:
- Keresd meg a megfelelő szócikket.
- Derítsd ki, hogy a hozzáadni kívánt információ már szerepel-e a szócikkben.
- Válassz ki egy szakaszt, amelyhez hozzáadod a mondatot.
- Kattints a szerkesztés megkezdéséhez.
- Gépeld be a mondatot a megfelelő helyre.
- Kattints az idézet gombra.
- Térj vissza a forráshoz a link vagy az idézetre vonatkozó információkért.
- Töltsd ki és mentsd el az idézet űrlapot.
- Kattints a szerkesztés közzétételéhez.
- Töltsd ki a szerkesztési összefoglalót.
- Közzététel.
A vizuális vagy wikitext-szerkesztővel először találkozó új szerkesztők nem tudják, hogy mik ezek a lépések, milyen sorrendben kell elvégezni őket, vagy hogy milyen gombokra kell kattintani, hogy mindezek megtörténjenek. Más szóval, a tapasztalatuk nem strukturált. Előfordulhat, hogy egyszerűen túlterheltek lesznek, és távoznak. Vagy pedig próbálgatják, hibáznak, és negatív visszajelzést kapnak a tapasztalt szerkesztőktől. Erről szól ez a projekt: hogyan tudnánk segíteni az új szerkesztőknek, hogy a megfelelő sorrendben lépkedjenek végig ezeken a munkafolyamatokon?
Más csapatok tudására építve
A szerkesztési munkafolyamatok rendszerezése már régóta része a Wikimédia-projekteknek. Néhány példa erre:
- HotCat: lehetővé teszi a szerkesztők számára, hogy a wikitext kézi szerkesztése helyett néhány kattintással válasszanak kategóriákat a cikkekhez.
- Commons Upload Wizard: egyszerű lépésekre bontja a média feltöltésének folyamatát a Commonsba.
- Citoid: a vizuális szerkesztőben elérhető, az idézet hozzáadásának folyamatát lépésekre bontja, melyek algoritmusokat tartalmaznak az idézet szövegének és sablonjának automatikus létrehozásához.
Legújabban a "strukturált feladatok" ötlete jól működik a Wikipédia Android alkalmazásában és a tartalomfordító eszközben. Bennünket az ő munkájuk inspirált.
A "javasolt szerkesztések" projektjükkel az Android-csapat a Wikipédia-cikk címleírásának hozzáadásának folyamatát egyetlen egyszerű, egy szövegdobozba való beírással járó lépésre bontotta le. Azóta ugyanezt tették a címleírások nyelvek közötti fordításával is. Ugyanezen feladatok elvégzéséhez strukturált munkafolyamat nélkül a szerkesztőknek a Wikidata oldalára kellene menniük, és több lépésen keresztül kellene elvégezniük ugyanezeket a szerkesztéseket. A csapat megtanulta, hogy ez a módszer működik: sok Android-felhasználó több száz ilyen apró hozzájárulást tesz.
A Nyelvi csapat megépítette a Tartalomfordító eszközt, mely több dolgot is tesz egy szócikk fordítási folyamatának felépítése érdekében. Egy fordításokhoz épített, egymás melletti felületet kínál, a fordítást szakaszokra bontja, és automatikusan alkalmazza a gépi fordítási algoritmusokat. Bár a Wikipédiások az eszköz létezése előtt is tudtak szócikkeket fordítani, a szükséges kézi lépések száma nagyon megnehezítette ezt. Ez az eszköz sikeres, több százezer fordítás már elkészült. Megtanultuk, hogy ha egy szócikk lefordítása lépésekre van bontva, és a rutinszerű részeket (pl. a gépi fordítás futtatását) automatikusan elvégzik, több szócikk kerül lefordításra.
A növekedési csapat ugyanezen elvek alkalmazásán gondolkodik a szócikkek tartalmi szerkesztésére, például linkek, képek, hivatkozások és mondatok hozzáadására.
-
A Wikipédia Android alkalmazás "javasolt szerkesztéseket" kínál, például a címleírások fordítását, amit a szerkesztők egyetlen egyszerű lépésben elvégezhetnek, ahelyett, hogy a Wikidatára kellene lépniük. -
A Tartalomfordító eszköz egy-egy cikk fordításának folyamatát egy-egy szakaszra bontja, a gépi fordítási algoritmusok automatikus segítségével.
Egy strukturált feladatvázlat
A legjobban talán egy gyors vázlat bemutatásával lehet elmagyarázni, hogyan gondolkodunk a strukturált feladatokról. Az első strukturált feladat, amire gondoltunk, a "(wiki)link hozzáadása". De ugyanezek az ötletek alkalmazhatóak a "kép hozzáadása", "hivatkozás hozzáadása" vagy akár az "adat hozzáadása" strukturált feladatokra is.
Az újoncok feladatai funkcióban sok új belépő tölti ki a "(wiki)link hozzáadása" feladatokat, -- melyekben belső kék linkeket adnak hozzá olyan szócikkekhez, ahol nincs sok. Ez egy egyszerű szerkesztési feladatnak tűnik a kezdéshez. De úgy gondoljuk, hogy sok új szerkesztő nem érti, hogyan kell végigmenni a link hozzáadásának lépésein, és nem biztos, hogy tudja, mely szavakból kell linket csinálni. Olyan munkafolyamatot képzeltünk el, ami lépésről lépésre végigvezeti őket, egy algoritmus segítségével, amely kitalálja, hogy mely szavak vagy kifejezések jelenthetik a legjobb linkeket.
Az alábbi vázlatban az új szerkesztő egy szócikkhez érkezik, és kap egy javaslatot egy szóra, amiből jó (wiki)linket készíthet. Ha egyetért azzal, hogy a szóból linket kellene készíteni, akkor végigkísérjük a link létrehozásának lépésein. Ez remélhetőleg megtanítja majd őket arra, hogy a jövőben saját maguk adjanak linkeket -- és talán élvezni fogják, hogy továbbra is kapják ezeket az algoritmikus linkjavaslatokat. Ami az algoritmust illeti, a WMF kutatócsoportja végzett néhány előzetes munkát, ami alapján biztosak vagyunk benne, hogy egy ilyen algoritmus lehetséges.
Ezen tovább gondolkodva felvázoltunk egy második ötletet is. Ez a következő munkafolyamat ahelyett, hogy arra irányulna, hogy a kezdőket megtanítsa a linkek hozzáadására a vizuális szerkesztő segítségével, lehetővé teszi a szerkesztő számára, hogy gyorsan megerősítse vagy elutasítsa az algoritmus ajánlásait, közvetlenül a szócikket szerkesztve. Ez ugyan nem tanítja meg, hogyan kell a szerkesztőn keresztül linkeket hozzáadni, de segíthet egy kezdőnek a nagy volumenű szerkesztésben, és talán jobban megfelel egy olyan felhasználónak, aki útközben próbál egyszerű feladatokkal produktív lenni. Vagy talán olyan szerkesztőknek is megfelelhet, akiket csak nagyon egyszerű szerkesztések érdekelnek, hasonlóan ahhoz, ahogy az Android alkalmazásban is sok szerkesztő csak címleírásokat szeretne írni.
A strukturált feladatokról gondolkodva úgy tűnik, hogy ez lehet a nagy kérdés: a munkafolyamatoknak inkább arra kell irányulniuk, hogy megtanítsák a kezdőket a hagyományos eszközök használatára, vagy inkább arra, hogy a kezdők egyszerű szerkesztéseket tudjanak végezni nagyobb volumenben?
Miért van ez az elképzelés előnyben részesítve
Úgy gondoljuk, hogy a gyors és produktív szerkesztés az, ami a kezdők sikeréhez vezet. Ha egyszer már végeztek néhány szerkesztést, a wiki többi része gyorsan gazdagabbá válik. Az új belépők ekkor láthatják a hatásukat, köszönetet kapnak, tájékozott kérdéseket tehetnek fel a mentoruknak, létrehozhatják a szerkesztői lapjukat is, stb. Ezért azt szeretnénk, ha sok kezdő minél hamarabb elvégezné az első szerkesztéseit. Az újoncfeladatok projektből már láttuk, hogy sok kezdő keresi a könnyen elvégezhető feladatokat. De megfigyeltük ezeket a dolgokat is:
- A javaslatra kattintó kezdőknek csak körülbelül 25%-a szerkeszti meg ténylegesen a javaslatot.
- Azoknak, akik egy javasolt szerkesztést elvégeznek, csak körülbelül 25%-a végez el egy másikat.
- Van egy maroknyi kezdő, aki igazán élvezi a javasolt szerkesztéseket, és naponta több tucatot végez belőlük. Ez azt mutatja, hogy az új szerkesztők rengeteg munkát végezhetnek a wikiben.
- Az élő felhasználói tesztek során, amikor az új felhasználóknak azt mondták, hogy másoljanak át egy cikket, vagy adjanak hozzá linkeket egy cikkhez, gyakran tudni akarták, hogy pontosan melyik mondatra vagy szócikkre kell figyelniük. Más szóval, a teljes cikk szerkesztésének megkísérlése túlságosan nyitott.
Ezeket a pontokat, valamint az Android és a tartalomfordító csapatok fentebb leírt tapasztalatait figyelembe véve úgy gondoljuk, hogy a Wikipédia néhány tartalomszerkesztési munkafolyamatának megszervezésével növelhetnénk a szerkesztést végző és a szerkesztést folytató új felhasználók számát.
Lehetőségek a strukturált feladatokkal
Amikor a szerkesztési munkafolyamatokat lépésekre bontjuk, "strukturált feladatoknak" nevezzük őket. Íme néhány lehetséges előny, melyet a strukturált feladatokból származhat:
- Megkönnyíti az új szerkesztők számára az értelmes szerkesztést.
- Olyan szerkesztési munkafolyamatok kidolgozása, melyeknek van értelme a mobileszközök számára. A mobiltervezés alapelvei azt mondják, hogy a szerkesztőknek egyszerre csak egy lépést kell látniuk, nem pedig egy bonyolult munkaterületet.
- Hagyd, hogy az új felhasználók fokozatosan fejlesszék készségeiket. Sikeresen vállalhatnak nagyobb kihívást jelentő feladattípusokat.
- Hagyni kell, hogy a szerkesztők megtalálják a számukra megfelelő szerkesztési élményt. Azzal, hogy a kezdők strukturált feladatokat kapnak, meglelhetik az általuk preferált feladattípust.
- Talán a jövőben hasonló munkafolyamatokat lehetne megnyitni a tapasztalt szerkesztők előtt is.
A strukturált feladatokkal kapcsolatos aggályok és hátrányok
Amikor új módszereket adunk az embereknek a Wikipédia szerkesztéséhez, sok minden elromolhat:
- Ha túl gyors és egyszerűvé tesszük a szerkesztést, akkor vonzóvá tehetjük a vandálok számára, vagy olyan felhasználók számára, akik nem elég körültekintőek a szerkesztés során.
- Ha egyszerű munkafolyamatokat adunk a kezdőknek, az megakadályozhatja őket abban, hogy megtanulják a hagyományos szerkesztési eszközöket, melyek nélkülözhetetlenek a leghatékonyabb wikimunkához.
- A strukturált feladatok nem biztos, hogy jól figyelembe veszik a nyelvek közötti különbségeket, a wikitext sajátosságait, és másfajta hibákat is okozhatnak.
- A strukturált feladatokat felszínre hozó algoritmusok nem biztos, hogy elég pontosak, és tévesen arra ösztönzik a kezdőket, hogy olyan szerkesztéseket végezzenek el, amiket nem kellene.
Közösségi megbeszélés
2020 májusában hat nyelven (angol, francia, koreai, arab, vietnámi és cseh) folytattunk megbeszéléseket a közösség tagjaival a fenti, strukturált feladatokra vonatkozó ötletekről. Az angol nyelvű megbeszélések többnyire az itteni vitalapon zajlottak, más beszélgetések az angol Wikipédián, a helyi nyelvű beszélgetések pedig a másik öt Wikipédián. A közösség 35 tagjától hallhattunk véleményt, és ez a rész a legnépszerűbb és legérdekesebb gondolatokat foglalja össze. Ezek a megbeszélések nagyban befolyásolták a következő tervezési sorozatunkat.
- A közösségi tagok általában pozitívan nyilatkoztak a strukturált feladatokban rejlő lehetőségekről, melyek segítik az új szerkesztőket a szerkesztés megkezdésében. De az is széles körben megfogalmazódott vélemény volt, hogy fontos, hogy a kezdők a folyamat során megismerkedjenek a hagyományos forráskóddal és a vizuális szerkesztőkkel. A közösség tagjai szeretnék, ha az új belépők nem lennének elszigetelve egy külön szerkesztési élményben, és megtalálnák az utat az értékesebb szerkesztésekhez.
- A cseh közösség megbeszéléseket folytatott arról, hogy a strukturált feladatokat hogyan lehetne a vizuális szerkesztőn belül elhelyezni, hogy az új belépők elkezdhessék megszokni a szerkesztőben való használatot. Talán a strukturált feladathoz nem szükséges szerkesztési eszközöket ki lehetne szürkíteni.
- A közösség tagjai megkérdezték, hogy miért a "link hozzáadása" az első strukturált feladat, szemben a magasabb értékű szerkesztési típusokkal. Arról beszéltünk, hogy ez a feladat az egyik legkönnyebben elkészíthető feladat, ami segít abban, hogy hamarabb prototípusokat készítsünk és tanuljunk a strukturált feladatokból, és hogy ez egy viszonylag alacsony kockázatú feladat, kevesebb lehetőség van arra, hogy a kezdők kárt okozzanak a szócikkekben.
- Több közösség is említette, hogy a helyesírási hibák javítása különösen értékes feladat lenne, és megbeszéltük a lehetséges helyesírási hibák listájának létrehozására vonatkozó technikai lehetőségeket. További részletekért lásd ezeket a jegyzeteket.
- Beszéltünk arról is, hogy a vandalizmus visszaállítása jó megoldás-e a kezdők számára. Úgy tűnik, a válasz nem egyértelmű, és erről a jövőben többet kell majd beszélnünk.
- Egy többször említett ötlet az, hogy hogyan lehetne a kezdőket fokozatosan egyre nagyobb kihívást jelentő feladatokhoz "eljuttatni", esetleg jutalmat adva nekik a könnyebb feladatok sikeres elvégzéséért.
Feladattípusok
Sokféle szerkesztési munkafolyamat létezik, melyek strukturálódhatnak. A munkafolyamatok felsorolását akkor kezdtük el, amikor először terveztük meg az újoncok feladatainak munkafolyamatát, és azóta leszűkítettük a feladattípusok rövidebb listájára, melyek a legalkalmasabbnak tűnnek arra, hogy strukturáltak legyenek. Az alábbi táblázat ezt a rövid listát tartalmazza, lehetséges fontossági sorrendben.
| Potenciális fontosság | Feladat típusa | Hogyan működhetne | Előnyök | Aggodalmak |
|---|---|---|---|---|
| 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.