Growth/Personalized first day/Structured tasks/bn

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

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


 * একটি লিঙ্ক যুক্ত করুন
 * একটি ছবি যুক্ত করুন

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

 * 2020-05-01: পরিকল্প‌না ও নথিভুক্ত করণের প্রাথমিক টীকা
 * 2020-05-17: সম্প্রদায়ের আলোচনার শুরু
 * 2020-05-29: প্রাথমিক পরিসীমা নির্ধারণ
 * 2020-08-24: পরিকল্পনা বৈঠক সপ্তাহ
 * 2020-09-08: সর্বশেষ নকশা নিয়ে সম্প্রদায়ের আলোচনা আহ্বান
 * 2020-10-21: ব্যবহারকারী কর্তৃক ডেস্কটপ নকশা পরীক্ষণ

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

যদিও রক্ষণাবেক্ষণ টেমপ্লেট নবাগতদেরকে বিভিন্ন ধরণের সম্পাদনা করার সুযোগ দেয়, এটা সফলভাবে সম্পন্ন করা নবাগতদের জন্য বেশ বড় কাজ বা কিছুটা বিভ্রান্তির মধ্যে ফেলে। মোবাইল ডিভাইসের ক্ষুদ্র স্ক্রিনে উইকি-টেক্সট বা দৃশ্যমান সম্পাদনা নবাগতদের জন্য কষ্টকর হতে পারে।

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

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


 * 1) সঠিক নিবন্ধ অনুসন্ধান।
 * 2) যে তথ্যটি যুক্ত করতে চাই সেটা ইতিমধ্যে আছে কীনা বের করা।
 * 3) বাক্যটি কোথায় যুক্ত করতে হবে সেই অনুচ্ছেদ খুঁজে বের করা।
 * 4) সম্পাদনা শুরু করুকে ক্লিক করা।
 * 5) সঠিক স্থানে বাক্যটি টাইপ করা।
 * 6) উদ্ধৃত করুন বাটনে ক্লিক করা।
 * 7) মূল উৎসে ফিরে উদ্ধৃতিদানের লিঙ্ক বা তথ্য নেওয়া।
 * 8) উদ্ধৃত করুন ফর্মের তথ্যাবলী পূরণ করা।
 * 9) সম্পাদনা সংরক্ষণ করুনে ক্লিক করা।
 * 10) সম্পাদনা সারাংশ যুক্ত করা।
 * 11) সংরক্ষণ করা।

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

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


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

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

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

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

গ্রোথ দল এই একই পদ্ধতি নিবন্ধের বিষয়বস্তু সম্পাদনার ক্ষেত্রে প্রয়োগ করার কথা ভাবছে। যেমন লিঙ্ক যুক্ত করা, ছবি যুক্ত করা, তথ্যসূত্র যুক্ত করা, এবং বাক্য সংযোজন করা।

একটি কাঠামোবদ্ধ কাজের স্কেচ
আমরা কীভাবে কাঠামোবদ্ধ কাজ নিয়ে ভাবছি সেটা বর্ণনা করার সবচেয়ে ভালো উপায় হল একটি দ্রুত স্কেচ দেখানো। প্রথম যে কাঠামোবদ্ধ কাজ নিয়ে আমরা ভাবছি, সেটা হল "একটি (উইকি)লিঙ্ক যুক্ত করুন"। তবে একই ভাবনা "একটি ছবি যুক্ত করুন", "একটি তথ্যসূত্র যুক্ত করুন", বা "একটি তথ্য যুক্ত করুন" কাজের জন্যও প্রযোজ্য।

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

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



In thinking further about this, we sketched a second idea. Instead of being aimed toward teaching the newcomer to add links using the visual editor, this next workflow lets the user quickly confirm or reject recommendations from the algorithm, directly editing the article. While it does not teach them how to add links via the editor, it might help a newcomer edit at high volume, and might be a better fit for a user who is trying to be productive with simple tasks while they are on the go. Or perhaps might be a good fit for users who only are interested in very simple edits, similarly to how the Android app has many editors who only want to write title descriptions.



In thinking about structured tasks, it looks like this might be a big question: should workflows be more aimed toward teaching newcomers to use the traditional tools, or be more aimed toward newcomers being able to do easy edits at higher volume?

Why this idea is prioritized
We think that quickly making productive edits is what leads to newcomer success. Once they've done some edits, the rest of the wiki experience quickly becomes richer. Newcomers can then see their impact, get thanked, ask informed questions to their mentors, create their userpage, etc. Therefore, we want lots of newcomers to make their first edits as soon as possible. We have already seen from the newcomer tasks project that many newcomers are looking for easy tasks to do. But we also have observed these things:


 * Only about 25% of the newcomers who click on a suggestion actually edit it.
 * Only about 25% of those who do a suggested edit do another one.
 * There are a handful of newcomers who really thrive on suggested edits, doing dozens of them every day. This shows the potential for newcomers to accomplish a lot of wiki work.
 * In live user tests, when newcomers are told to copyedit an article or add links to an article, they frequently want to know exactly which sentence or words need their attention. In other words, attempting to edit the full article is too open-ended.

Taking these points along with the experiences described above of the Android and Content Translation teams, we think we could increase the number of newcomers editing and continuing to edit by structuring some of the content editing workflows in Wikipedia.

Opportunities with structured tasks
When we break down editing workflows into steps, we call them "structured tasks". Here are some of the possible benefits we think could come from structured tasks:


 * Make it easy for newcomers to make meaningful contributions.
 * Develop editing workflows that make sense for mobile. Mobile design principles tell us that users should see one step at a time, not a complicated workspace.
 * Let newcomers increase their skills incrementally. They could take on successfully more challenging types of tasks.
 * Let people find an editing experience that fits them. By giving newcomers a feed of structured tasks, they could find the type of tasks that they prefer.
 * Perhaps similar workflows could be opened to experienced editors in the future.

Concerns and downsides to structured tasks
Whenever we add new ways for people to edit Wikipedia, there are many things that can go wrong:


 * By making editing too quick and easy, we may attract vandals, or users who don't apply enough care when editing.
 * Giving newcomers simple workflows may keep them from learning the traditional editing tools, which are essential for doing the most impactful wiki work.
 * Structured tasks may not be good at accounting for differences across languages, idiosyncrasies with wikitext, and could cause other kinds of bugs.
 * Algorithms that surface structured tasks may not be accurate enough, and falsely encourage newcomers to complete edits they shouldn't.

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.