Growth/Personalized first day/Newcomer tasks/vi

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ụ dành cho người mới", một dự án cụ thể nằm trong chuỗi sáng kiến "Cá nhân hóa ngày đầu tiên". Trang này chứa các sản phẩm, thiết kế 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 của Nhóm tăng trưởng nói chung, còn các cập nhật chi tiết hoặc lớn hơn sẽ được đăng ở đây.

Bạn có thể nhanh chóng xem những gì nhóm đang xây dựng bằng cách ghé thăm các bản nháp này (dùng phím mũi tên để di chuyển):


 * Máy tính để bàn
 * Điện thoại
 * Lựa chọn chủ đề

Thiết kế và kế hoạch cho dự án này bắt đầu vào ngày 24 tháng 7 năm 2019. Phiên bản đầu tiên được triển khai trên bốn wiki vào ngày 20/11/2019.

Tình hình hiện tại

 * 2019-07-24: Cuộc họp nhóm đầu tiên để bàn luận về các nhiệm vụ dành cho người mới
 * 2019-08-27: Họp nhóm để bàn về các ý tưởng thiết kế.
 * 2019-09-09: Tạo các nhiệm vụ Phabricator cho công tác kỹ thuật
 * 2019-09-23: Hoàn thiệt bản thử cho người dùng máy tính để bàn
 * 2019-09-30: Hoàn thành bản thử cho người dùng điện thoại di động
 * 2019-11-20: V1.0 được triển khai tại Wikipedia Tiếng Séc, Tiếng Hàn, Tiếng Ả Rập và Tiếng Việt
 * 2019-12-13: thử nghiệm biến thể đầu tiên được triển khai tại Wikipedia Tiếng Séc, Tiếng Hàn, Tiếng Ả Rập và Tiếng Việt
 * 2020-01-14: thử nghiệm việc bổ sung lựa chọn chủ đề, sẽ được triển khai vào tuần 20/01/2020.
 * 2020-01-21: the option to select topics of interest was added to the suggested edits module
 * Tiếp theo: engineering work on adding guidance

Tóm tắt
Chúng tôi nghĩ rằng người dùng mới nên có mọi cơ hội để thành công khi họ lần đầu tới wiki. Nhưng thường thì người dùng mới sẽ thử làm một nhiệm vụ quá khó đối với họ, không thể tìm thấy nhiệm vụ họ muốn làm, hoặc không tìm thấy ý tưởng gì cho việc tiếp tục tham gia sau sửa đổi đầu tiên. Điều này dẫn tới việc nhiều trong số họ bỏ đi và không quay trở lại. Trong quá khứ đã có những lần thử thành công trong việc gợi ý nhiệm vụ cho các biên tập viên, vậy nên chúng tôi tin rằng trang nhà cho người mới là một nơi tiềm năng để gợi ý các nhiệm vụ liên quan cho người dùng mới.

Chúng tôi sẽ cần phải lưu ý một số điều:
 * Nhiều người dùng mới đến wiki trong khi trong đầu họ đang có sẵn một công việc cụ thể mà họ muốn làm, ví dụ như thêm một hình ảnh vào một bài viết nhất định. Chúng tôi không muốn làm ngáng đường việc đó.
 * Người dùng mới bồi đắp kĩ năng của họ qua thời gian bằng cách tiến từ các sửa đổi dễ lên những cái khó hơn.
 * Khi người dùng mới thành công ngay từ sớm thì họ sẽ có nhiều động lực để tiếp tục sửa đổi hơn.

Sau khi cân nhắc những điều trên, chúng tôi muốn gợi ý các nhiệm vụ cho người mới đến vào đúng lúc và đúng thời điểm, dạy họ các kĩ năng mà họ cần để thành công, và có liên hệ nhất định tới mối quan tâm của họ.

Một công cụ đáng giá mà chúng tôi có cho việc giúp các nhiệm vụ có mối liên quan tới người dùng hơn chính là khảo sát chào mừng, thứ ngay từ đầu được xây dựng để dành riêng cho mục đích: cá nhân hóa trải nghiệm người dùng mới. Chúng tôi dự tính sự dụng các thông tin tùy chọn mà người dùng mới cung cấp về mục tiêu và sở thích của họ để gợi ý các nhiệm vụ phù hợp cho họ.

Một trong những thách thức to lớn nhất chính là việc tìm ra cách để thu thập các nhiệm vụ mà phù hợp cho người dùng mới. Đã có sẵn nhiều nguồn, ví dụ như các bản mẫu kêu gọi cải thiện bài viết, các gợi ý trong công cụ Biên dịch nội dung, hoặc các gợi ý từ những công cụ như là Tìm kiếm trích dẫn. Câu hỏi đặt ra là lựa chọn nào sẽ giúp người dùng mới đạt được mục tiêu của mình.

Đầu tiên, chúng tôi tập trung vào việc sử dụng Special:MyLanguage/Growth/Personalized first day/Newcomer homepage trang nhà người dùng mới làm nơi để đưa ra gợi ý nhiệm vụ, nhưng về lâu dài, chúng tôi có thể sẽ xây dựng một tính năng mở rộng thành trải nghiệm sửa đổi để gợi ý và giúp người dùng mới hoàn thành các nhiệm vụ được khuyến nghị.

Vào xa hơn nữa, chúng tôi sẽ nghĩ ra những cách để ràng buộc việc gợi ý nhiệm vụ với các phần khác của trải nghiệm người dùng mới, ví dụ như là mô-đun ảnh hưởng trên trang nhà, hoặc là vào Bảng giúp đỡ.

Why this idea is prioritized
We know from research and experience that many newcomers fail early in their editing journey for one of these reasons:


 * They arrive with a very challenging edit in mind, such as writing a new article or adding an image. Those tasks are difficult enough that they likely fail and don't return.
 * They arrive without knowing what to edit, and can't find any edits to make.

We also know that on the newcomer homepage, the most frequently clicked-on module is the "user page" module -- the only thing on the page that encourages users to start editing. This makes us think that many users are looking for a clear way to get started with editing.

And from past Wikimedia endeavors, we've seen that task recommendations can be valuable. SuggestBot is a project that sends personalized recommendations to experienced users, and is a well-received service. The Content Translation tool also serves personalized recommendations based on past translations, and has been shown to increase the volume of editing.

For all these reasons, we think that recommending specific editing tasks for newcomers will give them a clear way to get started. For those newcomers that have an edit in mind that we want to do, we'll encourage them to try some easy edits first to build up their skills. For those newcomers who do not have a specific preference on what to edit, they'll hopefully find some good edits from this feature.

Glossary
''There are many terms that sound similar and can be confusing. This section defines each of them.''


 * "Newcomer tasks"
 * The entire workflow that recommends edits for newcomers and guides them through the edits.


 * "Suggested edits"
 * The name of the specific module that the newcomer tasks workflow adds to the newcomer homepage.


 * "Task recommendations" or "Task suggestions"
 * Lists of articles that need editing work, suggested automatically to users.


 * "Personalized"
 * Software that adapts automatically to each user to fit their needs.


 * "Customized"
 * Software that the user adapts to fit their needs.


 * "Topic"
 * A content subject, such as "Art", "Music", or "Economics".


 * "Topic matching"
 * The ability to find tasks for newcomers that match their topics of interest.


 * "Guidance"
 * Features that help the newcomer complete the suggested task while they are working on it.


 * "Maintenance template"
 * Templates that are put on articles indicating that work needs to be done on them.

Recommending tasks
The core challenge to this project is: Where will the tasks come from and how will we give the right ones to the right newcomers?

The graphic below shows our priorities when recommending tasks to newcomers.

As shown in the graphic above, we would give newcomers tasks that...


 * ...arrive at the right time and place for a newcomer's journey.
 * ...teach relevant conceptual and technical skills.
 * ...gradually guide users to build up their editing abilities.
 * ...be personalized to their interests.
 * ...show them the value and impact of editing.
 * ...motivate them to participate continually.

For instance, we do not want to give newcomers tasks that are irrelevant to what they hope to accomplish. If a newcomer wants to write a new article, then asking them to add a title description will not teach them skills they need to be successful.

We're splitting this challenge into two parts: the sourcing the tasks and topic matching.

Sourcing the tasks
There are many different places we could find tasks for newcomers to do. Our team listed as many as we could think of and evaluated them for whether they seem to be achievable for the first version of the feature. Below is a table showing the many sources of tasks that we evaluated in coming to the decision to start by using maintenance templates.

Version 1.0: basic workflow
In version 1.0, we will deploy the basic parts of the newcomer tasks workflow. It will recommend articles to newcomers that require different types of edits, but it will not match the articles to the newcomers' topics of interest (version 1.1), and it will also not guide the newcomers in completing the task (version 1.2).

Maintenance templates
We're going to be starting by using maintenance templates and categories to identify articles that need work. All of our target wikis use some set of maintenance templates or categories on thousands of articles, tagging them as needing copyediting, references, images, links, or expanded sections. And previous task recommendations software, such as SuggestBot, have used them successfully. These are some examples of maintenance categories:


 * Articles needing links in Arabic Wikipedia
 * Articles needing copyediting in Korean Wikipedia
 * Articles needing references in Czech Wikipedia



In this Phabricator task, we investigated exactly which templates are present and in what quantities, to get a sense of whether there will be enough tasks for newcomers. There seem to be sufficient numbers for the initial version of this project. We are likely to incorporate other task sources from the table below in future versions.

It's also worth noting that it could be possible to supplement many of these maintenance templates with automation. For instance, it is possible to automatically identify articles that have no internal links, or articles that have no references. This is an area for future exploration.

During the week of October 21, 2019, the members of the Growth team did a hands-on exercise in which we attempted to edit articles with maintenance templates. This helped us understand what challenges we can expect newcomers to face, and gave us ideas for addressing them. Our notes and ideas are published here.

Comparative review
Our team's designer reviewed the way that other platforms (e.g. TripAdvisor, Foursquare, Amazon Mechanical Turk, Google Crowdsource, Reddit) offer task recommendations to newcomers. We also reviewed Wikimedia projects that incorporate task recommendations, such as the Wikipedia Android app and SuggestBot. We think there are best practices we can learn from other software, especially when we see the same patterns across many different types of software. Even as we incorporate ideas from other software, we will still make sure to preserve Wikipedia's unique values of openness, clarity, and transparency. The main takeaways are below, and the full set of takeaways is on this page:


 * Task types – bucket into 4 types: Rating content, Creating content, Moderating/Verifying content, Translating content
 * Incentives – Most products offered intangible incentives mainly bucketed into the form of: Awards and ranking (badges), Personal pride and gratification (stats), or Unlocking features (access rights)
 * Reward incentives – promote badges or attainments of specific milestones (e.g., a badge for adding 50 citations)
 * Personalization/Customization – Most have at least one facet of personalization/customization. Most common customization is user input on surveys upon account creation or before a task, most common system-based personalization type is geolocalization
 * Visual design & layout – incentivizing features (stats, leaderboards, etc) and onboarding is visually rich compared to pared back, simple forms to complete short edits.
 * Guidance – Almost all products reviewed had at least basic guidance prior to task completion, most commonly introductory ‘tours’. In-context help was also provided in the form of instructional copy, tooltips, step-by-step flows,  as well as offering feedback mechanisms (ask questions, submit feedback)

Mockups
Our evolving designs can always be found in two sets of interactive mockups (use arrow keys to navigate): Those mockups contain explorations of all the difference parts of the user journey, which we have broken down into several parts:
 * Desktop
 * Mobile


 * 1) Gathering information from the newcomer: learning what we need in order to recommend relevant tasks.
 * 2) Feature discovery: the way the newcomer first encounters task recommendations.
 * 3) Task recommendations: the interface for filtering and choosing tasks.
 * 4) Guidance during editing: once the newcomer is doing a task, the guidance that helps them understand what to do.
 * 5) User feedback: ways in which the newcomer can indicate that they are not satisfied with the recommended task.
 * 6) Next edit: how we continue the user's momentum after the save an edit.

Below are some of the original draft design concepts as the team continues to refine our approach.

Desktop
Trong tuần 16/9/2019, chúng tôi đã sử dụng usertesting.com để tiến hành sáu bài kiểm tra đối với nguyên mẫu nhiệm vụ người dùng mới trên máy tính để bàn với những người dùng internet không tham gia vào các hoạt động của Wikimedia. Trong các bài kiểm tra này, những người trả lời sẽ thử các bản thử, nói lên những gì họ quan sát thấy và trả lời các câu hỏi về trải nghiệm. Các bạn có thể xem kết quả đầy đủ tại nhiệm vụ Phabricator này. Mục tiêu của cuộc kiểm tra này là:


 * 1) Đánh giá khả năng phát hiện của mô-đun nhiệm vụ cho người mới
 * 2) Xác định những cải tiến đối với khả năng sử dụng của mô-đun nhiệm vụ:
 * 3) Người dùng có hiểu cách để lựa chọn và xem lại các gợi ý bài viết?
 * 4) Người dùng có hiểu cách lọc theo mối quan tâm và độ khó nhiệm vụ?
 * 5) Họ có biết cách bắt đầu sửa đổi một bài viết gợi ý?
 * 6) Đánh giá phản ứng người dùng đối với các gợi ý và kì vọng về việc được hướng dẫn làm các nhiệm vụ.


 * Tóm tắt các phát hiện


 * Tất cả người dùng nghĩ rằng việc có được gợi ý dựa trên chủ đề mà họ quan tâm là một việc có lý và sáng tạo.
 * Tương tự, những độ khó nhiệm vụ khác nhau cũng được đón nhận một cách tích cực từ mọi người tham gia.
 * Khả năng sử dụng chung của mô-đun sửa đổi gợi ý là cực kỳ cao. Mọi người biết cách click để xem thêm bài viết, sử dụng bộ lọc để thay đổi chủ đề và mức độ nhiệm vụ, và biết cách click vào các thẻ để mở một gợi ý sửa đổi.
 * 4/6 người tham gia ban đầu không nhận ra rằng họ nên click vào "Xem sửa đổi gợi ý" như là một cách để giúp họ đạt được mục tiêu viết một bài viết. Đây có vẻ như là một lối suy nghĩ phổ biến khi người dùng tách bạch "sửa đổi" và "tạo trang mới", coi chúng là khác nhau.
 * Mô-đun bắt đầu rõ ràng là điểm khởi đầu cho mọi người tham gia. Hơn nữa nhiều người sẽ bị thu hút bởi nút "Xem các sửa đổi gợi ý" như là một cách để theo dõi tiến trình hoạt động trong mô-đun bắt đầu.
 * Người dùng hiểu rõ và có kì vọng rằng họ sẽ được cho xem các bài viết gợi ý sửa đổi dựa trên các hộp thoại giới thiệu để thêm chủ đề và giới thiệu các cấp độ nhiệm vụ.
 * Ai cũng có thể lựa chọn các chủ đề phổ biến và thêm chủ đề của chính họ một cách dễ dàng.
 * Ai cũng hiểu mục đích của mô-đun sửa đổi gợi ý.
 * Hai người bị nhầm lẫn/cho rằng họ không thể tạo bài viết mới cho đến khi hoàn thành các nhiệm vụ dễ và vừa.
 * 5 trên 6 người tham gia biết click vào nút bảng trợ giúp để tìm kiếm sự hướng dẫn sau khi đã bước vào chế độ sửa đổi.
 * Bốn người kì vọng rằng họ có thể liên lạc với người hướng dẫn của mình trong bảng trợ giúp.
 * Các mẹo nhiệm vụ thiếu mức độ hướng dẫn đầy đủ đối với một số người tham gia.


 * Các khuyến nghị


 * Cải thiện copy và nhiều hơn nữa về việc cho người dùng biết rằng tạo nội dung mới là một dạng sửa đổi.
 * Cập nhật mô-đun Ảnh hưởng như đã được thử nghiệm ở đây để giúp người dùng hiểu hơn về các sửa đổi gợi ý.
 * Cung cấp những trợ giúp khi đang sửa đổi thật tốt. Điều đó rất quan trọng đối với những người dùng đang thử sửa đổi.
 * Thêm một "checklist" để người dùng xem lại trong mẹo nhiệm vụ của bảng trợ giúp.
 * Cung cấp các ví dụ ngắn của những việc nên làm.
 * Chỉ cho người dùng biết họ không cần phải biên tập lại toàn bộ bài viết.
 * Bao gồm các kết quả lọc thời gian thực để giúp người dùng biết được các gợi ý có mối liên hệ với việc sửa đổi bài viết và khuyến khích việc sử dụng bộ lọc để tìm các bài viết phù hợp.

Điện thoại di động
Trong tuần 30/9/2019, chúng tôi sử dụng usertesting.com để thực hiện sáu cuộc thử nghiệm đối với nguyên mẫu nhiệm vụ người mới trên điện thoại di động. Có thể tìm thấy kết quả đầy đủ tại nhiệm vụ Phabricator này. Mục tiêu của cuộc thử nghiệm này cũng tương tự như với máy tính, nhưng với một nhiệm vụ bổ sung là để hiểu xem trải nghiệm trên điện thoại có thể khác với trên máy tính như thế nào. Những người dùng thử trên điện thoại được nhắc trước về tình huống dự định thêm một hình ảnh vào Wikipedia (trong khi đó người tham gia trên máy tính thì là với dự định tạo một bài viết mới).

Tóm tắt các phát hiện


 * Nhìn chung người dùng nhận thấy mô-đun bắt đầu (đã được thiết kế lại) đã trình bày rõ ràng các bước được hướng dẫn để bắt đầu.
 * Mô-đun extra "Sửa đổi gợi ý" bên dưới, dù không đặc biệt gây nhầm lẫn, thì vẫn không đến gần được với những gfi mà người dùng kì vọng sẽ giúp họ với nhiệm vụ thêm một hình ảnh.
 * Sửa đổi gợi ý khá là trực quan để sử dụng, người tham gia hiểu cách hoạt động của yếu tố khác nhau của nó (bộ lọc, xem thêm bài viết, vân vân). Tuy nhiên, người dùng không nhìn ra được giá trị của việc thực hiện các sửa đổi gợi ý ngoài việc học thêm hay buồn chán.
 * Một số người muốn muốn có nhiều chủ đề cụ thể hơn thay vì các chủ đề rộng đã được liệt kê.
 * Có các cấp độ khó chi tiết thì mang tính giáo dục nhưng lại có khả năng gây nản lỏng. Tất cả đều ngạc nhiên khi "thêm hình ảnh" được phân loại là khó và đã có những cấp độ khó chịu khác nhau về sự thật này.
 * Lọc theo mối quan tâm là một điểm cộng lớn.
 * Cho tới tận cuối bài kiểm tra có 3 người cho rằng sẽ có một kiểu "thẩm tra" hoặc yêu cầu nào đó đối với các nhiệm vụ dễ trước khi có thể chuyển sang nhiệm vụ Vừa/Khó.
 * Mọi người đều hiểu mục đích của Sửa đổi gợi ý là đưa ra những sửa đổi mà sẽ giúp người dùng học cách sửa đổi, và cũng nhấn mạnh rằng nó sẽ cho họ thấy rằng một số sửa đổi khó thực hiện hơn.
 * Mọi người dùng đều chật vật khi sử dụng những hướng dẫn mà chúng tôi cung cấp tại bảng hướng dẫn mà họ đang sửa đổi. Đây là một vấn đề lớn mà chúng tôi cần phải suy nghĩ kĩ về việc thiết kế trước khi chúng tôi bắt đầu xây dựng nó.

Các khuyến nghị


 * Yêu cầu thực hiện sửa đổi gợi ý thì nằm bên trong mô-đun bắt đầu chứ không có riêng thẻ.
 * Cải thiện copy và hình tượng giáo dục người dùng để truyền tải một cách tốt hơn rằng có một giá trị thế giới thực trong việc thử sửa đổi gợi ý ngoài việc học hỏi và rằng mức độ khó nhiệm vụ chỉ là một sự hướng dẫn và các nhiệm vụ có thể được thực hiện không theo thứ tự.
 * Thêm một overlay chuyên cho việc giới thiệu các lời giới thiệu đã được cá nhân hóa về sửa đổi gợi ý.
 * Bao gồm cả đếm kết quả lọc thời gian thực ở cả bộ lọc chủ đề và nhiệm vụ.
 * Bổ sung tìm kiếm chi tiết chủ đề mối quan tâm bởi người dùng.
 * Lặp lại khi một người dùng mở một gợi ý mà là một sửa đổi thật sự, có tác động lớn.
 * Cập nhật thiết kế của bảng trợ giúp bên trong nhiệm vụ để mọi nội dung giúp đỡ có thể dễ dàng tiếp cận được.

Version 1.1: topic matching
Past research and development shows that users are more likely to do recommended tasks if the tasks match their topical interests. SuggestBot uses an editor's past editing history to find similar articles, and those intelligent results are shown in this paper to be executed on more often than random results. The Content Translation tool also recommends articles based on a user's previous translation history, and those recommendations have increased the translation volume.

In looking at the usage of V1.0 of newcomer tasks, which does not contain topic matching, we see that there are users who navigate through many suggested articles, and end up clicking on none. There are also users who navigate through many, and end up editing only the ones they happen to find that belong to a certain topic, such as medicine. These are also good indicators that topics can be valuable to help newcomers find articles they want to edit.

Our challenge with newcomers is a "cold start problem", in that newcomers do not have any edit history to use when trying to find relevant articles for them to edit. We want to have an algorithm that says what the topic is of each article, and use that to filter the articles that have maintenance templates.

Algorithms


There are multiple approaches with which we might find articles that match a user's stated topic of interest. While our team identified many, we built prototypes for three methods and tested them:


 * morelike: assign a seed list of articles that represent each topic area (e.g. "Art" might be represented by the articles for "Painting", "Sculpture", "Dance", and "Weaving".) Use that seed list to find other articles that are similar to those in the seed list by using a similarity algorithm called "morelike".
 * free text: instead of choosing from a set list of topics, allow newcomers to type in any phrase they want to indicate a topic. Use regular Wikipedia search to surface articles relevant to that phrase.
 * ORES: is a machine learning service that – among other things – can return a predicted topic for any article.  Though this prediction service only works in English Wikipedia, there are ways to translate predictions from English to other wikis.

In this Phabricator task, we evaluated the three methods, and decided to proceed with the ORES model. The Growth team worked with the Scoring team to strengthen the model, and with the Search team to make the model predictions available to the newcomer tasks workflow. During the time that this work was happening, we deployed the somewhat worse-performing morelike algorithm, and switched to the ORES model about a month later.

The ORES model we use now offers 64 topics, and we chose to expose 39 of them to newcomers. The evaluation in four different languages showed that on average, 8.5 out of 10 suggestions for a given topic seem like good matches for that topic.

Design
In designing interfaces that allow newcomers to choose topics of interest, these are some of the considerations:

These mockups contain our current designs for this interface. You can navigate with your keyboard's arrow keys. Below are some images of the mockups:
 * How to make a long list of about 30 topics not overwhelming to the user?
 * How to handle multiple layers of topics (e.g. if "Science" has sub-topics of "Biology", "Chemistry", etc.)
 * Whether users can give feedback when a topic does not match what they selected?

Version 1.2: guidance
After newcomers have selected an article from the suggested edits module, they should receive guidance about how to click edit and complete the edit successfully. While it is exciting that some portion of newcomers are completing suggested edits without guidance, we're confident that by adding guidance, we will substantially increase how many newcomers edit.

We have decided to repurpose the help panel as the place to deliver this guidance. Reusing the help panel will allow us to build quickly. The guidance contains three phases:


 * 1) When the user has arrived on the article and before they click edit.
 * 2) After clicking edit and before saving an edit.
 * 3) After saving an edit.

Some of the ideas we are considering implementing include:


 * Guidance tailored to each type of edit, varying depending on whether the suggested edit is a copyedit, adding links, adding references, etc.
 * Reminder that an edit can be small, and that the user does not have to edit the whole article.
 * Step-by-step walkthrough that is like a checklist for completing the edit.
 * Highlighting the maintenance templates in the article so that the user can see why the article was suggested.
 * An indicator that encourages the user to click the edit button.
 * A place to put videos that demonstrate how to complete the edit.
 * Suggestions for additional edits after saving the initial edit.
 * Ability for the user to notify their mentor that they have done an edit, so the mentor can check their work and thank them.

During the last week of December 2019, we user tested desktop and mobile prototypes, which can be found below. We will post the user test results after assembling them.


 * Desktop prototype
 * Mobile prototype

Below are some images of the prototype:

Variant testing
After deploying the first version of newcomer tasks, we want to start testing different variants of the feature, so that we can improve it iteratively. Rather than just having one design of newcomer tasks, and seeing if newcomers are more productive with it than without it, we plan to test more than variant of newcomer tasks at a time, and compare them. We have compiled an exhaustive list of all the ideas of variants to test -- but we will only end up testing perhaps 10 per year, because of the effort and time it takes to build, test, and analyze.

In March, April, and May 2020, we'll be testing variants that aim to get more users into the newcomer tasks flow.

See this page for the list of variant tests and their results.

Lượt sử dụng
As of 2020-01-13, 10,835 distinct users have visited their homepage since the deployment of newcomer tasks on 2019-11-20. The tables below show how far into the newcomer tasks workflow those users progressed. We see that generally one sixth of users who visit their homepage interact with the suggested edits module. Of those, most of them click a task. Most surprisingly, we see many users clicking on tasks and even going all the way through saving an edit (166 users saving about 400 edits). This is surprising because the feature does not yet contain topic matching (which would make the tasks more appealing to users) or guidance (which would help them understand how to save edits).

The second table shows percentages of the raw numbers in the first table.

Chất lượng sửa đổi
The Growth team's ambassadors have gone through over 300 edits saved by newcomers and marked whether or not each edit was productive (meaning that it improved the article). We are happy to see that about 75% of the edits are productive. This is similar to the baseline rate for newcomer edits, and we're glad that this feature has not encouraged vandalism. Most of the edits are copyedits, with many also adding links, and some even adding content and references. About a third of users who make one suggested edits go on to make additional suggested edits, and many also go on to make edits that are not suggested by the feature, which is behavior we are happy to see.

The high-quality edits we're seeing encourage us to improve the feature so that more newcomers begin and complete its workflow.