Tăng trưởng/Cá nhân hóa ngày đầu tiên/Nhiệm vụ có cấu trúc
Trang này mô tả công việc của Nhóm Tăng trưởng đối với dự án "nhiệm vụ có cấu trúc", một dự án liên quan tới các dự án "nhiệm vụ người mới" và "trang nhà người mới". Trang này chứa các sản phẩm, thiết kế, câu hỏi mở và quyết định chính. Hầu hết các cập nhật thêm vào sẽ được đăng trên trang cập nhật chung của Nhóm tăng trưởng, còn một số các cập nhật chi tiết hoặc lớn hơn sẽ được đăng ở đây.
|
Newcomer tasks
 Recommend tasks to newcomers that help them start editing
|
Trang này nói về ý tưởng "nhiệm vụ có cấu trúc" nói chung, với một số thảo luận về những loại nhiệm vụ cụ thể mà chúng tôi có thể xây dựng. Theo những cuộc thảo luận chung này, nhóm bắt đầu thiết kế và xây dựng những loại nhiệm vụ cụ thể đó. Những loại nhiệm vụ đó có những trang dự án riêng, nơi hầu hết mọi thông tin mới được đăng.:
Tình hình hiện tại
- 2020-05-01: lên kế hoạch và ghi chép những lưu ý đầu tiên
- 2020-05-17: bắt đầu cuộc thảo luận cộng đồng
- 2020-05-29: initial wireframes
- 2020-08-24: tuần họp mặt lên kế hoạch
- 2020-09-08: đề nghị cộng đồng thảo luận về mẫu thiết kế mới nhất
- 2020-10-21: người dùng thử nghiệm thiết kế cho máy tính
- 2021-05-27: Chúng tôi đã triển khai tính năng "thêm liên kết" cho bốn Wikipedia thí điểm của chúng tôi (tiếng Ả Rập, tiếng Séc, tiếng Việt, tiếng Bengal).
- 2021-07-21: tiếp tục mở rộng quy mô "thêm liên kết" đến nhiều Wikipedia hơn (T304110)
- 2022-08-20: bắt tay vào việc để giải quyết phản hồi của tuần tra viên về các nhiệm vụ có cấu trúc (T315732)
- 2022-09-02: công bố Phân tích loại sửa đổi của nhiệm vụ cho người mới
Tóm tắt
Nhóm Tăng trưởng triển khai dự án "nhiệm vụ người mới" vào tháng 11 năm 2019, thứ cung cấp cho người mới một danh sách các bài viết gợi ý để sửa đổi trên trang nhà người mới. Cho đến tháng 4 năm 2020, các bài viết gợi ý chỉ được lấy nguồn từ các bài viết có bản mẫu bảo trì do các biên tập viên có kinh nghiệm thêm vào, nó không hề đem lại cho người mới đến một chỉ dẫn cụ thể xem phải lưu ý vào câu, từ hay đoạn nào cả. Dù cho không có phương hướng như vậy nhưng chúng tôi rất vui khi thấy rằng người mới đến vẫn đang tạo ra những sửa đổi gợi ý có ích.
Mặc dù bản mẫu bảo trì cung cấp nhiều loại sửa đổi đa dạng cho người mới đến nhưng có thể chúng quá bao quát và bỏ ngỏ để có thể giúp người mới đến thành công. Và trên thiết bị di động, giao diện sửa đổi trực quan hoặc wikitext có thể khiến người mới đến bị ngợp trên màn hình nhỏ.
Do đó, chúng tôi muốn thử nghiệm một ý tưởng mang tên "nhiệm vụ có cấu trúc". Nó có nghĩa là bẻ nhỏ luồng công việc sửa đổi ra thành một chuỗi các bước mà người mới đến có thể hoàn thành một cách dễ dàng. Theo sau những ví dụ đầy thành công từ thành quả của nhóm Android và Ngôn ngữ, chúng tôi nghĩ người mới đến sẽ dễ dàng thực hiện những loại sửa đổi này hơn trên điện thoại di động, từ đó giúp càng nhiều người mới đến thực hiện càng nhiều sửa đổi hơn. Người mới đến có thể tiếp cận được những nhiệm vụ có cấu trúc này như là một phần của dự án nhiệm vụ người mới.
Bối cảnh
Sửa đổi là một công việc phức tạp
Thông qua kinh nghiệm của nhóm Tăng trưởng, chúng tôi tin rằng những giây phút đầu tiên của người mới đến trên wiki có thể nhanh chóng quyết định liệu họ muốn ở lại hay bỏ đi. Chúng tôi cũng tin rằng người mới đến muốn ở lại khi họ có thể nhanh chóng tạo sửa đổi và có một trải nghiệm tích cực. Nhưng đóng góp cho Wikipedia -- gần như bất kỳ loại đóng góp nào -- là một việc phức tạp, và nó khiến cho người mới khó thành công một cách nhanh chóng. Ví dụ, có cả tá các bước cần thiết để làm một việc đơn giản như là thêm một câu vào một bài viết:
- Tìm kiếm bài chính xác.
- Xem xem liệu thông tin bạn muốn thêm đã có trong bài chưa.
- Chọn đoạn văn bạn muốn thêm câu.
- Click để bắt đầu sửa đổi.
- Gõ câu vào đúng vị trí.
- Click nút chú thích.
- Quay trở lại nguồn tham khảo để lấy liên kết hoặc thông tin chú thích.
- Điền và lưu chú thích.
- Click đăng sửa đổi.
- Điền tóm tắt sửa đổi.
- Xuất bản.
Người mới đến nhìn vào trình sửa đổi trực quan hoặc wikitext lần đầu tiên sẽ không biết những bước đó là gì, phải thực hiện chúng theo thứ tự nào, hay phải click vào nút nào để thực hiện chúng. Nói cách khác, trải nghiệm của họ không được cấu trúc hóa. Có thể họ cảm thấy choáng ngợp và bỏ đi. Hoặc có thể họ sẽ thử-và-sai, mắc sai lầm rồi nhận phản hồi tiêu cực từ người dùng có kinh nghiệm. Dự án này chính là về điều đó: làm thế nào để chúng ta có thể giúp người mới đến bước qua luồng công việc này theo đúng thứ tự?
Xây dựng dựa trên những kiến thức từ các nhóm khác
Thêm cấu trúc vào các luồng công việc sửa đổi đã là một phần của các dự án Wikimedia từ lâu. Dưới đây là một số ví dụ:
- HotCat: cho phép người dùng lựa chọn thể loại để thêm vào bài viết chỉ với một vài cú click, thay vì phải sửa đổi wikitext bằng tay.
- Commons Upload Wizard: bẻ quy trình tải phương tiện lên Commons thành một chuỗi các bước đơn giản.
- Citoid: có sẵn tại Sửa đổi trực quan, công cụ này bẻ quy trình thêm chú thích thành các bước bao gồm các thuật toán để tự động sản sinh ra chữ và bản mẫu chú thích.
Gần đây nhất, ý tưởng về "nhiệm vụ có cấu trúc" đã hoạt động tốt trên ứng dụng Android Wikipedia và trên công cụ Biên dịch nội dung. Các công trình của họ đã truyền cảm hứng cho chúng tôi.
Với dự án "sửa đổi gợi ý" của mình, nhóm Android đã bẻ nhỏ quy trình thêm miêu tả bài viết vào một bài viết Wikipedia thành một bước dễ dàng là gõ vào một hộp thoại. Từ đó họ đã làm tương tự với việc biên dịch miêu tả bài viết xuyên suốt các ngôn ngữ. Để có thể làm cùng nhiệm vụ đó mà không có luồng công việc có cấu trúc thì người dùng sẽ phải đi tới Wikidata và trải qua nhiều bước khác nhau để thực hiện nó. Nhóm đã biết được rằng phương pháp này có hiệu quả: nhiều người dùng Android đã tạo hàng trăm đóng góp nhỏ kiểu này.
Nhóm Ngôn ngữ xây dựng công cụ Biên dịch nội dung thực hiện nhiều thứ để cấu trúc quy trình dịch một bài viết. Nó cung cấp một giao diện đặt song song để dịch, chia bản dịch thành các đoạn, và tự động áp dụng thuật toán dịch máy. Mặc dù Wikipedian "có thể" dịch bài viết trước khi công cụ này xuất hiện nhưng số lượng các bước thủ công cần thiết khiến việc đó trở nên rất khó khăn. Công cụ này là một sự thành công, với hàng trăm ngàn bản dịch đã được dịch. Chúng tôi biết được rằng khi việc dịch một bài viết được chia nhỏ thành các bước với những phần lặp đi lặp lại (ví dụ như chạy dịch máy) được thực hiện tự động thì sẽ càng có nhiều bài viết được dịch hơn.
Nhóm Tăng trưởng đang suy nghĩ về việc ứng dụng nguyên tắc tương tự vào việc sửa đổi nội dung bài viết, ví dụ như việc thêm liên kết, thêm hình ảnh, thêm nguồn tham khảo, và thêm câu văn.
-
App Wikipedia trên Android cung cấp "sửa đổi gợi ý", ví dụ như dịch mô tả bài viết, việc mà người dùng có thể thực hiện dễ dàng trong một bước thay vì phải lên Wikidata. -
Công cụ Biên dịch nội dung chia quy trình dịch một bài viết ra thành từng đoạn văn một, với sự trợ giúp tự động từ các thuật toán dịch máy.
Phác họa một nhiệm vụ có cấu trúc
The best way to explain how we're thinking about structured tasks may be through showing a quick sketch. The first structured task we've thought about is "add a (wiki)link". But the same ideas could apply to structured tasks for "add an image", "add a reference", or even "add a fact".
In the newcomer tasks feature, lots of newcomers complete "add a (wiki)link" tasks -- in which they add internal blue links in articles that don't have many. This seems like a simple editing task to get started. 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.
In the sketch below, the newcomer arrives on an article, and is given a suggestion of a word that might make a good (wiki)link. 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. Regarding the algorithm, the WMF Research team has done some preliminary work that makes us confident that such an algorithm is possible.
In thinking further about this, we sketched a second idea. 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.
In thinking about structured tasks, it looks like this might be a big question: should workflows be more aimed toward teaching newcomers to use the traditional tools, or be more aimed toward newcomers being able to do easy edits at higher volume?
Tại sao ý tưởng này lại được ưu tiên
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. We have already seen from the newcomer tasks project that many newcomers are looking for easy tasks to do. But we also have observed these things:
- Only about 25% of the newcomers who click on a suggestion actually edit it.
- Only about 25% of those who do a suggested edit do another one.
- 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.
Các cơ hội với nhiệm vụ có cấu trúc
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:
- Make it easy for newcomers to make meaningful contributions.
- 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.
- Perhaps similar workflows could be opened to experienced editors in the future.
Các mối lo ngại và mặt trái của nhiệm vụ có cấu trúc
Bất cứ khi nào chúng ta thêm vào những cách mới để mọi người sửa đổi Wikipedia, sẽ có rất nhiều thứ trở nên không đúng:
- Sửa đổi quá nhanh chóng và dễ dàng sẽ thu hút những kẻ phá hoại, hoặc những người dùng không mấy quan tâm khi sửa đổi.
- Cung cấp cho người mới đến những luồng công việc đơn giản có thể ngăn họ khỏi việc học các công cụ sửa đổi truyền thống, thứ cần thiết để thực hiện công việc wiki có sức ảnh hưởng nhất.
- Nhiệm vụ có cấu trúc có thể không tốt khi đương đầu với sự khác biệt giữa nhiều ngôn ngữ, các đặc điểm riêng của wikitext, và có thể gây ra nhiều loại bọ khác nhau.
- Các thuật toán của nhiệm vụ có cấu trúc có thể không đủ chính xác, từ đó khuyến khích người mới đến thực hiện những sửa đổi mà họ không nên thực hiện một cách sai lầm.
Thảo luận cộng đồng
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. We heard from 35 community members, and this section summarizes some of the most popular and interesting thoughts. These discussions heavily influenced our next set of designs.
- 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.
Loại nhiệm vụ
There are many different editing workflows that have the potential to become structured. We began to list workflows when we first designed the newcomer tasks workflow here, and we have since narrowed down to a shorter list of task types that seem best suited to being structured. Bảng dưới đây chứa danh sách ngắn đó, được xếp theo thứ tự ưu tiên tiềm năng.
| Ưu tiên tiềm năng | Loại nhiệm vụ | Nó có thể hoạt động như thế nào | Ưu điểm | Hạn chế |
|---|---|---|---|---|
| 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.