Growth/Personalized first day/Newcomer tasks/ar

تشرح هذه الصفحة عمل فريق النمو في مشروع "مهمات الوافد الجديد"، وهو يندرج ضمن المبادرة الأشمل "اليوم الأول المعدل". تحتوي الصفحة على أهداف وخطط وقرارات ونتائج. سيتم نشر معظم التحديثات التدريجية الجاري عليها العمل في الصفحة العامة لـتحديثات فريق النمو، مع نشر بعض التحديثات الكبرى أو المخصصة هنا.

بالامكان الاطلاع بإيجاز على ما يقوم الفريق بانشائه من خلال هذه النماذج التجريبية (استعمال الأسهم للتنقل):


 * كمبيوتر مكتبي
 * هاتف جوال
 * مطابقة المواضيع

بدأ التصميم والتخطيط لهذا المشروع في 24-07-2019 تم نشر النسخة الأولى في أربع ويكيبيديات يوم 20-11-2019.

الوضع الحالي

 * 2019-07-24: الاجتماع الأول للقريق لمناقشة مهام الوافد الجديد
 * 2019-08-27: اجتماع الفريق لتعديد ومناقشة التصميمات.
 * 2019-09-09: إنشاء مهام فبريكتور للأعمال الهندسية
 * 2019-09-23: انتهى اختبار نسخة سطح المكتب
 * 2019-09-30: انتهاء اختبارات مستخدمي الهاتف الجوال
 * 2019-11-20: نسخة 1.0 منشورة في الويكيبيديات التشيكية والكورية والعربية والفيتنامية
 * 2019-12-13: نسخة تجريبية أولى ("مبادرة") منشورة على الويكيبيديات التشيكية والكورية والعربية والفيتنامية
 * 2020-01-14: testing the addition of topic matching, to be deployed the week of 2020-01-20.
 * التالي: deploying V1.1. (topic matching)

ملخص
نعتقد أن للوافدين الجدد الحق في كل الفرص للنجاح عندما يصلون لأول مرة إلى الويكي. لكن، وبصفة متكررة، يحاول الوافدون الجدد القيام بأعمال تعدّ صعبة، أو لا يجدون مهمة يحبون القيام بها، أو لا يجدون أفكارا تبقيهم مهتمين ومعنيين بالمشروع بعد تعديلهم الأول. مما يفضي إلى هجر الكثير منهم وعدم عودتهم. هنالك محاولات ناجحة في الماضي في توكيل مهمات للمحرّرين، لذلك نعتقد أن لوحة المستخدم للوافد الجديد مكان واعد لتوصية المهام المثلى للوافدين الجدد.

سنحتاج إلى مراعاة بعض الأشياء:
 * العديد من الوافدين الجدد يحملون أمورا محددة في أذهانهم يريدون القيام بها، كاضافة صورة إلى مقالة محددة. لا نريد أن نعترض طريقهم في تحقيق مبتغاهم.
 * ينشئ الوافدون الجدد مهاراتهم مع مرور الوقت عند يرتقون من المهمات السهلة إلى الأصعب.
 * عندما ينجح الوافدون الجدد في وقت مبكر، يصبحون أكثر تحمسًا لمواصلة التحرير.

بأخذ عين الاعتبار هذه الأشياء، نريد توصيات للمهمات للوافدين الجدد التي ستظهر في المكان والوقت المناسبين، والتي ستعلمهم مهارات سيحتاجونها للنجاح، والتي تتماشى مع اهتماماتهم.

لدينا أداة قيّمة وهي الاستطلاع الترحيبي، لتساعد على تحديد المهمات للوافدين الجدد، والتي تم انشاؤها تحديدا لهذا الغرض: تخصيص تجربة الوافد الجديد. سنستخدم المعلومات الاختيارية المقدمة من قبل الوافدين الجدد التي تخص أهدافهم واهتماماتهم لنتمكن من توصية المهام التي تناسبهم.

من أكبر التحديات سيكون كيف نجمّع المهمات التي ستناسب الوافدين الجدد. هنالك العديد من المصادر الموجودة، كقوالب الصيانة التي تدعو إلى العمل على المقالات، كتوصيات أداة ترجمة المحتوى، أو كاقتراحات أدوات مثل البحت عن مصادر. السؤال الذي سيطرح هو أيّ من هذه الخيارات سيساعد الوافدين الجدد في تحقيق أهدافهم.

في البداية، سنركز على استخدام لوحة المستخدم للوافد الجديد كمكان لتوصية المهمات، لكن على المدى الطويل، يمكن أن نتخيّل إنشاء ميزات في تجربة التحرير للتوصية ولمساعدة الوافدين الجدد في إنهاء المهمات الموصاة إليهم.

علي المدى الطويل كذلك، سنفكر في طريقة ما لدمج توصية المهمات مع أجزاء أخرى من تجربة المستخدم الجديد، كـوحدة التأثير على الصفحة الرئيسية، أو على لوحة المساعدة.

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
خلال أسبوع السادس عشر من سبتمبر 2019، استخدمنا usertesting.com للقيام بـ 6 اختبارات على نسخة سطح المكتب لأنموذج مهمات الوافد الجديد بالاشتراك مع مستخدمي انترنت من خارج حركة ويكيميديا. في هاته الاختبارات، تم الطلب من المستجوَبين تجربة الأنموذج، التعليق على ما شاهدوه، والاجابة عن أسئلة تخص تجربتهم. يمكن الإطلاع على النتائج كاملة في هاته المهمة على فبريكاتور. أهداف هاته الاختبارات كانت:


 * 1) قيس قابلية استكشاف وحدة مهمات الوافد الجديد
 * 2) تحديد ما يجب تحسينه من أجل استعمال أسهل لوحدة المهمات:
 * 3) هل يفهم المستخدمون كيف يختارون وكيف يراجعون المقالات المقترحة؟
 * 4) هل يفهم المستخدمون كيف يضعون مرشحا حسب الاهتمامات وصعوبة المهمات؟
 * 5) هل يعلمون كيف يبدؤون المساهمة في مقالة مقترحة؟
 * 6) قياس ردود فعل المستخدم ازاء المقترحات والانتظارات حول التوجيهات خلال المهمة.


 * ملخص الموجودات


 * اعتقد جميع المستخدمين أنه من المنطقي ومن البديهي الحصول على اقتراحات بناءً على موضوعاتهم التي يهتمون بها.
 * على نفس النحو، مختلف مستويات الصعوبات تم قبولها بشكل ايجابي من قبل جميع المشاركين.
 * في مجملها، كانت قابلية الاستخدام لوحدة التعديلات المقترحة عالية للغاية. عرف الأشخاص كيفية النقر لعرض المزيد من المقالات، واستخدام المرشح لتغيير الموضوعات ومستويات المهام، وعرفوا النقر فوق البطاقة لفتح اقتراح للتحرير.
 * أربعة من ستة من المشاركين لم يدركوا في أول الأمر أن عليهم أن ينقروا على "انظر على التعديلات المقترحة" كطريقة لمساعدتهم ليتمكنوا من تحقيق هدفهم في كتابة مقالة جديدة. كان يبدو هذا نموذجا تفكيريا شائعا من خلاله ميّز المستخدمون "التعديل" كشكل مختلف عن "انشاء صفحة جديدة".
 * وحدة البدء هي جليا نقطة البداية الأولى لجميع المستخدمين. علاوة على ذلك، تم استدراج الكثير منهم إلى زر "انظر إلى التعديلات المقترحة" كوسيلة لمتابعة تقدم الأنشطة في وحدة البدء.
 * كان لدى المستخدمين فهم وتوقع واضحين بأنه ستُعرض عليهم مقالات مقترحة للتحرير بناءً على الحوار الذي تم في البداية لإضافة الموضوعات وتحديد مستويات صعوبة المهام.
 * كل واحد كانت له القدرة على انتقاء المواضيع ذات الشعبية واضافة المواضيع الخاصة بهم بسهولة.
 * فهم الجميع المغزى من وحدة التعديلات المقترحة.
 * شخصان كانا مرتبكين/افترضا أنهما غير قادرين على انشاء مقالة جديدة ريثما ينهيا المهمات السهلة والمتوسطة الصعوبة.
 * 5 أو 6 مشاركين تعلموا النقر على وحدة المساعدة لتوجيههم حينما كانوا داخل صفحة التعديل.
 * أربعة أشخاص توقعوا امكاتية الاتصال بمرشديهم من داخل وحدة المساعدة.
 * افتقرت نصائح المهمة إلى مستوى كافٍ من التوجيه لبعض المشاركين.


 * التوصيات


 * تحسين الكتابة وغيرها من تعليم المستخدم أن إنشاء محتوى جديد هو شكل من أشكال التحرير.
 * جعل تحديثات لوحدة التأثير مثلما جرت تجربتها هنا لمساعدة المستخدم لاستيعاب المهمات المقترحة.
 * توفير مساعدة ذات جودة أثناء التعديل. إنه من الهام جدا أن يجرب المستخدمون التعديل.
 * تضمين "قائمة مراجعة" ليتمكن المستخدمون من الرجوع إليها عبر النصائح المهمة من لوحة المساعدة.
 * تضمين أمثلة قصيرة لما يجب عمله.
 * إشارة للمستخدمين أنه لا يجب عليهم النسخ والتعديل لكامل مقالة.
 * إدراج مرشح آني لنتائج البحث سيساعد المستخدمين في وصل اقترحات مثل تعديل مقالات وتشجيع استعمال المرشح لإيجاد المقالات المترابطة.

هاتف جوال
خلال أسبوع الـ30 من سبتمبر 2019، استعملنا usertesting.com للقيام بستة اختبارات لانموذج مبدئي لمهمات الوافد الجديد على الجهاز المحمول. النتائج الكامل يمكن الاطلاع عليها في هاته المهمة على فبريكاتور. الهدف من هذا الاختبار كان هو نفسه هدف اختبار نسخة سطح المكتب، لكن مع زيادة هدف يتمثل في فهم مدى ستكون التجربة على الهاتف المحمول مختلفة عن تلك على سطح المكتب. تمت مطالبة مختبري الهاتف المحمول بسيناريو إضافة صورة إلى ويكيبيديا (في حين مختبري سطح المكتب تمت مطالبتهم بإنشاء مقالة جديدة).

ملخص الموجودات


 * وجد مجمل المستخدمين أن وحدة البدء (المعاد تصميمها) وضعت بوضوح الخطوات الإرشادية للبدء.
 * وحدة "التعديلات المقترحة" الإضافية أدناه، على الرغم من أنها ليست مربكة بشكل خاص، لم تكن بعد، المكان المتوقع أن يذهب إليه المستخدمون لمساعدتهم في مهمة إضافة صورة.
 * كانت التعديلات المقترحة سهلة الاستخدام، حيث فهم المشاركون كيفية عمل عناصرها المختلفة (الترشيح، رؤية المزيد من المقالات، إلخ). ومع ذلك، لا يرى المستخدمون قيمة إجراء تعديلات مقترحة تتجاوز التعلم أو الملل.
 * أراد العديد من الأشخاص الحصول على المزيد من الموضوعات الدقيقة أكثر من الموضوعات العامة المدرجة.
 * إن وجود معلومات مفصّلة عن مستويات الصعوبة كان تربويا، لكن يحتمل أن يكون مثبطًا. فوجئ الجميع بـأن "إضافة صور" تم تصنيفها على أنها صعبة، وبدرجات متفاوتة من الإحباط بشأن هذه الحقيقة.
 * الترشيحات على ضوء الاهتمامات هو ورقة رابحة.
 * افترض 3 أشخاص في نهاية الاختبار وجود بعض "التحقق" أو شرط للقيام ببعض المهام السهلة قبل أن يتم إنجاز المهام المتوسطة / الصعبة
 * أدرك الجميع أن الغرض من التعديلات المقترحة هو إعطاء تعديلات من شأنها أن يتعلم المستخدمون عبرها التحرير، ويؤكدون أيضًا أنها أظهرت لهم أن بعض التعديلات كانت أكثر صعوبة في انجازها.
 * عمل جاهدا جميع المستخدمين لاستخدام الإرشادات التي قدمناها من خلال لوحة المساعدة أثناء التحرير. هذا مجال رئيسي نحتاج إلى التفكير مليّا في التصميم قبل البدء في إنشائه.

التوصيات


 * التعديلات المقترحة هي دعوة إلى العمل داخل وحدة البداية، وليست بطاقتها الخاصة.
 * تحسين تحرير المستخدم تثقيفه بشكل أفضل عبر اقناعه أن هناك قيمة حقيقية في محاولة إجراء تعديلات مقترحة تتجاوز التعلم، وأن صعوبة المهمة هي دليل فقط ويمكن تجريب المهام خارج الترتيب.
 * اضافة على، وجه الخصوص، تراكب لتقديم مقدمة مخصصة إلى التعديلات المقترحة.
 * بما في ذلك التعداد الآني للنتائج التي تمت ترشيحها عبر كل من مرشحات المهمات مرشحات المواضيع.
 * دمج المزيد من البحث الدقيق حسب موضوعات الاهتمام من قبل المستخدمين.
 * تكرير عندما يفتح المستخدم اقتراحًا لمهمة، تكون حقيقة تعديلا فعالا.
 * تطوير تصميم لوحة المساعدة في المهمة بحيث يمكن الوصول إلى جميع محتويات التعليمات المتاحة بوضوح.

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: ORES is a machine learning service that can return a predicted topic for any article. Though it 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 will work with the Scoring team to strengthen the model, and with the Search team to make the model predictions available to the newcomer tasks workflow. This work will take several weeks, and in the meantime, we will deploy with the somewhat worse-performing morelike algorithm, and switch to the ORES model about a month later.

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


 * 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?

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:

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. Below are some of the most important ones variants to test.

Usage counts
As of 2019-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.

Edit quality
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.