Growth/Personalized first day/Structured tasks/ar

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

الوضع الحالي

 * 2020-05-01: التخطيط والتوثيق للملاحظات الأولية

ملخص
قام فريق النمو بنشر مشروع "مهمات الوافدين الجدد" في نوفمبر 2019، والذي خوّل للوافدين الجدد حزمة من المقالات المقترحة على لوحة المستخدم للوافدين الجدد الخاصة بهم قصد تعديلها. حتّى تاريخ 20 أبريل 2020، كان مصدر المقالات المقترحة حصريّا من المقالات التي تحمل قوالب الصيانة الموضوعة من قبل المستخدمين المخضرمين، والتي لا توجّه الوافدين الجدد إلى الكلمات أو الجمل أو الفقرات التي تحتاج إلى تدخّل. على الرّغم من هذا النقص في الوجهة، نحن سعداء بملاحظة أنّ الوافدين الجدد قد قاموا بتعديلات مقترحة بنّاءة.

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

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

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


 * 1) ابحثوا عن المقالة المنشودة.
 * 2) اكتشفوا ما إذا كانت المعلومات التي تريدون إضافتها موجودة بالفعل في المقالة.
 * 3) اختاروا القسم الذي تريدون إضافة الجملة فيه.
 * 4) اضغطوا للبدء في التعديل.
 * 5) اكتبوا الجملة في المكان الصحيح.
 * 6) اضغطوا على زر الاقتباس.
 * 7) ارجعوا إلى المصدر للحصول على الرابط أو معلومة الاقتباس.
 * 8) قوموا بملء ثم بحفظ نموذج الاقتباس.
 * 9) اضغطوا لنشر التعديل.
 * 10) قوموا بملء ثم تعديل الملخص.
 * 11) انشروا.

لا يعرف الوافدون الجدد الذين ينظرون إلى محرر مرئي أو نص الويكي لأول مرة ما هي تلك الخطوات، أو الترتيب الذي يجب أن يقوموا به، أو الأزرار التي يجب النقر عليها لتحقيقها. وبعبارة أخرى، فإن تجربتهم ليست "مهيكلة". قد يغلبهم الأمر ويغادرون. أو قد يستخدمون التجربة والخطأ، ويخطئون، ويحصلون على ردود فعل سلبية من المحررين ذوي الخبرة. هذا هو ما يدور حوله هذا المشروع: كيف يمكننا مساعدة الوافدين الجدد على تجاوز عمليات سير العمل هذه بالترتيب الصحيح؟

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


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

في آخر المستجدّات، تعمل فكرة "المهام المهيكلة" جيّدا في تطبيق ويكيبيديا على الأندرويد وفي أداة ترجمة المحتوى. نحن نستلهم من عملهم.

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

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

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

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

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

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



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



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

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


 * فقط حوالي 25% من الوافدين الجدد الذين يضغطون على مقالة مقترحة يقومون فعليا بتعديلها.
 * فقط حوالي 25% من الذين يقومون بتعديل مقترح يعاودون القيام بتعديلٍ مقترحٍ آخر.
 * هنالك قلّة من الوافدين الجدد الذين ينجحون فعليا في التعديلات المقترحة، يقومون بالعشرات منها يوميّا. يظهر هذا الطاقة الكامنة في الوافدين الجدد للقيام بالكثير من أعمال الويكي.
 * في اختبارات المستخدمين الحيّة، عندما يطلب من الوافدين الجدد من القيام بأعمال نسخ التحرير على مقالة ما أو إضافة وصلات إلى مقالة أخرى، يريدون في كثير من الأحيان معرفة دقيقة ماهي الجملة أو العبارة التي تتطلّب تدخّلهم. بعبارة أخرى، محاولة تعديل كامل المقالة/الصفحة أمر مفتوح جدّا.

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

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


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

مخاوف وسلبيات متعلقة بالمهام المهيكلة
عندما نضيف للمستخدمين طرق جديدة لتعديل ويكيبيديا، يمكن للعديد من الأمور أن تحيد:


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

Types of tasks
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. The table below contains that short list, ranked in a potential priority order.

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.

Design
While the "structured task sketch" section above contains some quick initial sketches to demonstrate the idea behind structured tasks, this section contains our current design thinking. To look into the full set of thinking around designs for the "add a link" structured task, , which contains background, user stories, and initial design concepts.

Comparative review
When we design a feature, we look into similar features in other software platforms outside of the Wikimedia world. These are some highlights from comparative reviews done in preparation for Android’s suggested edits feature, which remain relevant for our project.


 * Task types – are divided into five main types: Creating, Rating, Translating,  Verifying content created by others (human or machine), and Fixing content created by others.
 * Visual design & layout – incentivizing features (stats, leaderboards, etc) and onboarding is often very visually rich, compared to pared back, simple forms to complete short edits. Gratifying animations often compensate for lack of actual reward.
 * Incentives – Most products offered intangible incentives grouped into: Awards and ranking (badges) for achieving set milestones, Personal pride and gratification (stats), or Unlocking features (access rights)
 * Users motivations – those with more altruistic motivations (e.g., help others learn) are more likely to be incentivized by intangible incentives than those with self-interested motivations (e.g., career/financial benefits)
 * Personalization/Customization – was used in some way on most apps reviewed. The most common customization was via surveys during account creation or before a task; and geolocalization used for system-based personalization.
 * 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)

Initial wireframes
After organizing our thoughts and doing background research, the first visuals in the design process are "wireframes". These are simply meant to experiment and display some of the ideas we think could work well in a structured task workflow. For full context around these wireframes, see the.