Growth/Personalized first day/Structured tasks/Add an image/bn

এই পাতায় "একটি ছবি যুক্ত করুন" কাঠামোবদ্ধ কাজটির বিবরণ লিপিবদ্ধ রয়েছে। এটি এক ধরনের কাঠামোবদ্ধ কাজ যা নবাগতদের নীড়পাতার মাধ্যমে গ্রোথ দল প্রয়োগ করবে। অ্যান্ড্রয়েড দলও উইকিপিডিয়া অ্যান্ড্রয়েড অ্যাপের জন্য অনুরূপ কিছুর ক্ষুদ্রতর সংস্করণ তৈরি করতে চাইছে, যার মূল কার্যপদ্ধতি একইরকম হবে। এছাড়া কাঠামোবদ্ধ উপাত্ত দল অনুরূপ কিছু ভাবনার প্রাথমিক অবস্থায় আছেন, যার লক্ষ্য আরো অভিজ্ঞ উইকিপিডিয়ান এবং যা কমন্সের কাঠামোবদ্ধ উপাত্তভিত্তিক হবে। এই পাতায় বর্ণিত আলোচনা ও হালনাগাদকৃত তথ্য সকল দলের কাজের জন্য প্রাসঙ্গিক।

এই পাতায় প্রধান প্রধান সামগ্রী, নকশা, উন্মুক্ত প্রশ্নাবলী এবং সিদ্ধান্তসমূহ লিপিবদ্ধ রয়েছে। To try out the experience, |please open up this interactive prototype on your mobile device.

ধারাবাহিক উন্নতির হালনাগাদকৃত তথ্য সাধারণত গ্রোথ দলের হালনাগাদকৃত পাতায় দেয়া হবে। বৃহত্তর এবং বিস্তারিত তথ্য এখানে উল্লেখ করা হবে।

বর্তমান অবস্থা

 * 2020-06-22: ছবি সুপারিশ করার জন্য একটি সহজ অ্যালগোরিদম তৈরি করার পরিকল্পনাগুলো ভেবে দেখা
 * 2020-09-08: ইংরেজি, ফরাসি, আরবি, কোরিয়, চেক এবং ভিয়েতনামিয় ভাষায় একটি প্রাথমিক অবস্থার ম্যাচিং অ্যালগোরিদম পরীক্ষিত হয়েছে।
 * 2020-09-30: ইংরেজি, ফরাসি, আরবি, কোরিয়, চেক এবং ভিয়েতনামিয় ভাষায় দ্বিতীয় দফায় একটি ম্যাচিং অ্যালগোরিদম পরীক্ষিত হয়েছে।
 * 2020-10-26: ছবি সুপারিশকরণ সেবা চালুর সম্ভাব্যতা নিয়ে অভ্যন্তরীণ প্রকৌশলগত আলোচনা
 * 2020-12-15: ব্যবহারকারী পরীক্ষার প্রাথমিক ধাপগুলোর মাধ্যমে যাচাই করা হয় নবাগতরা এই কাজে সফল হবেন কীনা
 * 2021-01-20: প্ল্যাটফর্ম প্রকৌশল দল ছবির পরামর্শের প্রুফ-অব-কনসেপ্ট এপিআই-এর কাজ নিয়ে এগোচ্ছে।
 * 2021-01-21: অ্যান্ড্রয়েড দল শিখন উদ্দেশ্যে যতটুক প্রয়োজন, ততটুক টেকসই সংস্করণ নিয়ে কাজ শুরু করেছে।
 * 2021-01-28: ব্যবহারকারী পরীক্ষার ফলাফল প্রকাশ
 * 2021-02-04: সম্প্রদায় আলোচনা এবং সংশ্লিষ্ট পরিসংখ্যানের সংক্ষিপ্ত তথ্যাবলী প্রকাশ
 * 2021-05-07: ব্যবহারকারীদের জন্য অ্যান্ড্রয়েড এমভিপি-এর মুক্তি
 * 2021-08-06: posted results from Android and mockups for Iteration 1
 * 2021-08-17: backend work begins on Iteration 1
 * 2021-08-23: posted interactive prototypes and began user tests in English and Spanish
 * 2021-10-07: posted findings from user tests and final designs based on the findings
 * 2021-11-19: ambassador begin testing the feature in their production Wikipedias
 * 2021-11-22: image suggestion dataset is refreshed in advance of releasing Iteration 1 to users
 * 2021-11-29: Iteration 1 deployed to 40% of mobile accounts on Arabic, Czech, and Bengali Wikipedias.
 * 2021-12-22: posted leading indicators
 * 2022-01-28: desktop version deployed for 40% of new accounts on Arabic, Czech, and Bengali Wikipedias.
 * 2022-02-16: Spanish Wikipedia newcomers start getting "add an image"
 * পরবর্তী: expand to next set of wikis and analyze conversion funnel in detail

সারাংশ
কাঠামোবদ্ধ কাজের উদ্দেশ্য হল সম্পাদনার কাজগুলোকে ভেঙে ছোটখাটো আকারের ধারাবাহিক কাজ তৈরি করা। এর মাধ্যমে নবাগতরা আরো সহজভাবে কাজটি বুঝতে পারবে, বিশেষ করে মোবাইল ব্যবহারকারীদের ক্ষেত্রে। গ্রোথ দল বিশ্বাস করে যে সম্পাদনার পরিবেশে নতুন ধরনের কাজের গতিপথ তৈরির ফলে আরো অনেক নতুন মানুষ উইকিপিডিয়ায় কাজ করতে শুরু করবেন। এদের অনেকে হয়তো উল্লেখযোগ্য পরিমাণে কাজ করবে এবং তাদের সম্প্রদায়ের সাথে প্রত্যক্ষভাবে যুক্ত হয়ে যাবেন। সম্প্রদায়ের সাথে কাঠামোবদ্ধ কাজের পরিকল্পনা নিয়ে আলোচনার পরে, আমরা সিদ্ধান্ত নিয়েছি প্রথম কাঠামোবদ্ধ কাজ তৈরি করব: "সংযোগ করুন"।

After deploying "add a link" in May 2021, we collected initial data showing that the task was engaging to newcomers and that they were making edits with low revert rates -- indicating that structured tasks seem valuable for the newcomer experience and the wikis.

যখন আমরা প্রথম কাজটি তৈরি করছি, তখনই আমরা ভাবছিলাম পরের কাঠামোবদ্ধ কাজটি কী হতে পারে। আমরা চিন্তা করেছি যে ছবি যুক্ত করা নতুনদের জন্য একটা উপযুক্ত কাজ হবে। এর উদ্দেশ্য হল একটি সহজ অ্যালগোরিদমের মাধ্যমে কমন্স থেকে ছবি সুপারিশ করা হবে সেইসব নিবন্ধের জন্য, যেখানে কোনো ছবি নেই। প্রাথমিকভাবে এটা কেবল উইকিউপাত্তে বিদ্যমান সংযোগগুলো নিয়েই কাজ করবে, এবং নবাগতরা ঠিক করবেন যে ছবিটি ঐ নিবন্ধে যুক্ত করা প্রয়োজন আছে নাকি নেই।

আমরা জানি যে এটি কীভাবে কাজ করবে তা নিয়ে বিভিন্ন উন্মুক্ত প্রশ্ন রয়েছে। অনেক কারণ থাকতে পারে যার কারণে এটা সঠিকভাবে কাজ করবে না। এ জন্য আমরা বিভিন্ন সম্প্রদায়ের কাছ থেকে আলোচনার মাধ্যমে জানতে চাইছি আমরা কীভাবে এগোতে পারি।

ছবিই কেন?
উল্লেখযোগ্য অবদান অনুসন্ধানের জন্য

আমরা যখন সম্প্রদায়ে সদস্যদের সাথে প্রথম কাঠামোবদ্ধ কাজ নিয়ে আলোচনা করছিলাম, তখন অনেকেই জানিয়েছিলেন যে উইকিসংযোগ করাটা উঁচু ধরনের সম্পাদনা নয়। তারা জানিয়েছিলেন কীভাবে নবাগতরা উল্লেখযোগ্য অবদান করতে পারেন। একটি প্রস্তাবনা ছিল ছবিবিষয়ক। উইকিমিডিয়া কমন্সে প্রায় সাড়ে ছয় কোটিরও অধিক সংখ্যক ছবি আছে। কিন্তু বিভিন্ন ভাষার উইকিপিডিয়ার ৫০% নিবন্ধে কোনো ছবি নেই। আমরা বিশ্বাস করি কমন্স থেকে নেয়া অনেক ছবির মাধ্যমে উইকিপিডিয়ায় নিবন্ধগুলো আরো তাৎপর্যপূর্ণ হয়ে উঠবে।

নবাগতদের আগ্রহ

আমরা জানি যে উইকিপিডিয়ায় ছবি যুক্ত করার ব্যাপারে অনেক নবাগতই আগ্রহী। নবাগতরা যখন স্বাগত জরিপে অংশ নেন, তখন কেন অ্যাকাউন্ট তৈরি করছেন প্রশ্নের জবাবে উল্লেখযোগ্য সংখ্যক উত্তর দেন "ছবি যুক্ত করার জন্য"। আমরা সাহায্য প্যানেলের প্রশ্নের ক্ষেত্রেও দেখেছি কীভাবে ছবি যুক্ত করা যায় একটা নিয়মিত প্রশ্ন, যা আমরা যে সকল উইকির সাথে কাজ করেছি তার প্রত্যেক ক্ষেত্রেই লক্ষ্য করা গেছে। তবে অনেক নবাগতই প্রকৃতপক্ষে তাদের নিজেদের তোলা ছবি যুক্ত করতে চান, তবে এ থেকে এটা সুস্পষ্ট যে ছবি যোগ করার ব্যাপারটা আগ্রহোদ্দীপক এবং আকাঙ্ক্ষিত। এটা স্বাভাবিক, ছবি যোগ করার ব্যাপারটা নবাগতদের অংশ নেয়া ফেসবুক, ইনস্টাগ্রামের মত অন্যান্য প্ল্যাটফর্মের অনুরূপ।

ছবি নিয়ে কাজ করার ক্ষেত্রে সমস্যা

ছবির ব্যাপারে সাহায্য প্যানেলের বিভিন্ন প্রশ্নের মাধ্যমে বুঝতে পারা যায় যে নিবন্ধে ছবি যোগের পদ্ধতিটা বেশ কঠিন। নবাগতদের উইকিপিডিয়া ও কমন্সের পার্থক্য বুঝতে হয়, কপিরাইট সম্পর্কে জানতে হয়, এবং সঠিকভাবে ছবি বসানো ও শিরোনাম দেয়ার ব্যাপারগুলো বুঝতে হয়। ছবি নেই এমন কোনো নিবন্ধে কমন্স থেকে বেছে ছবি যোগ করার জন্য কিছুটা দক্ষতার প্রয়োজন হয়, এবং এক্ষেত্রে উইকিউপাত্ত ও বিষয়শ্রেণী সংক্রান্ত জ্ঞান কাজে লাগে।

"উইকিপিডিয়ার নিবন্ধে ছবি চাই" ক্যাম্পেইনের সাফল্য

উইকিপিডিয়ার নিবন্ধে ছবি যোগ করুন (WPWP) ক্যাম্পেইন অসাধারণভাবে সাফল্যমণ্ডিত হয়। ৬০০ জন ব্যবহারকারী ৮৫,০০০ পাতায় ছবি যোগ করে। তারা কিছু সম্প্রদায় সরঞ্জাম ব্যবহার করে কাজটি করতেন। এই সরঞ্জাম ছবিহীন নিবন্ধগুলো তুলে ধরতো এবং উইকিউপাত্তের মাধ্যমে ছবি সুপারিশ করতো। কীভাবে নবাগতদের সহায়তা করা যায়, সে ব্যাপারে গুরুত্বপূর্ণ অনেক কিছু শেখা বাকি থাকলেও এর মাধ্যমে আমরা আত্মবিশ্বাসী হয়েছি যে ব্যবহারকারীরা ছবি যোগ করার ক্ষেত্রে আগ্রহী এবং এক্ষেত্রে তারা সরঞ্জামের সহায়তা নিতে পারেন।

সবকিছুকে একত্রীত করে

সব তথ্যাবলীকে একত্রীত করে আমরা ভেবে দেখেছি যে যদি কাঠামোবদ্ধ কাজ হিসেবে "একটি ছবি যুক্ত করুন" যুক্ত করা হয়, তাহলে এটা উইকিপিডিয়ার জন্য যেমন সৃজনশীল হবে তেমনি নবাগতদের জন্যও চিত্তাকর্ষক হবে।

পরিকল্পনা যাচাই
'' From June 2020 through July 2021, the Growth team worked on community discussions, background research, evaluations, and proof-of-concepts around the "add an image" task. This led to the decision to start building our first iteration in August 2021 (see Iteration 1). This section contains all that background work leading up to Iteration 1. ''

অ্যালগোরিদম
কাঠামোবদ্ধ কাজ হিসেবে ছবি যোগ করার বৈশিষ্ট্যটি চালুর ক্ষেত্রে আমাদের সক্ষমতা নির্ভর করে অ্যালগোরিদমের উপরে, যা যথেষ্ট পরিমাণে ভালো সুপারিশ তৈরি করবে। আমরা চাই না নবাগতরা নিবন্ধে ভুল ছবি যোগ করার পথে হাঁটুক, কারণ তাহলে পরীক্ষকদের পরিষ্কারকরণে বেশ সময় ব্যয় হয়। এ জন্য প্রথমেই আমাদের কাজ করতে হবে যথেষ্ট পরিমাণে ভালো অ্যালগোরিদম তৈরি করতে।

যুক্তি
আমরা উইকিমিডিয়া গবেষণা দলের সাথে কাজ করছি এবং এযাবৎ আমরা যে অ্যালগোরিদমটি পরীক্ষা করছি সেটি সঠিকতা এবং মানুষের সিদ্ধান্তকে গুরুত্ব দেয়। কম্পিউটার ভিশন পদ্ধতি ব্যবহার করা হয়নি, যা কিছুটা অস্বাভাবিক ফলাফল প্রদান করে। বর্তমানে এটি সহজভাবে অভিজ্ঞ অবদানকারীদের অবদানের সংযোগ ঘটিয়ে উইকিউপাত্ত থেকে বিদ্যমান তথ্য গ্রহণ করে। মূলত তিন উপায়ে এটি ছবিবিহীন নিবন্ধে ছবির সুপারিশ করে:


 * নিবন্ধের উইকিউপাত্ত ভুক্তির দিকে লক্ষ্য করা হয়। যদি এটির কোনো ছবি (P18) থাকে, তবে সেই ছবিটি নির্বাচন করা হয়।
 * নিবন্ধের উইকিউপাত্ত ভুক্তির দিকে লক্ষ্য করা হয়। যদি এটির সাথে কোনো কমন্স বিষয়শ্রেণী (P373) থাকে, তবে বিষয়শ্রেণী থেকে সেই ছবিটি নির্বাচন করা হয়।
 * একই বিষয়ে অন্য ভাষার নিবন্ধে কোনো ছবি আছে কীনা দেখা হয়, থাকলে ঐ নিবন্ধের মূল ছবিটি নির্বাচন করা হয়।

অ্যালগোরিদম আরো কিছু যুক্তিকে ব্যবহার করে, যেমন আইকন বা কোনো নিবন্ধের পরিভ্রমণ বক্সে থাকা ছবি।

সঠিকতা
আগস্ট ২০২১ পর্যন্ত আমরা তিন দফায় অ্যালগোরিদম পরীক্ষা করেছি, প্রত্যেকবার মোট ছয়টি ভাষায় এটি পরিচালিত হয়েছে: ইংরেজি, ফরাসি, আরবি, ভিয়েতনামিয়, চেক এবং কোরিয়। আমাদের দলের অ্যাম্বাসেডররা এটি পরীক্ষা করেছে, যারা স্থানীয়ভাবে ঐ ভাষা ব্যবহার করেন। প্রতিটি ভাষার মোট ৫০টি প্রস্তাবনা দেয়া হয়েছে, তা যাচাই করে এবং শ্রেণিবিন্যাস করে আমরা নিম্নোক্ত বিভাগে ভাগ করেছি:

First two evaluations

Looking at 50 suggested matches in each language, we went through and classified them into these groups:

এ ধরনের অ্যালগোরিদমের কাজের ক্ষেত্রে একটি প্রশ্ন থাকে, যে এটাকে কতটা সঠিক হতে হবে? ৭৫% মিলে গেলে সেটা কি যথেষ্ট হবে? নাকি এটাকে ৯০% সঠিক হতে হবে? এটা ৫০% এর মত সঠিক হলে কি চলবে? এই সব নির্ভর করে নবাগত যারা এটা ব্যবহার করবে, তাদের দৃষ্টিভঙ্গির উপর, এবং কম মিলে যাওয়া ক্ষেত্রগুলোতে তারা কতটা ধৈর্যশীল হবেন। আমরা এ সম্পর্কে আরো জানতে পারব যখন সত্যিকারের নবাগতদের উপর অ্যালগোরিদমটা পরীক্ষা করতে সক্ষম হব।

প্রথম দফার মূল্যায়নে আমরা সবচেয়ে গুরুত্বপূর্ণ যে ব্যাপারটা দেখতে পেয়েছি সেটা হল অ্যালগরিদমের কিছু সহজ উন্নতির ক্ষেত্র, এবং কোন নিবন্ধ আর ছবি বাদ দিতে হবে সেটিও। এই উন্নতিগুলো বাদেও প্রায় ২০-৪০% মিল ছিল "২-এর", অর্থাৎ নিবন্ধের জন্য (বিভিন্ন উইকির উপর নির্ভরশীল) এগুলো দারুণভাবে মিলে গেছে। মূল্যায়নের সম্পূর্ণ ফলাফল এবং টিকা আপনি এখানে দেখতে পাবেন।

দ্বিতীয় দফার মূল্যায়নের জন্য নানাভাবে একে উন্নত করা হয়, সঠিকতাও বৃদ্ধি পায়। ৫০-৭০% "2s" মিলসম্পন্ন হয় (বিভিন্ন উইকির উপর নির্ভরশীল)। তবে সঠিকতা বৃদ্ধি করার ফলে ব্যাপকতা কমে যেতে পারে, অর্থাৎ সম্ভাব্য মিল দেখানোর জন্য পাওয়া নিবন্ধের সংখ্যা। কিছুটা সংরক্ষিত উপায় অনুসরণ করে এই অ্যালগোরিদম নির্দিষ্ট উইকিতে মাত্র কয়েক হাজার প্রস্তাবনা দিতে পারবে, যদি সেই উইকিতে হাজার বা লাখো নিবন্ধ থাকে তা সত্ত্বেও। আওরা বিশ্বাস করি যে এই সংখ্যা নতুন বৈশিষ্ট্যের প্রাথমিক সংস্করণের জন্য যথেষ্ট হবে। দ্বিতীয় দফা মূল্যায়নের সম্পূর্ণ ফলাফল এবং টিকা এখানে দেখতে পাবেন।

তৃতীয় পরীক্ষণ

মে ২০২১-এ কাঠামোবদ্ধ উপাত্ত দল বৃহত্তর পরিসরে ছবি ম্যাচিং অ্যালগোরিদম (এবং মিডিয়াসার্চ অ্যালগোরিদম) পরীক্ষা করেছে। আরবি, সেবুয়ানো, ইংরেজি, ভিয়েতনামিয়, বাংলা এবং চেক উইকিপিডিয়ায় পরীক্ষণ চালানো হয়। এই পরীক্ষায় ছবি ম্যাচিং ও মিডিয়াসার্চ অ্যালগোরিদমের প্রায় ৫০০টি পরামর্শ ঐ ভাষা সম্পর্কে অভিজ্ঞরা যাচাই করেন। তারা ছবিগুলোকে "ভালো", "ঠিকঠাক", বা "খারাপ" পরামর্শ হিসেবে শ্রেণিবিন্যস্ত করেন। নিচে বিস্তারিত ফলাফল উপস্থাপিত হলো:


 * ছবি ম্যাচিং অ্যালগোরিদম ৬৫-৮০% শতাংশ সঠিক, যা নির্ভর করছে আপনি "ভালো", বা "ভালো+ঠিকঠাক" গণনা করছেন কীনা। এটা উইকি/পরীক্ষকের উপরেও নির্ভর করে। লক্ষ্যণীয় যে আমাদের অভিজ্ঞতায় দেখা গেছে ছবি পরীক্ষণের সময় অভিজ্ঞদের নিজেদের মধ্যে মতানৈক্য দেখা যায়। কারণ তারা সবাই নিবন্ধে ছবি প্রযুক্ত করার ক্ষেত্রে নিজস্ব আদর্শ মেনে চলেন।
 * উইকিউপাত্ত পি১৮ ("উইকিউপাত্ত") হলো যথার্থতা যাচাইয়ের শক্তিশালীতম মাধ্যম। এটি ৮৫-৯৫% সঠিক। অন্যান্য উইকিপিডিয়ার ছবি ("আন্তঃউইকি") এবং কমন্সে উইকিউপাত্তের সাথে যুক্ত বিষয়শ্রেণীর ছবি ("কমন্স বিষয়শ্রেণী") তুলনামূলকভাবে কম সঠিক।
 * অন্যান্য উইকিপিডিয়ার ছবি ("আন্তঃউইকি") হলো সবচেয়ে সাধারণ যথার্থ ছবি খুঁজে পাওয়ার উৎস। অন্য ভাবে বলতে গেলে অ্যালগোরিদমের কাছে অন্য দুই উৎসের চেয়ে এই উৎস হতে আগত ছবি বেশি প্রাপ্য।

ফলাফলের সম্পূর্ণ উপাত্তসামগ্রীর তথ্য এখানে পাওয়া যাবে.

ধারণ ক্ষমতা
The accuracy of the algorithm is clearly a very important component. Equally important is its "coverage" -- this refers to how many image matches it can make. Accuracy and coverage tend to be inversely related: the more accurate an algorithm, the fewer suggestions it will make (because it is only making suggestions when it is confident). We need to answer these questions: is the algorithm able to provide enough matches that it is worthwhile to build a feature with it? Would it be able to make a substantial impact on wikis? We looked at 22 Wikipedias to get a sense of the answers. The table is below these summary points:


 * The coverage numbers reflected in the table seem to be sufficient for a first version of an "add an image" feature. There are enough candidate matches in each wiki such that (a) users won't run out, and (b) a feature could make a substantial impact on how illustrated a wiki is.
 * Wikis range from 20% unillustrated (Serbian) to 69% unillustrated (Vietnamese).
 * We can find between 7,000 (Bengali) and 155,000 (English) unillustrated articles with match candidates. In general, this is a sufficient volume for a first version of the task, so that users have plenty of matches to do. In some of the sparser wikis, like Bengali, it might get into small numbers once users narrow to topics of interest. That said, Bengali only has about 100,000 total articles, so we would be proposing matches for 7% of them, which is substantial.
 * In terms of how big of an improvement in illustrations we could make to the wikis with this algorithm, the ceiling ranges from 1% (cebwiki) to 9% (trwiki). That is the overall percentage of additional articles that would wind up with illustrations if every match is good and is added to the wiki.
 * The wikis with the lowest percentage of unillustrated articles for which we can find matches are arzwiki and cebwiki, which both have a high volume of bot-created articles. This makes sense because many of those articles are of specific towns or species that wouldn't have images in Commons. But because those wikis have so many articles, there are still tens of thousands for which the algorithm has matches.
 * In the farther future, we hope that improvements to the image matching algorithm, or to MediaSearch, or to workflows for uploading/captioning/tagging images yield more candidate matches.

MediaSearch
As mentioned above, the Structured Data team is exploring using the MediaSearch algorithm to increase coverage and yield more candidate matches.

MediaSearch works by combining traditional text-based search and structured data to provide relevant results for searches in a language-agnostic way. By using the Wikidata statements added to images as part of Structured Data on Commons as a search ranking input, MediaSearch is able to take advantage of aliases, related concepts, and labels in multiple languages to increase the relevance of image matches. You can find more information about how MediaSearch works here.

As of February 2021, team is currently experimenting with how to provide a confidence score for MediaSearch matches that the image recommendations algorithm can consume and use to determine whether a match from MediaSearch is of sufficient quality to use in image matching tasks. We want to be sure that users are confident in the recommendations that MediaSearch provides before incorporating them into the feature.

The Structured Data team is also exploring and prototyping a way for user generated bots to use the results generated by both the image recommendations algorithm and MediaSearch to automatically add images to articles. This will be an experiment in bot-heavy wikis, in partnership with community bot writers. You can learn more about that effort or express interest in participating in the phabricator task.

In May 2021, in the same evaluation cited in the "Accuracy" section above, MediaSearch was found to be far less accurate than the image matching algorithm. Where the image matching algorithm was about 78% accurate, matches from MediaSearch were about 38% accurate. Therefore, the Growth team is not planning to use MediaSearch in its first iteration of the "add an image" task.

উন্মুক্ত প্রশ্ন
উইকিপিডিয়া অভিজ্ঞতার একটি গুরুত্বপূর্ণ অংশে রয়েছে ছবি। আমরা তীক্ষ্ণভাবে বিচার করছি কীভাবে সহজে ছবি যুক্ত করার বৈশিষ্ট্যটি কাজ করবে, সম্ভাব্য সমস্যা কী হতে পারে, এবং সম্প্রদায়ের সদস্যদের জন্য প্রয়োগটা কেমন হবে। আমরা অনেক উন্মুক্ত প্রশ্ন পেয়েছি এবং আমরা সম্প্রদায়ের সদস্যদের থেকে আরো প্রশ্ন আহ্বান করছি।


 * আমাদের অ্যালগোরিদম কি যথেষ্ট পরিমাণে ভালো হবে, যেন পর্যাপ্ত সংখ্যক সম্ভাব্য মিলসম্পন্ন প্রস্তাবনা দেয়া সম্ভব হবে?
 * ছবি যোগ করা হবে কী না সংক্রান্ত সিদ্ধান্ত নেয়ার ক্ষেত্রে কমন্স এবং ছবিবিহীন নিবন্ধ সংশ্লিষ্ট কী কী মেটাডেটা নবাগতদের প্রয়োজন হবে?
 * পরামর্শগুলো দেখে কি নবাগতরা যথেষ্ট পরিমাণে সঠিক সিদ্ধান্ত নিতে পারবে?
 * কমন্সের মেটাডেটা যদি ইংরেজিতে থাকে, তাহলে কি নবাগত যারা ইংরেজি ভালো জানেন না, তারাও একইভাবে ভালো সিদ্ধান্ত নিতে পারবে?
 * নবাগতরা কি নিবন্ধে ছবি যোগ করার পাশাপাশি ভালো ক্যাপশন লিখতে পারবে?
 * ছবির "মান" দেখে বিচার করাটা নবাগতদের জন্য কতটা জরুরী, যদি এর মানের বিপরীতে "প্রাসঙ্গিকতা"র কথা চিন্তা করি?
 * নবাগতদের কাছে কি এই কাজটা আগ্রহোদ্দীপক হবে? মজাদার? কঠিন? সহজ? বিরক্তিকর?
 * আমরা ঠিক কীভাবে নির্ধারণ করব যে কোন কোন নিবন্ধে ছবি নেই?
 * ছবিবিহীন নিবন্ধের কোথায় ছবি বসানো হবে? নিবন্ধের শীর্ষভাবে ছবি বসানোই কি যথেষ্ট হবে?
 * পরামর্শের ক্ষেত্রে সম্ভাব্য পক্ষপাতের ব্যাপারে আমরা কীভাবে খেয়াল রাখতে পারি? যেমন, হয়তো পরামর্শের ক্ষেত্রে ইউরোপ ও উত্তর আমেরিকাকে অধিক সংখ্যক মিলের প্রস্তাবনা দেয়া হতে পারে।
 * এরকম একটি কার্যপদ্ধতি কি ধ্বংসপ্রবণতা তৈরি করবে? কীভাবে এর বিরুদ্ধে পদক্ষেপ নেয়া যেতে পারে?

Notes from community discussions 2021-02-04
Starting in December 2020, we invited community members to talk about the "add an image" idea in five languages (English, Bengali, Arabic, Vietnamese, Czech). The English discussion mostly took place on the discussion page here, with local language conversations on the other four Wikipedias. We heard from 28 community members, and this section summarizes some of the most common and interesting thoughts. These discussions are heavily influencing our next set of designs.


 *  Overall : community members are generally cautiously optimistic about this idea. In other words, people seem to agree that it would be valuable to use algorithms to add images to Wikipedia, but that there are many potential pitfalls and ways this can go wrong, especially with newcomers.
 *  Algorithm 
 * Community members seemed to have confidence in the algorithm because it is only drawing on associations coded into Wikidata by experienced users, rather than some sort of unpredictable artificial intelligence.
 * Of the three sources for the algorithm (Wikidata P18, interwiki links, and Commons categories), people agreed that Commons categories are the weakest (and that Wikidata is the strongest). This has borne out in our testing, and we may exclude Commons categories from future iterations.
 * We got good advice on excluding certain kinds of pages from the feature: disambiguations, lists, years, good, and featured articles.. We may also want to exclude biographies of living persons.
 * We should also exclude images that have a deletion template on Commons and that have been previously removed from the Wikipedia page.
 *  Newcomer judgment 
 * Community members were generally concerned that newcomers would apply poor judgment and give the algorithm the benefit of the doubt. We know from our user tests that newcomers are capable of using good judgment, and we believe that the right design will encourage it.
 * In discussing the Wikipedia Pages Wanting Photos campaign (WPWP), we learned that while many newcomers were able to exhibit good judgment, some overzealous users can make many bad matches quickly, causing lots of work for patrollers. We may want to add some sort of validation to prevent users from adding images too fast, or from continuing to add images after being repeatedly reverted.
 * Most community members affirmed that "relevance" is more important than "quality" when it comes to whether an image belongs. In other words, if the only photo of a person is blurry, that is usually still better than having no image at all.  Newcomers need to be taught this norm as they do the task.
 * Our interface should convey that users should move slowly and take care, as opposed to trying to get as many matches done as they can.
 * We should teach users that images should be educational, not merely decorative.
 *  User interface 
 * Several people proposed that we show users several image candidates to choose from, instead of just one. This would make it more likely that good images are attached to articles.
 * Many community members recommended that we allow newcomers to choose topic areas of interest (especially geographies) for articles to work with. If newcomers choose areas where they have some knowledge, they may be able to make stronger choices.  Fortunately, this would automatically be part of any feature the Growth team builds, as we already allow users to choose between 64 topic areas when choosing suggested edit tasks.
 * Community members recommend that newcomers should see as much of the article context as possible, instead of just a preview. This will help them understand the gravity of the task and have plenty of information to use in making their judgments.
 *  Placement in the article 
 * We learned about Wikidata infoboxes. We learned that for wikis that use them, the preference is for images to be added to Wikidata, instead of to the article, so that they can show up via the Wikidata infobox.  In this vein, we will be researching how common these infoboxes are on various wikis.
 * In general, it sounds like a rule of "place an image under the templates and above the content" in an article will work most of the time.
 * Some community members advised us that even if placement in an article isn't perfect, other users will happily correct the placement, since the hard work of finding the right image will already be done.
 *  Non-English users 
 * Community members reminded us that some Commons metadata elements can be language agnostic, like captions and depicts statements. We looked at exactly how common that was in this section.
 * We heard the suggestion that even if users aren't fluent with English, they may still be able to use the metadata if they can read Latin characters. This is because to make many of the matches, the user is essentially just looking for the title of the article somewhere in the image metadata.
 * Someone also proposed the idea of using machine translation (e.g. Google Translate) to translate metadata to the local language for the purposes of this feature.
 *  Captions 
 * Community members (and Growth team members) are skeptical about the ability of newcomers to write appropriate captions.
 * We received advice to show users example captions, and guidelines tailored to the type of article being captioned.

ব্যবহারকারী পরীক্ষণের পরিকল্পনা


সম্প্রদায়ের মতামত আর উপরে বর্ণিত উন্মুক্ত প্রশ্নসমূহের পাশাপাশি আমরা চাই "একটি ছবি যুক্ত করুন" বৈশিষ্ট্যের জন্য কিছু গুণগত আর পরিমাণগত তথ্য তৈরি করতে চাই। আমরা কর্মকর্তা এবং উইকিমিডিয়ানগণ এই অ্যালগোরিদমের মূল্যায়ন করছেন, নবাগতরা এই বৈশিষ্ট্যটি কীভাবে দেখেন, তা জানাটা গুরুত্বপূর্ণ। তারা নিবন্ধে ছবি যোগ করার ক্ষেত্রে কীভাবে বিচক্ষণতার পরিচয় দেবেন সেটাও একটা গুরুত্বপূর্ণ ব্যাপার।

আমরা usertesting.com ব্যবহার করে কিছু পরীক্ষা করব, যেন উইকিপিডিয়ার সম্পাদনার ক্ষেত্রে যারা নতুন তারা ছবি শনাক্তকরণ প্রোটোটাইপের জন্য "হ্যাঁ", "না", বা "নিশ্চিত নই" নির্বাচন করতে পারেন। আমরা পরীক্ষার জন্য একটা দ্রুত প্রোটোটাইপ তৈরি করেছি, যা বর্তমান অ্যালগোরিদমের সত্যিকারের মিলগুলোকে নিয়ে নির্মিত। প্রোটোটাইপটি একটার পর একটা মিল দেখাবে। ছবি দেখানোর পাশাপাশি কমন্স থেকে প্রাসঙ্গিক মেটাডেটাও দেখানো হয়।


 * চিত্রের নাম
 * আকার
 * তারিখ
 * ব্যবহারকারী
 * বিবরণ
 * শিরোনাম
 * বিষয়শ্রেণীসমূহ
 * ট্যাগসমূহ

ভবিষ্যতে নবাগতদের জন্য যে কার্যপদ্ধতি তৈরি হবে, তার সাথে এটার অবিকল মিল না থাকলেও পরীক্ষকরা যেন সহজেই কিছু মিল নিয়ে কাজ করতে পারেন, তথ্য পেতে পারেন, তার জন্যই প্রোটোটাইপটি নির্মিত হয়েছে।

প্রোটোটাইপটি পরীক্ষা করার জন্য, এই লিঙ্ক ব্যবহার করুন।

পরীক্ষার জন্য আমরা যা দেখছি:


 * 1) পরামর্শ এবং প্রদত্ত তথ্যের ভিত্তিতে অংশগ্রহণকারীরা কি নিশ্চিতভাবে মিলগুলো শনাক্ত করতে পারবে?
 * 2) পরামর্শগুলো মূল্যায়নের ক্ষেত্রে অংশগ্রহণকারীরা কতটা সঠিক? তারা এমনি সময়ে যা করে থাকেন, তার চেয়ে কি এই কাজকে আরো ভালো বা খারাপ বলে মনে করছেন?
 * 3) নিবন্ধে ছবি যুক্ত করার কাজের ব্যাপারে অংশগ্রহণকারীরা কীরকম বোধ করেন? তারা কি সহজ/কঠিন, মজার/বিরক্তিকর, কাজের/অপ্রাসঙ্গিক মনে করেন?
 * 4) ছবি ও নিবন্ধের মিল মূল্যায়নের ক্ষেত্রে কোন ধরনের তথ্য অংশগ্রহণকারীরা সবচেয়ে বেশি গুরুত্ব দিয়ে থাকে?
 * 5) প্রদত্ত তথ্যের ভিত্তিতে অংশগ্রহণকারীরা কি ভালো ক্যাপশন লিখতে পারবেন?

Concept A vs. B
In thinking about design for this task, we have a similar question as we faced for "add a link" with respect to Concept A and Concept B. In Concept A, users would complete the edit at the article, while in Concept B, they would do many edits in a row all from a feed. Concept A gives the user more context for the article and editing, while Concept B prioritizes efficiency.

In the interactive prototype above, we used Concept B, in which the users proceed through a feed of suggestions. We did that because in our user tests we wanted to see many examples of users interacting with suggestions. That's the sort of design that might work best for a platform like the Wikipedia Android app. For the Growth team's context, we're thinking more along the lines of Concept A, in which the user does the edit at the article. That's the direction we chose for "add a link", and we think that it could be appropriate for "add an image" for the same reasons.

Single vs. Multiple
Another important design question is whether to show the user a single proposed image match, or give them multiple images matches to choose from. When giving multiple matches, there's a greater chance that one of the matches is a good one. But it also may make users think they should choose one of them, even if none of them are good. It will also be a more complicated experience to design and build, especially for mobile devices. We have mocked up three potential workflows:


 *  Single : in this design, the user is given only one proposed image match for the article, and they only have to accept or reject it. It is simple for the user.
 *  Multiple : this design shows the user multiple potential matches, and they could compare them and choose the best one, or reject all of them. A concern would be if the user feels like they should add the best one to the article, even if it doesn't really belong.
 *  Serial : this design offers multiple image matches, but the user looks at them one at a time, records a judgment, and then chooses a best one at the end if they indicated that more than one might match. This might help the user focus on one image at a time, but adds an extra step at the end.



User tests December 2020
 Background 

During December 2020, we used usertesting.com to conduct 15 tests of the mobile interactive prototype. The prototype contained only a rudimentary design, little context or onboarding, and was tested only in English with users who had little or no previous Wikipedia editing experience. We deliberately tested a rudimentary design earlier in the process so that we could gather lots of learnings. The primary questions we wanted to address with this test were around feasibility of the feature as a whole, not around the finer points of design:


 * 1) Are participants able to confidently confirm matches based on the suggestions and data provided?
 * 2) How accurate are participants at evaluating suggestions? And how does the actual aptitude compare to their perceived ability in evaluating suggestions?
 * 3) How do participants feel about the task of adding images to articles this way? Do they find it easy/hard, interesting/boring, rewarding/irrelevant?
 * 4) What metadata do participants find most valuable in helping them evaluate image and article matches?
 * 5) Are participants able to write good captions for images they deem a match using the data provided?

In the test, we asked participants to annotate at least 20 article-image matches while talking out loud. When they tapped yes, the prototype asked them to write a caption to go along with the image in the article. Overall, we gathered 399 annotations.

 Summary 

We think that these user tests confirm that we could successfully build an "add an image" feature, but it will only work if we design it right. Many of the testers understood the task well, took it seriously, and made good decisions -- this gives us confidence that this is an idea worth pursuing. On the other hand, many other users were confused about the point of the task, did not evaluate as critically, and made weak decisions -- but for those confused users, it was easy for us to see ways to improve the design to give them the appropriate context and convey the seriousness of the task.

 Observations 

'' To see the full set of findings, feel free to browse the slides. The most important points are written below the slides. ''




 * General understanding of the task matching images to Wikipedia articles was reasonably good, given the minimal context provided for the tool and limited knowledge of Commons and Wikipedia editing. There are opportunities to boost understanding once the tool is redesigned in a Wikipedia UX.
 * The general pattern we noticed was: a user would look at an article's title and first couple sentences, then look at the image to see if it could plausibly match (e.g. this is an article about a church and this is an image of a church). Then they would look for the article's title somewhere in the image metadata, either in the filename, description, caption, or categories.  If they found it, they would confirm the match.
 * Each image matching task could be done quickly by someone unfamiliar with editing. On average, it took 34 seconds to review an image.
 * All said they would be interested in doing such a task, with a majority rating it as easy or very easy.
 * Perceived quality of the images and suggestions was mixed. Many participants focused on the image composition and other aesthetic factors, which affected their perception of the suggestion accuracy.
 * Only a few pieces of image metadata from Commons were critical for image matching: filename, description, caption, categories.
 * Many participants would, at times, incorrectly try to match an images to its own data, rather than to the article (e.g. "Does this filename seem right for the image?"). Layout and visual hierarchy changes to better focus on the article context for the image suggested should be explored.
 * “Streaks” of good matches made some participants more complacent with accepting more images -- if many in a row were "Yes", they stopped evaluating as critically.
 * Users did a poor job of adding captions. They frequently would write their explanation for why they matched the image, e.g. "This is a high quality photo of the guy in the article." This is something we believe can be improved with design and explanation for the user.

 Metrics 


 * Members of our team annotated all the image matches that were shown to users in the test, and we recorded the answers the users gave. In this way, we developed some statistics on how good of a job the users did.
 * Of the 399 suggestions users encountered, they tapped "Yes" 192 times (48%).
 * Of those, 33 were not good matches, and might be reverted were they to be added to articles in reality. This is 17%, and we call this the "likely revert rate".

 Takeaways 


 * The "likely revert rate" of 17% is a really important number, and we want this to be as low as possible. On the one hand, this number is close to or lower than the average revert rate for newcomer edits in Wikipedia (English is 36%, Arabic is 26%, French is 22%, Vietnamese is 11%).  On the other hand, images are higher impact and higher visibility than small changes or words in an article.  Taking into account the kinds of changes we would make to the workflow we tested (which was optimized for volume, not quality), we think that this revert rate would come down significantly.
 * We think that this task would work much better in a workflow that takes the user to the full article, as opposed to quickly shows them one suggestion after another in the feed. By taking them to the full article, the user would see much more context to decide if the image matches and see where it would go in the article.  We think they would absorb the importance of the task: that they will actually be adding an image to a Wikipedia article.  Rather than going for speed, we think the user would be more careful when adding images.  This is the same decision we came to for "add a link" when we decided to build the "Concept A" workflow.
 * We also think outcomes will be improved with onboarding, explanation, and examples. This is especially true for captions.  We think if we show users some examples of good captions, they'll realize how to write them appropriately.  We could also prompt them to use the Commons description or caption as a starting point.
 * Our team has lately been discussing whether it would be better to adopt a "collaborative decision" framework, in which an image would not be added to an article until two users confirm it, rather than just one. This would increase the accuracy, but raises questions around whether such a workflow aligns with Wikipedia values, and which user gets credit for the edit.

Metadata
The user tests showed us that image metadata from Commons (e.g. filename, description, caption, etc.) is critical for a user to confidently make a match. For instance, though the user can see that the article is about a church, and that the photo is of a church, the metadata allowed them to tell if it is the church discussed in the article. In the user tests, we saw that these items of metadata were most important: filename, description, caption, categories. Items that were not useful included size, upload date, and uploading username.

Given that metadata is a critical part of making a strong decision, we have been thinking about whether users will need to be have metadata in their own language in order to do this task, especially in light of the fact that the majority of Commons metadata is in English. For 22 wikis, we looked at the percentage of the image matches from the algorithm that have metadata elements in the local language. In other words, for the images that can be matched to unillustrated articles in Arabic Wikipedia, how many of them have Arabic descriptions, captions, and depicts? The table is below these summary points:


 * In general, local language metadata coverage is very low. English is the exception.
 * For all wikis except English, fewer than 7% of image matches have local language descriptions (English is at 52%).
 * For all wikis except English, fewer than 0.5% of image matches have local language captions (English is at 3.6%).
 * For depicts statements, the wikis range between 3% (Serbian) and 10% (Swedish) coverage for their image matches.
 * The low coverage of local language descriptions and captions means that in most wikis, there are very few images we could suggest to users with local language metadata. Some of the larger wikis have a few thousand candidates with local language descriptions.  But no non-English wikis have over 1,000 candidates with local language captions.
 * Though depicts coverage is higher, we expect that depicts statements don’t usually contain sufficient detail to positively make a match. For instance, a depicts statement applied to a photo of St. Paul’s Church in Chicago is much more likely to be “church”, than “St. Paul’s Church in Chicago”.
 * We may want to prioritize image suggestions with local language metadata in our user interfaces, but until other features are built to increase the coverage, relying on local languages is not a viable option for these features in non-English wikis.

Given that local-language metadata has low coverage, our current idea is to offer the image matching task to just those users who can read English, which we could ask the user as a quick question before beginning the task. This unfortunately limits how many users could participate. It's a similar situation to the Content Translation tool, in that users need to know the language of the source wiki and the destination wiki in order to move content from one wiki to another. We also believe there will be sufficient numbers of these users based on results from the Growth team's welcome survey, which asks newcomers which languages they know. Depending on the wiki, between 20% and 50% of newcomers select English.

অ্যান্ড্রয়েড এমভিপি
অ্যান্ড্রয়েড এমভিপি সম্পর্কে বিস্তারিত জানতে এই পাতাটি দেখুন।

প্রেক্ষাপট
After lots of community discussion, many internal discussions, and the user test results from above, we believe that this "add an image" idea has enough potential to continue to pursue. Community members have been generally positive, but also cautionary -- we also know that there are still many concerns and reasons the idea might not work as expected. The next step we want to in order to learn more is to build a "minimum viable product" (MVP) for the Wikipedia Android app. The most important thing about this MVP is that it will not save any edits to Wikipedia. Rather, it will only be used to gather data, improve our algorithm, and improve our design.

The Android app is where "suggested edits" originated, and that team has a framework to build new task types easily. These are the main pieces:


 * The app will have a new task type that users know is only for helping us improve our algorithms and designs.
 * It will show users image matches, and they will select "Yes", "No", or "Skip".
 * We'll record the data on their selections to improve the algorithm, determine how to improve the interface, and think about what might be appropriate for the Growth team to build for the web platform later on.
 * No edits will happen to Wikipedia, making this a very low-risk project.

Results
The Android team released the app in May 2021, and over several weeks, thousands of users evaluated tens of thousands of image matches from the image matching algorithm. The resulting data allowed the Growth team to decide to proceed with Iteration 1 of the "add an image" task. In looking at the data, we were trying to answer two important questions around "Engagement" and "Efficacy".

Engagement: do users of all languages like this task and want to do it?
 * On average, users in the Android MVP did about 11 annotations each. While this is less than image descriptions and description translations, it is greater than the other four kinds of Android tasks.
 * Image matching edits showed a substantially lower retention rate than other kinds of Android suggested edits, but there are concerns that it’s not possible to calculate an apples-to-apples comparison. Further, we think that the fact that the edits from this MVP do not actually change the wikis would lead to lower retention, because users would be less motivated to return and do more.
 * With respect to language, data was collected for users in English Wikipedia as well as from users who exclusively use non-English Wikipedia, including large numbers of evaluations from German, Turkish, French, Portuguese, and Spanish Wikipedias. We expected English and non-English users to have quite different experiences, because the majority of metadata on images in Commons is in English. But metrics were remarkably similar across the two groups, including number of tasks completed, time spent on task, retention, and judgment. This bodes well for this task being usable across wikis, although it's likely that many of the non-English Android users are actually bilingual.

Efficacy: will resulting edits be of sufficient quality?
 * 80% of the matches for which newcomers said "yes" are actually good matches according to experts. This is an improvement of about 5 percentage points over the algorithm alone.
 * This number goes up to 82-83% when we remove newcomers who have very low median time for evaluations.
 * Experts tend to agree with each other only about 85% of the time.
 * Because newcomer accuracy goes up when certain kinds of newcomers are removed (those who evaluate too quickly or who accept too many suggestions), we think that automated “quality gates” could boost newcomer performance to levels acceptable by communities.

See the full results are here.

Engineering
This section contains links on how to follow along with technical aspects of this project:


 * Work on the "proof of concept" API by the Platform Engineering team, built to back the Android MVP
 * Phabricator tasks around the Android team's MVP
 * Phabricator tasks and evaluations of the image matching algorithm

প্রথম চক্র
জুলাই ২০২১-এ গ্রোথ দল ওয়েবে "একটি ছবি যুক্ত করুন"-এর প্রথম চক্র নির্মাণের জন্য এগিয়ে যায়। এটি একটি কঠিন সিদ্ধান্ত ছিল, কারণ উইকিপিডিয়ার নিবন্ধে নবাগতদের ছবি যোগ করতে উৎসাহিত করার ক্ষেত্রে বিভিন্ন উন্মুক্ত প্রশ্ন ও ঝুঁকি ছিল। তবে প্রায় এক বছর ধরে পরিকল্পনা যাচাইয়ের পর এবং সম্প্রদায়ের সাথে আলোচনা, পরীক্ষণ, এবং পরিকল্পনার ধারণার প্রমাণের পরে আমরা প্রথম চক্র নির্মাণের দিকে এগিয়ে যাই, যা আমরা ক্রমাগত পরীক্ষা করতে পারব। পরিকল্পনা যাচাইয়ের ক্ষেত্রে নিম্নোক্ত দিক আমাদের এগিয়ে যেতে উৎসাহিত করে:


 * সম্প্রদায়ের সতর্কতামূলক সমর্থন: সম্প্রদায়ের সদস্যগণ এই কাজের ব্যাপারে আশাবাদী। তারা একমত যে এটি একটি মূল্যবান কাজ হবে, তবে এর ঝুঁকি ও সমস্যার দিকগুলো তুলে ধরেছেন যা আমাদেরকে ভালো নির্মাণের মাধ্যমে সমাধান করতে হবে।
 * সঠিক অ্যালগোরিদম: ছবি ম্যাচিং অ্যালগোরিদম বিভিন্ন পরীক্ষণের ক্ষেত্রে মোট ৬৫-৮০% সঠিক হিসেবে প্রমাণিত হয়েছে। আমরা সময়ের সাথে এটাকে আরো পরিশুদ্ধ করব।
 * ব্যবহারকারী পরীক্ষণ: অনেক নবাগত এই প্রোটোটাইপ যাচাই করেছেন এবং মজাদার ও অন্তর্ভুক্তিমূলক হিসেবে অভিহিত করেছেন।
 * অ্যান্ড্রয়েড এমভিপি: অ্যান্ড্রয়েড এমভিপির ফলাফলে দেখা গেছে যে নবাগতরা সাধারণত পরামর্শের ক্ষেত্রে সুবিবেচনার পরিচয় দেয়। তবে তারা সবচেয়ে গুরুত্বপূর্ণ যে ব্যাপারে অবদান রেখেছেন তা হলো আমাদের ফলাফলের উন্নয়নে। এই ফলাফলে দেখা গেছে যে এই কাজ বিভিন্ন ভাষায় ভালোভাবে কাজ করতে পারে।
 * সামগ্রিক শিখন: যাচাইয়ের বিভিন্ন পর্যায়ে নানাবিধ সমস্যায় পড়ে এবং উত্তরণ ঘটানোর মাধ্যমে আমরা আগামী নকশায় সমস্যা এড়াতে পেরেছি। এই কাজগুলো আমাদেরকে অনেক চিন্তার খোরাক জুগিয়েছে, যে কীভাবে নবাগতরা সঠিক চিন্তার পথে যেতে পারে, এবং কীভাবে অনাকাঙ্ক্ষিত সম্পাদনা এড়াতে পারে।

অনুকল্প
আমরা নিশ্চিত না যে এই কাজ ভালো কাজ করবেই -- যে কারণে আমরা ছোট চক্রে বিভক্ত করে এটাকে নির্মাণ করতে চাই। শিখতে চাই পথে। আমরা মনে করি যে এযাবৎকালে আমরা যা শিখেছি, তার ভিত্তিতে ছোট আকারে প্রথম চক্র প্রস্তুত করতে পারি। আমরা যা করছি, সেটাকে অনুকল্প পরীক্ষণ হিসেবে দেখা যায়। "একটি ছবি যুক্ত করুন" কাজে আমাদের পাঁচটি আশাবাদী অনুকল্প নিচে উল্লেখিত হলো। প্রথম চক্রে আমাদের লক্ষ্য এই অনুকল্পগুলো সঠিক কীনা, তা দেখা।


 * 1) ক্যাপশন: ব্যবহারকারীরা সন্তোষজনক পর্যায়ে ক্যাপশন লিখতে পারবেন। এটা আমাদের সবচেয়ে বড় উন্মুক্ত প্রশ্ন, কারণ উইকিপিডিয়ার নিবন্ধে যুক্ত করা ছবির সাথে ক্যাপশন থাকতে হয়, তবে অ্যান্ড্রয়েড এমভিপি নবাগতরা ভালোভাবে ক্যাপশন লিখতে পারেন কীনা তা যাচাই করেনি।
 * 2) কার্যকারিতা: নবাগতরা সম্পাদনার ক্ষেত্রে তাদের বিবেচনাকে কাজে লাগাতে পারবেন, যা সম্প্রদায় গ্রহণ করবে।
 * 3) অন্তর্ভুক্তি: ব্যভারকারীরা মোবাইলে এই কাজটি করতে পছন্দ করবেন, একাধিকবার, এবং ফিরে এসে আবারও এই কাজ করবেন।
 * 4) ভাষা: যে ব্যবহারকারীরা ইংরেজি জানেন না, তারাও এটা ব্যবহার করতে পারবেন। এটা একটা গুরুত্বপূর্ণ প্রশ্ন, কারণ কমন্সে মেটাউপাত্তের বেশিরভাগই ইংরেজিতে, এবং ব্যবহারকারীর পক্ষে যথার্থ ছবি খুঁজে পাওয়ার জন্য ফাইলের নাম, বর্ণনা ও ক্যাপশন পড়তে পারাটা জরুরী।
 * 5) দৃষ্টান্ত: এই নকশা  "একটি লিঙ্ক যুক্ত করুন কাঠামোবদ্ধ কাজের" সম্প্রসারিত দৃষ্টান্ত।

পরিধি
প্রথম চক্র পরিচালনার ক্ষেত্রে আমাদের অন্যতম প্রধান লক্ষ্য শিখন। আমরা ব্যবহারকারীদের কাছে অভিজ্ঞতা পৌঁছে দিতে চাই, যত দ্রুত সম্ভব। এর মানে আমরা আমাদের ক্ষমতা সীমিত করে দ্রুত মুক্তি দিতে চাই। নিচে প্রথম চক্র পরিচালনার ক্ষেত্রে আমাদের সবচেয়ে গুরুত্বপূর্ণ সীমাবদ্ধতাগুলো তুলে ধরা হলো:


 * কেবলমাত্র মোবাইল: অনেক অভিজ্ঞ উইকিমিডিয়ান তাদের উইকি কাজের বেশিরভাগটাই করেন ডেস্কটপ/ল্যাপটপ দিয়ে। নবাগতরা, যাদের উইকিমিডিয়াতে অবদান রাখতে কষ্ট হয়, তারা অধিকাংশ মূলত মোবাইল ডিভাইস ব্যবহার করেন। তারা গ্রোথ দলের অধিকতর গুরুত্বপূর্ণ লক্ষ্য। আমরা যদি প্রথম চক্র কেবলমাত্র মোবাইলের জন্য তৈরি করি, তবে ঐ জনগোষ্ঠীর প্রতি দৃষ্টিনিবদ্ধ করতে পারব, এবং একইসাথে ডেস্কটপ/ল্যাপটপে কাজের ধারা নির্মাণ করার সময় বাঁচাতে পারব।
 * স্থিতিশীল পরামর্শ: বিদ্যমান ছবির পরামর্শগুলো দেয়ার জন্য ব্যাকএন্ডে কোনো প্রোগ্রাম সবসময় না চালিয়ে বরং একবারেই এই অ্যালগোরিদমের মাধ্যমে বিপুল সংখ্যক ছবির পরামর্শ তৈরি করা হবে প্রথম এই চক্রে। যদিও এর মাধ্যমে সবচেয়ে নতুন ছবি পাওয়া সম্ভব হবে না, তবে আমাদের শিখনের জন্য এটা যথেষ্ট হবে।
 * একটি লিঙ্ক যুক্ত করুন-এর দৃষ্টান্ত: আমাদের নকশা পূর্বের কাঠামোবদ্ধ কাজ, "একটি লিঙ্ক যুক্ত করুন"-এর ধাপগুলোকে অনুসরণ করেই নির্মিত হয়েছে।
 * ছবিবিহীন নিবন্ধ: আমরা আমাদের পরামর্শ ঐ নিবন্ধাবলীর জন্যই তৈরি করব, যেগুলোতে কোনো ছবি নেই। যেসকল নিবন্ধে কিছু ছবি আছে, সেগুলোতে আরো ব্যবহারের জন্য ছবির পরামর্শ এই চক্রে থাকবে না। এর মাধ্যমে নবাগতদের জন্য নিবন্ধের কোথায় ছবি বসাতে হবে, এই ধারণা থাকতে হবে না। যেহেতু একটিমাত্রই ছবি থাকবে, নিবন্ধের শীর্ষভাগে এটা বসবে ধারণা করে নেয়া যেতে পারে।
 * কোনো তথ্যছক নয়: আমরা কেবলমাত্র সেইসব নিবন্ধকে বেছে নেব, যেগুলোতে কোনো তথ্যছক নেই। এর কারণ যদি কোনো নিবন্ধে তথ্যছক থাকে, তবে শীর্ষভাগে ছবিটি তথ্যছকে বসানো প্রয়োজন। তবে প্রযুক্তিক কিছু কারণে সঠিক ছবি ও ছবির ক্যাপশনের ঘর পূরণ করার ক্ষেত্রে তা কঠিন হবে। এর মাধ্যমে উইকিউপাত্তের তথ্যছক রয়েছে এমন নিবন্ধও বাদ দেয়া হবে।
 * একক ছবি: যদিও ছবি ম্যাচিং অ্যালগোরিদম একটি ছবিবিহীন নিবন্ধের জন্য একাধিক ছবির পরামর্শ দিতে পারে, আমরা প্রতিটি নিবন্ধের জন্য সবচেয়ে সম্ভাবনাময় পরামর্শ বেছে নেব। এর মাধ্যমে নবাগতদের জন্য অভিজ্ঞতাটি সহজ হবে, এবং দলের জন্য প্রকৌশল ও নকশার দিক থেকেও এটা তুলনামূলক সহজ হবে।
 * মাননিয়ন্ত্রণকারী গেট: আমরা মনে করি যে আমাদের কিছু স্বয়ংক্রিয় পদ্ধতি চালু করা উচিত, যা ব্যবহারকারীকে একসাথে বিপুল সংখ্যক বাজে সম্পাদনা করার ক্ষেত্রে বাধা দেবে। এগুলো হতে পারে (ক) ব্যবহারকারীকে প্রতিদিন নির্দিষ্ট সংখ্যকবার "একটি লিঙ্ক যুক্ত করুন" ব্যবহার করতে দেয়া, (খ) যদি ব্যবহারকারী প্রতিটি পরামর্শ নিয়ে খুব কম সময় ব্যয় করে, তবে ব্যবহারকারীদের অতিরিক্ত নির্দেশনা দেয়া, (গ) যদি ব্যবহারকারীরা অনেক বেশি সংখ্যক ছবি গ্রহণ করে, তবে তাদের অতিরিক্ত নির্দেশনা দেয়া। এই চিন্তার উৎস ইংরেজি উইকিপিডিয়ার ২০২১-এর উইকিপিডিয়ার পাতায় চিত্র যোগ ক্যাম্পেইন।
 * পাইলট উইকি: যেহেতু গ্রোথদলের উন্নতিগুলো প্রথমে পাইলট উইকিতে প্রয়োগ করা হয়, তারই ধারাবাহিকতায় আমরা আরবি, ভিয়েতনামিয়, বাংলা, ও চেক উইকিপিডিয়ায় এই বৈশিষ্ট্য চালু করব। এই সম্প্রদায় গ্রোথ দলের কাজের সাথে ঘনিষ্ঠভাবে যুক্ত এবং তারা এই পরীক্ষণ সম্পর্কে অবগত। গ্রোথ দলের সম্প্রদায় অ্যাম্বাসেডরগণ এই সম্প্রদায়ে দ্রুত পৌঁছতে সাহায্য করেন। আমরা স্প্যানিশ ও পর্তুগিজ উইকিপিডিয়াকে আগামী বছরে এই তালিকায় যুক্ত করতে পারি।

আমরা এ সমস্ত বিষয়ে সম্প্রদায়ের মতামত জানতে আগ্রহী। আমাদের চিন্তাগুলো কি ঠিক আছে, না কোনো কিছু বিবেচনা করা প্রয়োজন, যা প্রথম চক্রকে প্রভাবিত করতে পারে বলে তারা মনে করেন।

Mockups and prototypes
আমাদের পূর্বোক্ত ব্যবহারকারী পরীক্ষণের এবং অ্যান্ড্রয়েড এমভিপির নকশার ভিত্তিতে আমরা প্রথম চক্রের জন্য বেশকিছু নকশার ধারণা নিয়ে ভেবেছি। ব্যবহারকারীর ধারার পাঁচটির প্রতিটির জন্য আমরা দুইটি বিকল্প ভেবেছি। আমরা নবাগতদের থেকে তথ্যের জন্য দুইটি পরীক্ষণ নিয়েই চিন্তা করেছি। আমরা আশা করি যে এই ব্যাপারে সম্প্রদায়ের সদস্যগণ আলাপ পাতায় তাদের চিন্তা তুলে ধরতে পারেন। For each of five parts of the user flow, we have two alternatives. We'll user test both to gain information from newcomers. Our user tests will take place in English and Spanish -- our team's first time testing in a non-English language. We also hope community members can consider the designs and provide their thoughts on the talk page.

 Prototypes for user testing 

The easiest way to experience what we're considering to build is through the interactive prototypes. We've built prototypes for both the "Concept A" and "Concept B" designs, and they are available in both English and Spanish. These are not actual wiki software, but rather a simulation of it. That means that no edits are actually saved, and not all the buttons and interactions work -- but the most important ones relevant to the "add an image" project do work.


 * Concept A (English)
 * Concept B (English)
 * Concept A (Spanish)
 * Concept B (Spanish)

 নমুনা 

নিচে নমুনার কিছু স্থিরচিত্র দেয়া হয়েছে, তবে সম্প্রদায়ের সদস্যদের গ্রোথ দলের নকশাকারীর ফিগমা ফাইল দেখার আমন্ত্রণ জানাচ্ছি। ক্যানভাসের নিচে ডানদিকে মকআপগুলো রয়েছে, এছাড়া বিভিন্ন উৎসের অনুপ্রেরণাও উল্লেখিত আছে।

ফিড

এই নকশা কাজের ধারার সবচেয়ে প্রথম অংশ নিয়ে আলোচনা করে, যেখানে ব্যবহারকারী পরামর্শকৃত সম্পাদনার নীড়পাতা থেকে নিবন্ধ নির্বাচন করেন। আমরা চাই কার্ডটি যেন আকর্ষণীয় হয়, তবে ব্যবহারকারীকে বিভ্রান্ত করে তুলতে চাইনা।

 Final designs for Iteration 1 

Based on the user test findings above, we created the set of designs that we are implementing for Iteration 1. The best way to explore those designs is here in the Figma file, which always contains the latest version.

Leading indicators
Whenever we deploy new features, we define a set of "leading indicators" that we will keep track of during the early stages of the experiment. These help us quickly identify if the feature is generally behaving as expected and allow us to notice if it is causing any damage to the wikis. Each leading indicator comes with a plan of action in case the defined threshold is reached, so that the team knows what to do.

We collected data on usage of "add an image" from deployment on November 29, 2021 until December 14, 2021. "Add an image" has only been made available on the mobile website, and is given to a random 50% of registrations on that platform (excluding our 20% overall control group). We therefore focus on mobile users registered after deployment. This dataset excluded known test accounts, and does not contain data from users who block event logging (e.g. through their ad blocker).

Overall: The most notable thing about the leading indicator data is how few edits have been completed so far: only 89 edits over the first two weeks. Over the first two weeks of "add a link", almost 300 edits were made. That feature was deployed to both desktop and mobile users, but that alone is not enough to make up the difference. The leading indicators below give some clues. For instance, task completion rate is notably low. We also notice that people do not do many of these tasks in a row, whereas with "add a link", users do dozens in a row. This is a prime area for future investigation.

Revert rate: We use edit tags to identify edits and reverts, and reverts have to be done within 48 hours of the edit. The latter is in line with common practices for reverts.

The "add an image" revert rate is comparable to the copyedit revert rate, and it’s significantly higher than "add a link" (using a test of proportions). Because "add an image" has a comparable revert rate to unstructured tasks, the threshold described in the leading indicator table is not met, and we do not have cause for alarm. That said, we are still looking into why reverts are occurring in order to make improvements. One issue we've noticed so far is a large number of users saving edits from outside the "add an image" workflow. They can do this by toggling to the visual editor, but it is happening so much more often than for "add a link" that we think there s something confusing about the "caption" step that is causing users to wander outside of it.

Rejection rate: We define an edit “session” as reaching the edit summary dialogue or the skip dialogue, at which point we count whether the recommended image was accepted, rejected, or skipped. Users can reach this dialogue multiple times, because we think that choosing to go back and review an image or edit the caption is a reasonable choice.

The threshold in the leading indicator table was a rejection rate of 40%, and this threshold has not been met. This means that users are rejecting suggestions at about the same rate as we expected, and we don't have reason to believe the algorithm is underperforming.

Over-acceptance rate: We reuse the concept of an "edit session" from the rejection rate analysis, and count the number of users who only have sessions where they accepted the image. In order to understand whether these users make many edits, we measure this for all users as well as for those with multiple edit sessionsfive or more edit sessions. In the table below, the "N total" column shows the total number of users with that number of edit sessions, and "N accepted all" the number of users who only have edit sessions where they accepted all suggested links.

It is clear that over-acceptance is not an issue in this dataset, because there are no users who have 5 or more completed image edits, and for those who have more than one, 38% of the users accepted all their suggestions. This is in the expected range, given that the algorithm is expected usually to make good suggestions.

Task completion rate: We define "starting a task" as having an impression of "machine suggestions mode". In other words, the user is loading the editor with an "add an image" task. Completing a task is defined as clicking to save the edit, or confirming that you skipped the suggested image.

The threshold defined in the leading indicator table is "lower than 55%", and this threshold has been met. This means we are concerned about why users do not make their way through the whole workflow, and we want to understand where they get stuck or drop out.