উইকিমিডিয়া ফাউন্ডেশনের বার্ষিক পরিকল্পনা/২০২৫-২০২৬/পণ্য ও প্রযুক্তির ওকেআরসমূহ (উদ্দেশ্য এবং মূল ফলাফলগুলি)

উইকিমিডিয়া ফাউন্ডেশন
Annual Plan 2025–2026

Wikimedia Foundation Annual Plan 2025–2026

• Summary
• Global Trends
• Progress
• Goals
  • Infrastructure
  • Volunteer Support
  • Effectiveness
• Financial Model
• Budget Overview
• Collaboration

আগামী বছর

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

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

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

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

স্বেচ্ছাসেবী বৃদ্ধিকে উৎসাহিত করা

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

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

বিশ্বস্ত বিশ্বকোষীয় বিষয়বস্তু প্রদান

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

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

নতুন সংকেত উন্মোচন করে (আইপি ঠিকানার বাইরে) আমরা আমাদের কার্যনির্বাহীদের সাহায্য করব বিষয়বস্তু রক্ষা করতে। এই প্রক্রিয়া অসৎ সম্পাদকদের চিহ্নিত করতে সাহায্য করবে, এবং ব্যবহারকারীদের এমনভাবে ব্লক করা যাবে যাতে সৎ সম্পাদকদের ভুলভাবে ব্লক হওয়া কমবে।

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

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

'মুক্ত' ভবিষ্যতের জন্য অর্থায়ন করুন

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

একটি পরিবর্তনশীল ইন্টারনেট গঠন

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

অবকাঠামোর মধ্যে একে তিনটি কাজের পোর্টফোলিওতে (যাকে “বাকেট” বলা হয়) বিভক্ত করা হয়েছে: উইকি এক্সপেরিয়েন্সেস, সিগন্যালস অ্যান্ড ডেটা সার্ভিসেস, এবং ফিউচার অডিয়েন্সেস। এই বাকেটগুলি আগের বছর এবং তার আগের বছরও একই ছিল।

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

আমাদের মূল্যবোধের ওপর ভিত্তি করে উইকিমিডিয়া প্রকল্প ও স্বেচ্ছাসেবকদের জন্য অবকাঠামোর নির্মাণ করা, উন্নতি ঘটানো এবং বাঁচিয়ে রাখা

"ফাউন্ডেশন তার প্রকল্পগুলির দরকারী তথ্য চিরস্থায়ীভাবে নিখরচায় ইন্টারনেটে উপলব্ধ করবে।"

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

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

আমরা মুক্ত-উৎসের সফটওয়্যার ডিজাইন এবং ডেভেলপ করি (বিশেষ করে মিডিয়াউইকি)। আমরা অনেক বিদ্যমান তৃতীয় পক্ষের মুক্ত উৎস অ্যাপ্লিকেশন, লাইব্রেরি ও ফ্রেমওয়ার্ক ব্যবহার এবং স্থাপন করি। আমাদের সফ্টওয়্যারের গুরুত্বপূর্ণ ত্রুটিগুলিকে অগ্রাধিকার দিয়ে ঠিক করা হয়। মুক্ত-উৎসের সফ্টওয়্যার রক্ষণাবেক্ষণের জন্য মুক্ত-উৎসের সফ্টওয়্যার ডেভেলপমেন্ট, সাইট রিলায়েবিলিটি ইঞ্জিনিয়ারিং (এসআরই), পণ্য ব্যবস্থাপনা, প্রোগ্রাম ব্যবস্থাপনা, ডিজাইন এবং আরও অনেক কিছুতে বিশেষ দক্ষতা সম্পন্ন ব্যক্তিদের কাছ থেকে অত্যন্ত দক্ষ কাজের প্রয়োজন হয়। আমাদের কর্মীরা আমাদের সফ্টওয়্যার ও সিস্টেমগুলির হালনাগাদ করেন এবং পরিবর্তনশীল পরিবেশের সাথে খাপ খাইয়ে নেওয়ার জন্য কাজ করেন। এর মধ্যে রয়েছে আমাদের কোড আধুনিকীকরণ যাতে আমরা নিরাপত্তাজনিত ব্যবস্থা সংশোধনের সুবিধা পেতে পারি এবং নতুন তৃতীয় পক্ষের সফ্টওয়্যারের সাথে ভালভাবে কাজ করতে পারি। উদাহরণস্বরূপ, মিডিয়াউইকি পিএইচপিতে লেখা হয়, এবং গত বছর আমরা পিএইচপি ৭.৪ থেকে ৮.১ এ উন্নীত হয়েছি, যার জন্য আমাদের সাইট এবং পরিষেবাগুলি যেখানে হোস্ট করি সেই কোড এবং অবকাঠামো উভয় ক্ষেত্রেই পরিবর্তন করার প্রয়োজন হয়েছিল। এই বছর, আমরা সেই প্রচেষ্টার ওপর ভিত্তি করে কাজ করব এবং ৮.১ সংস্করণের আপগ্রেড থেকে নেওয়া শিক্ষা ও উন্নত সরঞ্জামগুলি ব্যবহার করে ৮.৩ সংস্করণে উন্নীত হব। হালনাগাদ করার ফলে আমাদের সিস্টেমগুলি পাঠকদের কাছে দ্রুততর হবে, কর্মী ও স্বেচ্ছাসেবকদের জন্য ব্যবহার করা সহজ হবে এবং সকলের জন্য আরও নিরাপদ হবে। ভাষার হালনাগাদ করলে নিরাপত্তা, কর্মক্ষমতা এবং সহায়তার উন্নতি ঘটবে, যার ফলে ভবিষ্যতেও কম সময়ে উন্নয়ন করা যাবে।

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

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

পণ্য ও প্রযুক্তিগত উদ্দেশ্য

এখানে উপস্থাপিত উদ্দেশ্যগুলি খসড়া আকারে আছে এবং মন্তব্য ও আলোচনার জন্য উন্মুক্ত রয়েছে।

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

উইকি অভিজ্ঞতা (উই)

অবদানকারীর অভিজ্ঞতা (উই১)

• উদ্দেশ্য: স্বেচ্ছাসেবীদের আকর্ষণীয় সুযোগ দেওয়া হয় এবং তাদের প্রভাব বুঝতে সাহায্য করার ফলে অবদান বৃদ্ধি পায়। আলোচনা
  • প্রসঙ্গ: উদ্দেশ্য হবে নতুন অবদানকারী কৌশল বাস্তবায়নের ভিত্তি, যার ৩টি স্তম্ভ রয়েছে: ১) স্বেচ্ছাসেবকদের তাদের উইকি-ভিত্তিক কার্যকলাপ সংগঠিত করার জন্য একটি কেন্দ্রীভূত উপায় প্রদান করা, ২) আরও পরিষ্কারভাবে বুঝতে সাহায্য করার জন্য ছোট ছোট, পৃথক্ কাজ প্রদান করা এবং স্বেচ্ছাসেবকদের তাদের ক্ষমতা অর্জনে সহায়তা করা, এবং ৩) অবদানকে আরও অর্থবহ করে তোলা। ২৫/২৬ অর্থবছরে, স্বেচ্ছাসেবকেরা যাতে তাঁদের উইকি কার্যক্রম কেন্দ্রীয়ভাবে সংগঠিত করতে পারেন তাতে সাহায্য করার জন্য আমরা মৌলিক অবকাঠামো সরবরাহ করার পরিকল্পনা করছি, এটি বিশেষভাবে অভিজ্ঞ সম্পাদক এবং মডারেটরদের ওপর কেন্দ্র করে কাজ দিয়ে শুরু হবে। পরবর্তী বছরগুলিতে আমরা সকল ভূমিকার অবদানকারীদের জন্য প্রবেশ যুক্ত করব এবং আরও সমস্যা স্থান অন্তর্ভুক্ত করব। অতিরিক্তভাবে, আমরা সম্পাদনা পরীক্ষা এবং গঠনমূলক কাজগুলিতে বিনিয়োগ চালিয়ে যাব; সম্পাদনা প্রক্রিয়ার সময় নির্দেশনা হিসাবে এবং স্বেচ্ছাসেবকদের আকর্ষণীয় সুযোগের দিকে পরিচালিত করার উপায় হিসাবে, এআই কিভাবে একটি বর্ধনশীলভাবে কার্যকর উপায়ে ব্যবহার করা যায় তার ভিত্তি তৈরি করব। এবং সবশেষে, আমরা স্বেচ্ছাসেবকদের প্রভাব আরও দৃশ্যমান করার জন্য বিনিয়োগ করব যাতে তাদের জন্য আরও অর্থপূর্ণ অভিজ্ঞতা তৈরি করা যায়।
    • মূল ফলাফল উই১.১: নিয়ন্ত্রিত পরীক্ষা-নিরীক্ষার মাধ্যমে পরিমাপ করা (দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ) ≤১০০ মোট সম্পাদনা সহ সম্পাদকদের মোবাইল ওয়েবে গঠনমূলক সম্পাদনা [i] প্রকাশের হার ৪% বৃদ্ধি করা [ii]।
      • i. "গঠনমূলক সম্পাদনা" = উইকিপিডিয়ার মূল নামস্থানের এমন পাতাগুলির সম্পাদনা যা প্রকাশিত হওয়ার ৪৮ ঘন্টার মধ্যে প্রত্যাবর্তন করা হয় না।
      • ii. T389403#10960480
      • নতুন(তম) স্বেচ্ছাসেবকদের সম্পাদনা সফলভাবে শুরু করতে সমস্যা হয়। বিশেষ করে, যাঁরা মোবাইল ডিভাইস ব্যবহার করেন, যেখানে স্ক্রিনের জায়গা সীমিত থাকে এবং মনোযোগ প্রায়শই বিঘ্নিত হয়।
      • কেউ কেউ গঠনমূলক অবদান রাখার জন্য প্রয়োজনীয় প্রেক্ষাপট, ধৈর্য এবং পরীক্ষা-ত্রুটি (ট্রায়াল-এরর) দেখে ক্লান্ত হয়ে পড়েন। অন্য অনেকে চেষ্টা করার মতো জোরালো সুযোগ পাননি।
      • উই ১.১ এই সমস্যাগুলি সমাধান করবে:
        • সম্পাদনা সংক্রান্ত পরামর্শ সামনে এনে
        • সম্পাদনা সংক্রান্ত কার্যক্ষম নির্দেশিকা প্রদান করে
        • আরও কার্য-নির্দিষ্ট সম্পাদনা কর্মপ্রবাহ তৈরি করে
      • এই প্রচেষ্টার মূলে রয়েছে চলমান সম্পাদনা এবং বিদ্যমান বিষয়বস্তু কিভাবে উন্নত করা যেতে পারে তা সনাক্ত করার জন্য মাপনযোগ্য উপায়গুলির প্রয়োজনীয়তা। এই ক্ষমতা বৃদ্ধির জন্য, এটি কি করে সম্পাদকদের ভূমিকা এবং অভিজ্ঞতার স্তরে সবচেয়ে ভালোভাবে সাহায্য করতে পারে তা শেখার জন্য আমরা মেশিন শিক্ষণ নিয়ে পরীক্ষা-নিরীক্ষা চালিয়ে যাব।
      • প্রস্তাবিত কেআর স্কোরিং পদ্ধতি: প্রতিটি প্ল্যাটফর্মের ভিত্তিতে, আমরা যে পরিমাণ প্রবেশ মোতায়েন করেছি এবং মূল্যায়ন করেছি, নিয়ন্ত্রিত পরীক্ষা-নিরীক্ষার মাধ্যমে তার অনুপাত গণনা করব, এই বছরের শুরুতে আমরা গঠনমূলক সম্পাদনার যে লক্ষ্যমাত্রা নির্ধারণ করেছি তা পূরণ করেছে এবং/অথবা অতিক্রম করেছে কিনা। চিন্তাভাবনার জন্য phab:T379285#10782051 দেখুন।
        • বিঃদ্রঃ: ২০২৫ সালের ৩০শে জুন তারিখে, উই ১.১-এর দুটি নিয়ন্ত্রিত পরীক্ষার পরিকল্পনা রয়েছে।
    • মূল ফলাফল উই১.২: চতুর্থ প্রান্তিকের শেষে উইকিতে সহযোগিতার সংখ্যা ৫৫% বার্ষিক বৃদ্ধি।
      • অবদানকারীরা প্রায়শই একে অপরের সাথে সহযোগিতা করার সুযোগ পাওয়া নিয়ে সমস্যায় পড়েন, বিশেষ করে নিজেদের পছন্দের বিষয় এবং কাজগুলির ক্ষেত্রে। তার ফলে নতুনদের উইকিতে একা লাগতে পারে এবং অভিজ্ঞ সম্পাদকদের কাছে এটি ক্লান্তিকর হতে পারে। উপরন্তু, সহযোগিতামূলক কার্যকলাপের প্রভাব প্রায়শই পরিষ্কার বোঝা যায়না, যার ফলে উইকিতে যোগদান, কিছু সংগঠিত করা বা সহযোগিতাকে সমর্থন করার জন্য আগ্রহ খুব কম লোকের মধ্যেই তৈরি হতে পারে।
      • আমরা নিম্নলিখিত কাজগুলি করে সহযোগিতার মূল্য আরও স্পষ্ট করতে চাই:
      1. উইকিগুলিতে সহযোগী কার্যকলাপের প্রভাব জানানোর জন্য নতুন উপায় তৈরি করা।
      2. সহযোগিতামূলক কার্যকলাপের প্রভাব সম্পর্কে আন্দোলন জুড়ে তথ্য সংগ্রহ শুরু করা।
      3. সহযোগিতামূলক অবদানের ওপর নজর রাখার জন্য মৌলিক পরিকাঠামো তৈরি করা, যাতে আমরা ভবিষ্যতে অবদানগুলিকে স্বীকৃতি দেওয়া ও পুরস্কৃত করার জন্য উদ্ভাবনীমূলক নতুন উপায় প্রদান করতে পারি।
      • ক্যাম্পেনইভেন্টস এক্সটেনশনের ইভেন্ট রেজিস্ট্রেশনের মাধ্যমে তৈরি নতুন কার্যক্রমগুলির সাহায্যে সহযোগিতা পরিমাপ করা হবে। এর লক্ষ্য হল, এই কেআর-এর শেষে, আমাদের কাছে এক্সটেনশন সরঞ্জামগুলি ব্যবহার করার জন্য আরও বেশি ব্যবহারকারী থাকবেন এবং সহযোগিতার প্রভাবকে প্রকাশ করার নতুন উপায় থাকবে। এটি আমাদেরকে এমন একটি অবস্থানে নিয়ে যাবে যেখানে আমরা আমাদের বর্তমান পরিকাঠামোকে উইকির কাজকে স্বীকৃতি ও পুরস্কৃত করার অন্যান্য উপায়ের (যেমন ইমপ্যাক্ট মডিউল, থ্যাঙ্কস ইত্যাদি) সাথে যুক্ত করতে পারব।
      • ইচ্ছা তালিকার ফোকাস এরিয়া: সম্প্রদায়ের ইচ্ছা তালিকা/ফোকাস এরিয়া/সংযোগকারী অবদানকারী
    • মূল ফলাফল উই১.৩: তৃতীয় ত্রৈমাসিকের শেষে, নতুন মডারেটরদের জন্য তৈরি করা প্রধান পাতা যাঁদের দেওয়া হয়েছিল, তাঁদের মধ্যে ১০% পরপর দুই সপ্তাহ ধরে এটি পরিদর্শন করেছেন।
      • আমরা বিশ্বাস করি যে স্বেচ্ছাসেবকদের অবদানের সুযোগগুলি সামনে আনার জন্য আমরা আরও ভাল কাজ করতে পারি। দীর্ঘমেয়াদীতে আমরা বিশ্বাস করি যে কোনও সম্পাদকের জন্য প্রধান পাতা তাঁদের কাজ সংগঠিত করতে, নতুন সুযোগ খুঁজে পেতে এবং সেগুলির প্রভাব বুঝতে সহায়ক হতে পারে। অর্থবর্ষ ২৫/২৬-এ আমাদের লক্ষ্য হল অভিজ্ঞ সম্পাদকদের সামনে এমন নতুন সুযোগ তুলে ধরা, যেখানে তাঁরা সাধারনভাবে যেসব নিয়ন্ত্রণ বা তদারকির কাজের সঙ্গে যুক্ত নন, সেগুলিতেও অংশ নেওয়ার সুযোগ পাবেন।
      • আমরা প্রথমে এই তত্ত্বটি পরীক্ষা করব এইভাবে যে, অভিজ্ঞ সম্পাদকরা প্রধান পাতার সঙ্গে কতটা যুক্ত হন — যেটি নবাগত ব্যবহারকারীদের জন্যও একইভাবে প্রাপ্য — তা বোঝার মাধ্যমে।
      • এরপর আমরা নির্দিষ্ট নিয়ন্ত্রণ কার্যক্রম (বিস্তারিত নির্ধারণ করা হবে) সেইসব অবদানকারীদের সামনে তুলে ধরব যাঁরা এই ধরণের নিয়ন্ত্রণ কার্যক্রমে নতুন, এর লক্ষ্য হল ব্যাকলগের বোঝা কমিয়ে অভিজ্ঞ সম্পাদকদের ওপর চাপ কমাতে সাহায্য করা (নতুন কেআর অনুযায়ী)।
      • যদি প্রধান পাতার ধারণাটি সফল হয়, তাহলে আমরা এই পাতাটিকে সম্প্রদায়ের চাহিদা পূরণের জন্য মডিউলার করার পরিকল্পনা করছি। সম্পাদকেরা যাতে তাঁদের প্রভাব সহজে বুঝতে পারেন এই মডিউলগুলিতে এমন বিষয় অন্তর্ভুক্ত থাকতে পারে।
      • পদ্ধতি সম্পর্কে টীকা:
      • আমরা আমাদের পাঠক গোষ্ঠী নির্ধারণ করার জন্য একটি অনুমান স্থাপন করব, যা উই১.৩.১ এর অংশ হবে।
      • "মডারেটর" Research:Develop a working definition for moderation activity and moderators থেকে শুরু হওয়া সংজ্ঞা অনুসরণ করবেন, যদিও পরিমাণ মূলক সংজ্ঞাটি সংকুচিত করার জন্য পরবর্তী কাজের প্রয়োজন হবে।
      • প্রতিটি ব্যবহারকারীর প্রথম পরিদর্শনের সময় অনুসারে দ্বিতীয় সপ্তাহ নির্ধারণ করা হবে। এই ক্ষেত্রে, আমরা সেই সমস্ত নতুন মডারেটরদের পর্যালোচনা করব যাঁরা একটি নির্দিষ্ট সময়সীমার মধ্যে প্রধান পাতাটি পরিদর্শন করেছেন এবং তারপরে কমপক্ষে আরও একবার (৭ থেকে ১৪ দিন) এর পুনরাবৃত্তি করেছেন।
      • ইচ্ছা তালিকার ফোকাস এরিয়া: সম্প্রদায়ের ইচ্ছা তালিকা/ফোকাস এরিয়া/কাজের অগ্রাধিকার
    • মূল ফলাফল উই১.৪: নজরে-রাখুন পাতা এবং/অথবা সাম্প্রতিক পরিবর্তনসমূহ পাতা, যেখানে ক্লিক করলে কোনো সম্পাদনা দেখা যায়, সেই পাতায় পরিভ্রমণকারী অনন্য দর্শকদের শতাংশ বৃদ্ধি করা।
      • আমাদের লক্ষ্য হল যে সব সম্পাদকের ১০০+ সম্পাদনা আছে তাঁদের আগ্রহের সাথে সম্পর্কিত বিষয়গুলি আরও দক্ষতার সাথে খুঁজে পেতে সম্পাদনার জন্য খুলতে সাহায্য করা। আমরা কার্য অগ্রাধিকার ফোকাস এরিয়া অন্বেষণ করব, এখানে শুভেচ্ছাবাণী রাখব এবং এই পাতাগুলি কিভাবে উন্নত করা যায় সে সম্পর্কে স্বেচ্ছাসেবকদের কাছ থেকে অতিরিক্ত প্রতিক্রিয়ার জন্য অনুরোধ করব। প্রতিটি পাতার ‘কাজ খোঁজার’ দক্ষতা বাড়িয়ে আমরা সাফল্য পরিমাপ করতে পারি, যা ক্লিক-থ্রু রেট নামক সূচক মানদণ্ড দ্বারা নির্ধারিত হয়।
    • মূল ফলাফল উই১.৫: চতুর্থ ত্রৈমাসিকের শেষ নাগাদ একটি ড্যাশবোর্ড তৈরি এবং ‘মাসিক সক্রিয় মডারেটর’ মানদণ্ড বাস্তবায়নের মাধ্যমে, কন্ট্রিবিউটর স্ট্র্যাটেজিতে নির্ধারিত লক্ষ‍্যসমূহ অর্জনের অগ্রগতি পর্যালোচনা করার জন্য সাতটি উচ্চ-অগ্রাধিকার [১] মানদণ্ড নির্ধারণ ও কার্যকর করা।
      [১] থেকে যাওয়া সম্পাদক, গঠনমূলক সক্রিয়করণ, গঠনমূলক সম্পাদনা, অ্যাকাউন্ট নিবন্ধন করে থেকে যাওয়া নতুন সম্পাদক, মেয়াদ অনুসারে সক্রিয় সম্পাদক, অভিজ্ঞতা স্তর অনুসারে সক্রিয় সম্পাদক।
      • অবদানকারী অভিজ্ঞতা কৌশলটিতে "স্বেচ্ছাসেবক বৃদ্ধিকে উৎসাহিত করার" জন্য এবং নতুন ও বিদ্যমান অবদানকারীদের "ধারণ এবং সক্রিয়করণ বৃদ্ধি" করার জন্য ৩-৫ বছরের প্রচেষ্টা তিনটি প্রধান ক্ষেত্রের কার্যক্রমের মাধ্যমে পরিকল্পনা করা হয়েছে:
      1. স্বেচ্ছাসেবকরা কিভাবে সুপারিশ পেতে পারেন, নিজেদের কাজ ও আগ্রহের বিষয় উভয়কেই দক্ষতার সাথে এগিয়ে নিয়ে যেতে পারেন, উইকিতে কি ঘটছে তা দেখতে পারেন এবং তাদের প্রভাব বুঝতে পারেন তার সুবিন্যস্তকরণ
      2. আরও স্পষ্টতা তৈরির জন্য যথাযথভাবে কাঠামোগত কাজ প্রদান এবং স্বেচ্ছাসেবকদের দক্ষতা বৃদ্ধিতে সহায়তা করতে তাদের কাছে আমরা যে সর্বোত্তম কর্মপ্রবাহ পাঠাই, বিশেষ করে মোবাইল ওয়েব অভিজ্ঞতাকে কেন্দ্র করে তার মধ্যে আছে কাঠামোগত নির্দেশনা প্রদানে এবং পুনরাবৃত্তিমূলক কাজগুলিকে স্বয়ংক্রিয় করার জন্য একটি বিনিয়োগ ব্যবস্থা অব্যাহত রাখা
      3. স্বেচ্ছাসেবকদের তাদের অবদানের প্রভাব দেখিয়ে অবদানকে অর্থপূর্ণ করে তোলা এবং ইতিবাচক প্রতিক্রিয়ার ওপর ভিত্তি করে মানব সংযোগ ও পরিবেশের জন্য বিনিয়োগ করা
      • এরপর পরিবর্তনের এই তত্ত্বটি পর্যালোচনা করার জন্য একটি পরিমাপ কৌশল প্রকল্পের মাধ্যমে মানদণ্ডের একটি বিস্তৃত নেটওয়ার্ক প্রস্তুত করা হয়। উপসংহারে বলা যায় যে যে সাফল্যের প্রাথমিক পরিমাপ ("মূল মানদণ্ড") হওয়া উচিত থেকে যাওয়া সম্পাদকের সংখ্যা। এর সঙ্গে কাজ করবে একটি সংকীর্ণ সূচক মানদণ্ড, যেমন গঠনমূলক সক্রিয়তা এবং অবদানকারীদের ফিরে আসার ইচ্ছা। এরসঙ্গে থাকবে বৃহত্তর "ডাউনস্ট্রিম" মানদণ্ড, যেমন সক্রিয় সম্পাদক এবং মানসম্পন্ন সম্পাদনা। এই মানদণ্ডগুলিকে কার্যকর এবং একটি ড্যাশবোর্ডে দৃশ্যমান করা আমাদের নিশ্চিত করতে হবে, যাতে কৌশলটির বাস্তবায়নের দিকে আমরা আমাদের অগ্রগতি মাপতে পারি।
    • Key result WE1.6: By the end of Q3, watchlist users can more easily organize their work and act more effectively on taking patrolling or editing action, as measured by qualitative feedback.
      • Our goal is to help editors with 100+ edits to more efficiently find edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces.
    • Key result WE1.7: Primary: Achieve a ≥ 10% relative increase in the edit completion rate of qualified newcomer and Junior Contributor mobile edit sessions, based on controlled A/B test(s).[i]
      [i] Qualified edit session = edit session in which a logged-in user with ≤100 cumulative edits spent at least ≥2 seconds in VE's "ready" state.
      Guardrail: No meaningful decreases in constructive edit rate among mobile edits published by newcomer and Junior Contributors, based on controlled A/B test(s).
      • 150,000–200,000 times/day, someone will tap "Edit" on mobile web, wait for the editing interface to load, look around for at least 2 seconds, and then leave without doing anything. No keystrokes, no taps on the toolbar…nothing.
      • WE 1.7 will meet these "curious clicks" with clear, compelling, and structured edit suggestions that cause the people making them to experience the satisfaction, joy, and meaning that can come with making Wikipedia, the resource they chose to visit, a bit better.
    • Key result WE1.8: By the end of Q4, target a 5 percent overall relative increase in the mobile web account creation completion rate, with success measured by at least three controlled experiments achieving a minimum 2 percent relative improvement each.
      • Account creation is the gateway to meaningful participation on Wikimedia projects, yet it remains an outdated experience in the newcomer journey. The current flows impose high cognitive load, present limited or confusing value propositions, and rely on legacy interface patterns that no longer reflect contemporary expectations. As a result, many potential contributors disengage before they have a chance to join the community.
      • This initiative aims to modernize account creation, reduce friction for good faith contributors, and introduce thoughtful experiments that encourage registration at the moments where motivation is naturally highest. The work lays essential groundwork for long term improvements in newcomer activation, retention, and editor diversity.
      • We estimate a 5 percent relative increase in account creation on Wikipedia on mobile would translate to several thousand additional new accounts per month, and several hundred more retained new editors per month, based on current registration volumes.
    • Key result WE1.9: By the end of Q4, deliver one tangible product recommendation each for goal setting, newcomer progression, and recognition to enable junior contributors to stay engaged and evolve.
      • Background: we know that retention of junior contributors is quite low despite recent gains (data). We believe that a fundamental challenge for overcoming this low junior contributor retention is developing our platforms to help editors stay highly motivated to contribute – i.e. not just reducing the barrier to contribute but also making the experience rewarding. This is not trivial though – e.g., editors enter the project with varying motivations; interventions such as gamification that may boost initial engagement might not help with long-term retention.
      • Why now: much of the focus of Contributors Product teams to date has been related to reducing technical barriers to activation/engagement but there are a suite of upcoming projects that are more retention-focused – e.g., Progression System and Recognition. The research under this KR aims to get ahead of this implementation work and provide clear recommendations to Product teams in this space about how they should design their platforms to better support the diverse motivations of editors and increase long-term retention. This links back to key questions related to newcomers and junior editors in the Contributor Strategy.
      • Proposed KR scoring methodology: for each identified project (goal setting; progression system; recognition), we will make at least one concrete recommendation with implications for design. Research is experimental work and the projects may evolve over the course of the KR but we will keep in close communication with the relevant product teams. In practice, these recommendations may include insights about what is most demotivating for newcomers (things to avoid) what is most satisfying (things to emphasize), common "tripping points" in journeys that need to be addressed, strategies for getting through these challenges, etc. The recommendation should help the PM identify clear next steps for design and/or engineering.
    • Key result WE1.10: By the end of Q4, implement a new guided article creation flow where the survival rate of articles created by junior editors on mobile is 5% greater on each deployed wiki than articles created by other means while the volume of surviving articles stays the same or higher, as measured by a controlled experiment.
      • The Article guidance initiative aims to develop new approaches that support editors in creating initial, well-structured contributions to Wikipedia that align with community policies and content quality. As an initial intervention, a new workflow for article creation was implemented last quarter, based on community-editable outlines that encapsulate the guidance for specific types of articles. In Q4, the goal is to run an A/B test experiment to measure the impact on a set of pilot wikis to evaluate the impact. Since the guidance is community-dependent, the experiment preparations will requires collaboration with the communities of the pilot wikis to adapt the system to their needs.

---

গুরুত্বপূর্ণ জ্ঞান (উই২)

• উদ্দেশ্য: ভাষা এবং বিষয়গুলিতে আরও গুরুত্বপূর্ণ জ্ঞান উপলব্ধ করা এবং ভালভাবে বর্ণনা করা। আলোচনা
  • উদ্দেশ্যমূলক প্রেক্ষাপট: এই লক্ষ্যটি এমন ধরনের বিষয়বস্তু বৃদ্ধিকে উৎসাহিত করবে, যেটি একদিকে যেমন নির্দিষ্ট বিষয় ও ভাষার প্রতি অবদানকারীদের আগ্রহের সাথে সামঞ্জস্যপূর্ণ, তেমনই অন্যদিকে পাঠকদের প্রয়োজনীয় চিত্রসহ স্পষ্টভাবে উপস্থাপিত জ্ঞান অর্জনের চাহিদার প্রতি সাড়া দেয়। গুরুত্বপূর্ণ জ্ঞান হল কিছু নিবন্ধের একটি সেট যা একটি ব্যবহারযোগ্য উইকিপিডিয়া ভাষা প্রকল্পের জন্য প্রয়োজনীয় বিষয়গুলিকে প্রশস্ততা এবং গভীরতা প্রদান করে। নিবন্ধগুলির উল্লেখযোগ্যতা, প্রাসঙ্গিকতা, সম্ভাব্য পাঠকসংখ্যা এবং তাদের পারস্পরিক সংযোগের ভিত্তিতে সেগুলি সম্প্রদায় দ্বারা নির্ধারিত হয়।
  • আমরা একটি সামাজিক-প্রযুক্তিগত পদ্ধতি গ্রহণ করব, বৈশিষ্ট্য, সরঞ্জাম এবং সামাজিক প্রক্রিয়াগুলির কার্যকারিতা উন্নত করব। আমরা প্রস্তাবিত কাজ, মিডিয়া অনুসন্ধান এবং বিষয়বস্তু অনুবাদের মতো উচ্চ-প্রভাবশালী পণ্য বৈশিষ্ট্যগুলির ওপর ভিত্তি করে এটি তৈরি করব, তবে ছোট ভাষার উইকিপিডিয়াগুলির শুরু হওয়া এবং বিকাশকেও সহজতর করব। আমরা সেই উইকিমিডিয়া আয়োজকদের সমর্থন করব, যারা নিয়োগ, প্রশিক্ষণ এবং সহযোগিতামূলক সেটআপ যেমন উইকি-প্রজেক্ট এবং প্রচারণার মাধ্যমে অংশগ্রহণকারীদেরকে বিষয়বস্তু সংক্রান্ত যৌথ লক্ষ্য নিয়ে কাজ করতে সাহায্য করে। উৎস উপকরণের প্রতিবন্ধকতা দূর করার জন্য আমরা সবচেয়ে প্রাসঙ্গিক প্রকাশকদের সাথেও সম্পর্ক গড়ে তুলব। (বর্তমানে বিশ্বের শীর্ষ ১০০ টিরও বেশি সাবস্ক্রিপশন-কেবল ডাটাবেসের সাথে আমাদের অংশীদারিত্ব রয়েছে।)
  • আমাদের হস্তক্ষেপগুলি যাতে গুরুত্বপূর্ণ জ্ঞানের ওপর ইতিবাচক প্রভাব ফেলতে পারে তা নিশ্চিত করার জন্য, আমরা সম্প্রদায়-অগ্রাধিকারপ্রাপ্ত সামগ্রীর বৃদ্ধি এবং সেই সামগ্রীর গুণমান উভয়ই পরিমাপ করব, এছাড়াও নিবন্ধের পূর্বাবস্থায় ফেরার হার এবং উদ্ধৃতি ও চিত্রের সংখ্যার মতো বিষয়গুলিও আমরা বিবেচনা করে।
    • মূল ফলাফল উই২.১: দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ, ৩টি পদক্ষেপের পরীক্ষা এবং মূল্যায়ন করা যা অবদানকারীদের তাদের উইকিপিডিয়ার গুরুত্বপূর্ণ বিষয়বস্তুর অবস্থা উন্নত করতে সাহায্য করবে।
      • এই কেআর সম্পাদনা ব্যবস্থার মধ্যে বিষয়বস্তুর অভাবগুলি তুলে ধরবে, যেমন উইকিপিডিয়ায় চিত্র খুঁজে বার করা, বিষয়বস্তু অনুবাদ করা এবং নতুন নিবন্ধের নির্দেশিত সৃষ্টি করা। আমরা ছোট ভাষা সম্প্রদায়ের জন্য বিষয়বস্তু তৈরির কার্যকলাপকে সমর্থন করার উদ্দেশ্যে একটি সামাজিক-প্রযুক্তিগত হস্তক্ষেপের বাস্তবায়ন এবং পরীক্ষাও করব। প্রতিটি পরিকল্পনার ভিত্তিতে সাফল্য মূল্যায়ন করা হবে
    • মূল ফলাফল উই২.২: চতুর্থ ত্রৈমাসিকের শেষ নাগাদ, আমরা যে বৃহৎ পরিসরে বিমূর্ত উইকিপিডিয়ার দৃষ্টিভঙ্গিকে সমর্থন করতে পারি তা যাচাই করার জন্য প্রয়োজনীয় প্ল্যাটফর্ম সক্ষমতা তৈরি করব। আমরা যদি দেখাই উইকিউপাত্ত এবং প্রাকৃতিক ভাষা তৈরির মাধ্যমে সিস্টেমের আউটপুট সমৃদ্ধ, বহুভাষিক বিশ্বকোষীয় বিষয়বস্তু প্রদর্শন করছে, যা উইকিমিডিয়া সম্প্রদায় দ্বারা নিয়ন্ত্রিত হয় এবং বিস্তৃত প্রচারণায় কার্যকর থাকে, তাহলে আমরা বুঝব যে আমরা সফল।
      • এখন যেহেতু আমরা উইকিউপাত্ত ব্যবহার করে উইকিপিডিয়াতে মৌলিক, সাধারণ পাঠ্য সামগ্রী দিতে পারি, পরবর্তী পদক্ষেপটি হল প্ল্যাটফর্মের এমন সক্ষমতা তৈরি করা যা বিমূর্ত উইকিপিডিয়াকে বৃহৎ পরিসরে সমর্থন করতে পারে। এই প্ল্যাটফর্মটিকে সমৃদ্ধ, বহুভাষিক বিষয়বস্তু সমর্থন করতে হবে যা সম্প্রদায় দ্বারা নিয়ন্ত্রিত হতে পারে এবং ব্যাপকভাবে কর্মক্ষম থাকতে পারে। যেহেতু আমরা ০ থেকে ১-এ যাচ্ছি, এটি একটি কেআর মাইলফলক।
    • মূল ফলাফল উই২.৩: চতুর্থ ত্রৈমাসিকের শেষের দিকে, সম্প্রদায়ের মাধ্যমে বিমূর্ত নিবন্ধগুলির প্রাথমিক পর্যায়ের সৃষ্টির জন্য নতুন উইকির প্রাথমিক রূপটি চালু করা।
      • আগামী বছর এই কেআর একটি বিমূর্ত উইকির প্ল্যাটফর্ম ক্ষমতা পরীক্ষা করার জন্য আমাদের প্রস্তুত করবে। নতুন, স্বতন্ত্র উইকিতে উইকিফাংশনের ওপর নির্মিত বিমূর্ত নিবন্ধের লাইব্রেরি থাকবে, এবং ভবিষ্যতে উইকিপিডিয়ায় বিমূর্ত নিবন্ধগুলিকে একীভূত করার জন্য প্রয়োজনীয় প্ল্যাটফর্ম ক্ষমতা প্রদান করে।
    • মূল ফলাফল উই২.৪: ২৫-২৬ অর্থবছর পর্যন্ত লক্ষ্য ও পরিমাপসহ উইকিউপাত্ত সংক্রান্ত একটি গুরুত্বপূর্ণ ব্যবহারক্ষেত্রকে সহায়তা করার জন্য প্রযুক্তিগত অবকাঠামোর উন্নয়নের সফলতার সংজ্ঞা নিয়ে ডব্লিউএমএফ এবং ডব্লিউএমডিই-র মধ্যে সমন্বয় সাধন করা, যা দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ সম্পন্ন হবে।
      • ডব্লিউএমএফ উইকিউপাত্ত প্ল্যাটফর্ম (ডব্লিউডিপি) দল ২০২৫ সালের আগস্টে প্রতিষ্ঠিত হয়েছে এবং সেখানে কর্মচারী নিযুক্ত করা হয়েছে - কর্মচারীদের মধ্যে আছেন একজন প্রোডাক্ট দলের নেতা এবং একজন প্রযুক্তি দলের নেতা। ডাব্লুএমএফ এবং ডাব্লুএমডিই-এর প্রযুক্তিগত ও পণ্য মালিকদের বহু বছরের উন্নয়নের মাধ্যমে গঠিত একটি প্রোগ্রামে নতুন সংযোজন হিসেবে, এই লক্ষ্যটি আমাদের উদ্দেশ্যকে প্রতিফলিত করে — ব্যবহারক্ষেত্র, নির্ভরতা এবং মূল সাফল্যের মানদণ্ডে সমন্বয়ের মাধ্যমে দায়িত্ব হস্তান্তরের দিকে অগ্রসর হওয়া। এই কেআর সমস্যা ক্ষেত্র সম্পর্কে পারস্পরিক বোঝাপড়ার ভিত্তি তৈরি করবে, যা আমরা অর্থবছরের বাকি সময় ধরে (মে ২০২৬) গড়ে তুলব।
    • Key result WE2.5: By the end of Q4, our backend replacement has been stood up in parallel to Blazegraph and is capable of supporting the cutover of select users. We define “migration ready” for this KR as capable of supporting the pilot phase of our migration in Q1 of FY26-27.
      • Following the progress made towards defining the success criteria as a part of WE2.4, we are now shifting into execution mode. In the next two quarters, we will outline all of the variables associated with the Blazegraph cutover in a migration plan, determine which are critical for pilot launch, implement them in a new RDF database, and define the migration timeline for all requirements beyond our pilot personas. Our work between now and our target launch of a new WDQS backend (est. July 2026) will be guided by the requirements laid out in this plan.

---

ভোক্তা অভিজ্ঞতা (উই৩)

• উদ্দেশ্য: একাধিক প্রজন্মের পাঠকেরা উইকিপিডিয়ার সাথে জড়িত হন এবং নিযুক্ত থাকেন, যার ফলে সম্পাদক ধারণ এবং দানের কার্যকলাপে উল্লেখযোগ্য বৃদ্ধি ঘটে। আলোচনা
  • উদ্দেশ্যমূলক প্রেক্ষাপট: উদ্ভাবনী বিন্যাসের মাধ্যমে নতুন পাঠকদের ধরে রাখতে বিষয়বস্তুর, পরিচিত পাঠ-অভিজ্ঞতাকে আরও শক্তিশালী করার মাধ্যমে মূল পাঠকগোষ্ঠীকে বজায় রাখতে, এবং পাঠকদের সঙ্গে গভীর সম্পর্ক গড়ে তুলে দীর্ঘমেয়াদি স্থায়িত্ব নিশ্চিত করতে ও দানের উৎস বৈচিত্র্যকরণের দিকে এই উদ্দেশ্য মনোনিবেশ করে। নতুন এবং আরও পরীক্ষামূলক বৈশিষ্ট্য যেমন এআই সারাংশ বা ব্যক্তিগতকৃত র‌্যাবিট হোল ব্যবহারের মাধ্যমে সহজে বিষয়বস্তু আবিষ্কার করায় সহায়তা করে এটি আমাদের কাজের ধারাবাহিকতা বজায় রাখবে। পাঠ প্রক্রিয়ার গভীর স্তরে পাঠ অভিজ্ঞতার গুণমান ধরে রাখা ও উন্নত করার কাজ এবং পাঠ তালিকা ও সম্পাদনার বাইরের অন্যান্য উপায়ে অংশগ্রহণের মাধ্যমে পাঠ-সংগ্রহ নিয়ে অনুসন্ধানও এর অন্তর্ভুক্ত থাকবে। দাতাদের ক্ষেত্রে, প্ল্যাটফর্মের ভেতর থেকেই আয়ের উৎসকে বৈচিত্র্যময় করার কাজে এই প্রচেষ্টা চলতে থাকবে।
    • মূল ফলাফল উই৩.১: দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ, প্রতি প্ল্যাটফর্মের একটি বৈশিষ্ট্যের এ/বি পরীক্ষার মাধ্যমে পরিমাপ করা লগ-আউট করা পাঠককে ধরে রাখার ক্ষেত্রে কার্যত উল্লেখযোগ্য বৃদ্ধি দেখা যাবে
      • নতুন প্রযুক্তি এবং বিন্যাস ব্যবহারের মাধ্যমে এই কেআর প্রায়শই এমন অভিজ্ঞতায় বিনিয়োগ অব্যাহত রাখার ওপর জোর দেবে যা ব্রাউজিং এবং শেখার নতুন উপায়কে সর্বোত্তম করে, - বিদ্যমান বিষয়বস্তুকে নতুন এবং আকর্ষণীয় উপায়ে উপস্থাপনের মাধ্যমে। এই অর্থবছরে, আমরা নতুন বৈশিষ্ট্যগুলি নিয়ে পরীক্ষা-নিরীক্ষা চালিয়ে যেতে চাই, একই সাথে উইকি এবং প্ল্যাটফর্মগুলিতে সফল পরীক্ষা-নিরীক্ষার পরিধি বৃদ্ধির ওপরও মনোযোগ দেব। কেআর-এর কাজটি মোবাইল এবং ডেস্কটপ ওয়েবসাইট, সেইসাথে আইওএস এবং অ্যান্ড্রয়েড অ্যাপ জুড়ে বিস্তৃত হবে। এটি বিষয়বস্তু খুঁজে নেওয়া (ব্রাউজিংয়ে প্রবেশের স্থান ও সুপারিশ) এবং শেখার অভিযোজিত বিন্যাসের (মেশিন-সহায়ক সংক্ষিপ্তসার, বিষয়বস্তু রিমিক্সিং) ওপর দৃষ্টি নিবদ্ধ করবে।
      • ইচ্ছা তালিকার কেন্দ্রবিন্দু: নতুন গ্রাহক অভিজ্ঞতা
    • মূল ফলাফল উই৩.২: দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ পণ্য হস্তক্ষেপের মাধ্যমে প্রতি প্ল্যাটফর্মে ব্যানার বা ইমেল ছাড়া অন্য পদ্ধতিতে অনুদানের সংখ্যা ৫% বৃদ্ধি করা যা আরও গভীর সংযোগ তৈরি করে এবং দাতাদের মধ্যে অসুবিধা কমায়।
      • এই কেআর-এ আমরা অনুদান পাওয়ার জন্য নতুন পথ ও পাঠকদের দাতাতে রূপান্তরিত করার অন্যান্য সুযোগগুলি অন্বেষণ করতে থাকব এবং উইকির সাথে তাদের সংযোগকে আরও গভীর করে তাদের ধরে রাখতে পারব, যার মধ্যে আরও ব্যক্তিগতকৃত বিষয়বস্তু অন্তর্ভুক্ত থাকবে। তহবিল সংগ্রহকারী দলের সাথে সহযোগিতায় অ্যাপ এবং ওয়েবে অনুদানে নতুন পথ প্রবর্তন এবং বিদ্যমান গুলিতে পুনরাবৃত্তি করার ওপর কেআর মনোনিবেশ করবে।
    • মূল ফলাফল উই৩.৩: দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ, প্রতি প্ল্যাটফর্মের একটি বৈশিষ্ট্যের এ/বি পরীক্ষার মাধ্যমে পরিমাপ করা লগ-আউট পাঠক ধারণের ক্ষেত্রে কার্যত উল্লেখযোগ্য বৃদ্ধি দেখা যাবে
      • এই কেআর আমাদের বর্তমান শ্রোতাদের ধরে রাখার এবং সাইটের সাথে তাদের সংযোগকে আরও গভীর করার লক্ষ্যে বিদ্যমান এবং অভিজ্ঞ পাঠকদের জন্য পড়া ও শেখার অভিজ্ঞতাকে উন্নত করার দিকে মনোনিবেশ করবে যাতে তারা আরও শিখতে পারে, পাশাপাশি অনুদান এবং সম্পাদনার দিকে এগোতে প্রস্তুত ও উন্মুক্ত হতে পারে। এখানে কাজটি ওয়েব এবং অ্যাপগুলিতে পড়ার অভিজ্ঞতা উন্নত করার ওপর দৃষ্টি নিবদ্ধ করবে (পঠনযোগ্যতার উন্নতি, আরও ভাল নেভিগেশন এবং খুঁজে পাওয়া)। এর পাশাপাশি এর মনোযোগ থাকবে আমাদের বিষয়বস্তু নির্বাচন ও ব্যক্তিগতকরণ সুবিধাগুলি (পঠন তালিকা, ব্যক্তিগতকৃত পরামর্শ, ব্যবহারকারী ও প্রবন্ধের ইতিহাস ইত্যাদি) তৈরি করা এবং উন্নত করার দিকে।
    • মূল ফলাফল উই৩.৪: চতুর্থ ত্রৈমাসিকের শেষ নাগাদ, ছোট-মাপের ক্যাশে সাইট (পপ) মোতায়েন করার উদ্দেশ্যে সমস্ত শনাক্তকৃত বাধা দূর করা যাবে, পপ সমূহ আমাদের বর্তমান ক্যাশে সাইট মোতায়েনের মান অনুযায়ী পরিষেবার গুণমান এবং নিরাপত্তা মান পূরণ করবে।
      • এই কেআর মূলত যে ধারণাটি প্রমাণ করার ওপর কেন্দ্রীভূত হবে সেটি হলো আমরা আমাদের পাঠকদের জন্য ওয়েবসাইটের কর্মক্ষমতা উন্নত করতে পারি এবং বিলম্ব কমাতে পারি। এটি করা যাবে আমাদের ক্যাশে অবকাঠামোর সরলীকরণ এবং ক্যাশে সাইট স্থাপনার প্রক্রিয়াগুলি উন্নত করার যায়, ভিত্তিরেখা স্থাপনের সময় গড়ে প্রায় এক বছর থেকে কমিয়ে সর্বাধিক এক চতুর্থাংশ করে ফেললে এটি সম্ভব হবে। এখানে মূল লক্ষ্য হবে সরলীকরণ সম্পূর্ণ করা, একটি পিওসি স্থাপন করা, একটি নিরাপত্তা পর্যালোচনা পরিচালনা করা এবং সেইসঙ্গে পাবলিক ক্লাউডে আমাদের প্রান্তিক ক্যাশে স্থাপনের সাথে এগিয়ে যাওয়া উচিত কিনা সে সম্পর্কে একটি সিদ্ধান্ত সংক্ষিপ্তসার সম্পূর্ণ করা। বিলম্ব কমানোর ফলে পাতায় পরিভ্রমণ বৃদ্ধি পেতে পারে এবং ভৌগোলিকভাবে আরও বৈচিত্র্যময় পাঠক সংখ্যা বাড়তে পারে।
    • মূল ফলাফল উই৩.৫: অনুদান দাতা শনাক্তকরণ উন্নত করা — চতুর্থ ত্রৈমাসিকের শেষ নাগাদ নিশ্চিত করা যে সমস্ত সম্মতিপ্রাপ্ত লগ-ইন পাঠককে ব্যক্তিগতকৃত অভিজ্ঞতার জন্য দাতার অবস্থা দ্বারা চিহ্নিত করা যেতে পারে।
      • আমরা দাতা শনাক্তকরণ কৌশল বাস্তবায়ন করব যাতে নিশ্চিত করা যায় যে সমস্ত সম্মতিপ্রাপ্ত লগ-ইন পাঠকদের দাতার অবস্থা দ্বারা চিহ্নিত করা যেতে পারে, যা আরও উপযুক্ত এবং আকর্ষণীয় অভিজ্ঞতা প্রদান করবে। ভবিষ্যতে আরও কার্যকর ব্যক্তিগতকরণ এবং সক্রিয়করণ উদ্যোগগুলিকে সমর্থন করার জন্য চতুর্থ ত্রৈমাসিকে দাতা শনাক্তকরণ প্রচেষ্টাকে অগ্রাধিকার দেওয়া হবে।
    • মূল ফলাফল উই৩.৬: চতুর্থ ত্রৈমাসিকের শেষ নাগাদ প্ল্যাটফর্ম জুড়ে উইকিপিডিয়া পাঠক ও ভোক্তাদের অভিজ্ঞতার জন্য একটি কৌশল চূড়ান্ত করা, প্রকাশ করা ও যোগাযোগ করা, যার লক্ষ্য এবং ভিত্তিমূলক মানদণ্ড নির্ধারিত থাকবে, যা সংশ্লিষ্ট পক্ষ এবং সম্প্রদায়ের সহযোগিতায় তৈরি করা হবে এবং ২০৩০ সাল পর্যন্ত আমাদের কাজকে পরিচালনা করবে।
      • ভোক্তা কৌশলের ওপর কাজ অব্যাহত থাকবে, অভ্যন্তরীণভাবে এবং সম্প্রদায়ের সাথে কৌশলটি তৈরি ও যোগাযোগের ওপর মনোযোগ দেওয়া হবে এবং ভোক্তাদের জন্য মূল মানদণ্ড ও তাদের নিজ নিজ ভিত্তিরেখা সংজ্ঞায়িত ও প্রতিষ্ঠা করা হবে।
    • Key result WE3.7: Increase the number of donations through non-banner or email methods by 10% YoY per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q4.
      • This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team.
    • Key result WE3.8: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for active readers in a test environment, monitoring a guardrail appropriate for the feature.
      • This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
    • Key result WE3.9: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for logged-out casual readers in a test environment, monitoring a guardrail appropriate for the feature.
      • In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
    • Key result WE3.10: By the end of Q4, perform at least one experiment per platform (web and apps) that shows a practically significant improvement in logged-out casual reader retention or another indicator metric over control (with casual reader retention defined as 21-day cumulative retention for web, and 14-day cumulative retention for apps).
      • We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

---

নিরাপত্তা এবং সুরক্ষা (উই৪)

• উদ্দেশ্য: আমাদের সম্পাদকদের অ্যাকাউন্ট এবং ব্যক্তিগত তথ্যকে আমাদের সিস্টেমগুলি স্বয়ংক্রিয়ভাবে আরও ভালভাবে সুরক্ষিত করে, একই সাথে বর্ধিত অধিকার সহ সম্পাদক এবং ব্যবহারকারীদেরকে অপব্যবহারমূলক কার্যকলাপের প্রতিরোধ করতে এবং তার বিরুদ্ধে প্রতিক্রিয়া জানাতে আরও পথ প্রদান করে। আলোচনা
• মূল ফলাফল উই৪.১: দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ আমাদের সমস্ত উইকিতে একটি বাস্তবায়নযোগ্য এবং কার্যকর ঘটনা প্রতিবেদন ব্যবস্থা স্থাপন করা, যা তাদের সম্প্রদায়ের দ্বারা ব্যবহৃত এবং গৃহীত হবে।
  • ব্যবহারকারীদের নিরাপত্তা এবং ভালো থাকা নিশ্চিত করা আমাদের প্ল্যাটফর্মের একটি মৌলিক দায়িত্ব। অনেক বিচারব্যবস্থায় এমন কিছু নিয়ম রয়েছে যার অনুযায়ী আমাদের মতো অনলাইন প্ল্যাটফর্মগুলিকে নিজেদের প্ল্যাটফর্মে হয়রানি, সাইবার বুলিং এবং অন্যান্য ক্ষতিকারক বিষয়বস্তু পর্যবেক্ষণ করতে এবং তার বিরুদ্ধে ব্যবস্থা নিতে হবে। এই বিষয়গুলি সমাধান করতে ব্যর্থ হলে প্ল্যাটফর্মগুলির আইনি দায়বদ্ধতা এবং নিয়ন্ত্রক নিষেধাজ্ঞার সম্মুখীন হওয়ার সম্ভাবনা থেকে যায়।
  • আমরা চাই আমাদের ব্যবহারকারীরা যাতে সহজেই খুঁজে পাওয়া যায় এমন অনুভূতিপ্রসূত প্রতিবেদন ব্যবস্থার মাধ্যমে তাৎক্ষণিকভাবে ক্ষতির হুমকির প্রতিবেদন করতে পারেন, এর ফলে আমরা এই ধরনের ঘটনা সম্পর্কে জানতে পারব এবং প্রয়োজনে তাৎক্ষণিক পদক্ষেপ নিতে পারব। আমাদের প্ল্যাটফর্মে অবদান রাখার সময় আমাদের ব্যবহারকারীদের নিরাপদ বোধ করার দিকে এটি একটি পদক্ষেপ। আমরা আমাদের উইকিগুলিতে একটি ঘটনা প্রতিবেদন ব্যবস্থা বাস্তবায়নের মাধ্যমে এটি করছি।
• মূল ফলাফল উই৪.২: দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ ২টি উন্নতি স্থাপনের মাধ্যমে অপব্যবহার-বিরোধী সরঞ্জামের নির্ভুলতা এবং কার্যকারিতা জোরদার করা।
  • আমাদের এবং আমাদের সম্প্রদায়ের উইকিতে অসত্য ও ক্ষতিকারক কার্যকলাপকে আরও ভালভাবে শনাক্ত ও প্রতিরোধ করা প্রয়োজন। আমরা এটি করব প্ল্যাটফর্মে উপলব্ধ সংকেতের সংখ্যা এবং গুণমান বৃদ্ধি করে। এই সংকেতগুলিকে এমন সরঞ্জামগুলিতে একত্রিত করা হবে যেগুলি আমরা বর্ধিত অধিকার সহ ব্যবহারকারীদের জন্য উপলব্ধ করব এবং সন্দেহজনক কার্যকলাপের ওপর আমরা কোথায় নিরাপদে স্বয়ংক্রিয় বিধিনিষেধ আরোপ করতে পারি তা শনাক্ত করব।
  • আমরা একই সাথে উইকিপিডিয়া এবং আমাদের অন্যান্য প্রকল্পগুলিত প্রবেশাধিকার উন্নত করার সুযোগ নিয়েও কাজ করছি। উদাহরণস্বরূপ, একটি প্রকল্প হল উইকিগুলির অত্যন্ত প্রচলিত স্ব-পরিচালিত ক্যাপচা, যা ব্যবহারকারীকে একটি ধাঁধা সমাধান না করা পর্যন্ত লগ ইন করতে দেয় না। এটি এমন একটি পরিষেবা যা খুব কমই ব্যবহারকারীকে চ্যালেঞ্জ করে। পরিবর্তে, এটি নীরবে অ্যাকাউন্টগুলিকে সন্দেহের স্তর অনুযায়ী ট্যাগ করবে যা আমরা অ্যাকাউন্টগুলির কার্যকারিতা অক্ষম করতে ব্যবহার করতে পারি এবং এই অবস্থাটি অত্যন্ত সুবিধাপ্রাপ্ত নিয়ন্ত্রকদের কাছে তাদের কাজে সহায়তা করার জন্য দৃশ্যমান করে তুলবে।
  • সাধারণভাবে, উইকিমিডিয়া প্রকল্পগুলি ধ্বংসপ্রবণ ব্যক্তিদের কাছ থেকে অপব্যবহার কমাতে আইপি অ্যাড্রেস ব্লকিংয়ের ওপর ব্যাপকভাবে নির্ভর করে। অপব্যবহার বন্ধে এটি ক্রমশ অকার্যকর হয়ে উঠছে এবং আইপি ও আইপি রেঞ্জ ব্লকের দ্বারা প্রভাবিত সৎ বিশ্বাসী ব্যবহারকারীদের ওপর নেতিবাচক প্রভাব ফেলছে। এই কেআর-এ, আমরা বিদ্যমান ক্ষমতা উন্নত করার এবং ধ্বংসপ্রবণ ব্যক্তিদের আরও সুনির্দিষ্ট এবং কার্যকরভাবে ব্লক করার জন্য নতুন সরঞ্জাম সরবরাহ করার লক্ষ্য রেখেছি, এবং আইপি ও আইপি রেঞ্জ ব্লক দ্বারা সৃষ্ট সমান্তরাল ক্ষতি কমাতে পারব।
  • আমাদের কার্যকারিতা পরিমাপ করার জন্য, আমরা অপব্যবহার-বিরোধী কাজে নিযুক্ত স্বেচ্ছাসেবকদের কাছ থেকে গুণগত প্রতিক্রিয়া দেখব এবং আইপি ব্লক স্থাপনের হার, আইপি খ্যাতি এবং ব্রাউজার সিগন্যাল-ভিত্তিক প্রশমন গ্রহণ, ব্যবহারকারীকে ব্লক করা হলে সম্ভাব্য-মানব যোগাযোগের হার এবং অপব্যবহার-বিরোধী সরঞ্জামে নতুন সংকেত গ্রহণের মতো পরিমাণগত সূচকগুলিও দেখব।
  • এই কেআর-এর কাজের মধ্যে রয়েছে উন্নত সকপাপেটকে ও নিষেধাজ্ঞা এড়িয়ে যাওয়াকে সনাক্তকরণ এবং প্রশমন, সম্ভাব্য ক্ষতির তথ্য প্রকাশ করা, বট সনাক্তকরণ শক্তিশালী করা, অপব্যবহার-বিরোধী স্বেচ্ছাসেবকদের কাছে সংকেত প্রকাশ করা, অপব্যবহার-বিরোধী সরঞ্জাম ইন্টারফেসে দক্ষতা উন্নত করা, অপব্যবহার সম্পর্কিত মানদণ্ড উন্নত করা এবং চেকইউজারদের তদন্তের জন্য সন্দেহজনক অ্যাকাউন্ট কার্যকলাপে সম্বন্ধে পরামর্শ প্রদান করা।
• মূল ফলাফল উই৪.৩: চতুর্থ ত্রৈমাসিকের শেষ নাগাদ এসআরই-তে, মানব হস্তক্ষেপের প্রয়োজন এমন বৃহৎ আকারের আক্রমণের সংখ্যা ৫০% (অর্থবছরের তুলনায়) কমিয়ে আনা।
  • ইন্টারনেটের পটভূমির বিবর্তন আমাদের ঐতিহ্যবাহী পদ্ধতিগুলিকে বৃহৎ আকারের অপব্যবহার সীমিত করার ক্ষেত্রে অপ্রচলিত করে তুলেছে, অপব্যবহারের মধ্যে রয়েছে বৃহৎ আকারের বটনেটের উত্থান এবং ঘন ঘন আক্রমণ। এই ধরনের আক্রমণের ফলে আমাদের অবকাঠামোগুলি অনুরোধে ভরে গিয়ে আমাদের সাইটগুলিকে অনুপলব্ধ করে তুলতে পারে, অথবা বৃহৎ আকারের ধ্বংসাত্মক কার্যকলাপের বিরুদ্ধে লড়াই করার জন্য আমাদের সম্প্রদায়ের ক্ষমতাকে হ্রাস করতে পারে। এটি আমাদের উচ্চ-সুবিধাপ্রাপ্ত সম্পাদক এবং আমাদের প্রযুক্তিগত সম্প্রদায়ের ওপর অযৌক্তিক চাপও সৃষ্টি করে।
  • এই ধরনের আক্রমণকে স্বয়ংক্রিয়ভাবে সনাক্তকরণ, প্রতিরোধ এবং প্রশমিতকরণ বা বন্ধ করার ক্ষমতা আমাদের জরুরিভাবে উন্নত করতে হবে।
  • এই বছর আমরা মূলত আমাদের বিরুদ্ধে নিয়মিত আক্রমণে জড়িত আইপি ঠিকানা এবং নেটওয়ার্কগুলির স্বয়ংক্রিয় সনাক্তকরণের ওপর মনোনিবেশ করব এবং আমাদের সিস্টেমে ক্রমাগত ক্ষতিকারক সত্তাগুলির লোডের পরিমাণ হ্রাস করব।
• মূল ফলাফল উই৪.৪: আমাদের ১০০% প্রকল্পে অস্থায়ী অ্যাকাউন্ট স্থাপন করা, যাতে দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ আমাদের অনিবন্ধিত সম্পাদকদের ব্যক্তিগতভাবে শনাক্তযোগ্য তথ্য ০.১%-এরও কম ব্যবহারকারীর কাছে প্রকাশ করা যায়।
  • অস্থায়ী অ্যাকাউন্টগুলির লক্ষ্য হল গোপনীয়তা উন্নত করা এবং এর ফলে আমাদের অনিবন্ধিত সম্পাদকদের ব্যক্তিগতভাবে শনাক্তযোগ্য তথ্য (আইপি ঠিকানা) জনসাধারণের দৃষ্টিভঙ্গি থেকে রক্ষা করা এবং শুধুমাত্র টহল দেওয়ার জন্য যাদের এটির প্রয়োজন তাদের অ্যাক্সেস দেওয়া। ব্যবহারকারীর সুরক্ষার ক্ষেত্রে একটি বড় উন্নতি হওয়ার পাশাপাশি, এই প্রকল্পটি বিভিন্ন নিয়ন্ত্রক প্রয়োজনীয়তা মেনে চলার জন্যও গুরুত্বপূর্ণ।
• মূল ফলাফল উই৪.৫: আস্থা ও নিরাপত্তার ওপর জেনারেটিভ এআই-এর প্রভাব মূল্যায়ন করা, এবং তৃতীয় ত্রৈমাসিকের শেষ নাগাদ উইকিমিডিয়া প্রকল্পগুলির জন্য সুযোগগুলি কাজে লাগানো এবং হুমকি প্রতিরোধ করার জন্য পণ্য হস্তক্ষেপ নির্ধারণ করা।
  • ইন্টারনেট জুড়ে এআই ব্যবহার, বিশেষ করে জেনারেটিভ এআই, দ্রুত বৃদ্ধি পাচ্ছে। এআই সর্বব্যাপী হওয়ার সাথে সাথে আস্থা ও নিরাপত্তার সুযোগের পাশাপাশি হুমকিও তৈরি হচ্ছে। উদাহরণস্বরূপ, বিষয়বস্তু তৈরি করা সহজ এবং সস্তা, কিন্তু নিয়ন্ত্রণ আরও কঠিন। একইভাবে, গবেষণা অনেক কম প্রচেষ্টায় করা যেতে পারে কিন্তু এআই হ্যালুসিনেশন সনাক্ত করা কঠিন।
  • এই প্রকল্পের লক্ষ্য হল উইকিমিডিয়ার বাস্তুতন্ত্রের আস্থা এবং সুরক্ষার দিকগুলির ওপর এআই-এর প্রভাব মূল্যায়নের মাধ্যমে এমএল/এআই-এর মানবাধিকার প্রভাব মূল্যায়নের ওপর ভিত্তি করে গড়ে তোলা। এর মধ্যে রয়েছে:
    • বর্ধিত অধিকার যুক্ত ব্যবহারকারীদের সাথে পরামর্শ করা।
    • জেনারেটিভ এআই-সহায়তাপ্রাপ্ত অপব্যবহারের উদাহরণ এবং সম্ভাব্য প্রশমন চিহ্নিত করা।
    • বর্ধিত অধিকার সহ ব্যবহারকারীদের ওপর বোঝা কমাতে এমএল সুযোগগুলি চিহ্নিত করা।
    • সর্বাধিক প্রভাব ফেলতে আমাদের কিসের ওপর মনোযোগ দেওয়া উচিত তা বোঝার জন্য পরীক্ষা-নিরীক্ষা চালানো।
• মূল ফলাফল উই৪.৬: প্রযুক্তিগতভাবে বলবৎ করা যে ব্যবহারকারীদের নিরাপত্তা- বা গোপনীয়তা-সংবেদনশীল পদক্ষেপ নিতে সক্ষম করে এমন ১০০% সুযোগ-সুবিধা শুধুমাত্র সেই অ্যাকাউন্টগুলি দ্বারা সম্পাদিত হতে পারে যেগুলিতে দুই-স্তরের প্রমাণীকরণ সক্রিয় আছে, এবং এটি চতুর্থ ত্রৈমাসিক শেষ হওয়ার মধ্যে সম্পন্ন করতে হবে।
  • আমাদের উইকিগুলিতে ব্যবহারকারীদের অ্যাকাউন্টগুলির নিরাপত্তা জোরদার করা প্রয়োজন, বিশেষ করে সংবেদনশীল অনুমতিপ্রাপ্ত ব্যবহারকারীদের জন্য। একটি গুরুত্বপূর্ণ বিষয় হল যাঁরা দ্বি-ফ্যাক্টর প্রমাণীকরণ (২এফএ) সক্ষম করেছেন কেবলমাত্র সেই ব্যবহারকারীরাই কোনও সংবেদনশীল পদক্ষেপ নিতে পারেন। আমরা অধিকার প্রয়োগের জন্য একটি আরও বিস্তৃত সিস্টেম তৈরি করব, যা অডিট এবং ২-ফ্যাক্টর প্রমাণীকরণের (২এফএ) ম্যানুয়াল প্রয়োগের প্রয়োজনকে বাইপাস করবে এবং প্ল্যাটফর্মে কোন কোন অধিকারগুলোর জন্য ২এফএ সক্রিয় থাকা বাধ্যতামূলক করা হবে তা বিস্তৃত করবে।
  • এর অংশ হিসেবে, আমরা আমাদের প্রমাণীকরণ এবং পুনরুদ্ধার ব্যবস্থা উন্নত করব যাতে আমরা (ডব্লিউএমএফ) এবং আমাদের ব্যবহারকারীরা ২এফএ-এর প্রতি আরও কঠোর অবস্থানকে আরও সহজে সমর্থন করতে পারি। আমরা প্ল্যাটফর্ম জুড়ে দ্বি-ফ্যাক্টর প্রমাণীকরণের সাধারণ প্রাপ্যতা প্রসারিত করব, যাতে প্রতিটি ব্যবহারকারী প্রয়োজনমত এটি সক্ষম করতে পারেন এবং সংবেদনশীল সুবিধা প্রদানের আগে এটি সক্ষম করা হয়েছে তা নিশ্চিত করতে পারেন। আমরা আমাদের অ্যাকাউন্ট পুনরুদ্ধার এবং সহায়তা সিস্টেমের দ্বারা বহন করা কার্যক্ষম চাপ কমানোর উপরও আমাদের মনোযোগ কেন্দ্রীভূত করব, যা অ্যাকাউন্ট লগইনকে ঘিরে আমাদের রিসেট এবং পুনরুদ্ধার প্রক্রিয়াগুলিকে সহজতর করতে সাহায্য করবে। আমরা আমাদের ২এফএ বাস্তবায়নের ব্যবহারযোগ্যতা উন্নত করারও পরিকল্পনা করছি, ব্যবহারকারীদের তাদের অ্যাকাউন্ট সুরক্ষিত করার জন্য এবং সেখানে ভুলবশত প্রবেশ নিষেধাজ্ঞা এড়াতে আরও বিকল্প প্রদান করব।
• Key result WE4.7: Publicly conclude our bot detection trial, by the end of Q4.
  • This KR is a focused, one-quarter effort to evaluate the results of this trial, to decide inside WMF about whether to maintain and expand this system across our wikis, and to publicly publish the results of the trial and our path forward.
• Key result WE4.8: Simplify the patrolling of temporary accounts, by making it quicker to identify and address abuse, by the end of Q4.
  • The purpose of temporary accounts is to continue to safely support participation from good-faith unregistered editors. However, some anti-vandalism workflows became more complicated by the release of temporary accounts. To ensure temporary account vandalism can be sustainably managed, we will make it easier and quicker for patrollers to understand and respond to temporary-account activity, both good- and bad-faith.
    We will surface clusters of related temporary accounts to patrollers, while also exploring other interventions that could improve early identification and rapid response.
• Key result WE4.9: Empower volunteer investigators to deter and block more inauthentic activity on wikis where they actively review flagged accounts, as measured by a 20% increase in the rate of mitigating actions on those accounts, by the end of Q4.
  • For Q3 and Q4, recognizing the strategic potential that Suggested Investigations has demonstrated, we will invest in deploying new signals independent of bot detection, and will set aside time to prioritize a variety of efficiency and quality-of-life features that have been requested by SI users since its original MVP release.
• Key result WE4.10: By the end of Q4, we'll increase hCaptcha bot detection coverage from 18% to 100% of account creations and from 18% to 90% of higher risk edits.
  • In Q3, we concluded our hCaptcha trial, during which we enabled hCaptcha during account creation, and later expanded it to include new users on the desktop wikitext editor, on eight large Wikipedias, including English Wikipedia. Based on the results of that trial, we’re now expanding hCaptcha to more editing interfaces and more wikis. Our main priority will be expanding what we currently have to all wikis, but we’ll also focus on new avenues to (discussion tools, uploads), as well as categories of users whose actions will be protected by hCaptcha.
• Key result WE4.11: By the end of Q4, complete an IRS trial on enwiki with a graduated deployment, reaching at least 50% of logged in users and resulting in 5 new reporting metrics.
  • We are trialing an incident reporting system (IRS) on English Wikipedia that is designed to help less experienced community members more easily report potentially bad behavior to the community-managed place that can best deal with it. For more rare and severe cases, it also provides a form to directly report imminent threats of harm to the WMF Trust and Safety team.
  • This trial will be primarily focused on calibrating the first use case: helping editors report potentially bad behavior, without overloading the system.
  • During the trial, we will focus on monitoring the volume of new reports, checking that reports are routed correctly, and identifying any immediate issues. We will be coordinating closely with all community members to fix bugs if they arise, and to otherwise streamline the process. For example, we are exploring some ways to tighten the user experience and help people more directly submit their reports, which we may deploy and measure during the trial as well.
• Key result WE4.12: By end of Q4, we will have defined a detection pipeline for classifiers that automatically detect English Wikipedia policy-prohibited content, and evaluated the impact of at least one classifier detecting at least one type of prohibited content, validated against community datasets, on its potential for reducing volunteer workload.
  • We want to support volunteers and UWERs by reducing work needed to remove harmful content from the projects, to enable volunteers to handle more difficult cases.
  • In this quarter, we want to gain experience in defining repeatable processes for building detection pipelines for different types of content, and take first steps to evaluate these pipelines safely on large projects (A/B tests, log-only mode deployments, etc). We will start with a focus on content that should very likely be suppressed, such as threats, or disclosure of personal information.
  • We plan to expand on these initiatives in FY26-27 work as part of an overhaul of anti-abuse tooling that supports UWERs and volunteers in reducing the time to mitigation for bad-faith activity.

---

অবকাঠামোর দায়িত্বশীল ব্যবহার (উই৫)

• উদ্দেশ্য: ডেভেলপার এবং পুনঃব্যবহারকারীরা বাছাই করা পথের মাধ্যমে জ্ঞানভিত্তিক বিষয়বস্তুতে প্রবেশ করে, যাতে আমাদের অবকাঠামোর স্থায়িত্ব এবং বিষয়বস্তুর দায়িত্বশীল পুনঃব্যবহার নিশ্চিত হয়। আলোচনা
  • উদ্দেশ্যমূলক প্রেক্ষাপট: এই উদ্দেশ্যটি বিষয়বস্তু পুনঃব্যবহারের দায়িত্বশীল পথ প্রতিষ্ঠার ওপর দৃষ্টি নিবদ্ধ করবে।
  • ওয়েবে মানুষের দ্বারা সংগৃহীত জ্ঞানের বৃহত্তম সংগ্রহের আয়োজন করে উইকিমিডিয়া। আমাদের জ্ঞান অবকাঠামো এর ফলে কেবল মানুষের জন্যই নয়, স্বয়ংক্রিয় তথ্য গ্রাহকদের জন্যও একটি অমূল্য গন্তব্যস্থলে পরিণত হয়েছে। আমাদের বিষয়বস্তু থেকে সার্চ ইঞ্জিন, সোশ্যাল মিডিয়া প্ল্যাটফর্ম, ই-কমার্স তথ্য নেয় এবং এআই-এর উত্থানের পর থেকে, এটি বৃহৎ মেশিন লার্নিং মডেলগুলিকে প্রশিক্ষণ দেওয়ার জন্য ব্যবহৃত হয়। গ্রাহকরা স্ক্র্যাপিং পাতাগুলির মাধ্যমে এপিআই ব্যবহার করে এবং বিষয়বস্তু ডাউনলোড করে ডেটা সংগ্রহ করেন - সাধারণত উৎস স্বীকার ছাড়াই। অননুমোদিত ট্র্যাফিকের জগতে আমরা একজন ব্যবহারকারীকে অন্যজনের থেকে নির্ভরযোগ্যভাবে আলাদা করতে পারি না, যা আমাদের অবকাঠামোর দায়িত্বশীল ব্যবহারকে সক্ষম করার এবং প্রয়োগ করার ক্ষমতাকে ব্যাপকভাবে সীমিত করে: স্বয়ংক্রিয় বিষয়বস্তু ব্যবহারে সীমানা স্থাপনের পাশাপাশি আমরা কিভাবে আমাদের সম্প্রদায়কে সক্ষম করে তোলা বজায় রাখতে পারি? কিভাবে আমরা ব্যবহারকারীদের পছন্দসই, সমর্থিত চ্যানেলগুলিতে নিয়ে যেতে পারি? দায়িত্বশীল বিষয়বস্তুর পুনঃব্যবহারকে উৎসাহিত করার জন্য আমাদের কি নির্দেশিকা প্রয়োজন? কিভাবে আমরা একটি সমন্বিত ডেভেলপার অভিজ্ঞতার দিকে এগিয়ে যেতে পারি এবং এমন পণ্য তৈরি করতে পারি যা স্বেচ্ছাসেবক ডেভেলপার, কর্মী এবং পুনঃব্যবহারকারীদের চাহিদা পূরণ করবে? যদিও এই প্রশ্নগুলি একেবারেই নতুন নয়, তবে এগুলির সমাধানের তাগিদ দ্রুতগতিতে বৃদ্ধি পেয়েছে: ২০২৪ সাল থেকে আমরা অনুরোধের পরিমাণে নাটকীয়ভাবে বৃদ্ধি লক্ষ্য করছি, যার বেশিরভাগ বৃদ্ধি এসেছে স্ক্র্যাপিং বটদের এআই-চালিত কর্মপ্রবাহ এবং পণ্যগুলির জন্য প্রশিক্ষণ তথ্য সংগ্রহের ফলে। আমাদের পরিকাঠামোর ওপর এখন আর দীর্ঘমেয়াদী চাপ থাকছে না এবং এটি মানুষের জ্ঞানপ্রাপ্তির ঝুঁকি তৈরি করছে। এখনই আমাদের পদক্ষেপ নিতে হবে যাতে একটি সুস্থ ভারসাম্য পুনঃপ্রতিষ্ঠা করা যায়, যাতে আমরা কার্যকরভাবে উইকিমিডিয়া প্রকল্পগুলোকে সহায়তা করতে পারি এবং আমাদের লক্ষ্যকে দীর্ঘমেয়াদে সফল করতে পারি।
    • মূল ফলাফল উই৫.১: চতুর্থ ত্রৈমাসিকের শেষ নাগাদ, প্রোগ্রাম্যাটিক অ্যাক্সেস চ্যানেলের কাছে আসা ৫০% অনুরোধকে একটি পরিচিত ডেভেলপার বা অ্যাপ্লিকেশনের সঙ্গে যুক্ত করা যাবে।
      • বর্তমানে স্বয়ংক্রিয় ট্র্যাফিকের জন্য কে দায়ী তা শনাক্ত করার জন্য আমাদের উপায় খুব সীমিত এবং অন-উইকির বিপরীতে, ব্যবহারকারীদের সাথে যোগাযোগ করার বা তাদের প্রবেশ নিয়ন্ত্রণ করার উপায়ও বেশি নেই। আমরা বহিরাগত স্বয়ংক্রিয় ট্র্যাফিকের পরিমাণে উল্লেখযোগ্যভাবে বৃদ্ধি দেখতে পেয়েছি, যার ফলে আমাদের টিঁকে থাকা মুশকিল এবং জ্ঞানের প্রতি মানুষের অধিকার ঝুঁকির মধ্যে পড়ছে। আমরা উচ্চ মাত্রার স্ক্র্যাপিং এবং এপিআই ব্যবহারের জন্য স্তরীয় প্রবেশের ওপর ভিত্তি করে প্রমাণীকরণ এবং অনুমোদনের প্রয়োজনীয়তার মাধ্যমে একটি পরিচিত অ্যাকাউন্টের সাথে সম্পর্কিত স্বয়ংক্রিয় ট্র্যাফিকের শতাংশ বৃদ্ধি করার লক্ষ্য রাখি। কারা আমাদের বিষয়বস্তু ব্যাপকভাবে পুনঃব্যবহার করছে তা শনাক্ত করতে এটি আমাদের সাহায্য করবে, যার ফলে আমরা আমাদের অবকাঠামো রক্ষা করতে এবং ন্যায্য ব্যবহারের প্রতি নিয়ন্ত্রণব্যবস্থা উন্নত করতে সক্ষম হব, একই সাথে তাদের চাহিদা আরও কার্যকরভাবে পূরণ করতে পারব। আমরা আরও অনুসন্ধান করব যে কিভাবে প্রযুক্তিগত সম্প্রদায়কে আরও সুসংহত ডেভেলপার অভিজ্ঞতা প্রদান করা যায় যা সম্প্রদায়ের সদস্যদের জন্য অগ্রাধিকারমূলক প্রবেশ নিরাপদ করে এবং ডেভেলপারদের জন্য নতুন কার্যকারিতা সক্ষম করে।
    • মূল ফলাফল উই৫.২: চতুর্থ ত্রৈমাসিকের শেষ নাগাদ, উইকিমিডিয়া ওয়েব এপিআই এন্ডপয়েন্ট ৭০% সাধারণ অবকাঠামো দ্বারা সমর্থিত হবে।
      • আমরা সকল উইকিমিডিয়া ডেভেলপারদের জন্য আরও সামঞ্জস্যপূর্ণ, স্থিতিশীল এবং আবিষ্কারযোগ্য ওয়েব এপিআই প্রদান করে আমাদের ডেভেলপার পথের অভিজ্ঞতা এবং স্থায়িত্ব উন্নত করার লক্ষ্য রাখি। আমরা আমাদের এপিআই প্রস্তাবনাগুলোকে সহজতর করব, মূল এপিআই ক্ষমতার জন্য আরও কেন্দ্রীভূত অবকাঠামো প্রবর্তনের মাধ্যমে। এর ফলে আমরা নিম্নলিখিত বিষয়গুলোতে একরকম নিয়ম এবং ব্যবস্থাপনা নিশ্চিত করতে পারব: ওপেনএপিআই স্পেসিফিকেশন এবং ডকুমেন্টেশন, ডেভেলপার সনাক্তকরণ এবং অ্যাক্সেস নিয়ন্ত্রণ, এপিআই নীতি প্রয়োগ, রাউটিং, সংস্করণ নিয়ন্ত্রণ এবং ত্রুটি পরিচালনা। আমাদের এপিআই অফারগুলিকে সহজতর করার মাধ্যমে, আমরা উইকিমিডিয়া মিশনকে পরিবেশনকারী সরঞ্জাম, বট, গবেষণা প্রকল্প এবং বৈশিষ্ট্যগুলি তৈরি করা দ্রুত, সহজ এবং আরও আনন্দদায়ক করে তুলব। এই পদ্ধতিটি এপিআই অবকাঠামো রক্ষণাবেক্ষণ খরচ কমিয়ে, ধ্বংসপ্রবণদের বিরুদ্ধে লড়াই করার জন্য দৃশ্যমানতা এবং প্রবেশ নিয়ন্ত্রণ বৃদ্ধি করে এবং একটি শক্তিশালী বিকাশকারী সম্প্রদায় গড়ে তোলার মাধ্যমে মিশনের বহু-প্রজন্মের ভবিষ্যতকে সমর্থন করে।
    • মূল ফলাফল উই৫.৩: চতুর্থ ত্রৈমাসিকের শেষ নাগাদ, ওয়েব, অ্যাপস, ভয়েস অ্যাসিস্ট্যান্ট এবং এলএলএম-এর জন্য নতুন অ্যাট্রিবিউশন ফ্রেমওয়ার্ক প্রকাশিত হবে এবং উইকিমিডিয়া সাইটগুলিতে সংযুক্ত করা হবে, দুটি পুনঃব্যবহারের ডেমো স্থাপন করা হবে যা পরিমাপযোগ্য সম্পৃক্ততা চালাবে এবং একজন বহিরাগত পুনঃব্যবহার অংশীদার সেরা চর্চার উৎস উল্লেখ করবে।
      • উইকিমিডিয়া বিষয়বস্তুর প্রতি যথাযথ স্বীকৃতি প্রদান বৃদ্ধির জন্য আমরা এমন স্পষ্ট সর্বোত্তম অনুশীলন নির্দেশিকা প্রদান করব, যা দায়িত্বশীল পুনঃব্যবহারকে উৎসাহিত করে। এর মধ্যে রয়েছে গুরুত্বপূর্ণ প্ল্যাটফর্মগুলির (ওয়েব, অ্যাপস, ভয়েস, মাল্টিমিডিয়া) জন্য অ্যাট্রিবিউশন ফ্রেমওয়ার্ক তৈরি করা এবং উইকিমিডিয়া বিষয়বস্তুর অনুকরণীয় প্রয়োগগুলি তুলে ধরে কমপক্ষে দুটি ব্যবহারিক উদাহরণ প্রদর্শন করা। আউটপুটের উদাহরণগুলির মধ্যে রয়েছে মিডিয়া সংস্থাগুলিকে উইকিমিডিয়া কমন্সের ছবির জন্য স্বীকৃতি প্রদানে উৎসাহিত করা, প্রাসঙ্গিক উইকিমিডিয়া উপাত্ত আরও কার্যকরভাবে প্রকাশ করার জন্য সার্চ ইঞ্জিনগুলিকে উৎসাহিত করা, অথবা এআই সহকারীদের স্বচ্ছ এবং দায়িত্বশীল উপায়ে উইকিপিডিয়া জ্ঞানকে একীভূত করার জন্য উৎসাহিত করা যার ফলে তাদের নির্ভরযোগ্যতার ওপর আস্থা বৃদ্ধি পাবে। অ্যাট্রিবিউশন অনুশীলনকে শক্তিশালী করা কেবল জনসচেতনতা বৃদ্ধি করে না এবং উইকিমিডিয়া প্রকল্পগুলিতে সম্পৃক্ততা ফিরিয়ে আনে না, বরং জ্ঞানের পুনঃমিশ্রণে এবং অপব্যবহার রোধে দায়িত্বশীল ও অভিনব উপায় প্রতিষ্ঠা করতেও সহায়তা করে।
    • মূল ফলাফল উই৫.৪: অনুরোধের হার অনুযায়ী পরিমাপ করলে স্ক্র্যাপার দ্বারা সৃষ্ট ট্রাফিকের পরিমাণ ২০% এবং ব্যান্ডউইডথ অনুযায়ী পরিমাপ করলে ৩০% কমাতে হবে
      • স্ক্র্যাপিং সবসময়ই ছিল: সার্চ ইঞ্জিনগুলি দশকের পর দশক ধরে তাদের ব্যবহারকারীদের তথ্য সরবরাহের জন্য উইকিপিডিয়ার উপর নির্ভর করে আসছে; তবে সম্প্রতি আমাদের ডেটা স্ক্র্যাপ করার আরেকটি বড় প্রেরণা তৈরি হয়েছে: এটি ইন্টারনেটে আপনি খুঁজে পেতে পারেন এমন সবচেয়ে বৃহৎ, সুশৃঙ্খলভাবে সংগৃহীত বহু-ভাষিক জ্ঞানভিত্তিক সামগ্রীর ভান্ডার, এবং এটি বড় ভাষা মডেল প্রশিক্ষণের জন্য একটি মৌলিক সরঞ্জাম। আমাদের বিশ্বকোষধর্মী বিষয়বস্তু এবং বহুমাধ্যম ভাণ্ডার উইকিমিডিয়া কমন্স, উভয়ের ক্ষেত্রেই এটি সত্য, যা ছবি-উৎপাদনকারী মেশিন লার্নিং মডেলগুলির জন্য অমূল্য,
      • ফলস্বরূপ, গত এক বছরে, আমরা স্ক্র্যাপার ট্র্যাফিকের পরিমাণ এবং সম্পর্কিত সাইট-স্থিতিশীলতার ঘটনাগুলিতে উল্লেখযোগ্য বৃদ্ধি দেখেছি: সাইট নির্ভরযোগ্যতা প্রকৌশলীরা আমাদের অবকাঠামো রক্ষা করার জন্য বারবার আলাদা আলাদাভাবে সিদ্ধান্ত নিয়ে ক্রলারের হার সীমাবদ্ধ বা নিষিদ্ধ করার ব্যবস্থা প্রয়োগ করেছেন। স্ক্র্যাপিং এতটাই প্রকট হয়ে উঠেছে যে ২০২৪ সালে আমাদের বহির্গামী ব্যান্ডউইডথ ৫০% বৃদ্ধি পেয়েছে। তাছাড়া, সাম্প্রতিক এক বিশ্লেষণে দেখা গেছে যে আমাদের কাছে আসা সবচেয়ে ব্যয়বহুল অনুরোধগুলির (যেগুলি আমরা আমাদের ক্যাশিং সার্ভার থেকে পরিবেশন করতে পারি না এবং যেগুলি মূল ডাটাবেস থেকে পরিবেশন করা হয়) কমপক্ষে ৬৫% বট দ্বারা সম্পাদিত হয়।
      • আমরা যে পরিমাণ ট্র্যাফিক তৈরি করি, আমাদের কম্পিউটিং রিসোর্সগুলি তার তুলনায় অত্যন্ত সীমিত, তাই আমাদের এই রিসোর্সগুলি দিয়ে কাকে পরিষেবা দেব তা অগ্রাধিকার দিতে হবে, এবং আমরা মানুষের ব্যবহারের পক্ষে থাকতে চাই, এবং আমাদের স্বল্প সংস্থান দিয়ে উইকিমিডিয়া প্রকল্প এবং অবদানকারীদের সমর্থন করাকে অগ্রাধিকার দিতে চাই।

---

পণ্য ফলাফলের ত্বরান্বিত পথ (উই৬)

• উদ্দেশ্য: উইকিমিডিয়া ডেভেলপাররা দ্রুত এবং আত্মবিশ্বাসের সাথে তাদের পণ্যগুলি চূড়ান্ত ব্যবহারকারীদের কাছে পৌঁছে দেয়। আলোচনা
  • উদ্দেশ্যমূলক প্রেক্ষাপট: ৪টি কৌশলগত স্তম্ভ অর্জনে কার্যকর হওয়ার জন্য, উইকিমিডিয়া ডেভেলপারদের তাদের সময় এবং প্রচেষ্টা উচ্চ-উৎপাদনশীল কার্যকলাপে ব্যয় করতে হবে যার ফলে যত তাড়াতাড়ি সম্ভব মানসম্পন্ন পণ্য সরবরাহ করা সম্ভব হবে। অত্যধিক জটিল কর্মপ্রবাহ, স্ট্যান্ডার্ড টুলিংয়ের অভাব এবং অস্থিতিশীল সিস্টেম উপাদানগুলি এই ফলাফলের পথে বাধা হয়ে দাঁড়ায়।
  • এই কাজটি গত দুটি বার্ষিক পরিকল্পনার ওপর ভিত্তি করে গতি বাড়িয়েছে। এর ফলে মিডিয়াউইকি একটি প্ল্যাটফর্ম হিসেবে এবং এর উন্নয়ন ও স্থাপনার জন্য সহায়ক সফ্টওয়্যারটি বিকাশলাভ করেছে। এই বছরের কাজটি আরও নির্ভরযোগ্য বিকাশকারী পরিবেশ সরবরাহ, প্রাক-উৎপাদন কর্মপ্রবাহকে সহজতর করা এবং প্ল্যাটফর্ম ও অবকাঠামোগত ঝুঁকি হ্রাস করার দিকে মনোনিবেশ করবে।
    • মূল ফলাফল উই৬.১: চতুর্থ ত্রৈমাসিকের শেষে, পরীক্ষামূলক উইকির বাইরে প্রশিক্ষণ-ব্লকিং বাগের সংখ্যা ১০% কমে গেছে
      • ২০২৪ সালে, ডেভেলপারদের ১৪৪ বার কাজগুলি পুনর্বিবেচনা করতে হয়েছিল কারণ মিডিয়াউইকি স্থাপনে বাধা দেওয়ায় একটি জরুরি অবস্থা হয়েছিল। এর মধ্যে অনেক ক্ষেত্রেই টেস্টউইকিতে স্থাপন করার পরে বাগগুলি ধরা পড়েছিল, যার অর্থ সমস্যাটি কোটি কোটি সম্ভাব্য ব্যবহারকারী পাঠকদের কাছে পৌঁছেছিল। বাগগুলি যে থাকবে, আমরা সেই বিষয়টিকে নিয়ন্ত্রণ করতে পারি না। কিন্তু আগে তাদের ধরতে পারলে কঠিন পরিশ্রম কমে যাবে। এর ফলে ডেভেলপারদের মধ্যে আস্থা তৈরি হবে যে যখন কিছু আসল উৎপাদন শুরু হবে, তখন সমস্যা হবে না।
      • ডেভেলপাররা যাতে আত্মবিশ্বাসের সাথে বিকাশ এবং প্রয়োগ চক্র জুড়ে তাঁদের কোড সরবরাহ এবং পরীক্ষা করতে পারেন তার জন্য প্রয়োজনীয় পরিবেশ প্রদান করে আমরা এই বাগগুলি আগে থেকেই ধরতে পারব। আমাদের আরও নিশ্চিত করতে হবে যে এই উন্নতিগুলি ডেভেলপারদের কাজের গতির বিনিময়ে না আসে।
    • মূল ফলাফল উই৬.২: চতুর্থ ত্রৈমাসিকের শেষে, উৎপাদন প্রস্তুতি পর্যালোচনা চেকলিস্টের ৪টি ধাপ এসআরই হস্তক্ষেপ ছাড়াই কার্যকর করা যেতে পারে
      • বর্তমানে উৎপাদনে মোতায়েন করা একটি নতুন পরিষেবা বা বৈশিষ্ট্য পাওয়া তালিকার ২৪টি ধাপের ওপর নির্ভর করে। যার প্রতিটি ধাপের জন্য সাধারণত এসআরই-দের সহায়তা প্রয়োজন। আমরা উন্নয়ন চক্রের শুরুতে হস্তক্ষেপ করার জন্য এবং উন্নয়ন দলগুলির মধ্যে ক্ষমতা তৈরি করার জন্য এসআরই অ্যাম্বাসেডর প্রোগ্রামটি প্রতিষ্ঠা করেছি, তবে অনেক কাজ সম্পূর্ণরূপে স্ব-পরিষেবাযোগ্য হওয়া উচিত। বর্তমানে, এটি এমন একটি কাজ যা ম্যানুয়াল, পুনরাবৃত্তিমূলক, স্বয়ংক্রিয় এবং উন্নয়ন দলের সংখ্যার সাথে একত্রে সামঞ্জস্যপূর্ণ। দীর্ঘমেয়াদে এটি এসআরই দলের জন্য স্থিতিশীল নয়।
      • অতীতে, এই কাজের বেশিরভাগই উন্নয়ন দল থেকে বিমূর্তভাবে নেওয়া হত, কিছু সাধারণ লাইব্রেরির সঙ্গে আদানপ্রদান করে এবং আমাদের প্ল্যাটফর্মের সাথে যোগাযোগের সেরা অনুশীলন বজায় রেখে কাজটি করা হত। আমরা যখন আমাদের নতুন কুবারনেটস অবকাঠামোতে স্থানান্তরিত হয়েছি তখন এগুলি পরিত্যক্ত হয়ে গেছে এবং এর সরাসরি প্রতিস্থাপনের ব্যবস্থা এখন নেই। আমরা বিশ্বাস করি যে, আমরা আজ যেভাবে জিনিসপত্র তৈরি এবং স্থাপন করি তার সাথে সম্পর্কিত অনুরূপ লাইব্রেরি, ডকুমেন্টেশন এবং প্রশিক্ষণ প্রদান করে আমরা উৎপাদনে একটি নতুন পরিষেবা বা বৈশিষ্ট্য স্থাপনের আগে এসআরই থেকে প্রয়োজনীয় সম্পৃক্ততার পরিমাণ কমাতে পারব।
    • মূল ফলাফল উই৬.৩: চতুর্থ ত্রৈমাসিকের শেষে, উইকিপিডিয়ার পাতা পরিদর্শনের ১০০% পার্সয়েডের মাধ্যমে পরিবেশিত হয়েছে
      • উইকিটেক্সট বিবর্তন এবং প্ল্যাটফর্মের ভবিষ্যৎ-প্রমাণীকরণের জন্য পার্সয়েড উন্নত ক্ষমতা প্রদান করে। একই সাথে দুটি পার্সার বজায় রাখা দীর্ঘমেয়াদে স্থিতিশীল নয়, কারণ এটি প্রযুক্তিগত ঋণ এবং জটিলতা বৃদ্ধি করে। উপরন্তু, উইকিফাংশনের মতো কিছু নতুন প্রকল্পের সাফল্য পার্সয়েডের ব্যাপক উপলব্ধতার ওপর নির্ভর করে।
      • আমরা ছোট প্রকল্পগুলোর মধ্যে ধীরে ধীরে এই কর্মসূচির বিস্তার ঘটাচ্ছি এবং এ বছর আমরা উইকিপিডিয়ার জন্য প্রস্তুত হব। পরবর্তী গুরুত্বপূর্ণ মাইলফলক হলো পাঠকদের কাছে উইকিপিডিয়ার সমস্ত পাতার প্রদর্শন পার্সয়েডের মাধ্যমে পরিবেশন করা। কর্মসূচির বিস্তারের পাশাপাশি, এই কাজের মধ্যে রয়েছে কর্মক্ষমতা সংক্রান্ত সমস্যাগুলির সমাধান করা এবং পাঠক ও সম্পাদকদের সাথে এর প্রভাব সম্পর্কে কার্যকরভাবে যোগাযোগ করা।
    • মূল ফলাফল উই৬.৪: দ্বিতীয় ত্রৈমাসিকের শেষে, উইকিগুলির বিস্তার বা উন্নতি বজায় রাখার ক্ষেত্রে আমাদের ক্ষমতাকে হুমকির মুখে ফেলতে পারে এমন কমপক্ষে দুটি চিহ্নিত ঝুঁকি প্রশমিত করা হয়েছে বা গ্রহণযোগ্য পর্যায়ে হ্রাস করা হয়েছে।
      • কয়েকটি লক্ষ্যযুক্ত উদ্যোগের মাধ্যমে, আমরা আমাদের প্ল্যাটফর্ম এবং আমাদের পাবলিক প্রকল্পগুলির বৃদ্ধি ও স্থায়িত্বের জন্য সম্ভাব্য হুমকি হিসাবে চিহ্নিত বেশ কয়েকটি বৃদ্ধির ঝুঁকি, নির্ভরযোগ্যতা বা নিরাপত্তার ঝুঁকি হ্রাস বা প্রশমিত করব।
      • উদাহরণস্বরূপ, আমরা কমন্সের মূল ডাটাবেসের কাঠামোর পুনর্বিন্যাস করব যাতে নিশ্চিত করা যায় যে আগামী কয়েক বছরের মধ্যে উপলব্ধ সার্ভার হার্ডওয়্যারের ক্ষমতা দ্বারা এর বৃদ্ধি যেন সীমাবদ্ধ না হয়। মিডিয়াউইকি এবং সংশ্লিষ্ট পরিষেবাগুলিকে শক্তিশালী করে এমন প্রোগ্রামিং ভাষা পিএইচপি-কে আমরা আরও আধুনিক সংস্করণে উন্নীত করব। অন্যান্য ঝুঁকি চিহ্নিত করার জন্য আমাদের অবকাঠামো রক্ষা এবং শক্তিশালী করার উদ্দেশ্যে অতিরিক্ত নিরাপত্তা ব্যবস্থা বাস্তবায়নের প্রয়োজন হতে পারে।
    • Key result WE6.5: By the end of Q4, determine the feasibility of and next steps for scalable cross-wiki code collaboration and logged-in reader support.
      • One of the central features of wikis is collaborative content creation. In the context of the Wikimedia movement, the collaboration needs are very specific to the evolution of the projects and the challenges that arise at the scales that some of the larger projects operate in.
      • Code collaboration (cross-wiki or on-wiki) is a legitimate need and should be accommodated. This is less a single problem and more a problem space that includes several overlapping problems around code (templates & modules primarily) and solving problems in this space requires shared understanding around priorities that are most impactful.
      • With an experimentation mindset, we're exploring a leaner approach to test shared code libraries that could improve cross-wiki collaboration in a small and controlled environment. This means we will go through a phase of technical feasibility and scope exploration to approach the experiment roll-out in small iterations to collect insights that can help us decide how we want to tackle the aforementioned problem. Our intention is to demonstrate our learnings and progress in the Wikimedia Hackathon 2026.
      • Similarly, if we want to improve the experience of logged-in users, we need to know where the performance gains are, what product work will make demands, and what a sustainable approach will look like for this work next FY. Research in this area will set us up for starting platform work quickly next FY.
    • Key result WE6.6: By end of Q4, developers are able to get the results of MediaWiki Core CI in under 10 minutes.
      • Our current median CI cycle time baseline is over 24 minutes while a DevEx industry standard for high performing teams is 10 minutes or less.
      • To bridge this gap, we're planning to optimize the CI workflows, address main bottlenecks such us browser tests by optimizing how we run them, the underlying testing framework and its configuration.
      • By slashing median CI wait times from 24 to 10 minutes we ensure the rapid feedback loop needed to test and fix issues quickly, significantly accelerating iteration speed. Additionally, improving this metric speeds up merge times, shortening the time between a change being ready and being available for deployment, which directly contributes to the top-level OW5 metric of making it "easier and faster to build products".
    • Key result WE6.7: By end of Q1 of 2026-27 fiscal year, developers are able to test MediaWiki code in production within 1 day of it being merged.
      • Currently, on average developers can test their code on production ~4 days after merging. By shrinking this time, developers can test sooner, and by improving test environments they will have more confidence that their tests will result in fewer bugs reaching production.

---

সিগন্যাল এবং ডেটা সার্ভিসেস (এসডিএস)

মানদণ্ড (এসডিএস১)

• উদ্দেশ্য: সিদ্ধান্ত গ্রহণকারীরা পণ্য এবং কৌশলগত সিদ্ধান্ত গ্রহণের জন্য আরও বিশ্বাসযোগ্য এবং সময়োপযোগী মানদণ্ড ব্যবহার করেন। আলোচনা
  • উদ্দেশ্যমূলক প্রেক্ষাপট: আন্দোলনকে সর্বোত্তমভাবে পরিবেশন করার জন্য আমাদের প্রচেষ্টা কোথায় কেন্দ্রীভূত করতে হবে সে সম্পর্কে ফাউন্ডেশনের সিদ্ধান্তগুলিকে অবহিত করার জন্য আমরা মেট্রিক্স ব্যবহার করি। তবে, আমাদের কিছু ডেটা পাইপলাইন ভেঙে যাওয়ার সম্ভাবনা থাকে, যার ফলে বিতরণে বিলম্ব হয়।
  • ২৫-২৬ অর্থবছরে, আমরা আমাদের বর্তমান পরিকল্পনায় ডেটা মানের ঘাটতি সমাধানের জন্য নির্দিষ্ট বার্ষিক পরিকল্পনা ব্যবহারের ক্ষেত্রে মনোনিবেশ করব, ডেটা মানের সমস্যাগুলি পর্যবেক্ষণ ও সমাধানের জন্য অবকাঠামো এবং প্রক্রিয়া স্থাপন করব এবং সিদ্ধান্ত গ্রহণকারীদের প্রবণতা বুঝতে সক্ষম করে এমন সরঞ্জাম সরবরাহ করব।
  • একটি ব্যবহারের উদাহরণ হলো আমরা কিভাবে মানব এবং বট ট্র্যাফিকের পরিমাপ করি। গত কয়েক বছরে স্বয়ংক্রিয় ট্র্যাফিকের উত্থানের ফলে মানুষ উইকিমিডিয়া প্রকল্পগুলির সাথে কতটা যোগাযোগ করছেন এবং অবদান রাখছেন তা বোঝা কঠিন হয়ে পড়েছে। আমরা মানব এবং বট ট্র্যাফিক প্যাটার্ন মূল্যায়ন করার ক্ষমতা উন্নত করার লক্ষ্য রেখেছি, যা পরিকল্পনা এবং পণ্য সিদ্ধান্তের জন্য গুরুত্বপূর্ণ ইনপুট।
    • মূল ফলাফল এসডিএস১.১: প্রথম ত্রৈমাসিকের শেষ নাগাদ, যে বিশ্লেষকরা পেজভিউ মেট্রিক্স ব্যবহার করেন, তাঁরা ডেটা মানের বেসলাইন পরিমাপের এবং স্বয়ংক্রিয় ট্র্যাফিক সনাক্তকরণ অনুসন্ধানের কর্মক্ষমতার পরিমাপের প্রবেশাধিকার পাবেন।
      • এই কেআর-এ বিশ্লেষণ করা অনুমানের মাধ্যমে, আমরা আমাদের বর্তমান স্বয়ংক্রিয় ট্র্যাফিক সনাক্তকরণ অনুসন্ধানের ফাঁকগুলি চিহ্নিত করব এবং বুঝতে চেষ্টা করব যে তারা কোথায় পাতা পরিদর্শন ট্র্যাফিককে সঠিকভাবে শ্রেণীবদ্ধ করতে ব্যর্থ হয়েছে। এই অন্তর্দৃষ্টিগুলি পাতা পরিদর্শন মেট্রিক্স তৈরি এবং শ্রেণীবদ্ধকারী পরিকল্পনাগুলিতে উন্নতির বিষয়ে অবহিত করবে। অতিরিক্তভাবে, আমরা ডেটা নির্ভুলতার উন্নতি পর্যবেক্ষণ এবং পরিমাপ করার জন্য ডেটা মানের মেট্রিক্স সংজ্ঞায়িত করব।
      • এই কেআর পরবর্তী কেআর-এর ভিত্তি তৈরি করবে, যেখানে এখানে চিহ্নিত প্রয়োজনীয় কার্যপ্রবাহ উন্নয়ন বাস্তবায়নের ওপর গুরুত্ব দেওয়া হবে। এই পর্যায়ে প্রতিষ্ঠিত ডেটা মান সূচকগুলো ভবিষ্যতের সেই উন্নয়নের কার্যকারিতা মূল্যায়নের জন্য মানদণ্ড হিসেবে কাজ করবে।
    • মূল ফলাফল এসডিএস১.২: প্রথম ত্রৈমাসিকের শেষ নাগাদ, মিডিয়াউইকি কন্টেন্ট ইতিহাস ডেটা সেটের বিষয়বস্তু উপলব্ধ করা হবে একটি ফাইল এক্সপোর্টের মাধ্যমে, সঙ্গে থাকবে সাপ্তাহিক ডেলিভারি গ্যারান্টি (এসএলও)। এক্সপোর্ট করা ফাইলের উপাত্ত লিগ্যাসি এক্সএমএল ডাম্পস ১ এক্সপোর্ট কার্যপ্রবাহের তুলনায় সমতা পাবে।
      • ২৪/২৫ আর্থিক বছরের কেআর১.৪ এর লক্ষ্য ছিল ৩টি সবচেয়ে প্রাসঙ্গিক নিচের দিকের কার্যপ্রবাহের জন্য মাসিক হালনাগাদ হওয়া mediawiki_wikitext_history এবং mediawiki_wikitext_history_current ডেটা সেটের ওপর নির্ভরতা দূর করা করা এবং গ্যারান্টিযুক্ত সাপ্তাহিক এসএলও সহ একটি বিকল্প ডেটা সেট প্রদান করা।
      • যদিও ২৪/২৫ আর্থিক বছরে কেআর ১.৪ সবচেয়ে প্রাসঙ্গিক নির্ভরশীল কার্যপ্রবাহের জন্য নির্ভরযোগ্যতার সমস্যাগুলি হ্রাস করতে সাহায্য করেছে, তবুও এখনও অবিশ্বস্ত লিগ্যাসি ইনপুট উৎস সহ অবশিষ্ট কার্যপ্রবাহগুলি রয়েছে। এগুলিকে এবং সেইসঙ্গে ফাইল ভিত্তিক ইনপুট উৎসকে উইকিটেক্সট ইতিহাস ডেটা সেটে স্থানান্তরিত করা উচিত।
    • মূল ফলাফল এসডিএস৩.৩: দ্বিতীয় প্রান্তিকের শেষে, বট সনাক্তকরণে আরও একটি সিগন্যাল অন্তর্ভুক্ত করা হয়েছে এবং অসঙ্গতির জন্য স্বয়ংক্রিয় সতর্কতা তৈরি করা হয়েছে।
      • ফাউন্ডেশন জুড়ে, দলগুলি মানব পাঠক এবং স্বয়ংক্রিয় ট্র্যাফিকের মধ্যে পার্থক্য নির্ধারণ করতে সক্ষমতার ওপর ভিত্তি করে পণ্য এবং তহবিল প্রদানের সিদ্ধান্ত নিচ্ছে। ডেটা প্ল্যাটফর্ম হল বট সনাক্তকরণ সংকেত এবং ব্যাচ বিশ্লেষণের কেন্দ্রীয় ভাণ্ডার। প্রথম/দ্বিতীয় ত্রৈমাসিকে আমরা যে অনুমানগুলি বিশ্লেষণ করেছি, তার ভিত্তিতে আমরা স্বয়ংক্রিয় ট্র্যাফিকের বিশ্লেষণকে তীক্ষ্ণ করার জন্য নতুন বট সনাক্তকরণ সংকেত প্রবর্তন শুরু করার পরিকল্পনা করছি, এবং নতুন সংকেত প্রবর্তনের প্রক্রিয়াটিকে দক্ষ ও পুনরাবৃত্তিযোগ্য করে তোলার জন্য কাজ শুরু করব।
    • মূল ফলাফল এসডিএস১.৪: দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ, সিদ্ধান্ত গ্রহণকারীরা আমাদের সাংগঠনিক মেট্রিক্স দ্বারা প্রদত্ত অন্তর্দৃষ্টির বর্তমান অবস্থা সম্পর্কে স্পষ্ট ধারণা অর্জন করতে পারবেন। আমরা যদি একটি বোর্ড মিটিং-প্রস্তুত উপস্থাপনা ডেক প্রদান করি যা উইকিমিডিয়া ইকোসিস্টেমের পাশাপাশি বিস্তৃত ইন্টারনেট প্রবণতা এবং বাজারে চ্যালেঞ্জগুলির মধ্যে আমাদের মেট্রিক্সের বিশ্লেষণ স্থাপন করে, তাহলে আমরা জানতে পারব যে আমরা সফল।
      • ফাউন্ডেশন জুড়ে অসংখ্য সিদ্ধান্ত নেওয়ার জন্য আমাদের সাংগঠনিক মেট্রিক্স থেকে প্রাপ্ত অন্তর্দৃষ্টি ব্যবহার করা হয়, যার মধ্যে রয়েছে আমরা কিভাবে আমাদের পণ্য তৈরি করি, কিভাবে আমরা অবকাঠামোগত সম্পদ বরাদ্দ করি এবং কিভাবে আমরা তহবিল সংগ্রহ করি সে সম্পর্কে সিদ্ধান্তগুলি। একই সাথে, ইন্টারনেটের ইকোসিস্টেম বিকশিত হচ্ছে, বিশেষ করে স্বয়ংক্রিয় ট্র্যাফিক আমাদের মেট্রিক্সকে প্রভাবিত করছে। ফাউন্ডেশনের নেতৃত্বের লক্ষ্য হল ডিসেম্বরের বোর্ড সভায় উইকিমিডিয়া ইকোসিস্টেমের হুমকি এবং সুযোগ সম্পর্কে একটি স্পষ্ট ধারণা নিয়ে প্রবেশ করা, যা অভ্যন্তরীণ মেট্রিক্স এবং বাহ্যিক প্রবণতার আত্মবিশ্বাসী বিশ্লেষণ দ্বারা সমর্থিত হবে।
        • আমাদের পাঠকসম্প্রদায়ের অভ্যন্তরীণ পরিমাপের প্রবণতা (পাতা পরিদর্শন)
        • আমাদের অবদানকারী বাস্তুতন্ত্রের প্রবণতা
        • বহিরাগত তথ্য এবং প্রতিযোগী মানদণ্ড থেকে প্রবণতা
        • অভ্যন্তরীণ ও বহিস্থ গবেষণা এবং বিশ্বস্ত গবেষণা থেকে প্রাপ্ত অন্তর্দৃষ্টি
    • Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
      • In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
        • Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
        • Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).

We will need knowledge and calibration from third-parties that specialize in this domain to be able to quantify our current state and prioritize future improvements.

• • • • In Q3/Q4, we will follow that with three main deliverables:

• • • • • Extend our pageview metric to incorporate a numerical confidence score in addition to the existing labels, computed from at least 2 new signals, which will allow analysts to quantify and convey the nuances of those signals.
        • Curate trusted labels, preferably sourced from a third-party that specializes in this domain, and use it to evaluate our current performance and better understand the new signals.
        • Operationalize a client-side signal, which remains the most promising internally developed detection method.
    • Key result SDS1.6: Deliver a Movement Insights report on a regular basis, with consistent coverage across readership, contributors, and content thematic areas. We’ll know we’re successful when we’ve established the following by the end of Q4:
      • A consistent delivery cadence
      • Most valuable content for our stakeholders
      • Areas for future automation
      • Today, critical signals about the health of the Wikimedia Movement are fragmented across systems and teams. Readership trends, contributor health, brand perception, SEO/AEO, and competitor intelligence are monitored independently, without a consistent process or systems to aid in interpreting them together. We have existing monthly metric monitoring processes but they don’t address the scope and focus that is needed by executive decision-makers. The Movement Trends Brief is a concise, recurring intelligence brief that provides leadership and product teams with a shared understanding of how the Wikimedia movement is evolving week over week. Rather than describing everything that happened, this communication answers the following questions consistently:
        • What meaningfully changed in the past week/2 weeks?
        • Have we learned anything new about existing trends that we’re questioning?
        • Why does it matter now?
        • What requires attention or action?
      • The brief is designed to support situational awareness and provide a forum to present deeper analysis. It surfaces early signals, connects related trends across various data sources, and creates an entry point to inform decision-making.

---

পরীক্ষামূলক প্ল্যাটফর্ম (এসডিএস২)

• উদ্দেশ্য: পণ্য পরিচালকরা উইকিপিডিয়ায় পণ্য বৈশিষ্ট্য পরিবর্তনের প্রভাব দ্রুত, সহজে এবং আত্মবিশ্বাসের সাথে মূল্যায়ন করতে পারেন। আলোচনা
  • উদ্দেশ্যমূলক প্রেক্ষাপট: পণ্য বৈশিষ্ট্য উন্নয়নের বিষয়ে তথ্য-ভিত্তিক সিদ্ধান্ত গ্রহণকে সক্ষম এবং ত্বরান্বিত করার জন্য, পণ্য পরিচালকদের একটি পরীক্ষামূলক প্ল্যাটফর্মের প্রয়োজন যেখানে তাঁরা বৈশিষ্ট্যগুলি সংজ্ঞায়িত করতে, লক্ষ্যভিত্তিক ব্যবহারকারী গোষ্ঠী নির্বাচন করতে এবং প্রভাবের পরিমাপ দেখতে পারেন। উৎক্ষেপণ থেকে বিশ্লেষণ পর্যন্ত সময় দ্রুত করা অত্যন্ত গুরুত্বপূর্ণ, কারণ শেখার সময়সীমা সংক্ষিপ্ত করলে পরীক্ষা-নিরীক্ষা ত্বরান্বিত হবে এবং শেষ পর্যন্ত উদ্ভাবনও ত্বরান্বিত হবে। ম্যানুয়াল কাজ এবং পরিমাপের জন্য ইচ্ছামত পদ্ধতিগুলিকে গতির বাধা হিসেবে চিহ্নিত করা হয়েছে। আদর্শ পরিস্থিতি হল, প্রকৌশলী এবং বিশ্লেষকদের খুব কম বা কোনওরকম ম্যানুয়াল হস্তক্ষেপ ছাড়াই পণ্য পরিচালকরা পরীক্ষামূলক প্রবর্তন থেকে আবিষ্কার পর্যন্ত যেতে পারেন।
  • আমরা আগামী অর্থবছরে উইকিপিডিয়ার ওপর গুরুত্ব দিচ্ছি, কারণ কোর এক্সপেরিয়েন্স সেখানে পরীক্ষামূলক কাজ করতে আগ্রহী (সংগঠনের কৌশল অনুযায়ী আমরা উইকিপিডিয়ায় আরও বেশি জোর দিচ্ছি)। আর এভাবে আমরা কোন কোন দল ও প্রকল্পের সঙ্গে কাজ করছি তা আরও পরিষ্কারভাবে তুলে ধরতে ও লক্ষ্যভিত্তিকভাবে এগোতে পারবো। অন্যান্য দল পরীক্ষামূলক প্ল্যাটফর্মের উপাদানগুলি ব্যবহার করেছে এবং এটি চালিয়ে যেতে পারে, তবে সেই ব্যবহার এই উদ্দেশ্যের কেন্দ্রবিন্দু হবে না।
    • মূল ফলাফল এসডিএস২.১: দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ, পরীক্ষামূলক প্ল্যাটফর্ম ব্যবহার করে কমপক্ষে ২টি সম্পূর্ণ পরীক্ষামূলক চক্র সম্পন্ন করতে সক্ষম করা হবে।
      • যেহেতু সংস্থাটি ক্রমবর্ধমানভাবে ডেটা-অনুমোদিত পণ্য সিদ্ধান্তের ওপর জোর দিচ্ছে, তাই আমাদের অবশ্যই পরীক্ষা-নিরীক্ষা সকল পণ্য দলের জন্য উপলব্ধ করে তুলতে হবে, কেবল বিশেষ দক্ষতা সম্পন্ন ব্যক্তিদের জন্য নয়। মানক, সরঞ্জাম এবং অবকাঠামোর তথ্যের ভাগ পণ্য দলগুলির প্রয়োজন, যা তাদের সক্ষম করবে:
        • আমাদের বিশ্বব্যাপী ব্যবহারকারী ভিত্তি জুড়ে দ্রুত ধারণাগুলি পরীক্ষা করতে
        • মানসম্মত মেট্রিক্স ব্যবহার করে পণ্যের পরিবর্তনের প্রভাব পরিমাপ করতে
        • আমাদের আন্দোলনের অংশীদারদের সঙ্গে স্বচ্ছতার সাথে ফলাফল শেয়ার করতে।
      • কেন আমরা "সক্রিয় টিমের" সংখ্যার ওপর মনোযোগ কেন্দ্রীভূত করার পরিবর্তে "পরীক্ষা সম্পন্ন" করার ওপর মনোনিবেশ করছি:
      1. কৌশলগত সমন্বয়: এটি প্ল্যাটফর্মের প্রাথমিক সাফল্যের মাপকাঠি।
      2. তথ্য-অনুসন্ধান পদ্ধতি: ব্যবহারকারী গবেষণা (চলছে) আমাদের পুরো প্রতিষ্ঠান জুড়ে পরিবর্তনশীল দল প্রস্তুতির পরামর্শ দেয়, যদিও আমরা জানি যে ওয়েব দল দুটি নির্দিষ্ট পরীক্ষায় আগ্রহ নিশ্চিত করেছে।
      3. সংস্থানের সবচেয়ে কার্যকর ব্যবহার: আমাদের এমভিপি প্ল্যাটফর্ম চালু করার ক্ষেত্রে উচ্চমাত্রার সহায়তা ও অনবোর্ডিংয়ের প্রয়োজন হবে। তাই স্বল্পমেয়াদে বহু টিমে ছড়িয়ে পড়ার বদলে পরীক্ষামূলক সুযোগগুলোর ওপর মনোযোগ দেওয়াই বেশি কার্যকর হবে। আমরা সাধারণ প্রকাশের দিকে অগ্রসর হওয়ার পরিকল্পনা করছি এবং প্রয়োজন না হলে একই টিমগুলির জন্য পুনরায় প্রশিক্ষণে বিনিয়োগ করতে চাই না।
      4. ভবিষ্যৎ কেন্দ্রিক: আংশিক বা অসম্পূর্ণ গ্রহণ থেকে প্রাপ্ত শিক্ষার বদলে সম্পূর্ণ পরীক্ষা চক্র থেকে প্রাপ্ত প্রতিক্রিয়া আমাদের প্ল্যাটফর্মের উন্নতিগুলিকে আরও কার্যকরভাবে জানাবে। আমরা যখন সাধারণ প্রকাশের দিকে এগিয়ে যাচ্ছি, তখন পরীক্ষা সমাপ্তির ওপর মনোযোগ কেন্দ্রীভূত করার ফলে অস্থায়ী পদ্ধতিতে, যেখানে পুনর্বিকাশের প্রয়োজন হয়, বিনিয়োগ এড়ানো যাবে।
      • আমাদের পরস্পর দলের চাহিদা এবং প্রয়োজনীয়তাগুলি পূরণ করার জন্য ব্যবহারকারী গবেষণা প্রক্রিয়াধীন রয়েছে: ২০২৫ সালের মে মাসের দ্বিতীয়ার্ধে পণ্য দলের চাহিদাগুলিতে স্পষ্টতা যোগ করার জন্য জরিপ এবং সাক্ষাৎকারের সময়সূচী নির্ধারণ করা হচ্ছে। এই গবেষণাটি সম্পন্ন হয়ে গেলে, আমরা একটি পরীক্ষামূলক ক্যালেন্ডার তৈরি করব যা আমাদের পরবর্তী কেআর লক্ষ্য এবং অগ্রাধিকার নির্ধারণ করতে ব্যবহার করা যেতে পারে।
    • Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
      • After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
      • Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
      • The architectural decisions we made during FY24/25 SDS2 and GrowthBook’s modularity allow us to replace parts of the Experimentation Lab out of order, i.e. WMF staff can define and deploy experiments with xLab UI while analyzing them with GrowthBook. Further, we can run the current experiment analytics pipeline and GrowthBook’s in parallel, which allows for side-by-side comparisons as well as User Acceptance Testing in real-world scenarios.
    • Key result SDS2.3: By the end of Q4, all new Test Kitchen experiments are configured in GrowthBook.
      • After having enabled WMF staff to use GrowthBook for analyzing experiment results, the Experiment Platform team held a design sprint to assess options for experiment configuration. The decision was to use GrowthBook as the source of truth for experiment configuration but keep Test Kitchen UI (TKUI) as the source of truth for instrument configuration.
        In making GrowthBook the source of truth for experiment configuration, we aim to:
        • Reduce coordination when running an experiment
        • Enable more frequent and repeatable experimentation
        • Clearly delineate between instruments and experiments
        • Move toward a mental model centered on metrics rather than instruments
    • Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
      • The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
      • KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
      • This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

---

ফিউচার অডিয়েন্স (এফএ)

ফিউচার অডিয়েন্স (এফএ১)

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

---

সামাজিক ভিডিও (এফএ২)

• উদ্দেশ্য: তরুণ বয়সীরা (<২৫ বছর বয়সী) উইকিপিডিয়ার বিষয়বস্তু ভালোবাসে, শেখে, এর সাথে যুক্ত হয় এবং যেখানে তারা অনলাইনে সময় কাটাতে পছন্দ করে সেখানে বিষয়বস্তু ভাগ করে নেয়। আলোচনা
  • উদ্দেশ্যমূলক প্রেক্ষাপট: এই অর্থবছরে ছোট ভিডিও নিয়ে ভবিষ্যৎ পাঠকের পরীক্ষা-নিরীক্ষা দেখিয়েছে যে আমরা এই প্ল্যাটফর্মগুলিতে বৃহৎভাবে তরুণ দর্শকদের কাছে পৌঁছোতে পারি, কিন্তু আমাদের ব্র্যান্ড হেলথ ডেটা দেখায় যে জেন-জেড পাঠকদের মধ্যে উইকিপিডিয়ার প্রতি সচেতনতার অভাব এবং প্রবণতা হ্রাসের বিরুদ্ধে লড়াই করার জন্য আমাদের বর্তমান বিনিয়োগ যথেষ্ট নয়।
  • এই প্রজন্মের কাছে কার্যকরভাবে পৌঁছোতে এবং তাদের সম্পৃক্ত করতে, আমরা বিশ্বাস করি যে আমাদের বিভিন্ন কৌশল অবলম্বন করতে হবে। অর্থপ্রদানকারী ও প্রভাবশালী বিপণন, সৃজনশীল প্রচারণা, প্রবণতার প্রতি প্রতিক্রিয়াশীল হওয়া এবং এই চ্যানেলগুলিতে আমাদের পরীক্ষা-নিরীক্ষার স্তর বৃদ্ধির মতো ক্ষেত্রগুলিতে আমাদের সম্পৃক্ততা উল্লেখযোগ্যভাবে বৃদ্ধি করতে হবে।
  • আমরা মনে করি আমরা যে চ্যালেঞ্জগুলির মুখোমুখি হচ্ছি, বিশেষ করে যোগাযোগ এবং বিপণনের প্রচেষ্টায় সম্পৃক্ততা তৈরিতে, সেগুলি কাটিয়ে উঠতে আমাদের আরও উল্লেখযোগ্য বিনিয়োগের প্রয়োজন হবে। এর পাশাপাশি এই প্ল্যাটফর্মগুলিতে নতুন পণ্য সৃষ্টির জন্য আন্তঃবিভাগীয় সহযোগিতার এবং উইকিপিডিয়ার ব্র্যান্ড ও বিষয়বস্তুর উপস্থিতি বৃদ্ধির লক্ষ্যে অভিজ্ঞতার প্রয়োজন।
    • মূল ফলাফল এফএ২.১: এইচ১ এর শেষ নাগাদ সমস্ত নিজস্ব চ্যানেল জুড়ে সংক্ষিপ্ত-ফর্ম ভিডিও বিষয়বস্তু থেকে ৯,৫০০,০০০ প্রদর্শন তৈরি করতে হবে।
      • এই বছর, আমরা টিকটক, ইনস্টাগ্রাম এবং ইউটিউবে @উইকিপিডিয়া চ্যানেলগুলিতে সংক্ষিপ্ত ভিডিও চালু করার ৩ মাসের মধ্যে প্রায় ১০ লক্ষ প্রদর্শন অর্জন করেছি। আগামী আর্থিক বছরের শুরুতে, আমরা আমাদের নিজস্ব চ্যানেলগুলিতে আরও বেশি অনুগামী এবং কার্যকর/আকর্ষণীয় বিষয়বস্তু সম্পর্কে আরও অন্তর্দৃষ্টি আশা করি যা আমরা আরও বেশি দর্শকদের কাছে পৌঁছানোর জন্য বাস্তবায়িত করতে পারি।
      • বছরের প্রথমার্ধে একটি উচ্চ লক্ষ্য নির্ধারণের মাধ্যমে, আমরা আরও উল্লেখযোগ্য প্রভাবের দিকে এগিয়ে যাওয়ার আশা করি, কাজটি সহজতর করার জন্য নতুন কৌশল/প্রক্রিয়া তৈরির সুযোগ করে দেব এবং এই লক্ষ্য অর্জনের উদ্দেশ্যে অতিরিক্ত সংস্থানের জন্য সমর্থন জানাতে সক্ষম হব।
    • মূল ফলাফল এফএ২.২: ২৫/২৬ আর্থিক বছরের (জুন ২০২৬) শেষ নাগাদ টিকটক-এ আমাদের অফ-প্ল্যাটফর্ম অনুগামীদের সংখ্যা মধ্য স্তর (১ লক্ষ–২.৫ লক্ষ অনুগামী) থেকে ম্যাক্রো স্তর (২.৫ লক্ষ–১০ লক্ষ অনুগামী) পর্যন্ত বৃদ্ধি করা।
      • আমরা বর্তমানে টিকটক-এর অনুগামীদের মধ্যম স্তরে আছি (১০০,০০০-২৫০,০০০ অনুগামী), এবং আমাদের লক্ষ্য হল ২৫/২৬ অর্থ বর্ষের (জুন ২০২৬) শেষ নাগাদ ম্যাক্রো স্তরে (২৫০,০০০-১ মিলিয়ন অনুগামী) পৌঁছোনো। মাইক্রো, মধ্য এবং ম্যাক্রো এই স্তরগুলি দর্শকের আকার এবং প্রসারণের ক্ষমতার জন্য শিল্পে আদর্শ মানদণ্ড। সেই লক্ষ্যে পৌঁছানোর জন্য, আমরা আমাদের কন্টেন্ট কৌশলকে আরও উন্নত করব যাতে জেন জেড-এর অনুসারীদের আরও ভালোভাবে আকৃষ্ট করা যায় এবং সম্প্রদায় ব্যবস্থাপনার মাধ্যমে আমাদের সামগ্রিক দৃশ্যমানতা বৃদ্ধি করা যায়। এইচ১ এর কর্মক্ষমতা থেকে পাওয়া কৌশলগত সমন্বয়ের মাধ্যমে এইচ২-তে প্রবৃদ্ধি ত্বরান্বিত হবে এবং এই মাইলফলক অর্জন করবে।
    • মূল ফলাফল এফএ২.৩: ভবিষ্যতের দর্শকদের শেখার/মিডিয়া ব্যবহারের নতুন পদ্ধতির লক্ষ্যে প্ল্যাটফর্মের বাইরে একটি পণ্য চালু করা এবং একটি সহযোগিতামূলক পণ্য ব্র্যান্ডিং ও বিপণন প্রচারণার মাধ্যমে এটি বাজারে আনা।
      • ফিউচার অডিয়েন্স দল সাধারণত ন্যূনতম/জৈব বিপণনের মাধ্যমে ছোট আকারের পরীক্ষা-নিরীক্ষার ওপর কাজ করে। এই বছর, আমরা প্ল্যাটফর্মের বাইরে তরুণ দর্শকদের লক্ষ্য করে আরও বর্ধিত নতুন পণ্য + বিপণন প্রচারণার জন্য সময় সংরক্ষণ করতে চাই।

---

পণ্য ও প্রকৌশল সহায়তা (পিইএস১)

• উদ্দেশ্য: উন্নত প্রক্রিয়ার কারণে ডব্লিউএমএফ-এর পণ্য এবং প্রকৌশল দলগুলি আরও কার্যকরভাবে কাজ করে, এটি আমাদের সংস্কৃতিতে ইতিবাচক পরিবর্তন আনছে। আলোচনা
  • উদ্দেশ্যমূলক প্রেক্ষাপট: এই উদ্দেশ্যটি নেওয়া হয়েছে উইকিমিডিয়া ফাউন্ডেশনের কাজের পদ্ধতিগুলিকে দ্রুত, পরিচ্ছন্ন এবং উন্নত করে তোলার জন্য। আমরা কিভাবে কাজ করি এটি সম্পূর্ণরূপে তার উপর নির্ভর করে। এর অর্থ হল প্রক্রিয়াগুলিতে সংঘাত ও বাধা (অদক্ষতা এবং ত্রুটি) কমানো এবং দ্রুত প্রভাব অর্জন করা। সারা বিভাগ এবং সংস্থা জুড়ে গ্রহণ করা যেতে পারে এমন কাজের পদ্ধতি শেখার বিষয়েও এই উদ্দেশ্যটি কাজ করে।
    • মূল ফলাফল পিইএস১.১: দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ, অগ্রাধিকার তালিকার ওপর ভিত্তি করে ৬টি উৎপাদন পরিষেবার জন্য এসএলও সংজ্ঞায়িত করা, যার লক্ষ্য হল সংশ্লিষ্ট দলগুলির নির্ভরযোগ্যতা সম্পর্কিত কাজের অগ্রাধিকার নির্ধারণে অবগত সিদ্ধান্ত নেওয়ার জন্য কিভাবে এসএলও-কে সংজ্ঞায়িত করতে হয় এবং তাকে ব্যবহার করতে হয় সে সম্পর্কে আমাদের শেখা সর্বাধিক করা।
      • একটি পরিষেবা স্তরের উদ্দেশ্য (এসএলও) হল সংশ্লিষ্ট দলগুলির মধ্যে পরিষেবার একটি লক্ষ্য স্তর (নির্ভরযোগ্যতা/কর্মক্ষমতা) নিয়ে একটি চুক্তি করা, দলগুলি যা পূরণ করতে সহযোগিতা করবে (এবং খুব বেশি অতিক্রম করে না)। উদাহরণস্বরূপ, কখন নির্ভরযোগ্যতাকে বা কর্মক্ষমতাযুক্ত কাজকে একটি উন্নয়ন দল অগ্রাধিকার দেবে বা বঞ্চিত করবে, অথবা কোনটি সমস্যা তৈরি করছে, এই এসএলও সেটি নির্ধারণ করতে সাহায্য করে। কোনটি তাৎক্ষণিক (সতর্কীকরণ/ঘটনার প্রতিক্রিয়া/সংকটপূর্ণ ত্রুটি) এবং কোনটি তাৎক্ষণিক নয় তা চিহ্নিত করার বিষয়ে দলগুলিকে যত্নবান হতে হবে। লক্ষ্য হল বিভিন্ন কার্যাবলীর মধ্যে সংঘর্ষ কমানোর উদ্দেশ্যে লক্ষ্যমাত্রা নিয়ে আলোচনা করে এবং সকলের সঙ্গে তা ভাগ করে নিয়ে স্পষ্ট অগ্রাধিকার নির্ধারণ করা।
    • মূল ফলাফল পিইএস১.২: দ্বিতীয় ত্রৈমাসিকের শেষ নাগাদ, সম্প্রদায়ের ইঙ্গিত (ইচ্ছা তালিকা সহ) ডব্লিউএমএফ-কে প্রভাবিত করেছে তৃতীয় ত্রৈমাসিক থেকে চতুর্থ ত্রৈমাসিকের জন্য কমপক্ষে ৫টি পণ্য কর্মধারাকে অগ্রাধিকার দেওয়ার জন্য।
      • দলগুলি যখন প্রমাণভিত্তিক সম্প্রদায়ের চাহিদাকে অগ্রাধিকার দিয়ে কাজ করে, তখন তাকে চিহ্নিত এবং উদযাপন করাই আমাদের লক্ষ্য।
      • দুটি পরিকল্পিত অনুমান শুধুমাত্র ইচ্ছা তালিকার ওপর কেন্দ্রীভূত। এগুলি আস্থা উন্নত করার জন্য, প্রক্রিয়াগুলিকে সহজতর করার জন্য এবং কর্মী ও স্বেচ্ছাসেবকদের মধ্যে অংশগ্রহণ বৃদ্ধি করার জন্য তৈরি করা হয়েছে। আরেকটি অনুমান হল একটি পরীক্ষা। সম্প্রদায়ের আলোচনাসভা ইত্যাদি থেকে যথেষ্ট মূল্যবান ইঙ্গিত পাওয়া যাচ্ছে কিনা এবং এআই আমাদের তথ্য সংগ্রহের ক্ষমতাকে সহায়তা করতে পারে কিনা দেখার জন্য এটি ডিজাইন করা হয়েছে।
    • মূল ফলাফল পিইএস১.৩: আমাদের বার্ষিক পরিকল্পনায় দুটি প্রাথমিক পর্যায়ের আন্তঃবিভাগীয় পরীক্ষা ফাউন্ডেশন অন্তর্ভুক্ত করেছে। এগুলি বহিস্থ গ্রাহক, দাতা এবং অবদানকারী পাঠকের দ্বারা যাচাইকৃত।
      • আমাদের প্রতিষ্ঠান জুড়ে পরীক্ষা-নিরীক্ষা তৈরি করা ও পরীক্ষামূলক প্রক্রিয়া গ্রহণের জন্য এই কাজটি নেওয়া হয়েছে।
      • ফাউন্ডেশন তার বার্ষিক পরিকল্পনায় আন্তঃবিভাগীয় পরীক্ষা-নিরীক্ষার সংস্কৃতিকে শক্তিশালী করার জন্য দুটি বৈধ, প্রাথমিক পর্যায়ের পরীক্ষা অন্তর্ভুক্ত করেছে। এই উদ্যোগটি পণ্য ও প্রযুক্তি বিভাগের বৈশিষ্ট্য দলগুলির বাইরেও সহযোগিতাকে উৎসাহিত করে, সংস্থার অন্যান্য বিভাগগুলির সাথে (যেমন যোগাযোগ এবং প্রগতি) আরও উদ্ভাবনকে উৎসাহিত করে। নতুন ও অপরীক্ষিত ধারণা প্রবর্তন করে এবং পরীক্ষার প্রক্রিয়া সহজতর করার মাধ্যমে দলগুলি উৎপাদনশীলতা বাড়ায় ও আরও বড় প্রভাব বিস্তার করতে পারে। প্রতি বছর দুটি আন্তঃবিভাগীয় পরীক্ষা সম্পন্ন করে সাফল্যের পরিমাপ করা হয়, ভবিষ্যতের ওকেআর কাজে সেগুলিকে একীভূত করা হয় এবং পরীক্ষামূলক অনুশীলনের পরিকল্পনা বৃদ্ধি করা হয়। আউটপুটের উদাহরণ হল নতুন সম্পাদকের বৃদ্ধি এবং উৎপাদনশীলতা বৃদ্ধির জন্য নতুন প্রোটোটাইপ, পরীক্ষামূলক বৈশিষ্ট্য যা পাঠক এবং দাতাদের উইকিপিডিয়ার সাথে সংযোগকে আরও গভীর করবে। চিহ্নিত একটি নির্দিষ্ট সুযোগ হল উইকিপিডিয়ার ২৫তম জন্মদিন উদযাপনের জন্য ছোট বৈশিষ্ট্য অনুসন্ধানগুলিকে সংযুক্ত করা।
    • Key result PES1.4: By the end of Q4, we'll see a 10% adoption rate increase for Codex among P&T teams.
      • As a standardized UI library, Codex vastly reduces both the maintenance burden of creating custom UI components, as well as the time needed for implementing product UIs. Codex also provides a shared vocabulary for talking about design and implementation, which increases efficiency between Design & Engineering.
      • Codex will lose utility if adoption doesn’t increase and Codex isn’t widely used, and currently it is not being adopted or widely used in some places because the tooling isn't ready for some use cases. It may also need more prominent advertising/awareness. This work is a priority because teams must be able to adopt Codex organically, and currently not all can without blockers to adoption being addressed first.
      • We're anticipating that this will mean:
        • Discovery - What do different teams show us is blocking them? What are the use cases and blockers about which we are not yet aware?
        • Improvement - Example: We know that Codex PHP 1.0 will unblock server-side adoption.
        • Metrics deep dive - Example: What do the baseline metrics established in Q1 tell us about where organic adoption is not working (and are there lessons from OOUI adoption in years past)?
      • The KR will focus on tracking “official” usage (i.e. adoption that follows the documented guidance) separately from partial or piecemeal usage, e.g. when teams use only part of a component or just the CSS. The latter type of adoption incurs a higher maintenance cost than out-of-the-box component usage.
    • Key result PES1.5: 20% of service SLOs result in an impactful decision made by the end of Q4.
      • Service Level Objectives (SLOs) are a tool used to determine priorities based on data from service reliability. For instance, whether a down service needs immediate attention. SLOs work most effectively when ownership is clear, and everyone is using them. To make this happen we need to shift development culture toward adopting SLOs for every service. Building on the last few quarters of creating SLOs and testing them with service teams, we've identified an opportunity to clarify the value of SLOs, so that we can continue to spread this culture.
        • We have 19 SLOs currently.
        • We want to incentivize SLOs for services that would be most likely to leverage them. If we get ~3-4 (~20% 0f 19) "impactful decisions" from our current crop, great, but we anticipate we'll need to make more. The denominator will increase, but that further incentivizes targeting the right services.
        • Q4 is the end of the timebox because we want more than one cycle of data, and each quarter is a cycle. It also gives us space to shore up tooling, pilot SRE-alerting, etc.
      • Success looks like:
        • Impactful decision = “is this service currently reliable enough, or do we need to prioritize work to fix it” -- that is, it's as much a decision to find an error and say it's OK not to prioritize it, as it is to find an error and prioritize correcting it.
        • We want decisions to be diverse (e.g. Architectural vs Organizational vs Implementation; or affirmative vs deciding not to do something), because this is about spreading the value of SLOs and shifting culture. All the same type of decision or all from the same team doesn't accomplish that, even if it's good.
        • Even if we don't meet the KR target, we hypothesize that we'll have learned valuable information about why (e.g. we're targeting the wrong services).
        • Important: 80% of our SLOs not having an impactful decision is not a failure state for those, because most of the time services should not be failing.
    • Key result PES1.6: 20% of critical unowned services, according to a risk analysis framework, get owners committed by the end of Q4.
      • Clear code and service ownership is critical to ensuring the Wikimedia Foundation’s technical infrastructure remains reliable, scalable, and secure. Addressing current gaps in ownership will improve accountability, enhance cross-team collaboration, fast-track effective decision-making, and reduce risks to platform stability, security and sustainability. Additionally, it will provide greater clarity for Wikimedia affiliates and volunteers, helping them understand who is responsible for maintaining and supporting key services.
        • We estimate there are ~20 critical services without owners.
        • We think we can assign 4 owners over 4 months during Q3/4. The first 2 months or so will be setting ourselves up for success with prep work.
        • We plan to develop a risk analysis framework to determine criticality, as part of hypothesis work under this KR.
    • Key result PES1.7: By the end of Q4, 85% of wishes have a response within 10 working days, and a monthly update is posted on the work we committed to implement.
      • Having revamped Wishlist triage in the first half of the year, we want to consistently demonstrate that volunteers are getting responses to their Wishes plus a monthly update consisting of what’s coming, what’s pending or blocked, and what’s being scoped. We will judge the metric by measuring response time on a rolling average over a month, and aim to sustain that for at least a month.

অনুমান

কিউ১

ডব্লিউএমএফ-এর বার্ষিক পরিকল্পনার প্রথম ত্রৈমাসিক (কিউ১) জুলাই-সেপ্টেম্বর জুড়ে।

উইকি অভিজ্ঞতা (উই) অনুমান [ উই-এর মূল ফলাফল ] আলোচনা
অনুমানের সংক্ষিপ্ত নাম	কিউ১ পাঠ্য	বিস্তারিত এবং আলোচনা
WE1.1.1	নতুন(তম) স্বেচ্ছাসেবকেরা কোনও বাহ্যিক সাইট থেকে আনা পাঠ্য পেস্ট করলে, তারা যে সামগ্রী যুক্ত করার চেষ্টা করছে সেটি তাদের নিজস্ব লেখা কিনা তা নিশ্চিত করার জন্য যদি আমরা অনুরোধ করি, তাহলে দেখতে পাব নতুন সামগ্রী সম্পাদনায় WP: COPYVIO (এবং সম্পর্কিত নীতি) এর ভিত্তিতে আগেকার অবস্থায় ফিরে আসাতে (রিভার্ট) শতকরা ১০% হ্রাস হয়েছে।
WE1.1.2	যদি আমরা "ইমপ্রুভ টোন" সাজেস্টেড এডিট-এর একটি প্রাথমিক বিটা সংস্করণ সরবরাহ করি, তাহলে আমরা জানতে পারব যে সাজেস্টেড এডিট-এর এই নতুন ফর্ম্যাটটি নতুন অবদানকারীদের জন্য গঠনমূলক সম্পাদনা বৃদ্ধি করার একটি অর্থপূর্ণ উপায় কিনা, এবং এর ফলে প্যাট্রোলার/পর্যালোচকদের জন্য মডারেশনের বোঝা কমবে।
WE1.1.3	যদি আমরা ভিজ্যুয়াল এডিটরের (মোবাইল + ডেস্কটপ) মধ্যে অভিজ্ঞ অবদানকারীদের লক্ষ্য করে একটি নতুন পরামর্শ মোডকে বিটা বৈশিষ্ট্য হিসেবে স্থাপন করি, যার মধ্যে ≥ ৩টি নতুন সম্পাদনা পরামর্শ থাকবে, তাহলে আমরা একটি নিয়ন্ত্রিত পরীক্ষার মাধ্যমে, যদি প্রয়োজন হয়, নতুন স্বেচ্ছাসেবকদের অভিজ্ঞতা মূল্যায়ন করার আগে কি সমন্বয় করা প্রয়োজন তা আবিষ্কার করব।
WE1.1.4	যদি আমরা একটি নিয়ন্ত্রিত পরীক্ষার মাধ্যমে en.wiki-তে রেফারেন্স চেক স্থাপন করি, তাহলে আমরা নতুন স্বেচ্ছাসেবকদের দ্বারা প্রকাশিত গঠনমূলক সম্পাদনাগুলিতে ≥১০% বৃদ্ধি দেখতে পাব এবং বৈশিষ্ট্যটি আরও ব্যাপকভাবে সক্ষম করার জন্য প্যাট্রোলার ও মডারেটরদের মধ্যে পর্যাপ্ত সমর্থন আছে কিনা তা জানতে পারব।
WE1.1.5	যদি আমরা নতুনদের সাথে ডিজাইন প্রোটোটাইপের মাধ্যমে একটি প্রগতি ব্যবস্থা পরীক্ষা করি, তাহলে আমরা কোন ধরণের মাইলফলক, নির্দেশিকা এবং স্বীকৃতি সবচেয়ে অনুপ্রেরণামূলক বলে মনে করা হয় তা সনাক্ত করতে পারব এবং ভবিষ্যতের পাইলট উইকি পরীক্ষার জন্য একটি নকশা চূড়ান্ত করতে এই অন্তর্দৃষ্টিগুলি ব্যবহার করতে পারব।
WE1.1.6	যদি আমরা ব্যবহারকারী গবেষণা এবং উপাত্ত বিশ্লেষণের মাধ্যমে মোবাইল ওয়েব সম্পাদনার ক্ষেত্রে শীর্ষ প্রযুক্তিগত, সামাজিক এবং আচরণগত বাধা ও সক্ষমকারী বিষয়গুলি অনুসন্ধান করি, তাহলে আমরা কমপক্ষে ৩টি কার্যকর অন্তর্দৃষ্টি তৈরি করব যা মূল জ্ঞানের ব্যবধানগুলি পূরণ করবে এবং ২৫/২৬ অর্থবর্ষের দ্বিতীয়ার্ধে এবং তার পরেও আত্মবিশ্বাসের সাথে পণ্য বিনিয়োগকে অগ্রাধিকার দেওয়ার ক্ষেত্রে আমাদের ক্ষমতাকে শক্তিশালী করবে।
WE1.2.1	যদি আমরা উইকিগুলিতে সহযোগী অবদানের তথ্য প্রদর্শনের জন্য একটি প্রমাণের ধারণা তৈরি করি, তাহলে আমরা কমপক্ষে ৩০ জন অবদানকারীর কাছ থেকে প্রতিক্রিয়া সংগ্রহ করতে পারব, যার মধ্যে ৭০% উত্তরদাতা বলবেন যে এই বৈশিষ্ট্যটি দরকারী এবং সহযোগিতামূলক বৃদ্ধিকে ত্বরান্বিত করতে সাহায্য করতে পারে।
WE1.3.1	আমরা যদি পূর্ববর্তী গবেষণা ও ডিজাইনে চিহ্নিত প্রয়োজনগুলি কাজে লাগাই এবং সবচেয়ে প্রভাবশালী শীর্ষ X সংখ্যক মডারেটর মডিউলের প্রাথমিকভাবে তৈরী প্রতিরূপ ভাগ করে নিই, তাহলে আমরা সেগুলি ব্যবহার করে মডারেশন কার্যপ্রবাহের জন্য প্রধান পাতায় পরিবর্তন আনতে পারি।
WE1.3.2	যদি আমরা নতুন আসা প্রধান পাতাটিকে শর্তসাপেক্ষে মডারেটর মডিউল পেশ করার জন্য পরিবর্তন করি, তাহলে আমরা মডারেটরদের জন্য প্রধান পাতা ব্যবহারের সম্ভাব্যতা প্রমাণ করতে পারব।
WE1.4.1	যদি আমরা T396489-তে উল্লেখিত বেশ কিছু উন্নতিসাধন করি, তাহলে বৃহৎ উইকিগুলিতে ধীরগতির সাম্প্রতিক পরিবর্তনের প্রশ্নগুলি X শতাংশ কমিয়ে আনব। তারপর মডারেটর টুলগুলি বিশেষ ডিবি পারফরম্যান্স উদ্বেগ ছাড়াই সেই উইকিগুলিতে প্রধান পাতা মডিউল স্থাপন করতে সক্ষম হবে।	T400696
WE2.1.1	যদি আমরা ছোট উইকির স্থানীয় ভাষাভাষীদের তাদের অঞ্চলের উচ্চ-ট্র্যাফিক উইকিপিডিয়ায় সেন্ট্রালনোটিস ব্যানারের মাধ্যমে সাজেস্টেডএডিটস এবং অন্যান্য বিকাশমূলক বৈশিষ্ট্যগুলিতে অবদান রাখার জন্য আমন্ত্রণ জানাই, তাহলে আমরা মূল্যায়ন করতে পারব যে এই পদ্ধতিটি নতুন স্থানীয় ভাষাভাষীদের আকর্ষণ করবে কিনা এবং তারা গুরুত্বপূর্ণ বিষয়বস্তু উন্নত করার জন্য এই সম্পাদনা সরঞ্জামগুলি ব্যবহার করবে কিনা।
WE2.1.2	যদি আমরা নতুন সম্পাদকদের জন্য বিশেষভাবে উপযোগী অনুবাদ পরামর্শ তৈরি এবং প্রকাশ করি, তাহলে আমরা পরীক্ষা করতে সক্ষম হব যে এই পদ্ধতিটি আমাদের বর্তমান পদ্ধতির তুলনায় আরও ভালো অনুবাদ ফলাফল তৈরি করবে কিনা। নতুন সম্পাদকেরা যেসব পরিচিত চ্যালেঞ্জের মুখোমুখি হয়, বিশেষ করে যাদের নিবন্ধ মুছে ফেলার সম্ভাবনা বেশি থাকে, এটি তার সমাধান করে। তারা আরও সহজে নিয়ন্ত্রণযোগ্য বিষয়বস্তু অনুবাদের দিকে চালিত হয়, এর লক্ষ্য হল অনুবাদ প্রক্রিয়ার একটি কম দুর্বহ এবং সহজলভ্য ভূমিকা প্রদান করা। যেগুলিতে বিন্যাস ও মোট দৈর্ঘ্যের দিক থেকে জটিলতা কম থাকে সেগুলি ভাল নিবন্ধ ও নিবন্ধের অংশের উপযুক্ত উদাহরণ হতে পারে।
WE2.1.3	যদি আমরা নতুন নিবন্ধ এবং বিভাগ তৈরি করার সময় সম্পাদকের অভিজ্ঞতা সম্পর্কে জানতে পারি (যেমন অনুপ্রেরণা, সমস্যা ও কিভাবে সেগুলিকে আরও ভালভাবে সমর্থন করা যায় সে সম্পর্কে নতুন ধারণাগুলির প্রতি তাদের প্রতিক্রিয়া), তাহলে ব্যবহারকারীর চাহিদা এবং আচরণ আমাদের সামনে আসবে; যা পণ্য, নকশা এবং প্রকৌশলকে নিবন্ধ তৈরির অভিজ্ঞতা উন্নত করার জন্য কার্যকর অন্তর্দৃষ্টি এবং কৌশল প্রদান করবে।
WE2.1.4	যদি আমরা অংশগ্রহণমূলক কর্মশালা বা সাক্ষাৎকারের মাধ্যমে অনুসন্ধান করি যে, তিনটি মাঝারি আকারের উইকিপিডিয়া জ্ঞানের ব্যবধান এবং গুরুত্বকে কিভাবে দেখে, তাহলে আমরা প্রতিটি সম্প্রদায়ের জন্য প্রাসঙ্গিক "গুরুত্বপূর্ণ জ্ঞান"-এর জন্য কার্যকরী সংজ্ঞা বা ধারণা তৈরি করতে পারব।
WE2.2.1	যদি আমরা পার্সয়েডের শুরু হওয়াকে অনুসরণ করি এবং বেশিরভাগ উইকিঅভিধানে এবং কিছু কম ট্র্যাফিক উইকিপিডিয়ায় উইকিফাংশনগুলিকে একীভূত করি, আমরা বৃহত্তর উইকিগুলিতে আত্মবিশ্বাসের সাথে এটি শুরু করার জন্য প্রয়োজনীয় পরীক্ষা করতে পারব।
WE2.2.2	যদি আমরা উইকিফাংশনে এইচটিএমএল টেবিল, স্টাইলিং এবং লিঙ্ক করার সুবিধা যুক্ত করি, তাহলে একটি ক্রিয়ার রূপান্তর টেবিল প্রদর্শনের মতো একটি ফাংশনের মাধ্যমে প্রমাণ করা যাবে যে এটি শুধু সাধারণ রূপান্তর নয়, উইকিশব্দকোষে নতুন জ্ঞানও তৈরি করতে সক্ষম।
WE2.2.3	যদি আমরা নিহিত করা ফাংশন কলে উইকিউপাত্ত সত্তার জন্য সমর্থন যোগ করি, তাহলে আমরা ২০০টিরও বেশি নতুন ফাংশনকে সক্ষম করতে পারব যা উইকিউপাত্ত সত্তা ব্যবহার করে ব্যাপক সংখ্যায় বাক্য তৈরি করতে পারে, যার ফলে উইকিমিডিয়া প্রকল্পগুলিতে ফাংশনগুলি আরও সহজে ব্যবহার করা যাবে।
WE2.2.4	বিমূর্ত বিষয়বস্তু কোথায় থাকবে এবং এটি উইকিপিডিয়ার সাথে কিভাবে যোগাযোগ করবে তার জন্য যদি আমরা একটি স্থাপত্য পরিকল্পনা করি, তাহলে আমরা উচ্চমানের বিশ্বকোষীয় বিষয়বস্তুর সরবরাহ বাড়ানোর জন্য বিমূর্ত উইকিপিডিয়া প্ল্যাটফর্ম বাস্তবায়নের জন্য যথেষ্ট প্রস্তুত থাকব।
WE2.2.5	যদি আমরা পণ্য ও প্রযুক্তি দলগুলির মধ্যে বিমূর্ত বিষয়বস্তুর প্রয়োজনীয় উদ্ধৃতিগুলির জন্য পণ্যের চাহিদার সংজ্ঞা এবং সামাজিকীকরণ করি, তাহলে আমরা বিমূর্ত বিষয়বস্তুর সাথে সংযুক্ত মূল তথ্য সরবরাহের জন্য আন্তঃ-উইকিমিডিয়া কাজ চালাতে সক্ষম হব, যা উইকি জুড়ে সফলভাবে গ্রহণের জন্য অত্যন্ত গুরুত্বপূর্ণ।
WE2.2.6	যদি আমরা আমাদের ব্যাকএন্ড-অভ্যন্তরীণ অনুরোধ বিন্যাসটিকে আরও অভিব্যক্তিপূর্ণ এবং সংক্ষিপ্ত করি, তাহলে আমরা সিস্টেমের স্থায়িত্ব বাড়াতে পারব, যার ফলে একটি বৃহত্তর রোলআউট সমর্থন করা যাবে।
WE2.2.7	যদি আমরা উইকিডাটা এবং উইকিফাংশনস কল ব্যবহার করে প্রাথমিক অংশ তৈরি করি যাতে স্বাভাবিক ভাষার ছোট ছোট অংশ তৈরি করা যায়, তাহলে আমরা প্রকল্পের জন্য প্রস্তুতি ও সক্ষমতা দেখাতে পারব এবং এটি এআই প্রশিক্ষণে ব্যবহার করা যাবে, যাতে মানুষকে ফাংশন নিয়ে বেশি চিন্তা করতে না হয়।
WE2.2.8	যদি আমরা যোগ্যতা সংযোজনকারী বিষয় সহ উইকিউপাত্ত বিবৃতি আমদানি প্রদান করি, তাহলে বহুমুখী তথ্য (যেসব তথ্য প্রকাশের জন্য কেবল বিষয়/ভবিষ্যদ্বাণী/মূল্যমানের চেয়েও বেশি কিছু প্রয়োজন) তৈরি করা সম্ভব হবে, যার মধ্যে উইকিডেটার আনুমানিক ৫০% বিশ্বকোষীয় বিষয়বস্তু অন্তর্ভুক্ত থাকবে।
WE2.2.9	যদি আমরা পুনরুদ্ধারকৃত উইকিউপাত্ত সত্তার ক্যাশিং প্রদান করি, তাহলে আমরা উইকিউপাত্ত বিষয়বস্তু-ভিত্তিক ফাংশনের গড় রানটাইম কমপক্ষে ৫০% কমিয়ে দেব, টাইমআউট এবং ব্যবহারকারীর হতাশা কমাতে পারব।
WE2.2.10	যদি আমরা উইকিফাংশন ইউআই-তে একটি উইকিউপাত্ত লেক্সিম সেন্স অংশ প্রদান করি, তাহলে অবদানকারীরা প্ল্যাটফর্ম/উইকিফাংশন থেকে না বেরিয়েই প্রাসঙ্গিক লেক্সিমগুলি সনাক্ত করতে এবং নির্বাচন করতে সক্ষম হবেন - প্রসঙ্গ পরিবর্তন হ্রাস হবে এবং দ্রুত ও আরও সফলভাবে ভাষা-সম্পর্কিত ফাংশনগুলির সৃষ্টি সক্ষম করবে।
WE2.2.11	যদি আমরা উইকিপিডিয়ায় উইকিফাংশন একীকরণের ওপর দাগবানি সম্প্রদায়ের ব্যবহারযোগ্যতার ফলাফলগুলি আলোচনা করি, তাহলে আমরা দেখতে পাব যে পরীক্ষার সময় কোনও নিবন্ধে কোনও ফাংশন সন্নিবেশ করার সময় সম্পাদকরা ব্যবহারগত দিক দিয়ে কম সমস্যার সম্মুখীন হয়েছেন অথবা একেবারেই হননি।
WE3.1.1	যদি আমরা এ/বি আইওএস অ্যাপে ট্যাব যুক্ত ব্রাউজিং বৈশিষ্ট্যের একটি উন্নত সংস্করণ পরীক্ষা করি, তাহলে আমরা ট্যাব ব্যবহারকারীদের মধ্যে বহু-দিনের ব্যবহারে ৫% বৃদ্ধি দেখতে পাব।
WE3.1.3	যদি আমরা ব্যবহারকারীদের নিবন্ধের পাতার মধ্যে প্রাসঙ্গিক ছবি বা ভিডিও সামগ্রী ব্রাউজ করার জন্য একটি নতুন উপায় প্রদান করি, তাহলে যে ব্যবহারকারীদের মধ্যে এই বৈশিষ্ট্যটি উপলব্ধ হবে, আমরা তাদের মধ্যে কমপক্ষে ৩% ক্লিক-থ্রু রেট দেখতে পাব।
WE3.1.4	যদি আমরা উইকিতে জ্ঞান নেটওয়ার্কে পাঠকদের খোঁজার জন্য বেশ কয়েকটি ধারণা দেখাই, তাহলে আমরা আরও উন্নয়নের ধারণা সম্পন্ন একটি অগ্রাধিকারপ্রাপ্ত তালিকা নিয়ে আসতে পারব।
WE3.1.5	যদি আমরা উইকিপিডিয়ার ওয়েব পাঠকদের জন্য এমন একটি মেশিন অনুবাদিত সংস্করণ দেখার বিকল্প প্রদান করি যা তাদের ভাষায় অনুপলব্ধ, তাহলে আমরা জানতে পারব যে পঠন কার্যকলাপ বৃদ্ধি পেয়েছে কিনা, পৃষ্ঠার যোগাযোগে ৩% বৃদ্ধি হিসাবে পরিমাপ করা গেছে কিনা, পাঠকদের স্থানীয় ভাষার উইকিতে আকৃষ্ট করা হয়েছে কিনা এবং স্থানীয় সম্পাদনা কার্যকলাপে সম্ভাব্য বৃদ্ধি ঘটেছে কিনা। পূর্ব সম্মতি নিয়ে ১৩টি উইকিপিডিয়ায়, উইকিপিডিয়া সম্পাদকদের জন্য ইতিমধ্যে উপলব্ধ ওপেন মেশিন অনুবাদ পরিষেবা ব্যবহার করে এটি সর্বাধিক ৬ মাসের জন্য একটি নিয়ন্ত্রিত এ/বি পরীক্ষার সেটিং হিসাবে প্রদান করা হবে।
WE3.2.1	যদি আমরা ফান্ডরেইজিং দলের সঙ্গে সহযোগিতা করি, তাহলে ব্যবহারকারী পরীক্ষার মাধ্যমে মূল্যায়িত হবে এমন আরও আকর্ষণীয়, সমন্বিত এবং ব্যক্তিগতকৃত দাতা-স্লাইড আমরা আইওএস বছরের পর্যালোচনায় তৈরি করতে পারব। এর পরে দ্বিতীয় ত্রৈমাসিকে একটি অনুমান করা হবে যাতে মূল্যায়ন করা যায় যে উন্নত বছরের পর্যালোচনায় ২০২৪ সালের পর্যালোচনার তুলনায় ৫% বেশি অনুদান প্রাপ্তি দেখা গেছে কিনা।
WE3.2.2	যদি আমরা প্রচারণা-বহির্ভূত বাজারগুলিতে অ্যান্ড্রয়েড অ্যাপ পাঠকদের উইকিপিডিয়া ব্যবহারের ওপর ভিত্তি করে অনুদানের জন্য একটি ঐচ্ছিক, নিজের প্রয়োজন মতো (পরিমাণ এবং সঙ্ঘটনের সংখ্যা) অনুস্মারক স্থাপন করতে অনুরোধ করি, তাহলে আমরা সেই বাজারগুলিতে অ্যাপ মেনু অনুদান প্রদানের ক্ষেত্রে ৫% বৃদ্ধি দেখতে পাব।
WE3.2.3	যদি আমরা লগ আউট হওয়া ব্যবহারকারীদের ওপর একটি এ/বি পরীক্ষা চালাই, যাতে মোবাইল এবং ডেস্কটপ উভয়ের জন্যই অনুদান প্রবেশ বিন্দুতে সূক্ষ্ম বৈকল্পিক প্রদর্শন করি, তাহলে আমরা নিয়ন্ত্রণের তুলনায় ট্রিটমেন্ট পথের মাধ্যমে অনুদানের সংখ্যা ২% বেশি লক্ষ্য করব।
WE3.3.1	যদি আমরা ২০২৪ সালে আইওএস ব্যবহারকারীদের অনুরোধ করা স্বল্প থেকে মাঝারি প্রচেষ্টার ব্যক্তিগতকৃত উপাদানগুলিকে ২০২৫ সালের পর্যালোচনায় যোগ করি, তাহলে ব্যবহারযোগ্যতা পরীক্ষা বা বিটা পরীক্ষার মাধ্যমে পরিমাপ করা গত বছরের তুলনায় আমরা সন্তুষ্টিতে ৩% বৃদ্ধি দেখতে পাব।
WE3.3.2	যদি আমরা অ্যান্ড্রয়েডে বিদ্যমান সম্পাদনা ট্যাবটিকে একটি ব্যক্তিগতকৃত কার্যকলাপ হাবে প্রসারিত করি যেখানে পঠনের জন্য এবং সম্পাদনা-বহির্ভূত অংশগ্রহণ চলে, তাহলে আমরা মূল সংস্করণের তুলনায় ট্যাবের সাথে বহু-দিনের সম্পৃক্ততায় ৫% বৃদ্ধি দেখতে পাব।
WE3.3.3	যদি আমরা অ্যাকাউন্টধারীদের জন্য অ্যান্ড্রয়েড অ্যাপে কমপক্ষে একটি আনলকযোগ্য প্রোফাইল প্রবর্তন করি—যেটি অর্জন করা যাবে নির্দিষ্ট সংখ্যক নিবন্ধ সংরক্ষণের মতো অর্থপূর্ণ পাঠক ক্রিয়াকলাপের মাধ্যমে—তবে আমরা একাধিক দিনে লগ-ইন করা ব্যবহারকারীদের সংশ্লিষ্ট ক্রিয়াকলাপের সাথে বারবার জড়িত থাকার হার ১০% বৃদ্ধি করব।
WE3.3.4	যদি আমরা লগ-ইন করা পাঠকদের একটি ব্যক্তিগত পঠন তালিকায় নিবন্ধ সংরক্ষণ করার ক্ষমতা দিই, তাহলে আমরা আশা করি সাইটে সম্পৃক্ততা বৃদ্ধি পাবে। এই বৈশিষ্ট্য ব্যবহারকারী পাঠকদের অভ্যন্তরীণ রেফারেল ট্র্যাফিকের ৫% বৃদ্ধি এবং সমস্ত ব্যবহারকারীর জন্য পরিসংখ্যানগতভাবে উল্লেখযোগ্য বৃদ্ধি দ্বারা এটির পরিমাপ করা হবে।
WE3.3.5	যদি আমরা এমন একটি ব্যবহারকারী গবেষণা পরিচালনা করি যা ওয়েব পাঠকদের উইকিপিডিয়া থেকে বিষয়বস্তু সংগ্রহ/কিউরেট করার সুযোগ দেয়, তাহলে কমপক্ষে ১০% অংশগ্রহণকারী দুই বা ততোধিক স্বতন্ত্র ধরণের বিষয়বস্তু (যেমন নিবন্ধ, উদ্ধৃতি, মিডিয়া) একটি সংগ্রহে সংরক্ষণ করবেন।
WE3.4.1	আমরা যদি হাইব্রিড পিওপি/সিডিএন স্থাপনার দিকে কাজ করি, তাহলে এর মাধ্যমে আমরা পূর্ণ পিওপি এবং মিনি পিওপি (ফিজিক্যাল এবং ক্লাউডে) উভয়কেই আনতে পারব, যা ভবিষ্যতে একটি প্রোটোটাইপ মিনি পিওপি স্থাপনার ভিত্তি স্থাপন করবে।
WE3.6.1	যদি আমরা লগ-আউট ব্যবহারকারীদের সংখ্যা বজায় রাখার হারের জন্য একটি এ/এ পরীক্ষা চালাই, তাহলে আমরা সেই হারের জন্য একটি বেসলাইন স্থাপন করব যা আমরা ভবিষ্যতের ত্রৈমাসিকের জন্য ব্যবহার করতে পারি।
WE3.6.2	যদি আমরা লগ-ইন করা পাঠকের একটি সংজ্ঞা তৈরি এবং প্রকাশ করি, তাহলে আমরা উই ৩.৩ কেআর সম্পর্কিত সমস্ত দল এবং অনুমানের জন্য এই সংজ্ঞাটি ব্যবহার করতে সক্ষম হব।
WE3.6.3	যদি আমরা পাঠকদের পরিবর্তনশীল চাহিদা এবং ইন্টারনেটে জ্ঞানের পরিবর্তিত প্রকৃতি নিয়ে সম্প্রদায়গুলির সাথে আলোচনা চালিয়ে যাই, তাহলে আমরা পাঠকদের পরিষেবা দেওয়ার উপায় এবং আমাদের বিভিন্ন ধারণাগুলি (মাল্টিমিডিয়া, অনুসন্ধান ও আবিষ্কার, এবং মেশিন লার্নিং সংক্রান্ত) নিয়ে কিভাবে ও কখন পরীক্ষা করা যেতে পারে সে সম্পর্কে একসঙ্গে কাজ করার একটি অভিন্ন লক্ষ্য গড়ে তুলতে পারি।
WE3.6.4	পাঠকরা কখন, কেন ও কিভাবে উইকিপিডিয়া এবং অন্যান্য জ্ঞান প্ল্যাটফর্ম ব্যবহার করেন তার পেছনের স্বতন্ত্র প্রেরণা, আচরণ এবং চাহিদাগুলি নিয়ে যদি আমরা গবেষণা করি, তাহলে আমরা এমন কিছু ফলাফল পাব যা আমরা আমাদের ভোক্তা কৌশলকে অবহিত করতে এবং বিকশিত করতে ব্যবহার করতে পারি।
WE4.1.1	যদি আমরা একটি ন্যূনতমভাবে কার্যকর অ-জরুরি প্রবাহের প্রোটোটাইপ করি, এবং বর্ধিত অধিকার সহ ব্যবহারকারীদের সাথে এটি বিকাশের সময় একটি পুনরাবৃত্তিমূলক প্রতিক্রিয়া লুপ খোলা রাখি, তাহলে এই গোষ্ঠীগুলি এই প্রবাহের বর্ধিত স্থাপনাকে সমর্থন করবে।	Project page
WE4.2.1	যদি আমরা বিশ্বস্ত কর্মীদের কাছে অ্যাকাউন্ট তৈরির সাথে সম্পর্কিত hCaptcha ঝুঁকির স্তর তুলে ধরি, তাহলে ধ্বংসপ্রবণদের সনাক্ত করতে প্রয়োজনীয় সময় কমবে এবং এই প্ল্যাটফর্মে তৈরি ধ্বংসপ্রবণদের অ্যাকাউন্ট সনাক্তকরণের সংখ্যা বৃদ্ধি পাবে। অ্যাকাউন্টগুলিতে প্রয়োগ করা ব্লকের হার, hCaptcha ঝুঁকির স্তর এবং সাধারণভাবে অ্যাকাউন্ট ব্লকের সারিবদ্ধতা ও কর্মীদের কাছ থেকে গুণগত প্রতিক্রিয়া দেখে আমরা অনুমানের সাফল্য পরিমাপ করতে পারি।
WE4.2.2	যদি আমরা চেকইউজার-এর জন্য প্রস্তাবিত তদন্ত তৈরি করি, তাহলে ধ্বংসপ্রবণ অ্যাকাউন্ট সনাক্ত করতে প্রয়োজনীয় সময় কমে যাবে এবং চিহ্নিত ধ্বংসপ্রবণ অ্যাকাউন্টের সংখ্যা বৃদ্ধি পাবে। “প্রস্তাবিত তদন্ত” বৈশিষ্ট্যের নিয়মিত ব্যবহার, প্রস্তাবিত তদন্তের মাধ্যমে চিহ্নিত অ্যাকাউন্টগুলিতে প্রয়োগকৃত প্রশমন বৃদ্ধি এবং গুণগত জরিপ প্রতিক্রিয়ার মাধ্যমে আমরা বুঝতে পারব যে আমরা সফল।
WE4.2.3	যদি আমরা এইচক্যাপচা অ্যাকাউন্ট তৈরির পরীক্ষা থেকে তথ্য বিশ্লেষণ করি, তাহলে আমরা অ্যাকাউন্ট তৈরির ফানেল, এইচক্যাপচা-র ধাঁধার কার্যকারিতা এবং স্কোরগুলি বুঝতে পারব এবং অ্যাকাউন্ট তৈরিতে এইচক্যাপচা-র আরও প্রবর্তন সম্পর্কে তথ্য পেতে পারব।
WE4.2.4	যদি আমরা সমস্ত উইকিতে ইউজারইনফোকার্ড স্থাপন করি, তাহলে আমরা কর্মী এবং মডারেটরদের আরও দক্ষতার সাথে ধ্বংসপ্রবণ অ্যাকাউন্টগুলি সনাক্ত এবং প্রশমিত করার ক্ষমতা প্রদান করব।	Project page
WE4.2.5	আমরা যদি গবেষণা করি, সম্প্রদায়ের সাথে পরামর্শ করি এবং প্রযুক্তিগত সমাধানের অনুসন্ধান করি, তাহলে আমরা কাঠামোগত ব্লক কারণগুলির একটি সেট সংজ্ঞায়িত করতে সক্ষম হব যা সমস্ত ডব্লিউএমএফ উইকিতে ব্যবহার করা যেতে পারে।
WE4.2.6	যদি আমরা ডেটা প্ল্যাটফর্মে ওপেনসার্চ-ভিত্তিক গুচ্ছ স্থাপন করার সক্ষমতা তৈরি করতে পারি, তাহলে পণ্য বৈশিষ্ট্যযুক্ত প্রকৌশলী দলগুলি এই সক্ষমতাকে ব্যবহার করে এমন সিস্টেম তৈরি করতে পারবে যেগুলো অন্য অনুসন্ধান-ভিত্তিক সিস্টেম থেকে যথেষ্ট পরিমাণ স্বায়ত্তশাসন, স্থিতিস্থাপকতা এবং বিচ্ছিন্নতা বজায় রেখে একীকরণ হবে। এই ব্যবস্থার প্রথম এবং প্রধান উপকারভোগী হবে আইপয়েড পরিষেবা।
WE4.2.7	যদি আমরা পাইলট ট্রায়াল হিসেবে বেশ কয়েকটি প্রোডাকশন উইকিপিডিয়ায় এইচক্যাপচা এন্টারপ্রাইজ ইন্টিগ্রেশন ইন্টিগ্রেশন স্থাপন করি, তাহলে আমরা অপব্যবহার বিরোধী, বট সনাক্তকরণ, ব্যবহারযোগ্যতা এবং অ্যাক্সেসযোগ্যতার ক্ষেত্রে এইচ ক্যাপচা এন্টারপ্রাইজের কার্যকারিতা এবং মূল্য সম্পর্কে তথ্য সংগ্রহ করতে সক্ষম হব।
WE4.3.1	যদি আমরা নতুন এজ ইউনিকস কুকির সমর্থনকে আমাদের এসআরই সমূহের অপব্যবহারের বিরুদ্ধে লড়াই করা এজ রুলস ইঞ্জিন রিকোয়েস্টসিটিএল-এ একীভূত করি, তাহলে আমরা ডিডিওএস এবং বিষয়বস্তুর পুনঃব্যবহার থেকে আরও ভালোভাবে রক্ষা পেতে সক্ষম হব।
WE4.4.1	যদি আমরা পাইলট প্রকল্পের প্রতিক্রিয়ার ওপর ভিত্তি করে উন্নতি করতে পারি এবং সমস্ত প্রকল্পে অস্থায়ী অ্যাকাউন্ট স্থাপন করতে পারি, তাহলে আমরা আমাদের সমস্ত প্রকল্পে অনিবন্ধিত ব্যবহারকারীদের ব্যক্তিগতভাবে শনাক্তযোগ্য তথ্য (আইপি ঠিকানা) প্রকাশ থেকে রক্ষা করতে সক্ষম হব যাতে এবং সমস্ত (নিবন্ধিত) ব্যবহারকারীর ০.১% এরও কম ব্যবহারকারীর কাছে প্রকাশিত হবে।	Project page
WE4.4.2	আমরা যদি সংশ্লিষ্ট আন্দোলনের অংশীদারদের (উইকি সম্প্রদায় এবং বিশ্বব্যাপী কর্মী সহ) সাথে স্পষ্টভাবে এবং সময়মতো যোগাযোগ করি, তাহলে এটি আমরা বাকি সমস্ত উইকিতে মোতায়েন করতে সক্ষম হব, শেষ মুহূর্তে আবিষ্কৃত কাজের চাপ কমাতে পারব এবং স্থাপনাকে পিছিয়ে দেওয়া এড়াতে পারব।
WE4.4.3	যদি টহলদারদের জন্য অস্থায়ী অ্যাকাউন্টগুলির আইপি ঠিকানার ওপর ভিত্তি করে তাদের ক্রিয়াকলাপ ফিল্টার করা এবং তাদের কার্যকলাপ দেখা আমরা সহজ করে তুলি, তাহলে অস্থায়ী অ্যাকাউন্টগুলিকে সমস্ত উইকিতে সফলভাবে চালু করতে আমরা সক্ষম হব।
WE4.4.4	যদি আমরা আইপি প্রকাশ অ্যাক্সেস নীতির সাথে সামঞ্জস্য রেখে অস্থায়ী অ্যাকাউন্টগুলির আইপি প্রকাশ অ্যাক্সেস প্রত্যাহার করার অনুমতি দিই এবং আরও জায়গায় বৈশিষ্ট্যটি প্রকাশ করি, তাহলে আমরা অস্থায়ী অ্যাকাউন্টগুলি সমস্ত উইকিতে সফলভাবে চালু করতে সক্ষম হব।
WE4.5.1	যদি আমরা জেনারেটিভ এআই-এর সাহায্যে অপব্যবহারকারী ব্যক্তিদের (যেমন স্প্যাম, হয়রানি, দীর্ঘমেয়াদী অপব্যবহারকারী, অপ্রকাশিত অর্থপ্রাপ্ত সম্পাদনা, বা বিভ্রান্তিমূলক প্রচারণা) অপব্যবহারের উদাহরণ সনাক্ত করার জন্য গুণগত গবেষণা পরিচালনা করি, তাহলে আমরা আমাদের সম্প্রদায়ের মডেলগুলির ঝুঁকি মূল্যায়ন করতে এবং বিভিন্ন ধরণের জেনারেটিভ এআই-এর সাহায্যে অপব্যবহার প্রশমিত করার জন্য ধারণা তৈরি করতে সক্ষম হব।
WE4.6.1	যদি আমরা পাসওয়ার্ড রিসেট করার জন্য জেনডেস্ক-এর মধ্যে সিঙ্ক অ্যাকাউন্ট প্রক্রিয়াটি স্বয়ংক্রিয় করে দিই, তাহলে এটি টিএণ্ডএস-এর ওপর বোঝা কমাবে এবং সেগুলি আরও বেশি করে আগত ২এফএ রিসেট অনুরোধগুলি পরিচালনা করতে পারবে।
WE4.6.2	যদি আমরা ব্যবহারকারীদের একাধিক প্রমাণীকরণ ফ্যাক্টর নিবন্ধন করতে সমর্থন করি এবং উৎসাহিত করি, তাহলে ২এফএ সক্ষম ব্যবহারকারীদের তাদের অ্যাকাউন্ট স্থগিত করার সম্ভাবনা কম থাকবে।
WE4.6.3	যদি আমরা নিশ্চিত ইমেল ঠিকানা সহ সকল ব্যবহারকারীকে তাদের অ্যাকাউন্টের জন্য ২এফএ চালু করার অনুমতি দিই, কিন্তু ব্যবহারকারীদের কাছে সক্রিয়ভাবে এই পরিবর্তনের প্রচার না করি, তাহলে আমাদের পুনরুদ্ধার সহায়তা ডেস্ক লোড একটি স্থিতিশীল স্তরে থাকবে।
WE5.1.1	যদি আমরা প্রমাণীকরণকৃত এবং বেনামী সেশনের জন্য আলাদা ধরণের স্টোরেজ ব্যাকএণ্ড ব্যবহার করি, তাহলে আমরা সেশনস্টোর কে ডিডিওএস আক্রমণ এবং উচ্চ-মাত্রার স্ক্র্যাপার থেকে রক্ষা করতে সক্ষম হব, কারণ প্রমাণীকরণ পৃষ্ঠায় সিএসআরএফ প্রতিরোধের জন্য যে বেনামী সেশন তৈরি হয়, তা সেশনস্টোরকে অতিরিক্ত লোড দেবে না।	T398814
WE5.1.2	যদি আমরা মিডিয়াউইকি সেশনের কুকিগুলিকে একটি ক্রিপ্টোগ্রাফিক স্বাক্ষর সহ একটি কাঠামোগত বিন্যাসে পরিবর্তিত করি, তাহলে আমরা স্ক্র্যাপারদের বিরুদ্ধে সুরক্ষার ক্ষেত্রে সেশনের উপস্থিতিকে একটি উপাদান হিসেবে ব্যবহার করতে পারব। সেশনের শেষ মুহূর্তে বিশ্বস্ত যাচাইকরণ সক্রিয় করে তার মাধ্যমে দ্রুত এবং অত্যন্ত বৃহৎভাবে এটি সম্ভব হবে।	T398815
WE5.1.3	যদি আমরা কুবেরনেটস-এর ওপর ভিত্তি করে স্থানীয় উন্নয়ন পরিবেশ ব্যবহার করে এপিআই গেটওয়ের জন্য একটি হার সীমায়িত করার সমাধান তৈরি করি, তাহলে আমরা কমপক্ষে তিনটি ভিন্ন হার সীমায়িত করার পরিষেবার কর্মক্ষমতা এবং কার্যকারিতা তুলনা করে উৎপাদন ট্র্যাফিকের সাথে পরীক্ষার জন্য সর্বোত্তম বিকল্পটি নির্ধারণ করতে সক্ষম হব।	T398913
WE5.2.1	যদি আমরা ডেভেলপারদের তথ্যগত চাহিদা আরও ভালোভাবে পূরণের জন্য আরইএসটি এপিআই খেলাঘর ইউআই পুনরায় ডিজাইন করি, তাহলে ব্যবহারযোগ্যতা পরীক্ষার মাধ্যমে যাচাইকৃত নথির স্বচ্ছতা উন্নত করতে পারব।
WE5.2.2	যদি আমরা rest.php এর নিচে সমস্ত এপিআই কে একটি কেন্দ্রীয় গেটওয়ের মাধ্যমে নির্দিষ্ট পথে পাঠাই, তাহলে আমরা কেন্দ্রীভূত এপিআই ব্যবস্থাপনার উপায়গুলি আনলক করব, এইসঙ্গে ভবিষ্যতের সিদ্ধান্ত ও পদক্ষেপগুলিকে অবহিত করার জন্য অন্তর্দৃষ্টি অর্জনের উদ্দেশ্যে ধারাবাহিকভাবে আরইএসটি এপিআই ট্র্যাফিক এবং ব্যবহারের ধরণগুলি পরিমাপ করা শুরু করতে পারব।
WE5.2.3	যদি আমরা মিডিয়াউইকি আরইএসটি এপিআই-এর জন্য মনিটরিং ড্যাশবোর্ড এবং অ্যালার্ম বাস্তবায়িত করি, তাহলে আমরা আমাদের সিস্টেমের আচরণ এবং উদ্ভুত সমস্যাগুলির দৃশ্যমানতা, বিশেষ করে গুরুত্বপূর্ণ পরিবর্তনের সময়, দ্রুত উন্নত করার জন্য একটি স্থিতিশীল, কার্যকর ও প্রতিলিপিযোগ্য উপায় প্রদর্শন করতে পারব।
WE5.3.1	যদি আমরা বিদ্যমান নির্দেশিকা হালনাগাদ করার সময় ইউএক্স স্বীকৃতি নির্দেশিকাগুলিকে প্রসারিত এবং একপথে চালিত করি, তাহলে আমরা উন্নত নির্দেশিকাগুলির একটি মূল সেট স্থাপন করব যা অভ্যন্তরীণভাবে পরীক্ষা করার জন্য প্রস্তুত এবং বৃহত্তর জনসাধারণের ব্যবহারের জন্য প্রস্তুত করার উদ্দেশ্যে পুনরাবৃত্তিমূলকভাবে পরিমার্জিত হবে।
WE5.3.2	যদি আমরা এমন একটি পিচ তৈরি করি যা তৃতীয় পক্ষের বিষয়বস্তু পুনর্ব্যবহারকারীদের এবং তাদের শেষ ব্যবহারকারীদের জন্য উইকিপিডিয়াকে স্বীকৃতি দেওয়ার উপকারিতা তুলে ধরে, তাহলে আমরা অন্তত আরও একজন পুনর্ব্যবহারকারী অংশীদারকে প্রথম ত্রৈমাসিকের শেষ নাগাদ কোনো অ্যাট্রিবিউশন কেস স্টাডি বা ডেমোতে অংশ নিতে রাজি করিয়ে ডব্লিউএমই৪.১ এবং ডব্লিউএমই৪.২-কে সমর্থন করতে পারব।
WE5.4.1	যদি আমরা নিশ্চিত করি যে বেশিরভাগ ওয়েব অনুরোধই একটি এজ ইউনিক কুকি পায়, তাহলে বট এবং জাল অনুরোধ সনাক্ত করা সহজ হবে।
WE5.4.2	যদি আমরা পরিচিত ক্লায়েন্টদের সনাক্ত করার জন্য একটি মাপনযোগ্য উপায় তৈরি করি, তাহলে আমরা যাচাইকৃত উৎসের বটগুলির জন্য সাধারণ হার-সীমার ব্যতিক্রমগুলিকে অনুমোদন করতে পারি এবং আমাদের নিয়মগুলির পদ্ধতিগত প্রয়োগের দিকে এগিয়ে যেতে পারি।
WE5.4.3	যদি আমরা সিডিএন-এ টেক্সট রিকোয়েস্টের ফিল্টারিংকে অ্যালাউলিস্ট/ডিনাইলিস্ট পদ্ধতির ভিত্তিতে পুনর্গঠন করি, তাহলে আমরা বটগুলির জন্য কঠোর সাধারণ রেট-সীমাবদ্ধকরণ প্রয়োগ করতে এবং ট্র্যাফিক ফিল্টারিংকে সহজতর করতে পারি।
WE5.4.4	যদি আমরা একটি সমন্বিত পরিমাপ কৌশল তৈরি করি, তাহলে আমরা 'অবকাঠামোর দায়িত্বশীল ব্যবহারের' জন্য বহু-বছরব্যাপী কৌশলের মূল্যায়ন সক্ষম করব এবং মেট্রিক উন্নয়ন ও প্রতিবেদন ক্ষমতা পরিচালনার জন্য একটি কৌশলগত পরিকল্পনা সংজ্ঞায়িত করব।
WE6.1.1	যদি আমরা প্রতিদিনের তৈরি ছবিগুলিকে নিয়োজন সার্ভারে পুনরায় তৈরি করি এবং নির্বাচিত স্থাপনার ক্রিয়াকলাপ দ্বারা উদ্দীপিত হওয়া ছবির হালনাগাদ যোগ করি, তাহলে আমরা সীমাবদ্ধতাগুলি উন্মোচন করতে পারব এবং আরও ধারাবাহিক নিয়োজন সম্পাদনের উদ্দেশ্যে প্রয়োজনীয় সময়ের জন্য একটি ভিত্তিরেখা স্থাপন করতে পারব।
WE6.1.3	যদি আমরা উইকিফার্মগুলিকে প্রাক-সংযুক্ত পরীক্ষার পরিবেশে যুক্ত করি, তাহলে উৎপাদন ভিত্তিক যেসব উন্নয়ন দল কাজ করে এবং যাদের একাধিক উইকি প্রয়োজন, তারা নিজেদের প্যাচ আলাদাভাবে পরীক্ষা করতে পারবে। এর ফলে উৎপাদনে যাওয়ার আগে তাদের আত্মবিশ্বাস বাড়বে এবং উৎপাদনে কম ত্রুটি আসবে।
WE6.2.1	যদি আমরা আমাদের উৎপাদন প্রস্তুতির চেকলিস্ট পর্যালোচনা ও প্রকাশ করি, যা একইসঙ্গে একটি পরিষেবাকে উৎপাদন-প্রস্তুত হিসেবে বিবেচনা করার পূর্বশর্তগুলি এবং সেইসঙ্গে ডেভেলপমেন্ট টিমের জন্য স্ব-পরিসেবাযোগ্য কাজগুলি স্পষ্টভাবে নির্ধারণ করবে, তাহলে এসআরই সমূহ এবং উন্নয়ন দলগুলির মধ্যে প্রত্যাশার সামঞ্জস্য তৈরি হবে, যা আমাদের সামগ্রিক কর্মক্ষম দক্ষতা ও সম্প্রসারণ ক্ষমতা উন্নত করবে
WE6.2.2	আমরা যদি ডেভেলপারদের অনেক ঝামেলাপূর্ণ কাজকে সরলীকরণ করার জন্য একটি গোল্যাং এবং Node.js লাইব্রেরি তৈরির ঘোষণা করি, তাহলে তারা আগ্রহ এবং মতামত নিয়ে সাড়া দেবে
WE6.2.3	যদি আমরা একটি চেকলিস্ট/ওয়ার্কশিট তৈরি করি, তাহলে ডেভেলপাররা ডেটা পারসিস্টেন্স ডিজাইন পর্যালোচনার জন্য আগে থেকেই সম্পূর্ণ প্রস্তুতি নিতে পারবেন।
WE6.3.1	যদি আমরা ভাষা বৈকল্পিক সমর্থনকারী উইকিগুলি বাদ দিয়ে, প্রথম ত্রৈমাসিকে কমপক্ষে ৭০টি কম ট্র্যাফিক উইকিপিডিয়া চালু করি, তাহলে আমরা শীর্ষ ১০টি উইকিতেও শেষ পর্যন্ত চালু করার জন্য আমাদের আত্মবিশ্বাস বাড়িয়ে দেব যা পার্সয়েডের মাধ্যমে পরিবেশিত পাতা পরিদর্শনের ওপর আরও বড় প্রভাব ফেলবে।
WE6.4.1	যদি আমরা কমন্সের স্প্লিটিং লিঙ্ক টেবিলকে তার নিজস্ব ক্লাস্টারে স্থাপন করি, তাহলে কমন্সের ডাটাবেস বৃদ্ধি স্থিতিশীল থাকার সম্ভাবনা বৃদ্ধি পাবে।	T398709
WE6.4.2	যদি আমরা (এসআরই) ডকুমেন্টেশন তৈরি করে, প্রয়োজনীয় অবকাঠামো প্রস্তুত করে (যেমন, PHP প্যাকেজ, কন্টেইনার ছবি), এবং নির্দেশনা এবং পর্যালোচনা প্রদান করে মিডিয়াউইকি প্রকৌশলী দলগুলিকে সহায়তা প্রদান করি, তাহলে তারা আত্মবিশ্বাসের সাথে দ্বিতীয় ত্রৈমাসিকের শুরুতে পিএইচপি ৮.৩ আপগ্রেডের উৎপাদন শুরু করতে সক্ষম হবে।	T360995
WE6.4.3	উন্নত সিস্টেম সুবিধাপ্রাপ্ত ব্যবহারকারীদের এসএসএইচ লগ ইনের জন্য যদি আমাদের একটি ফিজিক্যাল দ্বিতীয় ফ্যাক্টর (হার্ডওয়্যার নিরাপত্তা চাবি) প্রয়োজন হয়, তাহলে আমরা হ্যাক হওয়া একটি ল্যাপটপের কারণে গুরুতর নিরাপত্তা লঙ্ঘনের ঝুঁকি কমাব।
WE6.4.4	যদি আমরা মিডিয়াউইকি সাইটের সমস্ত পাতা পরিদর্শন একটি প্রধান ডোমেনের মাধ্যমে পরিবেশন করে আমাদের ডোমেনগুলিকে একীভূত করি, তাহলে আমরা মোবাইল-সাবডোমেন পুনঃনির্দেশনা বাদ দিয়ে প্ল্যাটফর্ম জটিলতা এবং সার্চ ইঞ্জিন অপ্টিমাইজেশন (এসইও) ঝুঁকি হ্রাস করব। প্রধান ডোমেনগুলিতে মোবাইল ভিজিটের জন্য পুনঃনির্দেশনা ১০০% থেকে ০%-এ কমিয়ে সম্পূর্ণতা পরিমাপ করা হয়।	T214998
WE6.4.5	If the MediaWiki Engineering Team actively monitor and fix issues in MediaWiki related to the PHP 8.3 upgrade, the SRE team will be unblocked to proceed with the PHP 8.3 upgrade by the start of Q2.	T360995

সিগন্যাল এবং ডেটা সার্ভিসেস (এসডিএস) অনুমান [ এসডিএস-এর মূল ফলাফল ] আলোচনা
অনুমানের সংক্ষিপ্ত নাম	কিউ১ পাঠ্য	বিস্তারিত এবং আলোচনা
SDS1.1.1	যদি আমরা আমাদের পেজভিউ ডেটাসেটগুলিতে স্বয়ংক্রিয় ট্র্যাফিক সনাক্তকরণ হিউরিস্টিকের কার্যকারিতা বিশ্লেষণ করি, তাহলে আমরা তাদের কর্মক্ষমতা বর্ণনা করার জন্য ডেটা মানের মেট্রিক্স তৈরি করতে সক্ষম হব এবং এই হিউরিস্টিকগুলিতে আরও বিনিয়োগের প্রয়োজনীয়তা নির্ধারণ করতে পারব।
SDS1.2.2	যদি আমরা বর্তমান ‘ডাম্পস ১’ অবকাঠামো থেকে এক্সএমএল ডাম্পস প্রক্রিয়াকে মিডিয়াউইকি কন্টেন্ট সরবরাহ লাইন-ভিত্তিক একটি ডেটা সরবরাহ লাইনে স্থানান্তর করি, তাহলে আমরা এসএলও নিশ্চিত করতে পারব এবং ‘ডাম্পস ১’-ভিত্তিক এক্সএমএল রপ্তানি বন্ধ করে দিতে পারব।
SDS1.2.3	যদি আমরা মিডিয়াউইকি বিষয়বস্তুর ইতিহাস এবং ইভেন্ট প্ল্যাটফর্ম / ইভেন্ট গেটের জন্য এসএলও গুলি পর্যালোচনা করি এবং পদ্ধতিগত ব্যাখ্যা করি, তাহলে আমরা গ্রাহক, মেট্রিক্স এবং নির্ভরশীল সংশ্লিষ্টদের যাচাই করতে পারব এবং এসএলও গুলির প্রয়োজনীয় উন্নতি কি করে হবে তা সনাক্ত করতে পারব, যা আমাদের সাপ্তাহিক বিতরণ গ্যারান্টিতে কোনো ফাঁক থাকলে তার ব্যাখ্যা করতে সাহায্য করবে।
SDS2.1.1	যদি আমরা পরীক্ষা-নিরীক্ষা পরিচালনাকারী দলগুলির সাথে ঘনিষ্ঠভাবে জুটি বাঁধি, তাহলে আমরা শিখব কিভাবে ভবিষ্যতে সিস্টেমটিকে আরও স্ব-সেবামূলক করা যায় এবং তারা কি কি ধারণাগত বা প্রযুক্তিগত চ্যালেঞ্জের মুখোমুখি হতে পারে।
SDS2.1.2	যদি আমরা ইভেন্ট লগিংয়ের জন্য আরও ভালো ত্রুটি নিরসন বাস্তবায়ন করতে পারি, তাহলে পণ্য দলগুলি জানতে পারবে যে তাদের পরীক্ষাটি প্রত্যাশা অনুযায়ী ইভেন্ট তথ্য সংগ্রহ করছে, যা পরীক্ষাকারীদের আত্মবিশ্বাস বৃদ্ধি করবে।
SDS2.1.3	যদি আমরা পরীক্ষামূলক প্ল্যাটফর্মের এ/বি টেস্টিং সিস্টেম (এক্সল্যাব) উপাদান এবং এর সাথে সম্পর্কিত মিডিয়াউইকি অংশগুলির জন্য লগিং ও পর্যবেক্ষণযোগ্যতা উন্নত করি, তাহলে আমরা সিস্টেমের কর্মক্ষমতার জন্য ভিত্তিরেখা স্থাপন করতে এবং পরীক্ষা-সম্পর্কিত ব্যর্থতার প্রতিক্রিয়া জানাতে সক্ষম হব।
SDS2.1.4	যদি আমরা মাসে একবার প্রতিষ্ঠান জুড়ে পরীক্ষার গল্প এবং ফলাফল শেয়ার করি (প্রোডাক্ট অপারেশন মিটিং, ডিজাইন টিম মিটিং এবং ক্রস-টিম উপস্থাপনার মাধ্যমে), তারপর আমরা পরীক্ষামূলক প্ল্যাটফর্মটির স্বাভাবিক গ্রহণযোগ্যতা তৈরি করব।
SDS2.1.5	যদি আমরা ব্যবহারকারীদের বলি যে তাদের যন্ত্রটি, যদি এক্স-ল্যাবে তৈরি হয়ে থাকে, তাতে এমন কিছু বৈশিষ্ট্য রয়েছে যাতে ঝুঁকির শ্রেণী পরিবর্তিত হয়, তাহলে আমরা যন্ত্র ব্যবহারকারীদের অতিরিক্ত ডেটা সংগ্রহ করা থেকে বিরত রাখব এবং কোন বৈশিষ্ট্যগুলির সমন্বয়ের জন্য গোপনীয়তা পর্যালোচনা প্রয়োজন সে সম্পর্কে স্পষ্টতা বৃদ্ধি করব।

ফিউচার অডিয়েন্স (এফএ) অনুমান [ এফএ-র মূল ফলাফল ] আলোচনা
অনুমানের সংক্ষিপ্ত নাম	কিউ১ পাঠ্য	বিস্তারিত এবং আলোচনা
FA1.1.1	যদি আমরা ১) অন্যান্য প্ল্যাটফর্মের (যেমন লেটারবক্সড, গুডরিডস, এবং রেটমাইমিউজিক) মিডিয়া সংগ্রাহকদের উইকিপিডিয়া-এক্সক্লুসিভ জ্ঞানের মাধ্যমে তাদের সংগ্রহ উন্নত করার উপায় প্রদান করি, অথবা ২) এই মিডিয়া সংগ্রাহকদের আকর্ষণীয় সামাজিক মাধ্যমে শেয়ার করার মতো জিনিস প্রদান করি, তাহলে আমরা প্ল্যাটফর্মের বাইরে উইকিপিডিয়ার প্রসারণ বৃদ্ধি করতে সক্ষম হব।
FA2.1.1	যদি প্রথম ত্রৈমাসিকে আমরা ছোট ভিডিও কন্টেন্ট সৃষ্টির জন্য আমাদের অভ্যন্তরীণ ক্ষমতা তৈরি করি (আমাদের দলের আকার বৃদ্ধি করে এবং অডিট করে ও আমাদের বর্তমান উৎপাদন প্রক্রিয়ায় দক্ষতা বৃদ্ধির সুযোগগুলি চিহ্নিত করে), তাহলে আমরা ২০২৪-২৫ অর্থবছরে তৈরি কন্টেন্ট থেকে প্রাপ্ত শিক্ষার ওপর ভিত্তি করে কাজ করতে সক্ষম হব এবং ২০২৫-২৬ অর্থবছরের দ্বিতীয় ত্রৈমাসিকে উৎপাদিত কন্টেন্টের বিস্তার আরও বাড়াতে পারব।

পণ্য ও প্রকৌশল সহায়তা (পিইএস) অনুমান [ পিইএস-এর মূল ফলাফল ] আলোচনা
অনুমানের সংক্ষিপ্ত নাম	কিউ১ পাঠ্য	বিস্তারিত এবং আলোচনা
PES1.1.1	যদি আমরা প্রমিথিউসে এসএলআই-এর (পরিষেবা স্তর নির্দেশক) মেট্রিক্স নির্ধারণে এক্স-ল্যাব, চার্টস এবং টোনচেক সমর্থন করি, এবং সেই পরিষেবা স্তরের উদ্দেশ্যগুলিকে (এসএলও) পাইরাতে যুক্ত করি, আমরা বিভিন্ন জটিল পরিস্থিতিতে আমাদের টুলিং-এর সীমাবদ্ধতা এবং বিরল ও অস্বাভাবিক পরিস্থিতি সম্পর্কে জানতে পারব, এবং এসএলও টেমপ্লেটের জন্য কোন কোন পরিবর্তন দরকার তা পরিষ্কার করতে পারব, যা আমাদের কেআর-এর জন্য পরিকল্পিত ৬টি এসএলও-কে আরও ভালোভাবে সমর্থন করতে সাহায্য করবে।
PES1.1.2	যদি আমরা দুটি সেট এসএলও সতর্কতা ড্যাশবোর্ড নিয়ে পাইলট প্রকল্প করি, তাহলে আমরা বুঝতে পারব যে উপযুক্ত টুলিং বাস্তবায়ন করা কতটা কঠিন হবে যার সাহায্যে পরিষেবাকারীরা তাদের প্রতিশ্রুতিগুলি স্পষ্টভাবে বুঝতে পারে, এবং এছাড়াও আমরা বুঝবো আমাদের এমন একটি ভিন্ন টুলে স্থানান্তরিত করতে হবে কিনা যা একটি নির্দিষ্ট এসএলও-র শুধুমাত্র একটি দৃশ্য প্রদান করে। একটি ড্যাশবোর্ড ত্রৈমাসিক প্রতিবেদনের জন্য থাকবে (যেখানে ত্রুটি বাজেটের জন্য প্রকৃত পরিষেবা স্তর চুক্তি সেট করা আছে) এবং একটি ছোট গতিশীল ড্যাশবোর্ড (যাকে "রোলিং" বলা হয়) দৈনন্দিন কার্যক্রম এবং সতর্কতার জন্য থাকবে।
PES1.1.3	যদি আমরা উইকিফাংশন প্রকল্পের জন্য একটি এসএলও (পরিষেবা স্তরের উদ্দেশ্য) খসড়া তৈরিতে অ্যাবস্ট্রাক্ট উইকিপিডিয়া গ্রুপকে সহায়তা করতে থাকি, তাহলে আমরা শিখব কিভাবে একটি জটিল বৈশিষ্ট্যের জন্য এসএলও লক্ষ্যগুলির একটি তালিকা (তাদের পরিষেবা স্তর নির্দেশক মেট্রিক্স সহ) সংজ্ঞায়িত করতে হয় যা বর্তমানে একটি গুরুত্বপূর্ণ ব্যবহারকারী কর্মপ্রবাহে যুক্ত হচ্ছে: উইকি নিবন্ধগুলিকে পেশ করা। এসআরই দ্বারা সরবরাহিত ড্যাশবোর্ড এবং মনিটর ব্যবহার করে সম্পর্কিত ত্রুটি বাজেটগুলি কি করে সঠিকভাবে পরিকল্পনা করতে হয় এবং সেগুলি সম্পর্কে সতর্ক করতে হয় আমরা তাও শিখব।
PES1.1.4	যদি আমরা মিডিয়াউইকি বিষয়বস্তু ইতিহাস প্রকল্পের জন্য পরিষেবা স্তরের উদ্দেশ্য (এসএলও) পর্যালোচনা এবং পুনরাবৃত্তির মাধ্যমে ডেটা প্ল্যাটফর্ম গ্রুপকে সমর্থন করি, তাহলে আমরা শিখব যখন ব্যাচ এবং স্ট্রিম প্রসেসিং সার্ভিসগুলি একসঙ্গে সমন্বিতভাবে চালিয়ে একটি ডেটাসেট হালনাগাদ করা হয় এবং তা ধারাবাহিকভাবে সঠিক ও ডাউনস্ট্রিম ব্যবহারকারীদের জন্য সবসময় ব্যবহারযোগ্য রাখা হয় তখন কিভাবে এসএলও ব্যবহার করে পরিষেবা সহায়তা নিশ্চিত করা যায়।
PES1.2.1	যদি আমরা ইচ্ছা তালিকার ৩টি লক্ষ্যবস্তুতে উন্নতি করি, তাহলে আমরা ইচ্ছা তালিকায় ৩০% বেশি অনন্য অংশগ্রহণকারীদের উৎসাহিত করতে পারব।
PES1.2.2	যদি আমরা আগত ইচ্ছাগুলিকে অগ্রাধিকারের ভিত্তিতে বাছাই করি এবং একজন রক্ষণাবেক্ষণকারীকে (যেমন পণ্য পরিচালক) ৭২ ঘন্টার মধ্যে নিযুক্ত করি (যার মধ্যে রয়েছে পরিষেবা বাতিল করা, স্পষ্ট করা, রক্ষণাবেক্ষণ না করা পরিষেবা বাতিল করা ইত্যাদি), এটি করা হবে ডেটাবেস টেবিলের সঙ্গে নতুন ইচ্ছাগুলিকে তুলনা করে এবং সবচেয়ে প্রাসঙ্গিক পণ্য দল বা ব্যক্তিকে একটি "রক্ষণাবেক্ষণকারী বিভাগ" বরাদ্দ করে, তাহলে রক্ষণাবেক্ষণকারীরা (যেমন পণ্য পরিচালক) ১০ দিন বা তার কম সময়ের মধ্যে ইচ্ছাগুলি মূল্যায়ন করতে এবং প্রতিক্রিয়া জানাতে সক্ষম হবেন।
PES1.2.3	যদি আমরা বৃহৎ পরিসরে সম্প্রদায়ের সংকেত সনাক্তকরণের জন্য পরীক্ষামূলকভাবে কাজ করি, তাহলে আমাদের সম্প্রদায়-অবহিত অগ্রাধিকার প্রচেষ্টায় আরও বেশি করে স্বেচ্ছাসেবকদের কণ্ঠস্বর অন্তর্ভুক্ত করতে পারব।
PES1.2.4	যদি আমরা প্রথম ত্রৈমাসিকে ৩টি দলের সাথে একটি ত্রৈমাসিক ইচ্ছা এবং সম্প্রদায় সংকেত পর্যালোচনা প্রক্রিয়া পরীক্ষামূলকভাবে চালু করি, তাহলে আমরা পণ্য পরিচালকদের তাদের ত্রৈমাসিক এবং বার্ষিক পরিকল্পনা প্রক্রিয়ায় সম্প্রদায় সংকেতগুলিকে একীভূত করার জন্য নিযুক্ত করব।
PES1.3.1	যদি, প্রথম ত্রৈমাসিকের শেষের দিকে, আমরা ডব্লিউপি২৫ উদ্যোগের জন্য বার্তাপ্রেরণ, সৃজনশীল চাহিদা এবং প্রচারণার সময়সীমার সাথে সামঞ্জস্যপূর্ণ করার জন্য যোগাযোগ বিভাগ এবং পণ্য দলগুলির সাথে ৩টি কার্যকরী পরিকল্পনা অধিবেশন সমন্বয় করি, তাহলে আমরা ৩টি প্রচারণা পরীক্ষার (২৫YiR, ইস্টার এগস, উইকিরান) জন্য সৃজনশীল সংক্ষিপ্তসার চূড়ান্ত করব।
PES1.3.2	যদি আমরা ডিজাইন এবং ফিচার ইঞ্জিনিয়ারিং-এর প্রতিনিধিদের নিয়ে একটি স্টিয়ারিং কমিটি গঠন করি, তাহলে আমরা কোডেক্সে অবদান সম্পর্কে ভিত্তিরেখা মেট্রিক্স সংজ্ঞায়িত করতে সক্ষম হব: যেগুলি হলো সচেতনতা, ব্যবহার, অবদানের মান এবং পরিমাণ। এই ভিত্তিরেখা মেট্রিক্স থেকে পাওয়া মূল্যায়নের অন্তর্দৃষ্টি আমাদের কোডেক্স অবদানকারী ভিত্তির যৌথ প্রবৃদ্ধির বৃদ্ধি এবং বৈচিত্র্যকরণের জন্য একটি রূপরেখা নির্ধারণ করতে সহায়তা করবে।

কিউ২

ডব্লিউএমএফ-এর বার্ষিক পরিকল্পনার দ্বিতীয় ত্রৈমাসিক (কিউ২) অক্টোবর-ডিসেম্বর জুড়ে।

উইকি অভিজ্ঞতা (উই) অনুমান [ উই-এর মূল ফলাফল ] আলোচনা
অনুমানের সংক্ষিপ্ত নাম	কিউ২ পাঠ্য	বিস্তারিত এবং আলোচনা
WE1.1.1	যদি আমরা পেস্ট চেক এ/বি পরীক্ষা শুরু হওয়ার ≥2 সপ্তাহ পরে পূর্বনির্ধারিত নেতৃস্থানীয় সূচকগুলির সেটের বিশ্লেষণ করি, তাহলে আমরা বৈশিষ্ট্যটির প্রভাব মূল্যায়নের বিষয়ে আত্মবিশ্বাসী হওয়ার আগে সম্পূর্ণ অভিজ্ঞতার কোন দিকগুলি সমন্বয় বা তদন্ত করা প্রয়োজন তা সনাক্ত করতে সক্ষম হব, যদি তদন্তযোগ্য কিছু থাকে।
WE1.1.4	যদি আমরা একটি নিয়ন্ত্রিত পরীক্ষার মাধ্যমে en.wiki-তে রেফারেন্স চেক স্থাপন করি, তাহলে আমরা নতুন স্বেচ্ছাসেবকদের দ্বারা প্রকাশিত গঠনমূলক সম্পাদনাগুলিতে ≥৪% বৃদ্ধি দেখতে পাব এবং বৈশিষ্ট্যটি আরও ব্যাপকভাবে সক্ষম করার জন্য টহলদার এবং মডারেটরদের মধ্যে পর্যাপ্ত সমর্থন আছে কিনা তা জানতে পারব।
WE1.1.7	টোন চেক এ/বি পরীক্ষা শুরু হওয়ার ≥২ সপ্তাহ পরে যদি আমরা পূর্বনির্ধারিত নেতৃস্থানীয় সূচকগুলির সেট বিশ্লেষণ করি, তাহলে আমরা বৈশিষ্ট্যটির প্রভাবের মূল্যায়ন সম্পর্কে নিশ্চিত হওয়ার আগে সমস্ত অভিজ্ঞতার দিকগুলি সামঞ্জস্য করা বা তদন্ত করা প্রয়োজন কিনা - যদি তদন্তযোগ্য কিছু থেকে থাকে - তা সনাক্ত করতে সক্ষম হব।
WE1.1.8	যদি আমরা প্রকাশিত নিবন্ধগুলিতে টোন চেক মডেল প্রয়োগ করি, তাহলে আমরা জানতে পারব যে আমরা ≥১০,০০০ টোন সমস্যা (প্রতিটি সম্ভাব্যতা স্কোর ০.৮ বা তার বেশি) সনাক্ত করতে পারি কিনা, যেগুলিতে সম্পাদকদের নিবন্ধের সুর উন্নত করতে সাহায্য করার জন্য উচ্চ-মান সম্পন্ন (নির্ভুলতা ≥ ৭০%) একগুচ্ছ প্রস্তাবের ভাণ্ডার তৈরি করা প্রয়োজন।
WE1.1.10	যদি আমরা en.wiki এবং fr.wiki-তে প্রায় ১০ জন অভিজ্ঞ স্বেচ্ছাসেবকের সাক্ষাৎকার নিই যারা টহল/সংযম কর্মপ্রবাহ স্বয়ংক্রিয় করার জন্য AbuseFilters (এবং অন্যান্য গ্যাজেট/স্ক্রিপ্ট/টেমপ্লেট/সম্পাদনা বিজ্ঞপ্তি) লেখেন, তাহলে আমরা ≥৩টি প্যাটার্ন/প্রয়োজন সনাক্ত করতে পারব যা সম্প্রদায়-লিখিত সম্পাদনা পরীক্ষাগুলির মূল্যবান প্রস্তাব গঠনে সহায়তা করবে।
WE1.1.11	যদি আমরা ≥৫০০ জন সফল নবাগতদের [i] মধ্যে একটি জরিপ বিতরণ করি এবং বৃহত্তর সফল নবাগত জনসংখ্যার প্রতিনিধিত্বকারী উচ্চমানের তথ্য সংগ্রহ করি, তাহলে আমরা ≥৪টি কার্যকর অন্তর্দৃষ্টি সনাক্ত করতে সক্ষম হব যা আমরা অনবোর্ডিং অভিজ্ঞতার কোন দিকগুলিকে উন্নত করতে হবে তা অগ্রাধিকার দেওয়ার জন্য ব্যবহার করতে পারি।
WE1.1.12	আমরা যদি ≥৩ জন স্বেচ্ছাসেবককে ≥৩০টি নমুনা সম্পাদনার মূল্যায়ন করতে সক্ষম করি, তাহলে আমরা যে ১০টি নতুন ভাষার জন্য টোন চেক মাপক করতে চাইছি, তার প্রতিটির জন্য আমরা জানতে পারব যে স্বেচ্ছাসেবকরা কত ঘন ঘন মডেল ভবিষ্যদ্বাণীর সাথে একমত হন এবং কোন নতুন উইকিগুলিতে টোন চেক স্থাপনের বিষয়ে যোগাযোগ করতে হবে তা সিদ্ধান্ত নিতে সক্ষম হবেন।
WE1.1.13	যেহেতু আমরা ইংরেজি উইকিপিডিয়ায় নতুন স্বেচ্ছাসেবকদের ১০০% পর্যন্ত "একটি লিঙ্ক যোগ করুন" বৃদ্ধি করেছি, তাহলে নতুনদের গঠনমূলক সক্রিয়তা এবং ধারণ উন্নত হবে, যা নতুন স্বেচ্ছাসেবকদের দ্বারা করা গঠনমূলক সম্পাদনা ≥৪% বৃদ্ধি করবে।
WE1.2.3	যদি আমরা ছোট ও মাঝারি আকারের উইকিগুলিতে ইভেন্ট নিবন্ধন ব্যবহারের জন্য ইভেন্ট অর্গানাইজারের অধিকারের প্রয়োজনীয়তা বাতিল করি, তাহলে আমরা অর্থবছরের শেষ নাগাদ ছোট ও মাঝারি আকারের উইকিগুলিতে কমপক্ষে আরও X ইভেন্ট* তৈরি দেখতে পাব। মুলতুবি থাকা ভিত্তিরেখা/লক্ষ্য গণনা।
WE1.2.4	যদি আমরা কমপক্ষে ২টি উন্নতি নিয়ে সহযোগিতামূলক অবদান এমভিপি-তে পুনরাবৃত্তি করি, তাহলে ইভেন্ট নিবন্ধনের মাধ্যমে আরও সহযোগিতা তৈরি হবে।
WE1.2.5	যদি আমরা দ্বিতীয় ত্রৈমাসিকের শুরুতে উইকিমিডিয়া কমন্সে ইভেন্ট নিবন্ধনের জন্য একটি গ্রহণ কৌশল নির্ধারণ করি, তাহলে আমরা কমপক্ষে একটি বৃহৎ প্রচারণার সংগঠকদের সাথে এটি পরীক্ষা করতে সক্ষম হব এবং ৫ জন স্থানীয় সংগঠককে এই বৈশিষ্ট্যটি ব্যবহার করতে সক্ষম করব।
WE1.3.3	যদি আমরা নতুন সম্পাদকদের কাছে একটি মডারেটর ড্যাশবোর্ড উপস্থাপনের জন্য একটি পরীক্ষা শুরু করি, তাহলে যাঁরা এটি পরিদর্শন করেন তেমন অবদানকারীদের মধ্যে ১০%-কে টানা দুই সপ্তাহ ধরে এটি করেন।
WE1.4.1	যদি আমরা T396489-এ বলা সংজ্ঞার উন্নতি করি, তাহলে আমরা বৃহৎ উইকিগুলিতে ধীরগতির সাম্প্রতিক পরিবর্তনের প্রশ্নগুলি কমপক্ষে ৩০% কমিয়ে আনব, যা সম্প্রদায় টেককে সাম্প্রতিক পরিবর্তনের ডাটাবেসকে অত্যধিক বোঝাই না করে নজরে রাখুন লেবেল স্থাপন করতে সক্ষম করবে।
WE1.4.3	যদি আমরা সাম্প্রতিক পরিবর্তন এবং নজরে রাখুন ব্যবহার করি, তাহলে লোকেরা কত ঘন ঘন পাতাগুলিতে ক্লিক করেন আমরা তার একটি ভিত্তিরেখা নির্ধারণ করতে পারি।
WE1.5.1	যদি আমরা ৭টি অবদানকারী মেট্রিক্স অন্বেষণ করার জন্য একটি ড্যাশবোর্ড বাস্তবায়ন করি এবং dbt ব্যবহার করে কমপক্ষে একটি মেট্রিকের গণনাকে মানসম্মত করি, তাহলে আমরা অবদানকারী পণ্য দলগুলিকে স্ব-পরিবেশন মেট্রিক অন্তর্দৃষ্টি প্রদান করতে এবং মেট্রিক গণনার যুক্তি সংরক্ষণের জন্য একটি মান তৈরি করতে সক্ষম করতে পারি।
WE1.5.2	যদি আমরা দ্বিতীয় ত্রৈমাসিকে নির্ধারণ করি যে মডারেটরকে তার সংজ্ঞায় কোন মডারেশন ক্রিয়াগুলি অন্তর্ভুক্ত করতে হবে, তাহলে মুভমেন্ট ইনসাইটস টিম তৃতীয় ত্রৈমাসিকে/চতুর্থ ত্রৈমাসিকে মাসিক সক্রিয় মডারেটরদের মেট্রিক তৈরি করতে পারে।
WE2.1.3	যদি আমরা নতুন নিবন্ধ এবং বিভাগ তৈরি করার সময় সম্পাদকের অভিজ্ঞতা সম্পর্কে জানতে পারি (যেমন অনুপ্রেরণা, সমস্যা এবং কিভাবে সেগুলিকে আরও ভালভাবে সমর্থন করা যায় সে সম্পর্কে নতুন ধারণাগুলির প্রতি তাদের প্রতিক্রিয়া), তাহলে আমরা ব্যবহারকারীর চাহিদা এবং আচরণগুলি প্রকাশ করতে পারব যা পণ্য, নকশা এবং প্রকৌশলকে নিবন্ধ তৈরির অভিজ্ঞতা উন্নত করার জন্য কার্যকর অন্তর্দৃষ্টি এবং কৌশল প্রদান করবে।
WE2.2.12	যদি উইকিফাংশনগুলিকে আমরা এমন উইকিগুলিতে চালু করি যেখানে পার্সয়েড সক্ষম আছে, তাহলে আমরা ক্রমবর্ধমান বিস্তৃত রোলআউটগুলিতে সিস্টেমটি কার্যক্ষম এবং ব্যবহারযোগ্য কিনা তা নিয়ে পরীক্ষা চালিয়ে যেতে সক্ষম হব।
WE2.2.13	যদি আমরা উইকশনারি কমিউনিটির সাথে সংযোজন টেবিল ফাংশনের প্রাপ্যতা সামাজিকীকরণ করি, তাহলে আমরা ফাংশন ব্যবহার সম্পর্কে মূল্যবান প্রতিক্রিয়া এবং আমাদের ব্যবহারকারীর ব্যক্তিত্ব সম্পর্কে অন্তর্দৃষ্টি লাভ করব যা আমরা ভবিষ্যতের রোলআউটগুলিতে প্রয়োগ করতে পারি।
WE2.2.14	যদি আমরা তথ্যছকের জন্য উইকিউপাত্ত ব্যবহারের ওপর সম্প্রদায়ের ডেটাবক্সের কাজটি খতিয়ে দেখি এবং উইকিফাংশন দিয়ে করা যায় কিনা তা অন্বেষণ করি, তাহলে আমরা তথ্যছকে উইকিফাংশনের জন্য একটি প্রথম পরীক্ষা সনাক্ত করতে সক্ষম হব।
WE2.2.15	যদি আমরা উইকিফাংশনে ত্রুটি বার্তা তৈরি এবং অনুবাদ করার ক্ষমতা সম্পর্কে সম্প্রদায়ের সচেতনতা তৈরি করি, তাহলে আমরা সহায়ক ত্রুটি বার্তার সংখ্যায় বৃদ্ধি দেখতে পাব।
WE2.2.16	যদি আমরা সম্প্রদায়ের কাছে শব্দার্থগত ফাংশনগুলির ডেমো উপলব্ধ করি, তাহলে আমরা ব্যাকরণগত ফাংশনগুলিতে ৫০% বৃদ্ধি দেখতে পাব।
WE2.2.17	যদি আমরা উইকিফাংশনে উইকিউপাত্ত বিবৃতি দেখার জন্য একটি বিশেষ উপাদান প্রদান করি, তাহলে ব্যবহারকারীরা উইকিউপাত্ত থেকে সংগৃহীত ডেটা বুঝতে আরও বেশি সক্ষম হবেন এবং কম চাপ অনুভব করবেন।
WE2.2.18	যদি আমরা মেমরি ব্যবহারের ১০ গুণ হঠাৎ বৃদ্ধি প্রতিরোধ করতে পারি, তাহলে অর্কেস্ট্রেটর উইকিউপাত্তের উদ্দেশ্যগুলি আরও ভালোভাবে পরিচালনা করতে পারবে, যার ফলে অ্যাবস্ট্রাক্ট উইকিপিডিয়ার একটি প্ল্যাটফর্ম হিসেবে উইকিফাংশনের কার্যকারিতা আরও বৃদ্ধি পাবে।
WE2.2.19	যদি আমরা ব্যবহারকারীদের নির্দিষ্ট ফাংশন কলের সরাসরি লিঙ্ক তাদের ইনপুট সহ শেয়ার করতে সক্ষম করি, তাহলে অবদানকারীরা আরও সহজে ফাংশন আচরণ পুনরুৎপাদন, যাচাই এবং আলোচনা করতে সক্ষম হবেন, যা ত্রুটিমুক্তিকে ত্বরান্বিত করবে, পরীক্ষার কর্মপ্রবাহ উন্নত করবে এবং উইকিফাংশন সম্প্রদায় জুড়ে সহযোগিতামূলক সমস্যা সমাধানে সহায়তা করবে।
WE2.3.1	যদি আমরা একটি নতুন উইকি তৈরির সিদ্ধান্ত চূড়ান্ত করি এবং সম্প্রদায়ের সাথে মিলে একটি নাম স্থির করি, তাহলে আমরা আমাদের স্টেকহোল্ডারদের সাথে এই নতুন উইকি তৈরির বিষয়টি আরও বিস্তৃতভাবে সামাজিকীকরণ করতে সক্ষম হব এবং সম্ভাব্য পণ্যের নাম পরিবর্তনের জন্য প্রস্তুতি নিতে পারব।
WE2.3.2	যদি আমরা একটি অ্যাবস্ট্রাক্ট উইকি প্রোটোটাইপের জন্য একটি এমভিপি সংজ্ঞায়িত করি যাতে আমাদের ব্যাক-এন্ড এবং এনএলজি ক্ষমতা পরীক্ষা করার জন্য সম্ভাব্য সবচেয়ে কম অভিজ্ঞতা অন্তর্ভুক্ত থাকে এবং আমাদের পুনরাবৃত্তিমূলকভাবে ডিজাইন করার অনুমতি দেয়, তাহলে আমরা তৃতীয় ত্রৈমাসিকে একটি লাইভ প্রোটোটাইপ পরিকল্পনা এবং চালু করতে সক্ষম হব।
WE2.3.3	আমরা যদি সম্প্রদায়ের সাথে কথা বলা শুরু করি এবং একটি অ্যাবস্ট্রাক্ট উইকির ব্যবহারকারীর অভিজ্ঞতার জন্য সম্ভাব্য নকশাগুলি অন্বেষণ করি, তাহলে আমরা তৃতীয় ত্রৈমাসিকে কাজ এগিয়ে নিয়ে যেতে সক্ষম হব।
WE2.4.1	যদি আমরা ডব্লিউএমডিই এবং ডব্লিউএমএফ টিম থেকে উইকিউপাত্ত এবং ডব্লিউডিকিউএস ব্যবহারের ঘটনা সংগ্রহ করি, তাহলে আমরা অবকাঠামোগত উন্নতির জন্য পণ্যের প্রয়োজনীয়তা নির্ধারণ করতে সক্ষম হব।
WE2.4.2	যদি আমরা উইকিউপাত্ত এবং ডব্লিউডিকিউএস-এর জন্য বিদ্যমান পরিষেবা স্তরের উদ্দেশ্য (এসএলও) সহ মূল কর্মক্ষমতা সূচকের (কেপিআই) একটি সমষ্টিগত প্রতিবেদন দৃশ্য তৈরি করি, তাহলে আমরা গুরুত্বপূর্ণ উইকিউপাত্ত ব্যবহারের ক্ষেত্রে সহায়তাকারী প্রযুক্তিগত অবকাঠামোর উন্নতির জন্য সাফল্যের মানদণ্ডগুলি স্পষ্ট করতে এবং ট্র্যাক করতে সক্ষম হব।
WE2.4.3	যদি আমরা এই ত্রৈমাসিকের মধ্যে উৎপাদন-বাস্তবসম্মত মানদণ্ড ব্যবহার করে ব্লেজগ্রাফের বিকল্প স্টোরগুলি মূল্যায়ন এবং কর্মক্ষমতা পরিমাপক তৈরি করতে পারি, তাহলে আমরা একটি তথ্য-চালিত স্থানান্তর সিদ্ধান্ত নিতে এবং সময়রেখা ও সংস্থানের প্রয়োজনীয়তা সহ একটি সুনির্দিষ্ট রূপরেখা তৈরি করতে সক্ষম হব।
WE3.1.1	যদি আমরা ট্যাবড ব্রাউজিং ফিচারের একটি উন্নত সংস্করণে এ/বি টেস্ট চালাই, তাহলে ট্যাব ব্যবহারকারীদের মধ্যে একাধিক-দিনের ব্যবহারে ৫% বৃদ্ধি দেখতে পাব
WE3.1.3	যদি নিবন্ধ পাতাগুলির মধ্যে আমরা প্রাসঙ্গিক চিত্র সামগ্রী ব্রাউজ করার জন্য ব্যবহারকারীদের একটি নতুন উপায় প্রদান করি, এবং উইকিগুলি জুড়ে লগ-আউট পাঠকদের একটি উপসেটের সাথে এ/বি পরীক্ষার মাধ্যমে এটি পরীক্ষা করি, তাহলে যে ব্যবহারকারীদের মধ্যে এই বৈশিষ্ট্যটি উপস্থাপিত হয়েছে সেখানে আমরা কমপক্ষে ৩% ক্লিক-থ্রু রেট দেখতে পাব।
WE3.1.4	যদি আমরা উইকির তথ্য নেটওয়ার্ক খোঁজার উদ্দেশ্যে পাঠকদের জন্য বেশ কয়েকটি ধারণা দেখাই, তাহলে আমরা আরও উন্নয়নের ধারণার জন্য একটি অগ্রাধিকারপ্রাপ্ত তালিকা নিয়ে পাব।
WE3.1.5	যদি আমরা ওয়েব পাঠকদের উইকিপিডিয়ার এমন একটি মেশিন অনূদিত সংস্করণ দেখার বিকল্প প্রদান করি যা তাদের ভাষায় অনুপলব্ধ, তাহলে আমরা জানতে পারব যে পঠন কার্যকলাপ বৃদ্ধি পেয়েছে কিনা, পাতায় যোগাযোগের ৩% বৃদ্ধি হিসাবে এটি পরিমাপ করা যাবে। স্থানীয় ভাষার উইকিতে পাঠকদের আকৃষ্ট করবে এবং স্থানীয় সম্পাদনা কার্যকলাপে সম্ভাব্য বৃদ্ধি ঘটাবে। এটি একটি নিয়ন্ত্রিত এ/বি পরীক্ষার সেটিং হিসেবে প্রদান করা হবে এবং ৬ মাসের অধিক সময় নেওয়া হবে না। উইকিপিডিয়া সম্পাদকদের জন্য ইতিমধ্যেই উপলব্ধ ওপেন মেশিন অনুবাদ পরিষেবা ব্যবহার করে পূর্ব সম্মতি নিয়ে এটি ১৩টি উইকিপিডিয়ায় করা হবে।
WE3.1.6	যদি আমরা শব্দার্থগত অনুসন্ধান এবং নিবন্ধগত প্রশ্নোত্তরের জন্য একটি প্রোটোটাইপ তৈরি করি, যা একটি ডেমো ইন্টারফেস হিসাবে সরবরাহ করা হবে এবং যেটি বর্তমান পদ্ধতির সাথে নতুন অনুসন্ধানমূলক পদ্ধতির তুলনা করবে, তাহলে রিডার দলগুলি বিভিন্ন ব্যবহারকারীর যাত্রাপথে প্রতিটি পদ্ধতির কার্যকারিতা গুণগতভাবে মূল্যায়ন করতে পারবে এবং আরও উন্নতির জন্য ঘাটতি বা সুযোগগুলি চিহ্নিত করতে পারবে।
WE3.1.7	উইকিপিডিয়ায় পাঠকরা কিভাবে অনুসন্ধান এবং নেভিগেশন সরঞ্জামগুলির সাথে যোগাযোগ করে এবং কিভাবে তারা উইকিপিডিয়ায় জ্ঞান খুঁজে পেতে বহিরাগত অনুসন্ধান ব্যবহার করে যদি আমরা সে সম্পর্কে বিদ্যমান গবেষণা পর্যালোচনা করি, তাহলে আমরা রিডার দলগুলিকে ≥৩ টি কার্যকর সুপারিশ এবং অনুসন্ধান প্রদান করতে সক্ষম হব যা পাঠকদের প্রত্যাশা এবং চাহিদার ঘাটতি পূরণের জন্য একটি অনুসন্ধান ও আবিষ্কার এমভিপি-র সুযোগ তৈরি করতে সহায়তা করবে।
WE3.1.8	যদি আমরা বহিস্থ অংশগ্রহণকারীদের মধ্যে দুটি শব্দার্থগত অনুসন্ধান প্রোটোটাইপ (প্রাকৃতিক ভাষা অনুসন্ধান, প্রশ্নোত্তর) মূল্যায়ন করি, তাহলে আমরা জানতে পারব যে ব্যবহারকারীরা উন্নত অনুসন্ধান সরঞ্জামগুলিকে মূল্যবান মনে করেন কিনা, এবং অনুসন্ধান ও আবিষ্কারের এমভিপি কিভাবে এগিয়ে নিয়ে যেতে হয় সে সম্পর্কে আমরা রিডার দলগুলিকে একটি সুপারিশ প্রদান করতে পারি।
WE3.1.9	যদি একটি গুণগত গবেষণায় আমরা ১০-২০ জন সাধারণ উইকিপিডিয়া পাঠকের কাছে শব্দার্থগত অনুসন্ধানের মাধ্যমে কন্টেন্ট আবিষ্কারের জন্য উচ্চ-বিশ্বস্ততা নকশার ধারণাগুলি দেখাই, তাহলে আমরা বৈশিষ্ট্যটির প্রতি ইতিবাচক মনোভাব দেখতে পাব এবং অনুসন্ধান ও আবিষ্কারের এমভিপি-র সাথে এগিয়ে যাওয়ার জন্য প্রয়োজনীয় আত্মবিশ্বাস অর্জন করব যে এমভিপি অনুসন্ধান প্রশ্নের জন্য সংক্ষিপ্ত আকারের মানব-লিখিত উদ্ধৃতাংশের ওপর নির্ভর করে।
WE3.1.10	যদি আমরা ১০ জন সাধারণ পাঠককে একটি অনিয়ন্ত্রিত ব্যবহারকারী গবেষণায় নতুন চিত্র ব্রাউজিং অভিজ্ঞতার একটি লাইভ প্রোটোটাইপ দেখাই, তাহলে ভবিষ্যতে বৈশিষ্ট্যটির পুনরাবৃত্তির জন্য আমরা কমপক্ষে একটি ইউএক্স উন্নতি আবিষ্কার করব।
WE3.1.11	যদি আমরা অনুসন্ধানের ক্ষেত্রে শব্দবন্ধের মিল শিথিল করি, তাহলে আমরা প্রাকৃতিক ভাষার প্রশ্নগুলিকে আরও ভালভাবে সমর্থন করতে পারব এবং পণ্যকে এই ক্ষমতা মূল্যায়ন করতে সক্ষম করব, সেইসঙ্গে শব্দার্থগত অনুসন্ধানের ক্ষেত্রে কিভাবে তারা ডিজাইন করে, অগ্রাধিকার দেয় এবং কাজ সরবরাহ করে তাতে এটি অন্তর্ভুক্ত করতে সক্ষম করব।
WE3.1.14	If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3)	T409163
WE3.2.5	যদি আমরা অ্যান্ড্রয়েডে 'পর্যালোচনা একটি বছর' বৈশিষ্ট্য চালু করি যা ব্যবহারকারীর প্রভাব তুলে ধরে এবং সমন্বিত দাতা বার্তা অন্তর্ভুক্ত করে, তাহলে আমরা নতুন অনুদান আচরণ চালু করব—এবং আমরা ২০২৪ সালের তুলনায় অ্যাপ মেনুতে ৫% বৃদ্ধি দেখতে পাব।
WE3.2.6	আইওএস বছরের পর্যালোচনায় যদি আমরা দাতা স্লাইডগুলিকে আরও সমন্বিত এবং ব্যক্তিগতকৃত করি, তাহলে আমরা ২০২৪ সালের তুলনায় ৫% অনুদান বৃদ্ধি দেখতে পাব।
WE3.3.3	যদি আমরা অ্যাকাউন্টধারীদের জন্য অ্যান্ড্রয়েড অ্যাপে কমপক্ষে একটি আনলকযোগ্য প্রোফাইল প্রবর্তন করি—যেটি অর্জন করা যাবে নির্দিষ্ট সংখ্যক নিবন্ধ সংরক্ষণের মতো অর্থপূর্ণ পাঠক ক্রিয়াকলাপের মাধ্যমে—তবে আমরা একাধিক দিনে লগ-ইন করা ব্যবহারকারীদের সংশ্লিষ্ট ক্রিয়াকলাপের সাথে বারবার জড়িত থাকার হার ১০% বৃদ্ধি করব।
WE3.3.4	যদি আমরা লগ-ইন করা পাঠকদের একটি ব্যক্তিগত পঠন তালিকায় নিবন্ধ সংরক্ষণ করার ক্ষমতা দিই, তাহলে আমরা আশা করি সাইটে ব্যস্ততা বৃদ্ধি পাবে, যা এই বৈশিষ্ট্য ব্যবহারকারী পাঠকদের অভ্যন্তরীণ রেফারেল ট্র্যাফিকের ৫% বৃদ্ধি এবং সমস্ত ব্যবহারকারীর জন্য পরিসংখ্যানগতভাবে উল্লেখযোগ্য বৃদ্ধি দ্বারা পরিমাপ করা হবে।
WE3.3.6	যদি আমরা এমন একটি পরিষেবার মাধ্যমে নিবন্ধের বিষয়ের অনুমানের তথ্য উপলব্ধ করি যা সম্মত বৃদ্ধি এবং প্রাপ্যতার প্রয়োজনীয়তা পূরণ করে, সেইসঙ্গে প্রয়োজনীয় ডেটা ব্যাকফিলও করে, তাহলে আমরা এই তথ্যের ওপর নির্ভরশীল আসন্ন ব্যক্তিগতকৃত পাঠক অভিজ্ঞতাগুলিকে সমর্থন করার জন্য প্রয়োজনীয় প্রযুক্তিগত ভিত্তি স্থাপন করব।
WE3.3.7	যদি আমরা ডেটা প্ল্যাটফর্মের প্রক্রিয়াকরণ ক্ষমতা ব্যবহার করে উপযুক্ত সম্পাদক মেট্রিক্স ও ইমপ্যাক্ট ডেটা একত্রিত করি এবং সংজ্ঞায়িত এসএলও সহ উপযুক্ত পরিষেবার মাধ্যমে সমষ্টিগত ডেটা পরিবেশন করি, তাহলে আমরা বছরের ভবিষ্যতের পর্যালোচনায় উই৩.৩.১ এবং অ্যাক্টিভিটি ট্যাব উই৩.৩.২ এর পুনরাবৃত্তিগুলিকে উন্নত করতে পারি।
WE3.3.9	যদি আমরা অ্যান্ড্রয়েড এবং এ/বি টেস্টে পর্যালোচনার বছর প্রকাশ করি যেখানে অংশগ্রহণকারী ব্যবহারকারীদের একটি কাস্টম রিডিং লিস্ট সংরক্ষণের জন্য পুরস্কার প্রদান করা হবে, তাহলে আমরা দেখতে পাব যে যাদের পুরস্কার প্রদান করা হয়নি তাদের তুলনায় পুরস্কার প্রদান করা পাঠকদের মধ্যে অ্যাপ ধরে রাখার হার ১% বৃদ্ধি পেয়েছে।
WE3.3.10	যদি আমরা A/B পরীক্ষায় বছরের পর্যালোচনার ব্যক্তিগতকৃত পঠন অন্তর্দৃষ্টি দেখার জন্য একটি অ্যাকাউন্ট থাকার প্রয়োজনীয়তা পরীক্ষা করি, তাহলে আমরা দেখতে পাব যেসব ব্যবহারকারীর অ্যাকাউন্ট থাকা বাধ্যতামূলক ছিল না তাদের তুলনায় যাদের অ্যাকাউন্ট থাকা বাধ্যতামূলক ছিল তাদের সামগ্রিক ধরে রাখার হারে ১% বৃদ্ধি ঘটেছে।
WE3.3.11	যদি আমরা আইওএস-এ "কার্যকলাপ" ট্যাবের একটি উন্নত সংস্করণের এ/বি পরীক্ষা করি যা পঠন, সম্পাদনা এবং অন্যান্য অংশগ্রহণমূলক আচরণগুলিকে তুলে ধরে, তাহলে আমরা প্রোটোটাইপ সংস্করণের তুলনায় লগ-ইন করা পাঠকদের ট্যাবে একাধিক-দিনের পরিদর্শনে ৫% বৃদ্ধি দেখতে পাব।
WE3.4.1	যদি আমরা একটি হাইব্রিড পয়েন্ট অফ প্রেজেন্স (পিওপি/সিডিএন) স্থাপনার দিকে কাজ করি, তাহলে এর মাধ্যমে আমরা আমাদের প্রয়োজন অনুসারে পূর্ণ পিওপি এবং মিনি পিওপি (ভৌত এবং ক্লাউড) উভয়ই আনতে পারব, যা ভবিষ্যতে একটি প্রোটোটাইপ মিনি পিওপি স্থাপনের ভিত্তি স্থাপন করবে।
WE3.5.1	যদি পণ্য ও প্রযুক্তি এবং তহবিল সংগ্রহ দল আমাদের প্ল্যাটফর্মের মধ্যে দাতাদের সনাক্তকরণের জন্য প্রযুক্তিগত পদ্ধতিগুলি যৌথভাবে মূল্যায়ন এবং নথিভুক্ত করে, তাহলে আমরা গোপনীয়তা, সম্ভাব্যতা এবং প্রভাবের ভারসাম্য বজায় রেখে একটি স্বল্প ও দীর্ঘমেয়াদী সমাধানের সুপারিশ করতে সক্ষম হব। এই ভাগ করা বোঝাপড়া সহায়তা করবে সিদ্ধান্ত গ্রহণকে সামঞ্জস্যপূর্ণ করতে, প্ল্যাটফর্মগুলিতে স্থায়ী দাতা স্বীকৃতি সক্ষম করতে, পাশাপাশি ভবিষ্যতে তহবিল সংগ্রহ সম্পর্কিত বৈশিষ্ট্যগুলিতে আরও লক্ষ্যযুক্ত পরীক্ষা করতে।
WE3.6.3	যদি আমরা পাঠকদের ক্রমবর্ধমান চাহিদা এবং ইন্টারনেটে জ্ঞানের পরিবর্তনশীল প্রকৃতি সম্পর্কে কথোপকথনে সম্প্রদায়গুলিকে সম্পৃক্ত করি, তাহলে পাঠকদের কিভাবে পরিষেবা প্রদান করা যায় এবং আমাদের বিভিন্ন ধারণা (মাল্টিমিডিয়া, অনুসন্ধান এবং আবিষ্কার এবং মেশিন লার্নিং সহ) পরীক্ষা করা যায় কিনা এবং কিভাবে তা নিয়ে একসাথে কাজ করা যায় তা নিয়ে আমরা সকলে একদিকে মনোনিবেশ করতে পারি।
WE3.6.4	পাঠকরা কখন, কেন এবং কিভাবে উইকিপিডিয়া ও অন্যান্য জ্ঞান প্ল্যাটফর্ম ব্যবহার করেন তার পেছনের স্বতন্ত্র প্রেরণা, আচরণ এবং চাহিদাগুলি নিয়ে যদি আমরা গবেষণা করি, তাহলে আমরা ভোক্তা কৌশলের জন্য অগ্রাধিকার ক্ষেত্র এবং নির্দিষ্ট উদ্যোগগুলি প্রস্তাব করতে সক্ষম হব।
WE3.6.5	যদি পণ্য ও প্রযুক্তি এবং তহবিল সংগ্রহ প্ল্যাটফর্মে অনুদানের সুযোগগুলিকে বৈচিত্র্যময় করার জন্য সহযোগিতার মাধ্যমে কৌশল ভাগ করে নেয় এবং অনুদানপ্রদানকারী পাঠকদের যত্ন নেয় ও স্বীকৃতি দেয়, তাহলে আমরা আমাদের ভোক্তা এবং তহবিল সংগ্রহের কৌশলগুলির সাথে সম্পর্কিত স্পষ্ট, সামঞ্জস্যপূর্ণ লক্ষ্য এবং মেট্রিক্স নির্ধারণ করব।
WE3.6.6	যদি আমরা একটি সমন্বিত পরিমাপ কৌশল তৈরি করি, তাহলে আমরা ভোক্তাদের বহু-বছরের কৌশল মূল্যায়ন সক্ষম করব এবং মেট্রিক উন্নয়ন ও প্রতিবেদন ক্ষমতা পরিচালনার জন্য একটি রূপরেখা সংজ্ঞায়িত করব।
WE4.1.1	যদি আমরা একটি ন্যূনতমভাবে কার্যকর অ-জরুরি প্রবাহের প্রোটোটাইপ করি, এবং বর্ধিত অধিকার সহ ব্যবহারকারীদের সাথে এটি বিকাশের সময় একটি পুনরাবৃত্তিমূলক প্রতিক্রিয়া লুপ খোলা রাখি, তাহলে এই গোষ্ঠীগুলি এই প্রবাহের বর্ধিত স্থাপনাকে সমর্থন করবে।
WE4.1.3	যদি আমরা অক্টোবরের শেষের মধ্যে ৭টি উইকিপিডিয়া (ফরাসি, জার্মান, স্প্যানিশ, হাঙ্গেরিয়ান, ইতালিয়ান, পোলিশ, পর্তুগিজ) হালনাগাদ করি, তাহলে ডিএসএ-এর প্রয়োজনীয়তা অনুসারে আমরা নতুন লিগ্যাল ফুটার চালু করার প্রথম ধাপ সম্পন্ন করব।
WE4.1.4	যদি আমরা বৃহত্তর জটিল সম্প্রদায়ের উপর দৃষ্টি নিবদ্ধ করে কমপক্ষে ১৫টি উইকিতে ঘটনা প্রতিবেদন ব্যবস্থা এমভিপি স্থাপন করি, আমরা পর্যবেক্ষণ করব যে এটি সম্প্রদায়ের উদ্দেশ্য হিসাবে ব্যবহৃত হবে এবং অ-জরুরি ঘটনার প্রতিবেদনের জন্য একটি কার্যকরী মডেল প্রদর্শন করবে।
WE4.1.5	যদি আমরা প্রতিষ্ঠিত অপব্যবহার-পরিচালনা প্রক্রিয়া ছাড়াই উইকিগুলিতে অপব্যবহারের ঘটনা রিপোর্ট করার জন্য একটি প্রবাহ চিত্র তৈরি করি, তাহলে এটি এই ধরনের উইকিগুলিতে ঘটনা প্রতিবেদন ব্যবস্থা গ্রহণকে উৎসাহিত করবে এবং সেই উইকিগুলির ব্যবহারকারীদের একটি স্পষ্ট এবং কার্যকর সহায়তা পথ পেতে সক্ষম করবে।
WE4.2.3	যদি আমরা এইচক্যাপচা অ্যাকাউন্ট তৈরির পরীক্ষা থেকে তথ্য বিশ্লেষণ করি, তাহলে আমরা অ্যাকাউন্ট তৈরির ফানেল, এইচক্যাপচা-র ধাঁধার কার্যকারিতা এবং স্কোরগুলি বুঝতে পারব এবং অ্যাকাউন্ট তৈরিতে এইচক্যাপচা-র আরও প্রবর্তন সম্পর্কে তথ্য পেতে পারব।
WE4.2.5	আমরা যদি গবেষণা করি, সম্প্রদায়ের সাথে পরামর্শ করি এবং প্রযুক্তিগত সমাধানগুলি অনুসন্ধান করি, তাহলে আমরা কাঠামোগত ব্লকের কারণগুলির একটি সেট সংজ্ঞায়িত করতে সক্ষম হব যা সমস্ত ডব্লিউএমএফ উইকিতে ব্যবহার করা যেতে পারে।
WE4.2.6	যদি আমরা ডেটা প্ল্যাটফর্মে ওপেনসার্চ-ভিত্তিক গুচ্ছ স্থাপন করার সক্ষমতা তৈরি করতে পারি, তাহলে পণ্য বৈশিষ্ট্যযুক্ত প্রকৌশলী দলগুলি এই সক্ষমতাকে সংহত করে এমন সিস্টেম তৈরি করতে পারবে যেগুলি অন্য অনুসন্ধান-ভিত্তিক সিস্টেম থেকে যথেষ্ট পরিমাণ স্বায়ত্তশাসন, স্থিতিস্থাপকতা এবং বিচ্ছিন্নতা বজায় রেখে একীকরণ হবে। এই ব্যবস্থার প্রথম এবং প্রধান উপকারভোগী হবে আইপয়েড পরিষেবা।
WE4.2.7	যদি আমরা পাইলট ট্রায়াল হিসেবে বেশ কয়েকটি প্রোডাকশন উইকিপিডিয়ায় এইচক্যাপচা এন্টারপ্রাইজ ইন্টিগ্রেশন স্থাপন করি, তাহলে আমরা অপব্যবহার বিরোধী, বট সনাক্তকরণ, ব্যবহারযোগ্যতা এবং অ্যাক্সেসযোগ্যতার ক্ষেত্রে এইচ ক্যাপচা এন্টারপ্রাইজের কার্যকারিতা এবং মূল্য সম্পর্কে তথ্য সংগ্রহ করতে সক্ষম হব।
WE4.2.8	যদি আমরা এইচক্যাপচা প্রক্সির প্রাপ্যতা এবং পর্যবেক্ষণযোগ্যতা উন্নত করে উৎপাদন-প্রস্তুত করি, তাহলে আমরা প্রথম ত্রৈমাসিকে উৎপাদন উইকিপিডিয়াগুলিতে আরও স্থিতিশীল এবং নির্ভরযোগ্য পরিষেবা প্রদান করতে পারব।
WE4.2.9	যদি আমরা স্থানীয় মোবাইল অ্যাপ্লিকেশনগুলিতে এইচ ক্যাপচা এসডিকে সংহত করি, স্থানীয় অ্যাপ ব্যবহারকারীর অভিজ্ঞতা মূল্যায়ন করি এবং অ্যাকাউন্ট তৈরির এপিআইয়ের অংশ হিসাবে এইচ ক্যাপচা চ্যালেঞ্জগুলি সক্ষম করার মূল্যায়ন করি, তবে অ্যাকাউন্ট তৈরির এপিআইয়ের জন্য এইচ ক্যাপচার আরও চালু করা সম্পর্কে জানাতে আমাদের যথেষ্ট ধারণা থাকবে।
WE4.2.11	আমরা যদি উচ্চ ঝুঁকিপূর্ণ সম্পাদনা পরিস্থিতিতে বটগুলি সনাক্ত করার জন্য এইচ ক্যাপচা সক্ষম করি, তাহলে আমরা দেখতে পাব যে এইচক্যাপচা স্বয়ংক্রিয় অপব্যবহার কমাতে পারে।
WE4.2.16	যদি আমরা সংশ্লিষ্ট ডব্লিউএমএফ দলের সঙ্গে পরামর্শ করি, তাহলে আমরা একটি সমঝোতাভিত্তিক পরিকল্পনা তৈরি করতে পারব যা অ-সর্বজনীন ডেটার আরও সূক্ষ্ম ব্যবহারকারী-অ্যাক্সেস ব্যবস্থাপনা করতে সাহায্য করবে এবং অ-সর্বজনীন প্রতিরক্ষামূলক সফটওয়্যার নিয়মগুলির বাস্তবায়নকে সহায়তা করবে।
WE4.2.17	যদি আমরা বাস্তব বিশ্বের উদাহরণ বিশ্লেষণ করি এবং সম্পাদক ইতিহাস প্রোটোটাইপ থেকে সম্ভাব্য আপত্তিজনক আচরণের কমপক্ষে ২টি সংকেত সনাক্ত করতে চেকইউজার-এর সাক্ষাৎকার নিই, তাহলে পণ্য সুরক্ষা এবং ইন্টিগ্রিটি দল পরবর্তীতে এই সংকেতগুলিকে প্রস্তাবিত তদন্ত বৈশিষ্ট্যে অন্তর্ভুক্ত করতে সক্ষম হবে এবং তাদের মধ্যে উচ্চ স্তরের এই আত্মবিশ্বাস থাকবে যে সংকেতগুলি মূল্যবান তথ্য দেবে।
WE4.3.2	যদি আমরা জেএ৪এইচ ফিঙ্গারপ্রিন্ট স্থাপন করি, যা এইচটিটিপি ক্লায়েন্ট আচরণের সারসংক্ষেপ করে, তাহলে আমরা বট ট্র্যাফিক সনাক্ত করতে এবং শ্রেণীবদ্ধ করতে আরও ভালভাবে সক্ষম হব।
WE4.4.1	যদি আমরা পাইলট প্রকল্পের প্রতিক্রিয়ার ওপর ভিত্তি করে উন্নতি করতে পারি এবং সমস্ত প্রকল্পে অস্থায়ী অ্যাকাউন্ট স্থাপন করতে পারি, তাহলে আমরা অনিবন্ধিত ব্যবহারকারীদের ব্যক্তিগতভাবে শনাক্তযোগ্য তথ্য (আইপি ঠিকানা) প্রকাশ থেকে রক্ষা করতে সক্ষম হব যাতে এবং সমস্ত (নিবন্ধিত) ব্যবহারকারীর ০.১% এরও কম ব্যবহারকারীর কাছে প্রকাশিত হবে।
WE4.4.2	যদি আমরা সংশ্লিষ্ট আন্দোলনের অংশীদারদের (উইকি সম্প্রদায় এবং বিশ্বব্যাপী কর্মীদের সহ) সাথে স্পষ্টভাবে এবং সময়মতো যোগাযোগ করি, তাহলে আমরা বাকি সমস্ত উইকিতে মোতায়েন করতে সক্ষম হব, শেষ মুহূর্তে আবিষ্কৃত কাজের চাপ কমাতে পারব এবং মোতায়েনকে পিছিয়ে দেওয়া এড়াতে পারব।
WE4.4.5	যদি আমরা অস্থায়ী অ্যাকাউন্ট ব্যবহারকারী ধ্বংসপ্রবণ ব্যক্তিদের চিহ্নিত করার জন্য টহলদারদের সমস্যা কমিয়ে আনি, তাহলে অস্থায়ী অ্যাকাউন্ট সহ সমস্ত উইকিতে রিভার্ট রেট বৃদ্ধি না করে আমরা ধ্বংসপ্রবণতার বৃদ্ধি রোধ করতে সক্ষম হব।
WE4.4.6	যদি আমরা লিকুইডথ্রেডস এক্সটেনশনটি বন্ধ করে দিই, তাহলে বর্তমানে এই এক্সটেনশনটি ব্যবহার করা সমস্ত প্রকল্পে স্থাপন করা অস্থায়ী অ্যাকাউন্টগুলি আমরা আনব্লক করব।
WE4.6.1	যদি আমরা পাসওয়ার্ড রিসেট করার জন্য জেনডেস্ক-এর মধ্যে সিঙ্ক অ্যাকাউন্ট প্রক্রিয়াটি স্বয়ংক্রিয় করে দিই, তাহলে এটি টিএণ্ডএস-এর ওপর বোঝা কমাবে এবং সেগুলি আরও বেশি করে আগত ২এফএ রিসেট অনুরোধগুলি পরিচালনা করতে পারবে।
WE4.6.3	যদি আমরা নিশ্চিত ইমেল ঠিকানা সহ সকল ব্যবহারকারীকে তাদের অ্যাকাউন্টের জন্য ২এফএ চালু করার অনুমতি দিই, কিন্তু ব্যবহারকারীদের কাছে সক্রিয়ভাবে এই পরিবর্তনের প্রচার না করি, তাহলে আমাদের পুনরুদ্ধার সহায়তা ডেস্ক লোড একটি স্থিতিশীল স্তরে থাকবে।
WE4.6.4	যদি আমরা আমাদের ২এফএ সিস্টেমের ব্যবহারকারীর অভিজ্ঞতার পুনর্গঠন অব্যাহত রাখি এবং পাসকির জন্য সমর্থন যোগ করি, তাহলে আরও বেশি ব্যবহারকারী একাধিক প্রমাণীকরণ ফ্যাক্টর নিবন্ধন করতে পারবেন এবং আরও সুরক্ষিতভাবে অ্যাকাউন্ট অ্যাক্সেস করেতে পারবেন।
WE4.6.5	স্থানীয় বা বিশ্বব্যাপী গোষ্ঠীর সদস্যদের যে প্রয়োজনীয়তাগুলি পূরণ করতে হবে সেগুলি নির্দিষ্ট করার জন্য যদি আমরা একটি সাধারণ কাঠামো ডিজাইন এবং তৈরি করি, তাহলে আমরা এই কাঠামোটি ব্যবহার করে অস্থায়ী-অ্যাকাউন্ট-আইপি-ভিউয়ার গোষ্ঠীর সদস্যদের বিদ্যমান নীতিগত প্রয়োজনীয়তাগুলি পূরণ করতে বাধ্য করব।
WE4.6.6	যদি আমরা গবেষণা করি যে বর্ধিত অধিকারযুক্ত (ইউডব্লিউইআর) ব্যবহারকারীরা কিভাবে ইউজার স্ক্রিপ্টের ওপর নির্ভর করে, তাহলে আমরা এমন একটি পরিকল্পনা প্রস্তাব করতে সক্ষম হব, যাকে ইউডব্লিউইআর সম্প্রদায় সমর্থন করতে পারে, যাতে এক বা একাধিক গুরুত্বপূর্ণ প্রযুক্তিগত হস্তক্ষেপ করা যায় যার মাধ্যমে ইউজার স্ক্রিপ্ট সিস্টেম অর্থপূর্ণভাবে সুরক্ষিত থাকবে।
WE4.6.7	যদি আমরা ওয়েব প্ল্যাটফর্মের সাথে মোবাইল সাইন-ইন অভিজ্ঞতাকে সামঞ্জস্য করার জন্য নেটিভ মোবাইল অ্যাপগুলিতে ব্যবহারকারীর অভিজ্ঞতা এবং প্রয়োজনীয় প্রযুক্তিগত পরিবর্তনগুলি মূল্যায়ন করি, এবং ওআউথ-এর মতো বিকল্প পদ্ধতিগুলি অন্বেষণ করি, তবে আমরা একীভূতকরণের সম্ভাব্যতা নির্ধারণ করতে পারি — যা ব্যবহারকারীদের জন্য আরও সুরক্ষিত এবং সঙ্গতিপূর্ণ অভিজ্ঞতা প্রদান করার উদ্দেশ্যে করা হবে।
WE4.6.8	যদি আমরা প্রথম ত্রৈমাসিকে তৈরি জেনডেস্ক এবং মিডিয়াউইকি ফর্মগুলির প্রভাব পর্যবেক্ষণ করি, তাহলে আমরা ভবিষ্যতের ত্রৈমাসিকের জন্য এমন প্রযুক্তিগত হস্তক্ষেপের প্রস্তাব করতে পারি যা অ্যাকাউন্ট পুনরুদ্ধারের বাকি প্রক্রিয়াটিকে আরও ভালভাবে স্বয়ংক্রিয় করবে।
WE5.1.2b	যদি আমরা এপিআই গেটওয়েতে ডেভেলপার শনাক্তকরণ এবং প্রমাণীকরণের জন্য একাধিক পদ্ধতি একীভূত করি, তাহলে আমরা বিভিন্ন ব্যবহারকারীর দল থেকে আসা অনুরোধগুলি সঠিকভাবে সনাক্ত করে প্রতিটি অনুরোধের জন্য একটি উপযুক্ত হার সীমা নির্ধারণ করতে সক্ষম হব।
WE5.1.3b	যদি আমরা আরইএসটি গেটওয়ের কমপক্ষে ৩টি রুটে পথ জুড়ে সীমাবদ্ধতার জন্য একটি ড্রাই রান করি, তাহলে এটি আমাদের সম্পদ ব্যবহারের ক্ষেত্রে রেট সীমাবদ্ধতার সম্ভাব্যতা যাচাই করতে এবং এমন একটি প্রাথমিক সীমা নির্ধারণ করতে সাহায্য করবে যেটি ব্যবহারকারীর ন্যূনতম প্রভাবের সাথে প্রয়োগ করা যেতে পারে।
WE5.1.4b	যদি আমরা প্রস্তাবিত এপিআই ব্যবহারকারী বিভাজন প্রক্রিয়াগুলিকে বিস্তৃত ডেটা সেট এবং চিহ্নিত গোষ্ঠীগুলির ম্যানুয়াল পর্যালোচনার মাধ্যমে যাচাই করি, তাহলে আমরা ব্যবহারকারী দলগুলিকে চূড়ান্ত করতে, গণনার জন্য ব্যবহৃত পদ্ধতিগুলিকে পরিমার্জন করতে এবং তাদের কার্যকারিতা আরও ভালভাবে বুঝতে সক্ষম হব।
WE5.1.5	যদি আমরা ট্র্যাফিক শনাক্তকরণ এবং হার সীমাবদ্ধকরণের বিষয়ে মিডিয়াউইকি প্ল্যাটফর্ম টিমের সাথে সহযোগিতা করি, তাহলে আমরা প্ল্যাটফর্ম টিমকে এই ক্ষমতা তৈরি এবং বাস্তবায়নে সহায়তা করে উৎপাদনে ড্রাই রান পরীক্ষার জন্য হার সীমাবদ্ধকরণ স্থাপন করতে সক্ষম হব।
WE5.2.1b	যদি আমরা নতুন আরইএসটি এপিআই এক্সপ্লোরারের সম্ভাব্য ব্যবহারকারীদের সাথে যোগাযোগ করি, তাহলে এটি আমাদের মূল ব্যবহারযোগ্যতার অন্তর্দৃষ্টি সনাক্ত করতে সাহায্য করবে যা নির্দেশ করে যে নতুন ডিজাইনটি ব্যবহার করা সহজ কিনা এবং ডেভেলপারদের মানসিক মডেলের সাথে সামঞ্জস্যপূর্ণ কিনা।
WE5.2.2b	যদি আমরা অ্যাকশন এপিআইকে কেন্দ্রীয় এপিআই গেটওয়ের মধ্য দিয়ে চালাই, তাহলে আমরা ধারাবাহিকভাবে ট্র্যাফিক এবং ব্যবহারের ধরণ পরিমাপ শুরু করতে পারব যাতে ভবিষ্যতের সিদ্ধান্ত এবং পদক্ষেপ সম্পর্কে অন্তর্দৃষ্টি পাওয়া যাবে।
WE5.2.4	যদি আমরা দুটি এপিআই-এর জন্য স্ট্যান্ডার্ড ডকুমেন্টেশন প্যাটার্ন বাস্তবায়ন করি, তাহলে আমরা বিষয়বস্তু নির্দেশিকাগুলিকে পরিমার্জন করতে, নির্দেশিকাগুলি গ্রহণ করার জন্য এপিআই মালিকদের কি প্রয়োজন তা বুঝতে এবং বাকি উইকিমিডিয়া এপিআই ডক্স জুড়ে নির্দেশিকাগুলি বাস্তবায়নের জন্য প্রয়োজনীয় প্রচেষ্টা পরিমাপ করতে সক্ষম হব।
WE5.2.5	যদি আমরা মিডিয়াউইকি আরইএসটি এপিআই গুলিতে ওপেনএপিআই স্পেক লিন্টিং নিয়ম সংজ্ঞায়িত এবং প্রয়োগ করার জন্য পরীক্ষা করি, তাহলে আমরা উইকিমিডিয়া এবং আমাদের সম্প্রদায়গুলিতে প্রকাশিত এপিআই গুলির গুণমান এবং ধারাবাহিকতা উন্নত করার জন্য প্রোগ্রামগতভাবে এপিআই স্টাইল নির্দেশিকাগুলিকে প্রয়োগ করার একটি উপায় প্রদর্শন করব।
WE5.2.6	If we introduce access controls to the sitemap API to only allow trusted bots, we can improve strategic alignment and reduce the risk of abusive scraping.	phab:T406921
WE5.3.1	যদি আমরা বিদ্যমান নির্দেশিকা হালনাগাদ করার সময় ইউএক্স অ্যাট্রিবিউশন নির্দেশিকাগুলিকে প্রসারিত করে এক প্রবাহে নিয়ে আসি, তাহলে আমরা উন্নত নির্দেশিকাগুলির একটি মূল সেট স্থাপন করব যা অভ্যন্তরীণভাবে পরীক্ষা করার জন্য প্রস্তুত এবং বৃহত্তর জনসাধারণের ব্যবহারের উদ্দেশ্যে প্রস্তুত করার জন্য পুনরাবৃত্তিমূলকভাবে পরিমার্জিত হবে।
WE5.3.1b	যদি আমরা খসড়া ইউএক্স নির্দেশিকা এবং ডেমো প্রকাশ ও তার পুনরাবৃত্তি করি, তাহলে আমরা একটি মূল কাঠামো প্রতিষ্ঠা করব যা অভ্যন্তরীণভাবে পরীক্ষা করার জন্য প্রস্তুত থাকবে এবং বৃহত্তর জনসাধারণের ব্যবহারের জন্য প্রস্তুত করার উদ্দেশ্যে পুনরাবৃত্তিমূলকভাবে পরিমার্জিত হবে।
WE5.3.2	যদি আমরা এমন একটি পিচ তৈরি করি যা তৃতীয় পক্ষের বিষয়বস্তু পুনর্ব্যবহারকারীদের এবং তাদের শেষ ব্যবহারকারীদের জন্য উইকিপিডিয়াকে স্বীকৃতি দেওয়ার উপকারিতা তুলে ধরে, তাহলে আমরা অন্তত আরও একজন পুনর্ব্যবহারকারী অংশীদারকে প্রথম ত্রৈমাসিকের শেষ নাগাদ কোনো অ্যাট্রিবিউশন কেস স্টাডি বা ডেমোতে অংশ নিতে রাজি করিয়ে ডব্লিউএমই৪.১ এবং ডব্লিউএমই৪.২-কে সমর্থন করতে পারব।
WE5.4.2b	যদি আমরা পরিচিত ক্লায়েন্টদের সনাক্ত করার জন্য একটি মাপনযোগ্য উপায় তৈরি করি, তাহলে আমরা যাচাইকৃত উৎসের বটগুলির জন্য সাধারণ হার-সীমার ব্যতিক্রমগুলিকে অনুমোদন করতে পারি এবং আমাদের নিয়মগুলির পদ্ধতিগত প্রয়োগের দিকে এগিয়ে যেতে পারি।
WE5.4.5	আমরা যদি বিভিন্ন শ্রেণীর ক্লায়েন্টদের জন্য তৈরি করা নিয়ন্ত্রিত সীমা কার্যকর করা শুরু করি, তাহলে আমাদের অবকাঠামোর ওপর চাপ কমবে।
WE5.4.6	যদি দ্বিতীয় ত্রৈমাসিকের শেষের দিকে আমরা শীর্ষ এন স্পাইডারগুলিকে পরিচিত বট হিসাবে শ্রেণীবদ্ধ করি, তাহলে আমরা তাদের ব্যবহৃত সম্পদের পরিমাণ সীমিত করতে পারব।
WE5.4.7	যদি আমরা আমাদের মিডিয়া অবকাঠামোতে অনুমোদিত থাম্বনেল সাইজগুলির একটি মানক সেট নির্ধারণ করি, এবং সবচেয়ে ব্যয়বহুল সাইজগুলি আগেই তৈরি করে রাখি, পাশাপাশি বিভিন্ন ইমেজ সাইজ তৈরির প্রক্রিয়ায় নিয়ন্ত্রিত সীমা প্রয়োগ করি, তাহলে এটি মিডিয়া সার্ভিং অবকাঠামোর ওপর চাপ কমাবে।
WE6.1.2	যদি আমরা উইকিফার্মগুলিকে প্রাক-সংযুক্ত পরীক্ষার পরিবেশে যুক্ত করি, তাহলে উৎপাদন ভিত্তিক যেসব উন্নয়ন দল কাজ করে এবং যাদের একাধিক উইকি প্রয়োজন, তারা নিজেদের প্যাচ আলাদাভাবে পরীক্ষা করতে পারবে। এর ফলে উৎপাদনে যাওয়ার আগে তাদের আত্মবিশ্বাস বাড়বে এবং উৎপাদনে কম ত্রুটি আসবে।
WE6.2.1	যদি আমরা আমাদের উৎপাদন প্রস্তুতির চেকলিস্ট পর্যালোচনা এবং প্রকাশ করি যা একটি পরিষেবাকে স্ব-পরিষেবাযোগ্য কাজের সাথে, উৎপাদন-প্রস্তুত হিসেবে বিবেচনা করার পূর্বশর্তগুলি স্পষ্টভাবে সংজ্ঞায়িত করে, তাহলে আমরা এসআরই এবং উন্নয়ন দলগুলির মধ্যে প্রত্যাশাগুলিকে সামঞ্জস্যপূর্ণ করব, আমাদের সামগ্রিক কর্মক্ষম দক্ষতা এবং বৃদ্ধিশীলতা উন্নত করব।
WE6.2.2	আমরা যদি ডেভেলপারদের অনেক ঝামেলাপূর্ণ কাজকে সরলীকরণ করার জন্য একটি গোল্যাং এবং Node.js লাইব্রেরি তৈরির ঘোষণা করি, তাহলে তারা আগ্রহ এবং মতামত নিয়ে সাড়া দেবে
WE6.2.4	যদি আমরা ডেটা পার্সিস্টেন্স ডিজাইন পর্যালোচনা প্রয়োগ করি এবং সক্রিয়ভাবে সমর্থন করি, তাহলে আমরা উৎপাদনে পৌঁছানোর সহজ ও নির্ধারিত পথগুলি চিহ্নিত করতে পারি।
WE6.3.2	যদি আমরা নতুন মেট্রিক্স তৈরি করি, পার্সয়েডের ক্যাশে অবকাঠামো উন্নত করি এবং দুটি "শীর্ষ-দশ" উইকিপিডিয়ায় স্থাপন করি, তাহলে আমরা আস্থা কাঠামোর জন্য কর্মক্ষমতার মানদণ্ড তৈরি করব, যা অন্যান্য বৃহৎ উইকিতে স্থাপনের জন্য আমাদের প্রস্তুতি যাচাই করতে সাহায্য করবে এবং স্কেলে উচ্চ মাত্রার-ট্রাফিক পরিচালনা করার ক্ষেত্রে আমাদের ক্ষমতা প্রদর্শন করবে।
WE6.3.3	যদি আমরা গুরুত্বপূর্ণ ভাষা বৈকল্পিক সহায়তা উন্নতি বাস্তবায়ন করি এবং দ্বিতীয় ত্রৈমাসিকে কমপক্ষে ৩টি ভাষা বৈকল্পিক উইকিতে সফলভাবে পার্সয়েড স্থাপন করি, তাহলে আমরা অবশিষ্ট সমস্ত ভাষা বৈকল্পিক উইকিতে আত্মবিশ্বাসের সাথে প্রবর্তনের জন্য প্রয়োজনীয় মূল প্রযুক্তিগত চ্যালেঞ্জগুলি চিহ্নিত এবং সমাধান করব।
WE6.4.6	যদি এসআরই মিডিয়াউইকি আমাদের প্রকৌশল দলগুলিকে ক্ষমতা ও ট্র্যাফিক ব্যবস্থাপনা, কনফিগারেশন পরিবর্তনের প্রস্তুতি ও পর্যালোচনা, এবং সমস্যাগুলি তদন্ত ও সমস্যা সমাধানের জন্য সহযোগিতার মাধ্যমে সহায়তা প্রদান করে, তবে আমরা একসাথে দ্বিতীয় ত্রৈমাসিকে উৎপাদন পিএইচপি ৮.৩ আপগ্রেড সম্পন্ন করব এবং ভবিষ্যতের আপগ্রেডের জন্য এসআরই-এর ওপর গুরুত্বপূর্ণ-পথ নির্ভরতা কমাতে সুপারিশগুলির একটি সেট নথিভুক্ত করব।	T360995
WE6.4.7	যদি আমরা বিশ্বব্যাপী রুট অ্যাক্সেস সহ সমস্ত ব্যবহারকারীর সংখ্যার কমপক্ষে ৯০% কে উইকিমিডিয়া প্রোডাকশন সার্ভার অ্যাক্সেস করার জন্য একটি হার্ডওয়্যার-সমর্থিত এসএসএইচ চাবি ব্যবহারে স্থানান্তরিত করি, তাহলে আমরা কোনো ঝুঁকিপূর্ণ ল্যাপটপের কারণে গুরুতর নিরাপত্তা লঙ্ঘনের ঝুঁকি হ্রাস করব।
WE6.4.8	যদি মিডিয়াউইকি প্রকৌশল দল সক্রিয়ভাবে মিডিয়াউইকিতে পিএইচপি আপগ্রেড সম্পর্কিত সমস্যাগুলি পর্যবেক্ষণ করে এবং তার সমাধান করে, তাহলে এটি এসআরই টিমকে ২০২৫ সালের নভেম্বরের মধ্যে পিএইচপি ৮.৩ আপগ্রেডের উৎপাদন সম্পন্ন করতে সক্ষম করবে।	T360995

সিগন্যাল এবং ডেটা সার্ভিসেস (এসডিএস) অনুমান [ এসডিএস-এর মূল ফলাফল ] আলোচনা
অনুমানের সংক্ষিপ্ত নাম	কিউ২ পাঠ্য	বিস্তারিত এবং আলোচনা
SDS1.2.1	যদি আমরা বর্তমান ‘ডাম্পস ১’ অবকাঠামো থেকে এক্সএমএল ডাম্পস প্রক্রিয়াকে মিডিয়াউইকি কন্টেন্ট সরবরাহ লাইন-ভিত্তিক একটি ডেটা সরবরাহ লাইনে স্থানান্তর করি, তাহলে আমরা এসএলও নিশ্চিত করতে পারব এবং ‘ডাম্পস ১’-ভিত্তিক এক্সএমএল রপ্তানি বন্ধ করে দিতে পারব।
SDS1.2.2	যদি আমরা মিডিয়াউইকি কন্টেন্ট হিস্ট্রি এবং ইভেন্ট প্ল্যাটফর্ম / ইভেন্ট গেটের জন্য এসএলও গুলি পর্যালোচনা করি এবং ব্যাখ্যা করি, তাহলে আমরা গ্রাহক, মেট্রিক্স এবং নির্ভরশীল স্টেকহোল্ডারদের যাচাই করতে পারব এবং এসএলও গুলির জন্য প্রয়োজনীয় উন্নতিগুলি সনাক্ত করতে পারব, যা আমাদের সাপ্তাহিক ডেলিভারি গ্যারান্টিতে যেকোনো ফাঁক পরিষ্কার করতে সাহায্য করবে।
SDS1.3.1	যদি আমরা ক্লায়েন্টের দিকের সিগন্যালগুলি চালু করি এবং সার্ভারের দিকের ওয়েবরিকোয়েস্ট লগের সাথে তুলনা করে সেগুলি অডিট করি, তাহলে আমরা অতিরিক্ত বট প্যাটার্ন খুঁজে পাব যা চিহ্নিত করা যেতে পারে।
SDS1.3.2	যদি আমরা বর্তমান বট বনাম মানব বিতরণকে ভিত্তিরেখা হিসেবে ধরে নিই এবং বিতরণে পরিবর্তনের জন্য স্বয়ংক্রিয় সতর্কতা তৈরি করি, তাহলে আমরা স্বয়ংক্রিয় ট্র্যাফিকের পরবর্তী অপ্রত্যাশিত ধরণ শনাক্ত করার সময়সীমা কয়েক সপ্তাহ থেকে কয়েক মিনিটে নামিয়ে আনা সম্ভব হবে।
SDS1.3.3	যদি আমরা ওয়েবরিকোয়েস্টের জন্য ব্যাকফিল প্রক্রিয়াটি স্বয়ংক্রিয় করি এবং মে মাসের লগে এটি ব্যবহার করি, তাহলে আমরা ভবিষ্যতের ঘটনার জন্য প্রতিকারের সময় মাস থেকে কমিয়ে দিনে নামিয়ে আনব এবং "মে মাসের পাতা পরিদর্শনে বৃদ্ধি" ঘটনার সমাধান করব।
SDS1.3.4	যদি আমরা বট শ্রেণীবিভাগের আউটপুটগুলির জন্য একটি নিয়মিত, কার্যকরী অভ্যন্তরীণ নিরীক্ষা প্রক্রিয়া তৈরি করি, তাহলে আমরা আমাদের সমাধানগুলিতে আস্থা তৈরি করতে পারব এবং ট্র্যাফিক প্যাটার্নের পরিবর্তনগুলি পূর্বাভাস দিতে পারব যা স্বয়ংক্রিয়ভাবে সনাক্ত করা যায় না।
SDS1.3.5	যদি আমরা মৌলিক ক্লায়েন্ট-সাইড সংকেত বিশ্লেষণ করি এবং এটিকে আমাদের হিউরিস্টিকসে অন্তর্ভুক্ত করি, তাহলে আমরা ডেটা প্ল্যাটফর্মে অতিরিক্ত বট প্যাটার্ন সনাক্ত করতে পারব।
SDS1.3.6	যদি আমরা আমাদের অনুসন্ধানে Spur.us আইপি রেপুটেশন আমদানি, বিশ্লেষণ এবং অন্তর্ভুক্ত করি, তাহলে আমরা ডেটা প্ল্যাটফর্মে অতিরিক্ত বট নিদর্শনগুলি সনাক্ত করতে পারব।
SDS1.3.7	যদি আমরা শেষ বিন্দু থেকে একটি সংকেত আমদানি, বিশ্লেষণ এবং আমাদের হিউরিস্টিকসে অন্তর্ভুক্ত করি, তাহলে আমরা ডেটা প্ল্যাটফর্মে অতিরিক্ত বট প্যাটার্ন সনাক্ত করব।
SDS1.4.1	যদি আমরা উইকিমিডিয়া ইকোসিস্টেমের মধ্যে বিদ্যমান প্রবণতাগুলি, যেগুলি হলো পাতা পরিদর্শন, অবদানকারী ও পাঠক সংখ্যা, ট্র্যাফিক ইত্যাদি, এদের বিশ্লেষণ পুনরায় নিশ্চিত করি - তাহলে আমরা আমাদের সবচেয়ে গুরুত্বপূর্ণ আন্দোলন অন্তর্দৃষ্টির জন্য গুরুত্বপূর্ণ আলোচনার বিষয়গুলিকে আত্মবিশ্বাসের সাথে সমর্থন করতে সক্ষম হব।
SDS1.4.2	যদি আমরা উইকিমিডিয়া ইকোসিস্টেমের মধ্যে বিদ্যমান প্রবণতাগুলি - পৃষ্ঠা দর্শন, অবদানকারী এবং পাঠক সংখ্যা, ট্র্যাফিক ইত্যাদি - এদের বিশ্লেষণ পুনরায় নিশ্চিত করি - তাহলে আমরা আমাদের সবচেয়ে গুরুত্বপূর্ণ আন্দোলন অন্তর্দৃষ্টির জন্য গুরুত্বপূর্ণ আলোচনার বিষয়গুলিকে আত্মবিশ্বাসের সাথে সমর্থন করতে সক্ষম হব।
SDS2.1.1	যদি আমরা পরীক্ষা-নিরীক্ষা পরিচালনাকারী দলগুলির সাথে ঘনিষ্ঠভাবে জুটি বাঁধি, তাহলে আমরা শিখব কিভাবে ভবিষ্যতে সিস্টেমটিকে আরও স্ব-সেবামূলক করা যায় এবং তারা কি কি ধারণাগত বা প্রযুক্তিগত চ্যালেঞ্জের মুখোমুখি হতে পারে।
SDS2.1.2	যদি আমরা ইভেন্ট লগিংয়ের জন্য আরও ভালো ত্রুটি নিরসন বাস্তবায়ন করতে পারি, তাহলে পণ্য দলগুলি জানতে পারবে যে তাদের পরীক্ষাটি প্রত্যাশা অনুযায়ী ইভেন্ট তথ্য সংগ্রহ করছে, যা পরীক্ষাকারীদের আত্মবিশ্বাস বৃদ্ধি করবে।
SDS2.1.3	যদি আমরা পরীক্ষামূলক প্ল্যাটফর্মের এ/বি টেস্টিং সিস্টেমের (এক্সল্যাব) উপাদান এবং এর সাথে সম্পর্কিত মিডিয়াউইকি অংশগুলির জন্য লগিং ও পর্যবেক্ষণযোগ্যতা উন্নত করি, তাহলে আমরা সিস্টেমের কর্মক্ষমতার জন্য ভিত্তিরেখা স্থাপন করতে এবং পরীক্ষা-সম্পর্কিত ব্যর্থতায় প্রতিক্রিয়া জানাতে সক্ষম হব।
SDS2.1.4	যদি আমরা মাসে একবার প্রতিষ্ঠান জুড়ে পরীক্ষার বিবরণ এবং ফলাফল শেয়ার করি (প্রোডাক্ট অপারেশন মিটিং, ডিজাইন টিম মিটিং এবং ক্রস-টিম উপস্থাপনার মাধ্যমে), তারপর আমরা পরীক্ষামূলক প্ল্যাটফর্মটির স্বাভাবিক গ্রহণযোগ্যতা তৈরি করব।
SDS2.1.5	যদি আমরা ব্যবহারকারীদের বলি যে তাদের যন্ত্রটি, যদি এক্স-ল্যাবে তৈরি হয়ে থাকে, তাতে এমন কিছু বৈশিষ্ট্য রয়েছে যাতে ঝুঁকির শ্রেণী পরিবর্তিত হয়, তাহলে আমরা যন্ত্র ব্যবহারকারীদের অতিরিক্ত ডেটা সংগ্রহ করা থেকে বিরত রাখব এবং কোন বৈশিষ্ট্যগুলির সমন্বয়ের জন্য গোপনীয়তা পর্যালোচনা প্রয়োজন সে সম্পর্কে স্পষ্টতা বৃদ্ধি করব।
SDS2.1.6	যদি গ্রোথ টিম এক্সপেরিমেন্ট ল্যাবের সাথে দুটি ব্যবহারের ক্ষেত্রে (একটি বাকেটিং ক্ষমতা সম্পর্কে অন্তর্দৃষ্টি অর্জনের জন্য এ/বি পরীক্ষার মাধ্যমে এবং অন্যটি দীর্ঘমেয়াদী উপকরণের মাধ্যমে কেপিআই-এর মতো মেট্রিক্সের জন্য সমর্থন সম্পর্কে জানার উদ্দেশ্যে) কাজ করে, তাহলে আমরা মূল্যায়ন করতে পারি যে এটি গ্রোথএক্সপেরিমেন্টস-এ আমাদের কাস্টমাইজড এক্সপেরিমেন্ট সেটআপ প্রতিস্থাপনের প্রয়োজনীয়তাগুলি যথেষ্ট পরিমাণে পূরণ করে কিনা।

ফিউচার অডিয়েন্স (এফএ) অনুমান [ এফএ-র মূল ফলাফল ] আলোচনা
অনুমানের সংক্ষিপ্ত নাম	কিউ২ পাঠ্য	বিস্তারিত এবং আলোচনা
FA1.1.4	[গত অর্থবছর থেকে চলমান] যদি আমরা রবলক্সে একটি নতুন উইকিপিডিয়া অভিজ্ঞতা তৈরি করি, তাহলে আমরা জানতে পারব যে এটি আমাদের ব্র্যান্ডকে ছোট পাঠকদের (জেন আলফা) কাছে পরিচয় করিয়ে দেওয়ার একটি কার্যকর উপায় হতে পারে কিনা।
FA1.1.2	যদি আমরা itch.io-এ নতুন উইকিপিডিয়া অভিজ্ঞতার জন্য একটি কেন্দ্রীয় হাব তৈরি করি, তাহলে আমরা ৫০ জনেরও বেশি আগ্রহী অ-উইকিপিডিয়ান পাঠক সংখ্যা বৃদ্ধি করতে সক্ষম হব যারা আমাদের প্রতিক্রিয়া জানাবে, যা আমাদের সাহায্য করবে গেমগুলিতে কি কাজ করে এবং কি করে না তা শিখতে।
FA2.2.1	যদি আমরা স্বল্প দৈর্ঘ্যের ভিডিও প্ল্যাটফর্মগুলিতে কমিউনিটি ব্যবস্থাপনায় বিনিয়োগ করি, তাহলে দ্বিতীয় ত্রৈমাসিকের (ডিসেম্বর ২০২৫) শেষ নাগাদ আমরা টিকটক-এ প্রদর্শনের শতাংশে নতুন পাঠকদের ৩০% QoQ বৃদ্ধি দেখতে পাব — এবং সমস্ত এসএফভি প্ল্যাটফর্ম জুড়ে, আমরা ৫০,০০০টি মোট সম্পৃক্ততা (লাইক ও রিপ্লাই মন্তব্য) অর্জন করব, যা আমাদের দৃশ্যমানতা বৃদ্ধি করতে এবং বর্তমানে আমরা যাদের কাছে পৌঁছোতে পারছিনা না তাদের সাথে সম্পৃক্ততা বৃদ্ধি করতে সাহায্য করবে।
FA2.2.2	যদি আমরা উইকিপিডিয়া ক্রিয়েটর পার্টনারশিপ প্রোগ্রামের অভ্যন্তরীণ কৌশল এবং বহিরাগত শেয়ারযোগ্য কৌশল (স্রষ্টাদের প্রতি আমাদের মূল্যের একটি রূপরেখা, অংশীদারিত্বের মানদণ্ড, চুক্তি প্রক্রিয়া এবং মালিকানাধীন ও নিজস্ব চ্যানেলগুলিতে স্রষ্টার সামগ্রী কিভাবে প্রদর্শিত হবে) তৈরি করি এবং সাইন-অফ পাই, তাহলে আমরা একটি শক্তিশালী স্রষ্টা কৌশল প্রতিষ্ঠা করতে সক্ষম হব যা আমাদের জ্ঞান সামগ্রীর মাধ্যমে সামাজিক মাধ্যম জুড়ে নতুন দর্শকদের কাছে পৌঁছোতে সাহায্য করবে।

পণ্য ও প্রকৌশল সহায়তা (পিইএস) অনুমান [ পিইএস-এর মূল ফলাফল ] আলোচনা
অনুমানের সংক্ষিপ্ত নাম	কিউ২ পাঠ্য	বিস্তারিত এবং আলোচনা
PES1.1.5	যদি আমরা মিডিয়াউইকি বিষয়বস্তু ইতিহাস এবং স্লথ/পাইরাতে উইকিফাংশনের জন্য পরিষেবা স্তরের উদ্দেশ্য (এসএলও) অন্তর্ভুক্ত করি, তাহলে আমরা উৎপাদনে আরও ২টি এসএলও পাব।
PES1.1.6	যদি আমরা বিদ্যমান এসএলও থেকে প্রাপ্ত পূর্ববর্তী ডেটা ব্যবহার করে Sloth পরীক্ষা করি, তাহলে আমরা বুঝতে পারব যে Pyrrra বা Sloth (অথবা অন্য কিছু) আমাদের ত্রুটি বাজেট উইন্ডোতে স্থির-উইন্ডো পদ্ধতির জন্য সঠিক হাতিয়ার কিনা। আমরা এসএলও মেট্রিক্সের জন্য স্ব-পরিষেবা পদ্ধতির মাধ্যমে পরিষেবা মালিকদের কিভাবে সহায়তা করতে হয় এবং সিদ্ধান্ত গ্রহণে সেগুলি কিভাবে ব্যবহার করতে হয় তা শিখব।
PES1.2.4	যদি আমরা প্রথম ত্রৈমাসিকে ৩টি দলের সাথে একটি ত্রৈমাসিক ইচ্ছা এবং সম্প্রদায় সংকেত পর্যালোচনা প্রক্রিয়া পরীক্ষামূলকভাবে চালু করি, তাহলে আমরা পণ্য পরিচালকদের তাদের ত্রৈমাসিক এবং বার্ষিক পরিকল্পনা প্রক্রিয়ায় সম্প্রদায় সংকেতগুলিকে একীভূত করার জন্য নিযুক্ত করব।
PES1.2.5	যদি আমরা ট্যাগ এবং ভোটিংয়ের মাধ্যমে শ্রেণীবদ্ধকরণের সুবিধা প্রদানকারী উন্নতিগুলির সাথে ইচ্ছাতালিকা এক্সটেনশনে উইশ ফিল্টার এবং বাছাই করার ক্ষমতা যোগ করি, তাহলে এই ৩টি উন্নতির মাধ্যমে ইচ্ছাতালিকায় আরও অনন্য অংশগ্রহণকারীদের সংখ্যা কমপক্ষে ৩০% বৃদ্ধি হবে।
PES1.3.3	যদি আমরা ব্যবহারকারীর পারস্পরিক যোগাযোগের ওপর ভিত্তি করে প্ল্যাটফর্মে কমপক্ষে ৫টি আনন্দদায়ক হস্তক্ষেপ তৈরি করি, তাহলে আমরা তাহলে আমরা নির্ধারণ করব কোন উদ্দীপনাগুলি পোর্টাল পৃষ্ঠা এবং বার্থডে মোড গ্যাজেটের জন্য কাজ করবে। ব্যবহারযোগ্যতা পরীক্ষা আমাদের বলবে কোন হস্তক্ষেপগুলি আমাদের ব্র্যান্ডের সাথে ইতিবাচক সম্পর্ক তৈরি করে। উইকিকন উত্তর আমেরিকা এই অনুমানের কাজ অক্টোবরের শেষের দিকে শেষ করার জন্য সময়সীমাবদ্ধ।
PES1.3.4	যদি আমরা যোগাযোগ বিভাগের সদস্যদের সাথে সহযোগিতায় উইকিপিডিয়ার ইতিহাস, বর্তমান এবং ভবিষ্যৎ অন্বেষণ করে একটি মগ্নকর ওয়েবসাইট তৈরি করি, যার লক্ষ্য থাকবে প্রচারণার লক্ষ্যবস্তু এলাকায়, ১৮-৩৪ বছর বয়সী অনলাইন দর্শকদের সম্পৃক্ত করা, তাহলে এটি সামাজিক শেয়ার এবং অন্যান্য অনলাইন কার্যকলাপের মাধ্যমে উইকিপিডিয়ার সাথে আরও বেশি সংযোগ স্থাপন করবে। এটি কমিউনিকেশনের ব্র্যান্ড উপস্থিতি ১০ শতাংশ বৃদ্ধিতে অবদান রাখবে, একই সাথে কন্টেন্টের গতিশীল পদ্ধতিগুলি ব্র্যান্ড পছন্দ উন্নত করে কিনা তা আমাদের জানাবে।

Q3

The third quarter (Q3) of the WMF annual plan covers January-March 2026.

Wiki Experiences (WE) Hypotheses [ WE Key Results ] আলোচনা
Hypothesis shortname	Q3 text	Details & Discussion
WE1.1.3	If the Editing Team makes an initial set of edit suggestions available within VE via a URL parameter and invites ≥10 newcomers and patrollers to offer feedback about it, we will learn what improvements would need to be made before running a controlled experiment to evaluate the intervention's impact.
WE1.1.4	If we deploy Reference Check at en.wiki through a controlled experiment, we will see a ≥4% increase in the constructive edits new(er) volunteers publish and learn whether there is sufficient support among patrollers and moderators to enable the feature more widely.
WE1.1.12	If we enable ≥3 volunteers to evaluate ≥30 sample edits each, for each of the 10 new languages we are seeking to scale Tone Check to, we will learn how often volunteers agree with model predictions and be able to decide which new wikis to approach about deploying Tone Check to.
WE1.1.14	If we prompt new(er) volunteers to consider the tone they are writing in when an AI model detects them using non-neutral language, then we will see a ≥4% decrease in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:NPOV (and related policies).
WE1.1.17	If we develop a task generation engine for the Revise Tone structured task, integrate our recent learnings about which content to include or filter out, and provide pipelines that automatically refresh the task list, we'll enable a qualitative evaluation of the tasks generated and an A/B experiment that tests whether this type of task helps newcomer editors to make more constructive edits.
WE1.1.18	If we analyze a pre-predetermined set of leading indicators ~2 weeks after the start of the Revise Tone Structured Task A/B test, we will be able to identify what – if any – facets of the end-to-end experience need to be adjusted or investigated before we can be confident evaluating the impact of the feature.
WE1.1.19	If we enable people on mobile web to edit any article section, regardless of which edit icon they first tap, then the newcomer mobile edit abandonment rate will decrease by #% because they will be able to more more easily locate the content they tapped edit seeking to change.
WE1.1.20	If the Growth team scales the “Add a Link” task to at least 10 additional Wikipedias, then we can complete leading indicator analysis to confirm that the task is performing as expected and identify any wikis that may require further review.
WE1.1.21	If we deploy the new Add-a-Link model version to both newly onboarded wikis and wikis currently using Add-a-Link, then the Growth team will be able to roll out Add-a-Link as a structured task to wikis where it did not previously exist, and wikis that already had the task will receive an updated model with fresher training data and improved offline performance.
WE1.1.22	If we improve the initial “Welcome to Wikipedia” verification email, the percentage of new accounts that verify their email address will increase. This would allow Growth to re-engage these accounts through follow up emails and ensure they receive talk page notifications.
WE1.1.23	If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.1.24	If we prompt new(er) volunteers pasting text from an external site to confirm whether they wrote the content they are attempting to add, then we will see a ≥4% increase in the percentage of new content edits new(er) volunteers publish that are reverted on the grounds of WP:COPYVIO (and related policies).
WE1.2.6	If we develop a goal-setting feature via Event Registration, then more collaborations will be created via Event Registration.
WE1.3.3	If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row.
WE1.3.4	If we deploy the Revert Risk filter to 150+ additional Wikipedias that currently lack damaging/goodfaith models, then we will see an increase in moderator patrol counts for contributors who use the personal moderator dashboard compared to those who don't get access to the dashboard.
WE1.5.1	If we implement a dashboard to explore 7 contributor metrics and standardize the calculation of at least one metric using dbt then we can enable contributor product teams to self-serve metric insights and develop a standard for storing metric calculation logic.
WE1.5.3	If Data Engineering productionizes a data product of edit types by the end of Q3, then the 6 moderator actions that are "Complicated" to measure will become "Simple", allowing Movement Insights to define a monthly active moderator metric as a next step.
WE1.5.4	If we produce a prototype dashboard with active moderator metrics that are currently available, then we will be able to produce a full dashboard by end of Q4.
WE1.6.1	If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE2.2.13	If we socialize the availability of the conjugation table function with the Wiktionary community, we will gather early signals about editor understanding and usability that can guide future improvements.
WE2.2.20	If we roll Wikifunctions out to wikis that have Parsoid enabled, we will be able to continue testing whether the system remains performant and usable in increasingly broad rollouts.
WE2.2.21	If we allow a limited set of reentrant functions in the evaluator, it will be possible to increase reliance on evaluated implementations, thereby leveraging the most performant part of the backend.
WE2.2.22	If we write an explicit interpreter for the composition language, the orchestrator will be more performant, and further performance-enhancing features will be easier to implement.
WE2.2.23	If we enable contributors to reuse whole composition blocks across functions, we will reduce repetitive work and significantly speed up the creation of new implementations, especially for similar linguistic functions.
WE2.2.24	If we define a clear documentation structure and entry points, function creators will more easily find relevant guidance and experience less friction when creating functions.
WE2.2.25	If we systematically identify the biggest friction points in the function creation experience, we can surface a small set of high-impact improvements that make creating and iterating on functions more efficient.
WE2.2.26	If we introduce a lightweight, local reference solution (via pop-ups) for Abstract Wikipedia, we can establish an initial citation mechanism to inform whether more complex solutions are necessary.
WE2.3.4	If we build and release an initial version of the Abstract Wikipedia platform, we can demonstrate the technical feasibility of the ecosystem working across multiple languages.
WE2.3.5	If we engage with a small number of under-resourced Wikipedia language communities with a concrete example of abstract content, we can validate whether content created outside their local wiki is acceptable and identify conditions needed for adoption.
WE2.3.6	If we design how Abstract Wikipedia content is surfaced and presented within local Wikipedias, and how local communities make integration decisions, we can socialize the proposal, reach agreement, and confidently plan Q4 development work.
WE2.5.1	If we deploy the Blazegraph candidate replacement in eqiad and augment existing evaluation work with production WDQS traffic-replay analysis, then we will confirm that the new backend performs comparably, supports real-world SPARQL queries, and is ready for limited live-traffic exposure once the surrounding ecosystem (UI, monitoring, onboarding, and real-time index update pipeline) is prepared.
WE2.5.2	If we define access guidelines for the Wikidata platform, we will better be able to control the load put on WDQS servers at the time of our backend migration.
WE2.5.3	If we define a cohort of user personas to test our new backend system, we will be prepared for the pilot and subsequent phases of the Blazegraph cutover.
WE2.5.4	If we produce a migration plan in a single document, we will be able to align upon and drive the execution of all aspects of the migration.
WE2.5.5	If we optimize the Wikidata Revert Risk model for low-latency inference and deploy it in a stable, scalable manner on LiftWing, then the Wikimedia Enterprise team will be able to integrate revert risk signals into their product pipeline, enabling customers to receive timely, high-quality model outputs.
WE3.1.8	If we evaluate 2 semantic search prototypes (natural language search, Q&A) with external participants, we can learn whether users see value in improved search tools, and provide the Readers teams with a recommendation on how to move forward with a search and discovery MVP.
WE3.1.12	If we collect a benchmark dataset consisting of a set of representative queries and annotations of relevant search results, we will be able to perform offline (i.e. without user studies) search evaluation of the quality of search results of different search models.
WE3.1.15	If we test hybrid search MVPs that blend keyword, natural-language, and meaning-based queries, in the Android app, we will rapidly identify the approach and design patterns that increases total search engagement by 10% without a negative impact on satisfaction, latency, or retention
WE3.1.16	If we define requirements for a Q&A model, we will produce model outputs to share with the community for feedback that we can incorporate into a production experiment.
WE3.1.17	If Search provides a production-ready (stable, performant) vector search infrastructure which supports semantic query processing — including a MediaWiki endpoint, then ML and Research will be able to generate embeddings and integrate their models with the system, enabling the MVP’s embedding-powered retrieval.
WE3.1.18	If we deploy a Qwen3 embeddings inference service that is compatible with our existing OpenSearch stack, then Mobile Apps can experiment with generating article-chunk and query embeddings through Qwen3, which should outperform the embeddings produced by OpenSearch’s built-in models.
WE3.3.6	If we make article topic inference data available via a service that meets agreed-upon scalability and availability requirements, plus any necessary data backfills, then we will have established the technical foundation necessary to support upcoming personalized reader experiences that depend on this data.
WE3.4.1	If we work towards a hybrid point of presence (PoP/CDN) deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.
WE3.5.2	If we offer donors a badge acknowledging their status, at least 70% of donors who opt-in will report positive sentiment on a linked survey.
WE3.6.5	If Product & Technology and Fundraising collaborate on a shared strategy to diversify on-platform donation opportunities and steward and recognize readers who donate, we will set clear, aligned goals and metrics tied to our consumer and fundraising strategies.
WE3.6.6	If we develop a unified measurement strategy, we will enable evaluation of the consumers’ multi-year strategy and define a roadmap to guide metric development and reporting capabilities.
WE3.6.7	If we run a secondary A/A test on retention rate for logged-out users, we will begin to establish seasonal trends for retention rate that we can use for future quarters
WE3.6.8	If we systematically compare the information seeking needs and behaviors of 1) new and infrequent English Wikipedia readers and non-readers with those of 2) current English Wikipedia readers by simultaneously surveying both populations, we will be able to identify key insights about the demographic characteristics, online information needs, and online platforms used by these audiences, identifying potential opportunities for growing our readership as well as potential threats to our existing readership.
WE3.8.1	If we add additional modules to the activity tab and scale it to all users, we’ll see a 5% increase in overall iOS app account creation compared to before release
WE3.9.1	If we update the Wikipedia iOS app’s visual foundations, component defaults, and navigation behaviours to align with Apple’s Liquid Glass design language—while clearly defining design and behaviour for high-priority fallbacks across OS versions—then downstream engineering implementation will be clearer, lower-risk, and the app will feel more platform-native when Apple forces user switchover
WE3.10.1	If we user test a design prototype of the Explore Feed built with lightweight personalization, clear freshness cues, and repeatable Wikipedia-native patterns (e.g., topical rabbit holes, time-bound highlights, and interactive elements), casual reader participants will report understanding of the proposed feed’s purpose, reach an “aha” moment faster, and show a stronger intent for daily use. The visual design we recommend moving forward with will be described as digestible and aligned with the Wikimedia movement.
WE4.1.3	If we update 6 Wikipedias (English, French, German, Spanish, Italian, Polish) by the end of Q2, we will complete phase 1 of the new Legal Footer roll-out in response to DSA requirements.
WE4.2.5	If we conduct research, consult with communities, and investigate technical solutions, we will be able to define a set of structured block reasons that can be used across all WMF wikis.
WE4.6.8	If we monitor the impact of the Zendesk and MediaWiki forms we built in Q1, then we can propose technical interventions for future quarters that would better automate the rest of the account recovery process.
WE5.1.3c	If we roll out rate limiting to all APIs routed through the gateway, we will be able to reduce the number of anonymous API requests that reach our backend infrastructure, by limiting requests based on user classes that give higher limits to authenticated and community users.
WE5.1.5	If we improve the sustainability and reliability of our OAuth 2.0 implementation, we will be able to convince more developers to use OAuth and support the migration of the Wikipedia mobile apps, by increasing confidence that it can be relied upon for high profile applications.
WE5.1.5b	If we improve the developer experience for creating and managing OAuth 2.0 clients, we will be able to increase the number of applications that use OAuth 2.0, by deprecating OAuth 1.0 for new applications and promoting OAuth 2.0 as the preferred option for API authentication.
WE5.2.2c	If we reroute all APIs currently going through the API Gateway through the common gateway, we will be able to fully deprecate the historic API Gateway and ensure consistency for all community facing Wikimedia HTTP/web APIs
WE5.2.6	If we introduce access controls to the sitemap API to only allow trusted bots, we can improve strategic alignment and reduce the risk of abusive scraping.
WE5.2.8	If we create dedicated API modules for all API extensions and self-contained functionality within MediaWiki Core, we will enable enforcement for higher quality documentation with independent management and versioning.
WE5.2.9	If we have better separation of concerns for API registration and spec definition processes, we will simplify the complexity of API management and create a better developer experience for API authors.
WE5.2.10	If we conduct a listening tour specifically focused on v2 API consolidation and feature gaps, we will be able to move more quickly with a v2 implementation.
WE5.2.11	If we experiment and establish processes for standardizing documentation currently in the API Portal, we can consolidate sources of information and improve documentation consistency.
WE5.3.1b	If we publish and iterate on the draft UX guidelines and demos, we will establish a core framework ready to be internally tested and iteratively refined to be prepared for broader public use.
WE5.3.2b	If we establish a partner pilot program to experiment with Wikimedia attribution, we can show mutually beneficial impacts of attribution by reusers to drive engagement and contributions to Wikimedia.
WE5.4.6	If by the end of Q2 we've classified the top N spiders as known bots, we can constrain the amount of resources they're using.
WE5.4.8	If we start enforcing rate limits tailored to different classes of individual clients for media files, we will reduce the burden of crawling on our infrastructure.
WE5.4.9	If we add ip-reputation data on residential proxies to our bot detection, it will improve our ability to block scrapers
WE5.4.10	If we stop allowing generation of non-standard thumbnail sizes, it will reduce the strain on our backend media serving infrastructure
WE5.4.11	If we identify two high-confidence signals from the December 2025 scraping/DDoS incidents and deliver them to SRE, then SRE will be able to develop more effective automated mitigation rules for future similar incidents.
WE5.4.12	If we are able to attest where and from whom a request for an image is originated, we can make more informed decisions about rate-limiting them
WE6.1.2	If we add wikifarms to a pre-merge testing environment this will enable development teams building against production who require multiple wikis to test their patches in isolation giving them greater pre-production confidence and result in fewer defect escapes.
WE6.1.3	If we resolve the top 5 flaky Selenium tests over the next 90 days, we will increase developer confidence in automated browser testing as a valuable part of the pre-deployment workflow.
WE6.2.4	If we apply, and actively support the Data Persistence design review, we may identify paved pathways to production
WE6.2.5	By collaborating with the SLO group and gathering feedback from teams currently working with them, will help us not only identify gaps and improvements for the Production Readiness checklist, but also adapt it in such a way to directly facilitate SLO adoption and onboarding
WE6.2.6	By piloting the production readiness checklist on the hCaptcha proxy service against launch and high-importance items, we will identify untracked technical debt and create a visible work backlog, which will demonstrate the framework's value, while shaping a repeatable process for consistent adoption across services.
WE6.2.7	By collaboratively refining the production readiness checklist with SRE input and contributions, we will ensure it addresses real operational needs, build shared ownership, and create a practical tool that teams see value in adopting.
WE6.2.8	By analysing feedback from our collaboration with the SLO group, hCaptcha proxy pilot, and SRE collaboration, we will identify which checklist items and process steps require clearer guidance or supporting resources, and determine the next steps for streamlining the framework to make adoption achievable before the December break.
WE6.2.9	If we adopt node.js service-utils, we will be able to release, in a tested way, either of: service-mesh routing or OpenTelemetry publishing.
WE6.3.2	If we develop new metrics, improve Parsoid's cache infrastructure, and deploy on two "top-ten" wikipedias, we will develop performance criteria for the confidence framework, which will help validate our readiness for deployment to other large wikis and demonstrate our ability to handle high-traffic volumes at scale.
WE6.3.3	If we implement critical Language Variant support improvements and successfully deploy Parsoid to at least 3 Language Variant wikis in Q2, we will identify and resolve the key technical challenges necessary to confidently roll out to all remaining Language Variant wikis.
WE6.3.4	If we QA, identify, triage, and fix bugs within the reading experience across platforms for Parsoid Read Views, we will maintain the quality of the reading experience and unblock further scaling across wikis
WE6.3.5	If we target a Time To First Byte (TTFB) metric of <= 110% of legacy for parser cache hits and <= 150% of legacy for parser cache misses, we can deploy to all Wikipedias except for Chinese and English by the end of Q3 with no performance complaints. This will help validate our readiness for deployment on English Wikipedia, preparing us to handle high-traffic volumes at scale by understanding our cache capacity.
WE6.4.4	If we unify our domains by serving all page views on MediaWiki sites through a canonical domain, then we will reduce platform complexity and SEO risks by eliminating the mobile-subdomain redirect. Completion is measured by decreasing redirects for mobile visits on canonical domains from 100% to 0%.
WE6.4.7	If we migrate at least 90% of all users with global root access to use a hardware-backed SSH key for accessing Wikimedia production servers, we will reduce the risk that a compromised laptop will cause a severe security breach.
WE6.4.8	If the MediaWiki Engineering Team actively monitors and fixes issues in MediaWiki related to the PHP upgrade, this will enable the SRE team to complete the production PHP 8.3 upgrade by November 2025.

Signals & Data Services (SDS) Hypotheses [ SDS Key Results ] আলোচনা
Hypothesis shortname	Q3 text	Details & Discussion
SDS1.5.1	If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected.
SDS1.5.2	If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3	If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS2.2.4	If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5	If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.4.2	If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.

Future Audience (FA) Hypotheses [ FA Key Results ] আলোচনা
Hypothesis shortname	Q3 text	Details & Discussion
FA1.1.1	If we build a central hub for new Wikipedia experiences on itch.io, then we’ll be able to grow an audience of >50 interested non-Wikipedians giving us feedback, which will help us learn what works and what doesn’t in games.
FA1.1.2	If we create and test 3 different app-based content discovery features as short experiments, we can share recommendations with the Apps team about how to effectively engage with and retain a new generation of apps users
FA1.1.3	If we create 4 TikTok filters and publish them on our TikTok account, we will be able to learn how well we can incentivize creation of Wikipedia content off-platform.
FA1.1.6	If we create 3 different potential previews for Wikipedia links shared on Discord, we can align internally on our measurement and execution strategy and collaborate with Discord's ProdEng team.
FA2.2.1	If we invest in community management across short-video platforms, then by the end of Q2 (December 2025) we will see a 30% QoQ increase in the percentage of views from New Viewers on TikTok — and across all SFV platforms, we’ll earn 50,000 total engagements (likes and reply comments) on brand comments left on external content, which will help us increase visibility and drive engagement with audiences we’re not currently reaching.
FA2.2.2	If we develop and get sign-off on a Wikipedia Creator Partnerships Program internal strategy and external shareables (inclusive of an outline of our value to creators, partnership criteria, contracting process, and how creator content will show up across owned and creator channels), we will be able to establish a robust creator strategy that will help us reach new audiences across social media with our knowledge content.

Product and Engineering Support (PES) Hypotheses [ PES Key Results ] আলোচনা
Hypothesis shortname	Q3 text	Details & Discussion
PES1.3.5	If we build community configuration for Easter Eggs, and leverage Reader Experience full time for code review, we’ll be able to launch on Feb 15 and track impact of the project.
PES1.3.6	If we create bespoke social media posts for 25 Years of Wikipedia (25YoW), we can achieve similar success with social impressions as Comms’ existing templates, and prove we can support Comms’ by increasing their capacity. Benchmarking will be off of Truth Collective posts about the same project.
PES1.4.1	If we meet with 4-5 teams that are not primarily using Codex (including, but not limited to, teams primarily using OOUI), we will be able to document blockers to those teams adopting Codex for current and future projects.
PES1.4.2	If we make Codex PHP easier to use and stable enough to do a 1.0 release, then teams will adopt Codex PHP for server-generated UIs. This will increase Codex PHP usage from 3 projects to 5.
PES1.5.1	If we upgrade Sloth from a prototype to a replacement for Pyrra, by onboarding existing services, we can converge on a unified set of SLO dashboards, refine our alerts, and streamline the SLO onboarding experience.
PES1.5.2	If we continue to onboard SLI metrics for Wikifunctions and MediaWiki Content History, and check metrics for WikiData Query Service and EditCheck, we will debug issues with both dashboard reporting and service-owner engagement on loud-but-unaddressed SLO reports.

Q4

The fourth quarter (Q4) of the WMF annual plan covers April-June 2026.

Wiki Experiences (WE) Hypotheses [ WE Key Results ] আলোচনা
Hypothesis shortname	Q4 text	Details & Discussion
WE1.3.3	If we launch an experiment to surface a moderator dashboard to newer editors, 10% of contributors who visit it do so two weeks in a row.
WE1.5.1a	If we add new metrics to the Contributors dashboard using DBT we will enable contributor product teams to get more actionable insights into editing trends
WE1.5.5	If we automate updates of DBT models with Airflow on a fixed schedule, we will allow Movement Insights to build analyses and reports on those models using up-to-date information.
WE1.5.6	If we document workflows and establish per-team default output locations and access controls for dbt models, we will allow dbt usage to scale across team members in Movement Insights and other teams.
WE1.5.7	If we extend the MAM dashboard as specified, then we will have a more complete picture of moderator pipeline health that can inform decisions in the Contributor strategy.
WE1.6.1	If we introduce custom watchlist labels, we expect the labels to be used by 5% of users with more than 100 pages on their watchlist in the first month.
WE1.7.2	By testing a design prototype of the in-app webview editing flow with newcomers on the mobile apps, we will identify the highest-risk friction points that could cause abandonment before publishing - specifically around context shift, editor comprehension, and edit attribution - so that we can prioritize what must be resolved before this approach can successfully onboard new editors at scale.
WE1.7.4	If we prompt readily available GenAI models to generate and rank a set of edit suggestions for a diversified sample of 150 English Wikipedia articles, then we will learn what types of editing tasks these generic models can produce at scale and gain a rough, anecdotal understanding of the usefulness of these suggestions. This early signal will help us assess whether some task types could plausibly be generated at scale with generic models (with or without fine-tuning), or whether they would require more specialized approaches - ultimately helping us validate whether pursuing this "single model many suggestions" direction is worthwhile.
WE1.7.5	If we replace the unstructured Copyedit task with the Revise Tone structured task in a controlled experiment, then the task completion rate for Revise Tone edits made by junior editors will be higher than the completion rate for edits made through the Copyedit task.
WE1.7.6	If we test 2 structured workflows via design prototypes that align contribution opportunities with what readers arrive motivated to learn, and frame contributions as ways to act on curiosity or share knowledge they already possess, then concept testing will help us identify approaches that inspire readers to imagine themselves as contributors.
WE1.7.7	If we present an exit survey to users with ≤100 cumulative edits who abandon mobile editing sessions after spending ≥2 seconds in either the mobile visual or source editor, we will discover patterns in the reasons behind this behavior and be able to decide what interventions we will prioritize to increase the mobile web edit completion rate.
WE1.7.8	If we present junior contributors who enter the mobile VisualEditor with immediately actionable edit suggestions, then the proportion of edit sessions that result in someone publishing a constructive edit will increase by ≥10%.
WE1.7.9	If we publish a proposal on-wiki to enable VisualEditor by default for newcomers on mobile web at en.wiki, we will define the steps needed to make this happen.
WE1.8.2	If we improve the logged out edit warning, the account creation rate among newcomers on mobile exposed to the warning will increase by at least 2% relative to the control group.
WE1.8.3	If we improve the account creation form, the registration completion rate among mobile users who land on the form will increase by at least 2% relative to the control group.
WE1.8.4	If we add a user account button to the header on mobile web, then the number of new accounts created on mobile will increase by at least 2% relative to the control group.
WE1.8.5	If we surface Reading Lists to logged-out readers on mobile web, the registration rate will increase by at least 2% relative to the control group.
WE1.9.2	If we introduce key questions about factors that impact editor motivations [i] into the 2026 Community Insights survey, by the end of Q4 we will be able to provide ≥5 research insights which can inform our Contributors strategy implementation, with a focus on editor progression and recognition. [i] Defined through the lens of competence (ability to use tools and resources), autonomy (ability to navigate the platform and make informed decisions), and relatedness (ability to join the community, feel supported and valued).
WE1.9.3	If we co-design guidance for mobile-first onboarding with at least two affiliates, by the end of June we will be able to identify which gaps are perceived by organizers as most detrimental to the retention of mobile-first newcomers.
WE1.10.3	If we work with a few selected communities to customize the Article Guidance workflow for their wikis, editors will get guidance that’s tailored to each community’s content and policies.
WE1.10.5	If we complete all path-to-production requirements for the Article Guidance A/B test (including security review, legal consultation, instrumentation, community outline review and translation, and experiment configuration) we will launch the experiment for it to run to completion before the end of Q4 and start generating statistically meaningful data on the impact of Article Guidance on the 30-day survival rate of articles created by junior editors.
WE2.2.13	If we socialize the availability of the conjugation table function with the Wiktionary community, we will gather early signals about editor understanding and usability that can guide future improvements.
WE2.3.7	If we identify and address small but frequent friction points in contribution workflows together with early contributors, we can support and sustain the engaged core community that is building the foundational building blocks for Abstract Wikipedia.
WE2.3.8	If we implement the capabilities for article-level opt-in integration of Abstract Wikipedia content into local Wikipedias, we can demonstrate how the model works in practice and be ready to engage pilot communities in Q1.
WE2.3.9	If we implement basic instrumentation for Abstract Wikipedia (in addition to existing MediaWiki instrumentation), we will better understand how users interact with Abstract Wikipedia and identify areas for improvement.
WE2.3.10	If we support displaying images from Commons in Abstract articles via Wikifunctions, we enable communities to incorporate visual elements commonly used in Wikipedia articles.
WE2.3.13	If we build an analytical capability to map content availability, production, and consumption against a flexible topic taxonomy, then we'll have greater visibility to content trends that we can derive insights from.
WE2.3.16	If the Rust evaluator is brought to feature parity with the Node evaluator and the Node evaluator phased out, we will eliminate a huge maintenance burden and free up engineering resources.
WE2.5.4	If we produce a migration plan in a single document, we will be able to align upon and drive the execution of all aspects of the migration.
WE2.5.6	If we develop the capability to automate output comparison between WDQS v1 and v2 for selected sets of queries, we will be able to improve confidence in the correctness of the new service.
WE2.5.7	If we assemble a plan for messaging about our migration, we will experience a smoother transition to the new endpoints by aligning with the Wikidata community on when to expect changes and how to prepare for them.
WE2.5.8	If we start to build the decoupled architecture described in our design doc, we should be able incrementally deliver value throughout the quarter and stand by a service that is able to support the pilot cohort by FY27 Q1.
WE3.1.15	If we test hybrid search MVPs that blend keyword, natural-language, and meaning-based queries, in the Android app, we will rapidly identify the approach and design patterns that increases total search engagement by 10% without a negative impact on satisfaction, latency, or retention.
WE3.1.16	If we define requirements for a Q&A model, we will produce model outputs to share with the community for feedback that we can incorporate into a production experiment.
WE3.1.17	If Search provides a production-ready (stable, performant) vector search infrastructure which supports semantic query processing — including a MediaWiki endpoint, then ML and Research will be able to generate embeddings and integrate their models with the system, enabling the MVP’s embedding-powered retrieval.
WE3.3.6	If we make article topic inference data available via a service that meets agreed-upon scalability and availability requirements, plus any necessary data backfills, then we will have established the technical foundation necessary to support upcoming personalized reader experiences that depend on this data.
WE3.4.1	If we work towards a hybrid point of presence (PoP/CDN) deployment, it will allow us to bring up both full PoPs and mini PoPs (physical and cloud) as required, laying the foundation for a prototype mini PoP deployment in the future.
WE3.5.3	If we implement consent-based donor segment storage in MediaWiki and establish a reliable CiviCRM → MW sync, Product and Fundraising will be able to successfully identify and differentiate donor segments on-platform across web and apps by the end of the quarter.
WE3.5.5	If we offer logged-out donors on mobile web a persistent Thank You badge by default that triggers a brief delightful interaction upon tap (C), then we will see a 1% improvement in 21-day cumulative retention rate compared to having a badge with a simple popover message (B), and users who do not get a badge at all post-donation (A). We will also track whether a larger percentage of donors in group (C) tap on the badge again in at least one future return session compared to those in (B), to inform whether playful interactions create a re-engagement loop.
WE3.6.9	If we coordinate across identified stakeholders, we will gather the necessary information on development needs, dependencies, and timeline to create a decision brief on the consumer strategy measurement plan that gets signed off by all relevant stakeholders.
WE3.6.10	If we run an A/A test on retention rate for logged-in readers, we will establish a baseline for retention rate we can use for future quarters.
WE3.6.11	If we analyze existing data to see what user factors or actions correlate with retention, we can document our understanding of what product interventions/levers might increase retention.
WE3.6.12	If we experiment with measuring whether increasing the amount of translated Wikipedia content leads to a direct increase in pageviews, we will be able to make a recommendation on future strategic investment into translations.
WE3.7.2	If we roll out the new “heart” donate button design to all projects with a header donate link on desktop, based on the positive results of the previous clickthrough rate experiment, the total number of donations coming from that entry point will not decrease.
WE3.8.2	If we provide reading lists on web as an opt-in beta feature, as well as opt-in all new user accounts, at least 50% of users will rate the feature as useful when surveyed.
WE3.8.3	If we add a temporary 25th Birthday reading challenge widget on the apps that motivates users to meet a reading goal, we'll see a 5% higher conversion rate from casual (2-week return) to active (2-day returned) for users who joined the challenge in the first 14 days, compared to our baseline of 16.8%.
WE3.9.3	If we widely roll out the image browsing carousel and detail view on mobile web, then we will maintain CTR > 5% on the carousel.
WE3.9.4	If we test the addition of the “Which came first” daily-play trivia game to the iOS App, we’ll see 15% of engaged logged-out readers return to play the game on multiple days.
WE3.10.3	If we show readers several concepts for traversing the knowledge network on the wikis, we will come away with a prioritized list of concepts for further development.
WE3.10.5	If we give readers an enhanced sharing option then [33%] of readers who see the dialog will complete the enhanced share action without harming logged-out reader retention.
WE3.10.6	If we redesign the mobile apps Explore Feed, we'll see a 10% practically significant increase in Explore Feed engagement over multiple days per unique logged-out reader within 14 days of release.
WE3.10.7	If we identify the most frequent and important unmet needs for casual users (as rated by them) as well as which early-stage concept ideas are most desirable and useful, we will be able to prioritize which concepts to put into A/B testing in FY26-27 to give us the best shot at increasing retention.
WE3.10.8	If we test adding Page Previews on Minerva, we will see practically significant improvement to logged-out reader retention.
WE4.6.13	If we encourage users with an unconfirmed email address to confirm their email address, then 10% of active users who receive this notification will attempt to confirm their email address.
WE4.6.16	If we build support for enforcing group membership restrictions on global groups, we will be able to use this to enforce a 2FA requirement for global groups.
WE4.6.17	If we announce and enforce 2FA requirements for an additional set of groups, the number of users who have sensitive rights but don't have 2FA will drop to 0.
WE4.6.18	If we build support for enforcing 2FA on private wikis, we will be able to use this to secure user accounts who have access to private information.
WE4.6.19	If we require reauthentication for sensitive actions and implement other hardening measures, we will be less vulnerable to an attacker exploiting user scripts.
WE4.6.20	If we proactively scan user scripts for malicious code, we will be less vulnerable to an attacker exploiting user scripts.
WE4.6.21	If we reduce the number of staff accounts with advanced rights and how long they have those rights for, attacks targeting staff accounts are less likely to cause damage.
WE4.8.1	If we introduce a mechanism that detects and surfaces related temporary accounts, including a connected-accounts panel on Special:Contributions, then patrollers will identify abusive temporary-account activity faster and more accurately.
WE4.8.3	If we investigate recent complaints about patrolling taking longer than before, we would be able to determine whether or not they are correlated with the introduction of Temporary Accounts.
WE4.10.1	If we roll out hCaptcha to more wikis (Special:CreateAccount, wikitext editor on desktop) in stages, we will increase bot detection coverage across all projects.
WE4.10.2	If we deploy the hCaptcha bot detection in the visual editing, discussion tools, file upload wizard, and mobile editing pathways on pilot wikis, we will see an increase of 35% in the percentage of actions on Wikimedia Foundation wikis that were verified by hCaptcha.
WE4.10.3	If we deploy an hCaptcha risk score collection for blocked edit notices, we will better understand collateral damage impacts of IP range blocks.
WE4.11.1	If we roll out the Incident Reporting System (IRS) on enwiki through a staged deployment, starting small and scaling to at least 50% of logged-in users, then we will have enough data from our newly instrumented metrics to determine if IRS should be adopted on enwiki.
WE4.12.1	If we optimize and compare the performance of at least 2 content policy models with a community-vetted dataset of oversighted (WP:Oversight) content from English Wikipedia, we will be able to recommend a model or combination of models for automatic oversighting or flagging of content that very likely should be oversighted.
WE4.12.2	If we host the gpt-oss-safeguard-20b, CoPE-A-9B, and CoPE-b-12b models on LiftWing and optimize each model's performance to meet the PSI team's initial evaluation requirements, then the PSI team will be able to test the three models and compare their behavior.
WE5.1.3e	If we create a data product for analysis of API requests, we'll simplify analysis and segmentation of API requests, and allow Product Analytics to prototype the API Analytics Dashboard by further segmenting and aggregating this new data.
WE5.1.3f	If we reduce API rate limits for requests that only provide a User-Agent, we will increase the number of authenticated and known clients, by encouraging UA-only users to move to a more responsible pathway.
WE5.2.2c	If we reroute all APIs currently going through the API Gateway through the common gateway, we will be able to fully deprecate the historic API Gateway and ensure consistency for all community facing Wikimedia HTTP/web APIs
WE5.2.5b	If we finalize the linter architecture and a core set of linting rules, we can improve the quality of OpenAPI descriptions and start introducing programmatic guarantees of their compliance into CI workflows in API development processes.
WE5.2.8b	If we onboard at least 3 more API modules demonstrating a variety of use cases (at least 1 stand-alone service API, 1 feature team owned extension API, 1 internal module), we will be able to refine usability and set the foundation for the future of the API Platform.
WE5.2.11b	If we complete API Portal documentation migration, we will be able to fully deprecate the API Portal system, which will simplify API documentation discovery, increase documentation consistency, and reduce the number of API support systems.
WE5.2.12	If we iterate on the design and discovery work required for building the unified front-door for developers early, we will be able to effectively expedite engineering work in FY26-27.
WE5.2.13	If we begin enforcing existing user-agent policies on the dumps website, we can better understand dumps users and use cases while ensuring more consistent access expectations across developer pathways.
WE5.3.2b	If we establish a partner pilot program to experiment with Wikimedia attribution, we can show mutually beneficial impacts of attribution by reusers to drive engagement and contributions to Wikimedia.
WE5.3.3	If we provide content reusers with canonical, low-friction retrieval paths, we will lower the effort required to adopt trust signals from Wikimedia’s Attribution Framework, avoid the standardization of suboptimal retrieval paths, and unlock our ability to reliably measure attribution adoption.
WE5.3.3b	If we build a data pipeline to compute unique contributor counts and develop a method to serve it to MediaWiki, we will be able to surface contributor counts as a signal to Attribution API users.
WE5.3.3c	If we design and implement an API and event stream offering a naive, pageviews-based "relative trending" metric for pages, we will allow the Attribution API to use it as a Trust & Engagement metric and enable prototyping for the mobile apps.
WE5.3.4	If we define “qualified traffic” (specific outcomes of interest) and distinguish referrers by platform and surface, then we will observe systematic differences in downstream engagement and contribution outcomes that are relevant for product and partnership decisions.
WE5.3.4b	If we establish a consistent set of traffic health indicators, then we can reliably detect and explain meaningful shifts in Wikimedia’s incoming traffic over time and by referrer beyond raw pageview counts.
WE5.3.4c	If we analyze real-world visibility shocks as natural experiments, then we will see measurable changes in content quality and maintenance outcomes, supporting the relationship between visibility and content health.
WE5.4.2c	If we can identify the official Wikimedia mobile apps on iOS and Android in the CDN using their application-layer fingerprints, we can add them as a known-client in requestctl, allowing us to set exceptions and custom rate-limits on them to ensure a smooth user experience.
WE5.4.8b	If we rate limit requests for multimedia files based on a tally of response sizes, we will increase fairness in allocating the available bandwidth to users.
WE5.4.10	If we stop allowing generation of non-standard thumbnail sizes, it will reduce the strain on our backend media serving infrastructure.
WE5.4.12	If we create signals to distinguish on-site media traffic from external reuse, SRE can prioritize on-site traffic when under load by rate-limiting expensive media requests from external sources.
WE5.4.12b	If we can get the image provenance information from MediaWiki, we can use that in conjunction with other identifiers such as referrers and the assigned X-Is-Browser score to relax or vary the rate-limits for on-wiki users.
WE5.4.13	If we establish regular processing and reporting of WE5 objective indicator metrics (request rate, bandwidth, and User-Agent compliance), it will help us track progress across the KRs and assess the effectiveness of blocking high-volume scraping and enforcing the User-Agent policy.
WE5.4.14	If we make our WAF software less tied to our CDN infrastructure, it will be able to serve more use-cases, internal or not.
WE5.4.15	If we can identify and categorize known large-scale NATs containing wiki users, we can use this information to fine-tune ratelimits and other defenses more-strictly on a per-IP level to blunt some of the impact of scraping.
WE5.4.16	If we create a threat model for selected operators of automated traffic, including their intentions, level of investment and techniques employed, we will be able to advance the SRE teams’ ability to identify scrapers and other actors.
WE5.4.17	If we can do near-real time analysis on webrequest traffic to detect one kind of persistent scraping campaign, it will allow us to export rules from the data lake that we can push out to the edge automatically to block/throttle that scraping.
WE6.3.3	If we implement critical Language Variant support improvements and successfully deploy Parsoid to at least 3 Language Variant wikis in Q2, we will identify and resolve the key technical challenges necessary to confidently roll out to all remaining Language Variant wikis.
WE6.5.1	If we investigate and audit the performance concerns and catalog the content-caching fragility for logged-in users, informed by the Readers' strategy for readership retention, we can plan ST6.4 confidently with the right prioritisation framework by observing which cataloged concerns deliver the most value.
WE6.5.2	If we experiment with a platform for cross-wiki code collaboration, testing on at least 4 Indian communities, we will learn how to empower community developers to reuse modules across wikis, and receive positive feedback of these findings at the Hackathon the first week of May. This will be scoped to Lua Modules only, and integrated with WMF's GitLab infrastructure.
WE6.6.1	If we reduce the runtime of the Browser Test jobs to under 10 minutes, we will remove them as the bottleneck and reduce the feedback time of the MW Core Main test build.
WE6.6.2	If we reduce the runtime of the Unit Test jobs to under 10 minutes, we will remove them as the bottleneck and reduce the feedback time of the MW Core Main test build.

Signals & Data Services (SDS) Hypotheses [ SDS Key Results ] আলোচনা
Hypothesis shortname	Q4 text	Details & Discussion
SDS1.5.1	If we create a regular, operationalized internal audit process for bot classification outputs, we will build trust in our solutions and anticipate changes in traffic patterns that are not automatically detected.
SDS1.5.2	If we deploy a Test Kitchen instrument with 100% sampling and a request identifier, we'll be able to capture all requests regardless of whether or not they sent client-side events and analyze them for bot behavior.
SDS1.5.3	If we analyze the basic client-side signal and incorporate it into our heuristics, we will detect additional bot patterns in the Data Platform.
SDS1.5.4	If we move our heuristics to a private repository, we will protect the exact logic and data sources we use from motivated attackers.
SDS1.5.5	If we add a numerical score to our pageview metric based on 2 of the signals we’ve evaluated, we will provide a more complete and nuanced view of our traffic.
SDS1.5.6	If we use hCaptcha scores collected as events on account creation and edits as trusted labels, we’ll be able to correlate them to signals and our current bot detection heuristics to evaluate both.
SDS2.2.4	If Product Safety and Integrity reviews GrowthBook and FerretDB, we will be able to identify, then mitigate and/or address any material risks before production rollout.
SDS2.2.5	If we update Test Kitchen JS and PHP SDKs with methods to log experiment exposure, we will not need to treat all events as exposure events, which will improve performance of experiment assignment queries in GrowthBook and yield more accurate experiment results.
SDS2.2.8	If we conduct end-to-end user acceptance testing (UAT) with analyzing Reader Growth’s upcoming A/B/C test exclusively in GrowthBook, then we will learn which aspects of the experience meet production-readiness standards and which need improvement and supporting content before wider rollout.
SDS2.3.1	If we validate and adapt GrowthBook's API to our own, we can use GrowthBook as the canonical experiment control plane, and if we regularly poll GrowthBook's API, we can deliver experiments configured in GrowthBook quickly and easily.
SDS2.3.2	If we implement custom validation in GrowthBook, we’ll know people can’t accidentally misconfigure experiments in ways that violate the constraints of the platform.
SDS2.3.3	If we confirm role-based needs for GrowthBook users (humans, automation scripts from WMF, affiliates with established trust, and prospectively, vetted NDA end users), ensure automatic de-provisioning of stale users with regular report back to DPE, and update documentation to describe the role-based approach and user expectations regarding permissions and system interaction, user onboarding will be more predictable, and we'll have some additional guards to avoid exceeding our paid licensed seating.
SDS2.4.2	If we safely expand traffic enrolment through monitored stress testing, we will increase statistical power for Reader team experiments, shortening experiment timelines and improving decision confidence.
SDS2.4.3	If we introduce support for non-cache splitting experiments, then teams will be able to test JS-only features beyond the current traffic caps (10% all wikis, 0.1% enwiki), removing one of the primary barriers preventing teams from adopting Test Kitchen.

Product and Engineering Support (PES) Hypotheses [ PES Key Results ] আলোচনা
Hypothesis shortname	Q4 text	Details & Discussion
PES1.4.2	If we make Codex PHP easier to use and stable enough to do a 1.0 release, then teams will adopt Codex PHP for server-generated UIs. This will increase Codex PHP usage from 3 projects to 5.
PES1.5.3	If we enable SLO-based alerting, and make it possible to generate reports quarterly and automatically, service owners will be able to respond to service reliability data without (always) needing SRE to initiate.
PES1.5.4	If we set expectations with SRE Ambassadors about roles and responsibilities for SLOs and production readiness in FY26-27, onboard TPgMs and Objective owners to those expectations, and define how the SLO working group will operate, we will achieve buy-in and scalability for “business as usual” SLO and production readiness work starting in Q1.
PES1.6.2	If we onboard directors to the Service Catalog, they will populate it with "obvious" candidates, and we will identify and find owners for at least 2 more critical unowned services.

Future Audience (FA) Hypotheses [ FA Key Results ] আলোচনা
Hypothesis shortname	Q4 text	Details & Discussion
FA1.1.2	If we create and test 3 different app-based content discovery features as short experiments, we can share recommendations with the Apps team about how to effectively engage with and retain a new generation of apps users
FA1.1.6	If we create 3 different potential previews for Wikipedia links shared on Discord, we can align internally on our measurement and execution strategy and collaborate with Discord's ProdEng team.
FA2.2.1	If we invest in community management across short-video platforms, then by the end of Q2 (December 2025) we will see a 30% QoQ increase in the percentage of views from New Viewers on TikTok — and across all SFV platforms, we’ll earn 50,000 total engagements (likes and reply comments) on brand comments left on external content, which will help us increase visibility and drive engagement with audiences we’re not currently reaching.
FA2.2.2	If we develop and get sign-off on a Wikipedia Creator Partnerships Program internal strategy and external shareables (inclusive of an outline of our value to creators, partnership criteria, contracting process, and how creator content will show up across owned and creator channels), we will be able to establish a robust creator strategy that will help us reach new audiences across social media with our knowledge content.

একসাথে পরিকল্পনা করা

জানুয়ারি ২০২৫ হালনাগাদ।

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

২০২৫ সালের জুলাই থেকে ২০২৬ সালের জুন পর্যন্ত আমাদের পরবর্তী বার্ষিক পরিকল্পনার জন্য, আমরা ভাবছি বিশ্ব এবং ইন্টারনেটের দ্রুত পরিবর্তনের পরিপ্রেক্ষিতে কিভাবে আমরা বহু-প্রজন্মের দৃষ্টিভঙ্গি সর্বোত্তমভাবে পরিবেশন করতে পারি, এবং এটি কিভাবে আমাদের মুক্ত জ্ঞানের লক্ষ্যকে প্রভাবিত করে।

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

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

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

আমাদের প্রযুক্তিগত পরিবেশের সমস্যা ও সুযোগ এবং পরবর্তী বার্ষিক পরিকল্পনায় আমাদের কি দিকনির্দেশনা নির্ধারণ করা উচিত সে সম্পর্কে যদি আপনি ভাবতে চান, তাহলে অনুগ্রহ করে নিচের প্রশ্নগুলি নিয়ে আমাদের সঙ্গে আলোচনা করুন।

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

প্রশ্নসমূহ:

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

আলোচনা

–– Selena Deckelmann