Growth/Personalized first day/Structured tasks/ar

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

الوضع الحالي

 * 2020-05-01: التخطيط والتوثيق للملاحظات الأولية
 * 2020-05-17: البدء في النقاش داخل المجتمع
 * 2020-05-29: المجسّمات الأوّلية
 * 2020-08-24: أسبوع الاجتماعات التخطيطية

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

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

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

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


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

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

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


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

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

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

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

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

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

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

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



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



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

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


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

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

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


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

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


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

Community discussion
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.

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.

August 2020 mockups
Our team discussed the wireframes from the previous section. We considered what would be best for the newcomers, taking into account the preferences expressed by community members, and thinking about engineering constraints. In August 2020, we took the next step of creating mockups, meant to show in more detail what the feature might look like. These mockups (or similar versions) will be used in team discussions, community discussions, and user tests. One of the most important things we thought about with these mockups is the concern we heard consistently from community members during the discussion: structured tasks may be a good way to introduce newcomers to editing, but we also want to make sure they can find and use the traditional editing interfaces if they are interested.We have mockups for two different design concepts. We're not necessarily aiming to choose one design concept or the other. Rather, the two concepts are meant to demonstrate different approaches. Our final designs may contain the best elements from both concepts:

Please note that the focus in this set of mockups is on the user flow and experience, not on the words and language. Our team will go through a process to determine the best way to write the words in the feature and to explain to the user whether a link should be added.To view these design concepts, we recommend viewing the full set of slides below. Essential questions
 * Concept A: the structured task edit takes place in the Visual Editor. The user can see the whole article, and switch out of "recommendation mode" into source or visual editor mode.  Less focused on adding the links, but easier access to the visual and source editors.
 * Concept B: the structured task edit takes place in its own new area. The user is shown only the paragraph of the article that needs their attention, and can go edit the article if they choose.  Fewer distractions from adding links, but more distant access to the visual and source editors.

In discussing these designs, our team is focusing on a set of essential questions that we wanted to answer:


 * 1) Should structured tasks have its own home/queue or should it be in the same place as ‘classic’ maintenance template tasks?
 * 2) Should the edit happen at the article (more context)?  Or in a dedicated experience for this type of edit (more focus, but bigger jump to go use the editor)?
 * 3) How could we make it possible to discover and do structured tasks both (a) from the homepage and (b) from the organic browsing experience?
 * 4) Should we initially show the whole article and all its suggestions?  Or highlight only one link at a time in an article excerpt?
 * 5) What if someone wants to edit the link target or text?  Should we prevent it or let them go to a standard editor?  Is this the opportunity to teach them about the visual editor?
 * 6) Should giving feedback about the machine recommendation be a focal point? (e.g. "Why should this not link?")
 * 7) We know it’s essential for us to support newcomers discovering traditional editing tools. But when do we do that? Do we do it during the structured task experience with reminders that the user can go to the editor? Or periodically at completion milestones, like after they finish a certain number of structured tasks?
 * 8) Is "bot" the right term here? What are some other options? "Algorithm", "Computer", "Auto-", "Machine", etc.?"   What might better help convey that machine recommendations are fallible and the importance of human input?