Jump to content

برنامهٔ سالانهٔ بنیاد ویکی‌مدیا/۲۰۲۵-۲۰۲۶/اهداف و نتایج کلیدی (OKR) محصول و فناوری

Add links
From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Wikimedia Foundation Annual Plan/2025-2026/Product & Technology OKRs and the translation is 58% complete.
Outdated translations are marked like this.
Other languages:
برنامهٔ سالانهٔ بنیاد ویکی‌مدیا ۲۰۲۵–۲۰۲۶

سال پیش رو

حتی با تغییر جهان، بنیاد ویکی‌مدیا همچنان مصمم است که مأموریت خود—یعنی فراهم آوردن و حفظ اطلاعات مفید از پروژه‌های ویکی‌مدیا به‌صورت رایگان در اینترنت—را به‌عنوان تلاشی چندنسلی ادامه دهد: ما می‌خواهیم دانش آزاد برای نسل‌های بسیاری در آینده در دسترس باقی بماند.

اینترنت به سرعت در حال تغییر است. نسل‌های جدید اطلاعات خود را از طریق ویدیوهای اجتماعی و تجربه‌های هوش مصنوعی دریافت می‌کنند و در مقایسه با نسل‌های قدیمی‌تر، تعداد کمتری از آن‌ها از وجود ویکی‌پدیا آگاه هستند. کاهش‌های مرتبطی در تعداد افرادی که به سایت‌های ما مراجعه می‌کنند و تعداد ویرایشگران مشاهده می‌شود. در همین حال، پلتفرم‌های مختلف در سراسر اینترنت به محتوای ویکی‌مدیا برای پشتیبانی از خدمات هوش مصنوعی و جستجوی خود وابسته‌اند. این روندها چالش‌های بزرگی هستند، اما به‌وضوح نشان می‌دهند که چرا دانش آزاد قابل اعتماد که با همکاری هم تولید می‌کنیم این‌قدر اهمیت دارد. جهان بیش از هر زمان دیگری به منبعی از دانش معتبر و بررسی‌شده توسط انسان نیاز دارد و پروژه‌های ویکی‌مدیا همچنان نشان می‌دهند که می‌توانند این نیاز را برآورده کنند.

برای رویارویی با این چالش‌ها در سال آینده، مسیرهایی برای استفادهٔ پایدار از محتوای ویکی‌مدیا ایجاد خواهیم کرد و محتوای ویکی‌مدیا را به فضاهای اجتماعی آنلاین که نسل‌های جدیدتر وقت خود را در آنجا می‌گذرانند، خواهیم برد. سایت‌های خود را بهبود خواهیم داد تا خوانندگان بخواهند بازگردند، به‌طور عمیق تعامل کنند و به شیوه‌هایی که برای آن‌ها معنی‌دار است، مشارکت کنند. همچنین، در توانایی خود برای آزمایش سریع با فناوری‌های جدید سرمایه‌گذاری خواهیم کرد تا سرعت توسعهٔ ما با سرعت تغییرات جهان هماهنگ شود.

هدف زیرساخت، چگونگی پشتیبانی سکوی و تجربهٔ کاربری از مواجهه با این چالش‌ها و دسترسی به اکثریت مشارکت‌کنندگان در جنبش است. این یک فهرست پروژه‌ها نیست، بلکه مجموعه‌ای از جهت‌گیری‌ها برای تقویت رشد داوطلبان، توانمندسازی آن‌ها در ایجاد محتوای دایرةالمعارفی قابل اعتماد، تأمین مالی مأموریت ما و توسعهٔ خدماتمان به‌منظور شکل‌دهی به اینترنت در حال تغییر است. می‌توانید دربارهٔ آن چهار ستون راهبردی بیشتر بخوانید.

تقویت رشد داوطلبانه

جامعهٔ داوطلبان موتور منحصربه‌فرد موفقیت پروژه‌های ویکی‌مدیا است و ما نیاز داریم که این جامعه سالم و در حال رشد باقی بماند. اما در سال گذشته، کاهش مداومی در تعداد ویراستاران جدید و بازگشتی پروژه‌ها مشاهده کرده‌ایم. برای درک بهتر و پاسخ مؤثرتر به نیازهای داوطلبان فعلی، بنیاد فرایند فهرست آرزوهای جامعه را از یک نظرسنجی سالانه به فرآیند دریافت مداوم تبدیل کرده است، جایی که نیازهای کاربران و ایده‌های پروژه می‌توانند در کار چندین تیم بنیاد تأثیرگذار باشند. ما آرزوها را در «مناطق تمرکز» گروه‌بندی کرده‌ایم و سه مورد از این مناطق تمرکز را در نتایج کلیدی برنامه سالانه گنجانده‌ایم. همچنین یک طرح آزمایشی شورای مشورتی محصول و فناوری Product and Technology Advisory Council را آغاز کرده‌ایم تا گفتگوهای متعدد تیم‌های بنیاد با اعضای جامعه در داخل و خارج ویکی را تکمیل کند. علاوه بر این، فرصت‌هایی برای جذب نسل‌های جدید به پروژه‌هایمان شناسایی کرده‌ایم، مانند این واقعیت که جوان‌ترها مشتاقانه در فضاهای اجتماعی آنلاین دیگری شرکت می‌کنند که راه‌های ساده و سازگار با موبایل برای ارتباط در موضوعات مشترک فراهم می‌کند.

در سال آینده، رشد داوطلبان را با آسان‌تر و جذاب‌تر کردن مشارکت برای نسل‌های جدید از طریق گسترش رویکرد «اول موبایل»، راه‌های نوین ویرایش («وظایف ساختاریافته») و افزودن جریان‌های کاری هوشمندی که ویرایش سازنده در موبایل را برای مشارکت‌کنندگان تازه آسان می‌کند («بررسی‌های ویرایش») تقویت خواهیم کرد. برای درگیر کردن عمیق‌تر و حفظ داوطلبان فعلی، اقدامات و وظایف پیشنهادی ارائه داده و آن‌ها را در مرکزیتی قرار می‌دهیم که سازماندهی فعالیت‌های درون ویکی را ساده می‌کند. به‌طور هوشمندانه از هوش مصنوعی برای تقویت داوطلبان در کارشان استفاده می‌کنیم، همواره انسان‌ها را در فرایند حفظ کرده و شفافیت را در اولویت قرار می‌دهیم. برای هر دو گروه داوطلبان جدید و باتجربه، مسیرهایی برای ارتباط و همکاری در سایت‌هایمان ایجاد می‌کنیم – الهام‌گرفته از کمپین‌ها و پروژه‌های موفق ویکی – تا آن‌ها بتوانند ویراستاران همفکر را پیدا کرده و محتوای مرتبط با علایقشان را بهبود دهند (همسو با «این منطقهٔ تمرکز فهرست آرزوها»).

ارائهٔ محتوای معتبر دانشنامه‌ای

با افزایش مواد تولیدشده توسط هوش مصنوعی در اینترنت، جهان بیش از هر زمان دیگری به محتوای دایرةالمعارفی قابل اعتماد نیاز دارد. ما می‌خواهیم توانمندی‌های داوطلبان را برای ایجاد محتوای جدید، تضمین اعتمادپذیری محتوای موجود، و ارائهٔ محتوای قابل اعتماد به نسل جدیدی از خوانندگان با نیازها و ترجیحات نوین افزایش دهیم.

برای کمک به داوطلبان در ایجاد محتوای جدید، بر ابزارها و جریان‌های کاری راهنمای موجود (مانند ابزار ترجمه محتوا) تکیه خواهیم کرد تا جوامع بزرگ و کوچک بتوانند محتوای حیاتی را پوشش دهند. برای اطمینان از اینکه محتوای موجود قابل اعتماد باقی بماند، به داوطلبان باتجربه کمک می‌کنیم تا با گسترش ابزارهایی که برای یافتن وظایفی که نیاز به توجه آن‌ها دارد استفاده می‌کنند، بار کاری فزاینده خود را بهتر مدیریت کنند—و این کار به آن‌ها کمک می‌کند مقالات را آسان‌تر به‌روزرسانی کرده و ویرایش‌های نامناسب را بازگردانند (همسو با «این منطقهٔ تمرکز فهرست آرزوها»).

همچنین به مسئولان کمک خواهیم کرد تا با ارائهٔ سیگنال‌های جدید (فراتر از آدرس‌های آی‌پی) که بازیگران بد را شناسایی می‌کنند، از محتوای ما دفاع کنند و به کاربران اجازه دهیم به گونه‌ای مسدود شوند که حداقل مسدودسازی اشتباهی برای ویراستاران با حسن نیت رخ دهد.

برای ارائهٔ محتوای دانشنامه‌ای به نسل جدید، ویژگی‌هایی خواهیم ساخت که به خوانندگان جدید کمک کند مقالات را آسان‌تر بفهمند، اطلاعات مورد علاقه‌شان را بیابند و در حین مطالعه به‌طور فعال مشارکت کنند. این تغییرات با هدف تشویق خوانندگان جدید ویکی‌پدیا به تبدیل شدن به خوانندگان وفادار و برخی از آن‌ها به اهداکنندگان طراحی شده‌اند (همسو با «این منطقهٔ تمرکز فهرست آرزوها»).

ارائهٔ محتوای قابل اعتماد همچنین به معنای پشتیبانی از مدل «دانش به‌عنوان خدمت» است، که در آن کل اینترنت از محتوای ویکی‌مدیا بهره می‌برد. در این مدل، زیرساخت ما فقط منبع ارزشمندی برای انسان‌هایی که به وب‌سایت ما مراجعه می‌کنند نیست، بلکه برای شرکت‌های جستجو و هوش مصنوعی نیز هست که به‌صورت خودکار به محتوای ما دسترسی دارند و آن را به‌عنوان ورودی و خروجی بنیادی محصولات خود استفاده می‌کنند. این نوع شرکت‌ها تنها یکی از موارد استفادهٔ متعدد هستند که بار غیرقابل پایداری بر زیرساخت ما وارد می‌کنند. در سال گذشته، افزایش چشمگیری در حجم درخواست‌ها از ابزارهای اسکریپر و ربات‌ها مشاهده شده است که اصلاح این روند را برای ما فوری‌تر کرده است. ما نیاز داریم مسیرهای پایدار برای توسعه‌دهندگان و بازاستفاده‌کنندگان فراهم کنیم تا به محتوای دانش دسترسی داشته باشند و در این میان انسان‌ها در اولویت قرار گیرند.

تأمین مالی آیندهٔ «رایگان»

بخش محصول و فناوری نقش مهمی در تضمین پایداری جنبش ما دارد. در سال پیشِ رو، همکاری نزدیکی با تیم تأمین مالی خواهیم داشت تا اهداکنندگان تجربه‌ای هرچه شفاف‌تر و رضایت‌بخش‌تر داشته باشند. در سایت‌ها و برنامه‌های همراه، فرصت‌هایی برای خوانندگان فراهم خواهیم کرد تا از ویکی‌پدیا قدردانی کنند از طریق اهدای کمک مالی، و راه‌های تازه‌ای ایجاد خواهیم کرد تا اهداکنندگان احساس کنند که شناخته می‌شوند و به این ترتیب، حمایت خود را سال‌به‌سال ادامه دهند.

شکل‌دهی به اینترنتِ در حال تغییر

برای رساندن دانش آزاد به همهٔ مردم جهان، لازم است آن‌ها را در جایی که هستند ملاقات کنیم و تجربه‌هایی را ارائه دهیم که به یادگیری آن‌ها کمک کند. افراد ۱۸ تا ۲۴ ساله آگاهی و استفادهٔ کمتری از ویکی‌پدیا نسبت به نسل‌های پیشین دارند. این گروه عمدتاً از طریق پلتفرم‌های ویدیویی کوتاه، شخصیت‌های آنلاین مورداعتماد، تجربه‌های بازی اجتماعی و به‌طور فزاینده‌ای برنامه‌های آی‌پیادگیری می‌کنند و تعامل دارند. امسال، ویکی‌پدیا را برای این مخاطبان در فضاهایی که وقت خود را به‌صورت آنلاین می‌گذرانند، در دسترس قرار خواهیم داد تا ویکی‌پدیا را به‌عنوان منبعی برای دانش معتبر و انسانی بشناسند. حضور خود را در پلتفرم‌های ویدیویی محبوب گسترش خواهیم داد و محتوای ویکی‌پدیا را در این فضاها منتشر کرده و جامعه‌ای ایجاد خواهیم کرد. همچنین، ایده‌هایی برای آوردن دانش ویکی‌پدیا به پلتفرم‌های بازی و اجتماعی بررسی خواهیم کرد.

در بخش زیرساخت، این موضوع به سه سبد کاری تقسیم شده است: تجربه‌های ویکی، سرویس‌های سیگنال و داده، و مخاطبان آینده. این سبدها همانند سال گذشته و سال قبل‌تر هستند.

در مجموع، باور داریم که این برنامه لحظه‌ای حیاتی را در تاریخ اینترنت پاسخ می‌دهد و زمینه‌ای فراهم می‌کند تا محتوای دانش آزاد همچنان در دسترس همهٔ نسل‌ها باشد و به‌وسیلهٔ آن‌ها شکل بگیرد. اهداف و نتایج کلیدی ما ساختار و جزئیات این برنامه را به‌وضوح نشان می‌دهد و مشتاق شنیدن پرسش‌ها و ایده‌های جامعهٔ گسترده‌تر هستیم.

ساخت، بهبود و پایدارسازی زیرساخت برای پروژه‌ها و داوطلبان ویکی‌مدیا، مبتنی بر ارزش‌های ما

«بنیاد، اطلاعات مفید پروژه‌های خود را به‌صورت رایگان و برای همیشه در اینترنت در دسترس قرار خواهد داد و نگه می‌دارد.»

تیم‌های محصول و فناوری اولویت دائمی و سالانه‌ای را به ساخت، بهبود و نگهداری زیرساختی اختصاص می‌دهند که به پروژه‌های ویکی‌مدیا خدمت می‌کند. ما در میزبانی پروژه‌های ویکی‌مدیا، توسعه نرم‌افزار متن‌باز و سیستم‌های طراحی، و نگهداری و بهبود زیرساخت محصولات داده و مدل‌های هوش مصنوعی سرمایه‌گذاری می‌کنیم.

بخشی از کارهای اساسی ما بر مبانی توسعه و میزبانی یک وب‌سایت بزرگ و محبوب متمرکز است. ما پروژه‌های ویکی‌مدیا را در مرکز داده‌هایی میزبانی می‌کنیم که سرورها و سخت‌افزارهای آن را خریداری، نصب و نگهداری می‌کنیم، و این مراکز به هم و به اینترنت از طریق شبکه‌ای پرسرعت متصل هستند. ما نظارت می‌کنیم و در صورت نیاز ظرفیت را افزایش می‌دهیم و تجهیزات را زمانی که قدیمی می‌شوند تعویض می‌کنیم. برای مثال، امسال پیش‌بینی می‌کنیم ظرفیت خود را افزایش داده و سخت‌افزارهای مراکز داده‌مان در اشبرن، ویرجینیا و کارولتون، تگزاس را به‌روزرسانی کنیم.

ما نرم‌افزارهای متن‌باز طراحی و توسعه می‌دهیم (مهم‌ترین آن‌ها مدیاویکی است). همچنین از بسیاری از برنامه‌ها، کتابخانه‌ها و چارچوب‌های متن‌باز شخص ثالث موجود استفاده و آن‌ها را مستقر می‌کنیم. باگ‌های مهم در نرم‌افزار ما اولویت‌بندی شده و رفع می‌شوند. نگهداری نرم‌افزار متن‌باز نیازمند کار تخصصی افراد ماهر با دانش ویژه در توسعه نرم‌افزار متن‌باز، مهندسی قابلیت اطمینان سایت (SRE)، مدیریت محصول، مدیریت برنامه، طراحی و موارد دیگر است. کارکنان ما تلاش می‌کنند تا نرم‌افزارها و سیستم‌های ما به‌روز باشند و با محیطی همیشه در حال تغییر سازگار شوند. این شامل نوسازی کد برای بهره‌مندی مستمر از رفع اشکالات امنیتی و همکاری بهتر با نرم‌افزارهای جدید شخص ثالث است. برای مثال، مدیاویکی به زبان PHP نوشته شده است و در سال گذشته، ما از نسخه ۷.۴ به ۸.۱ مهاجرت کردیم که نیازمند تغییراتی در کد و زیرساخت میزبانی سایت‌ها و خدمات ما بود. امسال، بر اساس آن تلاش، به سمت نسخه ۸.۳ مهاجرت خواهیم کرد و از درس‌های آموخته‌شده و ابزارهای توسعه‌یافته در ارتقای ۸.۱ استفاده خواهیم کرد. این به‌روزرسانی سیستم‌های ما را برای خوانندگان سریع‌تر، برای کارکنان و داوطلبان آسان‌تر و برای همه امن‌تر خواهد کرد. همچنین به‌خاطر بهبودهای امنیتی، عملکردی و پشتیبانی ناشی از به‌روزرسانی زبان، زمان توسعهٔ آینده را صرفه‌جویی خواهد کرد.

برای اطمینان از اینکه پروژه‌ها و محتوای ما هم امروز و هم برای همیشه در اینترنت در دسترس باقی بمانند، تیم‌های ما تلاش قابل توجهی برای تضمین دسترسی بالا به سایت‌ها و خدمات ما انجام می‌دهند. یکی از جنبه‌های این کار بر بازیابی پس از بلایا ناشی از رویدادهای فاجعه‌بار یا مخرب متمرکز است. برای مثال، ما اطمینان حاصل می‌کنیم که نسخه‌های پشتیبان از داده‌های مهم داریم و قادر به بازیابی آن‌ها هستیم. همچنین، دو بار در سال توانایی خود را در جابجایی خودکار سایت‌ها بین مراکز داده‌مان آزمایش می‌کنیم و هر مشکلی که پیدا کنیم رفع می‌کنیم. جنبهٔ دیگری از این کار به شناسایی و سازگاری با روندهای در حال تغییر در نوع و حجم ترافیکی که دریافت می‌کنیم اختصاص دارد. برای مثال، با رشد بی‌سابقهٔ ابزارهای اسکریپ خودکار، اولویت را به کاری داده‌ایم که اطمینان حاصل کنیم سایت‌ها و خدمات ما برای کاربران انسانی قابل دسترسی باقی بمانند و رویکردی سیستماتیک برای ایجاد هنجارهایی دربارهٔ استفاده مسئولانه از زیرساخت‌های ما اتخاذ کنیم.

تمام کارها از قبل برنامه‌ریزی نشده‌اند. ما همچنین به رویدادها و حوادث ناگهانی و پیش‌بینی‌نشده مانند قطعی‌های سایت، گزارش‌ها یا رخدادهای امنیتی، یا حملات تخریب گسترده به پروژه‌هایمان پاسخ می‌دهیم. عملکرد و موانع دسترسی‌پذیری خود را در سراسر جهان (شامل مشکلات اتصال اینترنت یا مسدودسازی‌های سانسور) رصد می‌کنیم و هر گونه ناهنجاری را بررسی می‌کنیم. برخی از این رویدادهای غیرمنتظره یا الگوهای تکرارشونده مشکلات باعث می‌شوند کارکنان پروژه‌های پیگیری کوتاه‌مدتی را در اولویت قرار دهند که هدف آن‌ها کاهش یا جلوگیری کامل از تأثیرات منفی بیشتر است. برای مثال، این تلاش‌ها نقش حیاتی در توانمندسازی پروژه‌های ویکی‌مدیا برای مقاومت در برابر افزایش ناگهانی ترافیک جهانی ناشی از رویدادهای خبری مهم (مانند مرگ‌های مشهور) داشتند، که با ترکیبی از بهینه‌سازی عملکرد، بازطراحی معماری نقاط گلوگاهی و افزایش ظرفیت انجام شد. به‌طور مشابه، بهبودهای اخیر در قابلیت استفاده از ابزارها و سیستم‌های مدیریت ترافیک دریافتی، امکان واکنش سریع‌تر و مؤثرتر به شرایط متغیر را برای ما فراهم کرده است. این نوع کار تطبیقی جزئی جدایی‌ناپذیر از توانایی ما برای پاسخگویی به رویدادهای نوظهور، اغلب در زمان‌های کوتاه، و تضمین در دسترس بودن پروژه‌ها و محتوای ما است.

اهداف محصول و فناوری

هدف‌های ارائه‌شده در اینجا به‌صورت پیش‌نویس ارائه شده‌اند و برای دریافت نظرات و بحث باز هستند.

  • هدف‌ها جهت‌گیری سطح بالایی را نمایان می‌کنند.
  • نتایج کلیدی (KRها) روش قابل اندازه‌گیری برای پیگیری موفقیت هدف‌ها را نمایان می‌کنند.
  • فرضیات پایه‌ای برای هر نتیجهٔ کلیدی نمایانگر کار واقعی است که برای دستیابی به نتایج کلیدی مرتبط انجام می‌دهیم. این فرضیات در این سند و صفحات ویکی پروژه یا تیم مربوطه به‌روزرسانی خواهند شد، زیرا در طول سال دیدگاه‌هایی به‌دست می‌آید.
  • wishlist item برای کارهایی است که بنیاد تحت فهرست آرزوهای جامعه اولویت‌بندی کرده است.

تجربیات ویکی (WE)

تجربیات مشارکت‌کنندگان (WE1)

  • هدف: مشارکت‌ها افزایش می‌یابند زیرا به داوطلبان فرصت‌های جذابی ارائه می‌شود و تأثیر آن‌ها را درک می‌کنند. بحث
    • زمینه: این هدف، پایه‌گذار اجرای استراتژی جدید مشارکت‌کنندگان خواهد بود که شامل ۳ رکن است: ۱) ارائه یک روش متمرکز به داوطلبان برای سازماندهی فعالیت‌های خود در ویکی، ۲) فراهم کردن وظایف کوچک و مجزا برای ایجاد وضوح بیشتر و کمک به داوطلبان برای دستیابی به پتانسیل خود، و ۳) معنادارتر کردن مشارکت. در سال مالی ۲۵/۲۶، برنامه داریم زیرساخت‌های پایه‌ای را برای کمک به داوطلبان جهت سازماندهی فعالیت‌های خود در ویکی به روش متمرکز، با تمرکز خاص بر ویرایشگران و مدیران با تجربه، فراهم کنیم. در سال‌های بعدی، مداخلات بیشتری برای تمام نقش‌های مشارکت‌کننده و فضاهای مشکل دیگر اضافه خواهیم کرد. علاوه بر این، به سرمایه‌گذاری در ابزارهای «ویرایش بررسی» و «وظایف ساختاری» ادامه خواهیم داد و پایه‌گذاری نحوه استفاده از هوش مصنوعی به طور مقیاس‌پذیر، هم به عنوان راهنمایی در فرایند ویرایش و هم به عنوان روشی برای هدایت داوطلبان به فرصت‌های جذاب، خواهیم ساخت. و در نهایت، به سرمایه‌گذاری در ایجاد شفافیت بیشتر از تأثیرات داوطلبان خواهیم پرداخت تا تجربه‌ای معنادارتر برای آن‌ها ایجاد کنیم.
      • آیتم فهرست آرزوها نتیجهٔ کلیدی WE1.1: افزایش نرخ ویرایشگران با حداکثر ۱۰۰ ویرایش تجمعی که ویرایش‌های سازنده در نسخهٔ وب موبایل [i] منتشر می‌کنند، به میزان ۴٪ [ii]، طبق آزمایش‌های کنترل‌شده (تا پایان فصل دوم).
        • i. «ویرایش‌های سازنده» = ویرایش‌هایی در هر صفحه از فضای نام اصلی ویکی‌پدیا که تا ۴۸ ساعت پس از انتشار واگردانده نشوند.
        • ii. T389403#10960480
        • داوطلبان جدیدتر در شروع ویرایش موفق با چالش‌هایی مواجه می‌شوند. به ویژه افرادی که از دستگاه‌های موبایل استفاده می‌کنند، جایی که فضای صفحه محدود است و توجه معمولاً پراکنده است.
        • برخی از داوطلبان از زمینه، صبر و خطاهای لازم برای مشارکت سازنده خسته می‌شوند. دیگران هنوز با فرصتی جذاب برای تلاش مواجه نشده‌اند.
        • نتیجهٔ کلیدی WE1.1 این مسائل را از طریق موارد زیر حل خواهد کرد:
          • ارائهٔ پیشنهادهای ویرایش
          • ارائهٔ راهنمایی‌های قابل اجرا در حین ویرایش
          • ساخت گردش‌کارهای ویرایش خاص‌تر برای وظایف
        • در مرکز این تلاش‌ها، نیاز به روش‌هایی مقیاس‌پذیر برای شناسایی راه‌های بهبود ویرایش‌های در حال انجام و محتوای موجود قرار دارد. برای گسترش این توانایی، به آزمایش با یادگیری ماشینی ادامه خواهیم داد تا دریابیم چگونه می‌تواند به بهترین شکل در خدمت ویرایشگران، در سطوح مختلف نقش و تجربه، قرار گیرد.
        • روش پیشنهادی ارزیابی نتیجهٔ کلیدی (KR): بر پایهٔ هر پلتفرم، نسبت اقدام‌هایی را محاسبه خواهیم کرد که از طریق آزمایش‌های کنترل‌شده اجرا و ارزیابی شده‌اند و به هدف ویرایش سازنده‌ای که در آغاز سال تعیین کرده‌ایم، دست یافته یا از آن فراتر رفته‌اند. برای توضیحات بیشتر به phab:T379285#10782051 مراجعه کنید.
          • توجه: تا تاریخ ۳۰ ژوئن ۲۰۲۵، برای WE 1.1 دو آزمایش کنترل‌شده برنامه‌ریزی شده است.
      • آیتم فهرست آرزوها نتیجهٔ کلیدی WE1.2: افزایش تعداد همکاری‌ها در ویکی‌ها به میزان ۵۵٪ نسبت به سال گذشته تا پایان فصل چهارم.
        • مشارکت‌کنندگان اغلب در پیدا کردن فرصت‌هایی برای همکاری با یکدیگر، به‌ویژه در مورد موضوعات و وظایفی که برایشان مهم است، با مشکل مواجه می‌شوند. این موضوع می‌تواند برای تازه‌واردان حس تنها بودن در ویکی‌ها را ایجاد کند و برای ویرایشگران با تجربه منجر به خستگی و فرسودگی شود. علاوه بر این، تأثیر فعالیت‌های همکاری‌جویانه اغلب نامشخص است که می‌تواند باعث کاهش تمایل افراد به پیوستن، سازمان‌دهی یا حمایت از همکاری‌ها در ویکی‌ها شود.
        • ما می‌خواهیم ارزش همکاری را با انجام موارد زیر واضح‌تر کنیم:
        1. ایجاد روش‌های جدید برای به اشتراک گذاشتن تأثیر فعالیت‌های همکاری در ویکی‌ها
        2. شروع جمع‌آوری داده‌های گسترده از جنبش در مورد تأثیر فعالیت‌های همکاری
        3. ایجاد زیرساخت‌های پایه برای پیگیری مشارکت‌های همکاری، تا بتوانیم راه‌های نوآورانه‌ای برای شناسایی و پاداش دادن به مشارکت‌ها در آینده ارائه دهیم
        • همکاری‌ها از طریق فعالیت‌های جدیدی که از طریق ثبت‌نام رویدادها در افزونهٔ CampaignEvents ایجاد می‌شوند، اندازه‌گیری خواهند شد. هدف این است که تا پایان این نتیجه کلیدی، کاربران بیشتری از ابزارهای افزونه استفاده کنند و روش‌های جدیدی برای نمایش تأثیر همکاری‌ها ارائه شود. این امر ما را در موقعیت مناسبی قرار می‌دهد تا زیرساخت‌های موجود خود را به روش‌های دیگر برای شناسایی و پاداش دادن به کار در ویکی‌ها (مانند ماژول تأثیر، تشکرها و غیره) متصل کنیم.
        • منطقهٔ تمرکز فهرست آرزوها: Community Wishlist/Focus areas/Connecting Contributors
      • آیتم فهرست آرزوها نتیجهٔ کلیدی WE1.3: تا پایان فصل سوم، ۱۰٪ از مشارکت‌کنندگانی که صفحهٔ آغازی ویژهٔ مدیران تازه‌کار به آن‌ها نمایش داده شد، دو هفتهٔ پیاپی از آن بازدید کردند.
        • بر این باوریم که می‌توانیم فرصت‌های مشارکت را برای داوطلبان بهتر نمایان کنیم. در بلندمدت، معتقدیم صفحهٔ آغاز می‌تواند برای هر ویرایشگری در سامان‌دهی کارها، یافتن فرصت‌های تازه و درک تأثیر فعالیت‌هایش سودمند باشد. هدف ما در سال مالی ۲۵/۲۶ این است که فرصت‌های تازه‌ای را پیش روی ویرایشگران باتجربه بگذاریم تا وظایف مدیریتی‌ای را بر عهده گیرند که در حالت عادی لزوماً با آن‌ها روبه‌رو نمی‌شدند.
        • ما ابتدا این فرضیه را با بررسی میزان تعامل ویرایشگران باتجربه با صفحهٔ آغازی مشابه آنچه تازه‌واردان به آن دسترسی دارند، مورد آزمون قرار خواهیم داد.
        • سپس فعالیت‌های مدیریتی مشخصی (جزئیات آن بعداً تعیین خواهد شد) را به مشارکت‌کنندگانی نمایش خواهیم داد که در آن نوع از اقدام مدیریتی تازه‌کار هستند، با این هدف که از طریق کاهش حجم کارهای معوق، فشار را از دوش ویرایشگران باتجربه کم کنیم (در چارچوب یک نتیجهٔ کلیدی جدید).
        • اگر مفهوم صفحهٔ آغاز موفقیت‌آمیز باشد، برنامه داریم این صفحه را به‌صورت ماژولار طراحی کنیم تا با نیازهای جامعه‌ها سازگار شود. این ماژول‌ها می‌توانند شامل امکاناتی باشند که درک تأثیر فعالیت‌ها را برای ویرایشگران آسان‌تر می‌سازد.
        • نکته‌هایی دربارهٔ روش‌شناسی:
        • فرضیه‌ای برای تعیین جامعهٔ هدف خود خواهیم داشت که بخشی از WE1.3.1 خواهد بود.
        • «مدیران» طبق تعریفی که در Research:Develop a working definition for moderation activity and moderators آغاز شده دنبال خواهند شد، هرچند برای دقیق‌تر کردن تعریف کمی، نیاز به کار تکمیلی خواهد بود.
        • هفتهٔ دوم بر اساس زمان اولین بازدید هر کاربر تعریف خواهد شد. در این حالت، همهٔ مدیران تازه‌ای را بررسی خواهیم کرد که در یک بازهٔ زمانی مشخص از صفحهٔ آغاز بازدید کرده‌اند و سپس بین ۷ تا ۱۴ روز بعد دست‌کم یک بازدید تکراری دیگر انجام داده‌اند.
        • حوزهٔ تمرکز فهرست آرزوها: Community Wishlist/Focus areas/Task prioritization
      • آیتم فهرست آرزوها نتیجهٔ کلیدی WE1.4: بهبود درصد بازدیدکنندگان یکتای فهرست پی‌گیری و/یا تغییرات اخیر که روی یک ویرایش برای مشاهده کلیک می‌کنند.
        • هدف ما این است که به ویرایشگرانی با بیش از ۱۰۰ ویرایش کمک کنیم تا ویرایش‌های مرتبط با علایق خود را کارآمدتر بیابند و باز کنند. ما حوزهٔ تمرکز اولویت‌بندی وظایف را بررسی خواهیم کرد، درخواست‌های مرتبط با این حوزه را برآورده می‌کنیم و بازخوردهای بیشتری از داوطلبان دربارهٔ بهبود این بخش‌ها دریافت خواهیم کرد. معیار سنجش موفقیت ما، بهبود کارایی هر صفحه در «یافتن کار» خواهد بود که با شاخص نرخ کلیک (click-through rate) اندازه‌گیری می‌شود.
      • نتیجهٔ کلیدی WE1.5: تعریف و اجرایی‌سازی هفت شاخص با اولویت بالا [1] برای پایش میزان پیشرفت در دستیابی به اهداف تعیین‌شده در راهبرد مشارکت‌کنندگان تا پایان فصل چهارم، از طریق ایجاد یک داشبورد و عملیاتی‌سازی شاخص‌های مدیران فعال ماهانه.
        [1] ویرایشگران حفظ‌شده، فعال‌سازی سازنده، ویرایش‌های سازنده، ثبت حساب‌های کاربری، تازه‌واردان حفظ‌شده، ویرایشگران فعال بر پایهٔ سابقهٔ فعالیت، و ویرایشگران فعال بر پایهٔ سطح تجربه.
        • راهبرد تجربهٔ مشارکت‌کنندگان چشم‌اندازی سه تا پنج‌ساله را ترسیم می‌کند برای «تقویت رشد داوطلبان» و «افزایش نگهداشت و فعال‌سازی» مشارکت‌کنندگان تازه و کنونی از طریق سه حوزهٔ اصلی فعالیت:
        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.

دانش حیاتی (WE2)

  • هدف: فراهم کردن دسترسی به دانش حیاتی بیشتر و به‌خوبی تصویرسازی‌شده در زبان‌ها و موضوعات مختلف. بحث
    • متن هدف: این هدف به رشد محتواهایی که هم‌راستا با علاقه‌مندی‌های مشارکت‌کنندگان در موضوعات و زبان‌های خاص و هم‌چنین نیاز خوانندگان به دانش حیاتی که به‌خوبی تصویرسازی شده باشد، خواهد انجامید. دانش حیاتی مجموعه‌ای از مقالات است که گستره و عمق موضوعاتی را ارائه می‌دهد که برای یک پروژه زبان ویکی‌پدیا قابل استفاده ضروری است. این دانش توسط جوامع با ارجاع به اهمیت، ارتباط، پیش‌بینی تعداد خوانندگان، و پیوندهای بین مقالات تعریف می‌شود.
    • ما رویکردی اجتماعی-فنی خواهیم داشت تا اثربخشی ویژگی‌ها، ابزارها و فرآیندهای اجتماعی را بهبود بخشیم. ما بر روی ویژگی‌های پر تأثیر محصول مانند وظایف پیشنهادی، جستجوی رسانه‌ها و ترجمه محتوا ساختار خواهیم ساخت و در عین حال فرایندهای شروع به کار و توسعه ویکی‌پدیای زبان‌های کوچک‌تر را تسهیل خواهیم کرد. ما از سازمان‌دهندگان ویکی‌مدیا که مشارکت‌کنندگان را جذب، آموزش و حمایت می‌کنند تا بر روی اهداف محتوای مشترک در قالب‌های همکاری مانند پروژه‌های ویکی و کمپین‌ها کار کنند، پشتیبانی خواهیم کرد. (ما تخمین می‌زنیم که حداقل ۳۰۰ سازمان‌دهنده در هر سه‌ماهه فعال هستند.) همچنین روابط خود را با ناشران مرتبط‌ترین برقرار خواهیم کرد تا موانع منابع اطلاعاتی را از بین ببریم. (در حال حاضر با بیش از ۱۰۰ پایگاه داده اشتراکی برتر جهانی شراکت داریم.)
    • برای اطمینان از اینکه مداخلات ما تأثیر مثبتی بر دانش حیاتی دارند، هم افزایش محتوای اولویت‌دار از سوی جامعه و هم کیفیت آن محتوا را اندازه‌گیری خواهیم کرد. ما عواملی مانند نرخ‌های بازگشت و تعداد ارجاعات و تصاویر را مورد بررسی قرار خواهیم داد.
      • نتیجه کلیدی WE2.1: تا پایان سه‌ماههٔ دوم (Q2)، سه مداخله را آزمایش و ارزیابی کنید که به مشارکت‌کنندگان کمک می‌کند وضعیت محتوای حیاتی در ویکی‌پدیاهای خود را بهبود بخشند.
        • این نتیجهٔ کلیدی شکاف‌های محتوایی را در مکانیسم‌های ویرایش برجسته خواهد کرد، مانند کشف تصاویر در ویکی‌پدیا، ترجمه محتوا و ایجاد هدایت‌شدهٔ مقالات جدید. همچنین یک مداخلهٔ اجتماعی-فنی برای پشتیبانی از فعالیت‌های ایجاد محتوا در جوامع زبانی کوچک پیاده‌سازی و آزمایش خواهیم کرد. موفقیت در هر فرضیه اندازه‌گیری خواهد شد.
      • نتیجهٔ کلیدی WE2.2: تا پایان فصل چهارم، ایجاد توانمندی‌های پلتفرمی لازم برای تأیید این‌که می‌توانیم از چشم‌انداز ویکی‌پدیای انتزاعی در مقیاس گسترده پشتیبانی کنیم. معیار موفقیت ما این است که سامانه بتواند محتوای دایرةالمعارفیِ غنی و چندزبانه را با استفاده از ویکی‌داده و تولید زبان طبیعی ارائه دهد، توسط جامعهٔ ویکی‌مدیا کنترل شود، و در گسترش‌های وسیع عملکرد مطلوب خود را حفظ کند.
        • اکنون که می‌توانیم از ویکی‌داده برای تولید محتوای ساده و متنی در ویکی‌پدیاها استفاده کنیم، گام بعدی ادامهٔ توسعهٔ توانمندی‌های پلتفرمی است که بتواند از ویکی‌پدیای انتزاعی در مقیاس گسترده پشتیبانی کند. این پلتفرم باید توانایی پشتیبانی از محتوای غنی و چندزبانه‌ای را داشته باشد که جامعه بتواند آن را کنترل کند و در مقیاس بزرگ نیز عملکرد خود را حفظ نماید. این نتیجهٔ کلیدی نقطهٔ عطفی است، زیرا ما از مرحلهٔ صفر به مرحلهٔ نخست گذار می‌کنیم.
      • نتیجهٔ کلیدی WE2.3: تا پایان فصل چهارم، نسخه‌ای اولیه از ویکی جدید را برای آغاز ایجاد مقاله‌های انتزاعی توسط جامعه عرضه کنیم.
        • این نتیجهٔ کلیدی زمینه را برای آزمودن توانمندی‌های پلتفرم ویکیِ انتزاعی در سال آینده فراهم می‌کند. ویکی جدید و مستقل، میزبان کتابخانه‌ای از مقاله‌های انتزاعی مبتنی بر ویکی‌فانکشنز خواهد بود و توانایی‌های پلتفرمی لازم را برای ادغام آیندهٔ مقاله‌های انتزاعی در ویکی‌پدیا فراهم می‌سازد.
      • نتیجهٔ کلیدی WE2.4: تا پایان فصل دوم، هم‌سوسازی بنیاد ویکی‌مدیا (WMF) و ویکی‌مدیای آلمان (WMDE) در تعریف موفقیت برای بهبود زیرساخت فنی پشتیبان یکی از موارد استفادهٔ حیاتی ویکی‌داده، از جمله تعیین شاخص‌ها و اهداف تا سال مالی ۲۵–۲۶.
        • تیم پلتفرم ویکی‌دادهٔ بنیاد ویکی‌مدیا در اوت ۲۰۲۵ تشکیل و با یک مدیر محصول و یک سرپرست فنی تکمیل شد. به‌عنوان افزوده‌ای تازه به برنامه‌ای که طی سال‌ها توسط مالکان فنی و محصول در بنیاد ویکی‌مدیا و ویکی‌مدیای آلمان توسعه یافته است، این هدف بیانگر قصد ما برای انتقال مسئولیت از طریق هم‌سویی در موارد استفاده، وابستگی‌ها و معیارهای کلیدی موفقیت است. این نتیجهٔ کلیدی بنیان درک متقابل از فضای مسئله را فراهم خواهد کرد که در ادامهٔ سال مالی (مهٔ ۲۰۲۶) بر پایهٔ آن کار خواهیم کرد.
      • 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.

تجربیات مصرف‌کننده (WE3)

  • هدف: خوانندگان از نسل‌های مختلف با ویکی‌پدیا تعامل می‌کنند و در آن باقی می‌مانند که منجر به افزایش قابل اندازه‌گیری در حفظ کاربران و فعالیت‌های اهدایی می‌شود. بحث
    • متن هدف: این هدف بر حفظ خوانندگان جدید از طریق فرمت‌های نوآورانه محتوا، تقویت تجربه‌های آشنا برای مخاطبان اصلی، و تضمین پایداری بلندمدت با عمیق‌تر کردن ارتباطات خوانندگان و تنوع‌بخشی به اهدای کمک‌ها متمرکز خواهد بود. این شامل ادامه کار ما در زمینه آسان‌تر کردن کشف محتوا از طریق ویژگی‌های جدید و تجربی مانند خلاصه‌های هوش مصنوعی یا دالان‌های شخصی‌سازی شده خواهد بود. همچنین شامل کار بر حفظ و بهبود کیفیت تجربه خواندن در مراحل بعدی فرآیند خواندن و اکتشاف دسته‌بندی مطالب از طریق فهرست‌های خواندن و سایر مشارکت‌های غیر ویرایشی خواهد بود. برای اهداکنندگان، این کار به تنوع‌بخشی منابع درآمدی از داخل پلتفرم ادامه خواهد یافت.
      • آیتم فهرست آرزوها نتیجهٔ کلیدی WE3.1: تا پایان سه‌ماههٔ دوم، افزایش معنادار و قابل‌توجهی در حفظ خوانندگان بدون ورود از طریق آزمون A/B یک قابلیت در هر پلتفرم نشان داده شود.
        • این نتیجهٔ کلیدی بر ادامهٔ سرمایه‌گذاری در تجربیاتی متمرکز خواهد بود که روش‌های جدید مرور و یادگیری محتوا را بهینه‌سازی می‌کنند، اغلب از طریق استفاده از تکنولوژی‌ها و فرمت‌های جدید - ارائه محتواهای موجود به شیوه‌های جدید و جذاب. در این سال مالی، ما می‌خواهیم به آزمایش ویژگی‌های جدید ادامه دهیم و در عین حال بر مقیاس‌سازی آزمایش‌های موفق across ویکی‌ها و پلتفرم‌ها تمرکز کنیم. کار در این نتیجه کلیدی در وب‌سایت موبایل و دسکتاپ، همچنین اپلیکیشن‌های iOS و Android خواهد بود و بر کشف محتوا (نقاط ورودی مرور و پیشنهادات) و فرمت‌های یادگیری تطبیقی (خلاصه‌های با کمک ماشین، ویرایش مجدد محتوا) تمرکز دارد.
        • اولویت فهرست خواسته‌ها: تجربیات جدید مصرف‌کننده
      • نتیجهٔ کلیدی WE3.2: تا پایان سه‌ماههٔ دوم (Q2)، با استفاده از مداخلات محصول که ارتباط عمیق‌تر با اهداکنندگان ایجاد کرده و موانع را کاهش می‌دهند، تعداد کمک‌های مالی از طریق روش‌های غیر از بنر یا ایمیل را در هر پلتفرم به‌صورت سالانه ۵٪ افزایش دهید.
        • این نتیجهٔ کلیدی به ما اجازه می‌دهد تا به کاوش در نقاط ورودی جدید برای کمک‌های مالی و سایر فرصت‌ها برای تبدیل خوانندگان به اهداکنندگان و نگه‌داشتن آن‌ها از طریق عمیق‌تر کردن ارتباطاتشان با ویکی‌ها، از جمله محتوای شخصی‌سازی‌شده، ادامه دهیم. این نتیجهٔ کلیدی بر معرفی نقاط ورودی جدید و اصلاح نقاط ورودی موجود در اپلیکیشن‌ها و وب‌سایت تمرکز خواهد داشت، در همکاری با تیم جمع‌آوری کمک‌های مالی.
      • نتیجهٔ کلیدی WE3.3: تا پایان سه‌ماههٔ دوم، افزایش معنادار و قابل‌توجهی در حفظ خوانندگان واردشده از طریق آزمون A/B یک قابلیت در هر پلتفرم نشان داده شود.
        • این نتیجهٔ کلیدی بر بهبود تجربهٔ خواندن و یادگیری برای خوانندگان فعلی و با تجربه تمرکز خواهد داشت، با هدف نگه‌داشتن مخاطبان فعلی و عمیق‌تر کردن ارتباط آن‌ها با سایت تا بتوانند بیشتر بیاموزند و همچنین آماده و مشتاق باشند تا به مسیرهای اهدا و ویرایش هدایت شوند. کار در این زمینه بر بهبود تجربهٔ خواندن در وب‌سایت و اپلیکیشن‌ها (بهبود خوانایی، ناوبری و کشف بهتر) تمرکز خواهد داشت، همچنین بر روی ساخت و آزمایش ویژگی‌های انتخاب و شخصی‌سازی (فهرست‌های خواندن، پیشنهادات شخصی‌سازی‌شده، تاریخچهٔ کاربر و مقاله‌ها و غیره) نیز تمرکز خواهد شد.
      • نتیجهٔ کلیدی WE3.4: تا پایان فصل چهارم، حذف همهٔ موانع شناسایی‌شده برای استقرار مراکز ذخیره‌سازی کوچک‌مقیاس (PoPs) که با استانداردهای کنونی ما در زمینهٔ کیفیت خدمات و امنیت، مطابق با استقرارهای فعلی مراکز ذخیره‌سازی، هم‌خوانی دارند.
        • این نتیجهٔ کلیدی بر اثبات این مفهوم متمرکز خواهد بود که می‌توانیم عملکرد وب‌سایت را بهبود بخشیم و تأخیر را برای خوانندگان خود با ساده‌سازی زیرساخت کش و بهبود فرایندهای استقرار سایت کش کاهش دهیم، از طریق کاهش زمان استقرار اولیه از حدود یک سال به حداکثر یک سه‌ماهه. تمرکز اصلی در اینجا بر تکمیل ساده‌سازی، استقرار یک نمونه اثبات مفهوم (PoC)، انجام بررسی امنیتی و تکمیل گزارشی تصمیم‌گیری در مورد ادامه استقرار کش‌های مرزی ما در ابر عمومی خواهد بود. کاهش تأخیر می‌تواند منجر به افزایش ثابت‌شده در تعداد بازدید صفحات و گسترش پایه خوانندگان از لحاظ جغرافیایی شود.
      • نتیجهٔ کلیدی WE3.5: تا پایان سه‌ماههٔ چهارم (Q4)، شناسایی اهداکنندگان را بهبود بخشید—به‌طوری‌که همهٔ خوانندگان واردشده و موافق بتوانند بر اساس وضعیت اهداکننده شناسایی شده و تجربه‌ای شخصی‌سازی‌شده دریافت کنند.
        • ما استراتژی‌های شناسایی اهداکنندگان را اجرا خواهیم کرد تا اطمینان حاصل شود که همهٔ خوانندگان واردشده و موافق بر اساس وضعیت اهداکننده‌شان شناسایی می‌شوند و تجربه‌ای شخصی‌سازی‌شده و جذاب‌تر دریافت می‌کنند. تلاش‌های شناسایی اهداکنندگان تا پایان سه‌ماهه چهارم (Q4) در اولویت قرار خواهند گرفت تا از برنامه‌های شخصی‌سازی و فعال‌سازی مؤثرتر در آینده پشتیبانی شود.
      • نتیجهٔ کلیدی WE3.6: تا پایان سه‌ماههٔ چهارم، راهبردی برای تجربهٔ خواننده و مصرف‌کنندهٔ ویکی‌پدیا در تمام پلتفرم‌ها نهایی، منتشر و اطلاع‌رسانی شود؛ این راهبرد باید شامل اهداف مشخص و شاخص‌های مبنایی بوده و با همکاری ذی‌نفعان و جامعه تدوین گردد تا راهنمای کار ما تا سال ۲۰۳۰ باشد.
        • کار بر روی راهبرد مصرف‌کننده ادامه خواهد یافت، با تمرکز بر تدوین و اطلاع‌رسانی این راهبرد در داخل سازمان و همچنین با جامعه، و تعریف و تثبیت شاخص‌های اصلی برای مصرف‌کنندگان و مقادیر مبنای مربوط به آن‌ها.
      • 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).

اعتماد و ایمنی (WE4)

  • هدف: توسعهٔ قابلیت‌های پیشرفته پیشگیری از سوءاستفاده برای دفاع از پروژه‌های ما در برابر تهدیدات گسترده و هدفمند، در حالی که حفاظت از حریم خصوصی و ایمنی کاربران را تقویت می‌کنیم. بحث
  • نتیجهٔ کلیدی WE4.1: تا پایان سه‌ماههٔ دوم (Q2)، سیستم گزارش‌دهی رویدادهای عملی و کارآمد را در تمام ویکی‌ها مستقر کنید که توسط جوامع آن‌ها استفاده و پذیرفته شود.
    • اطمینان از ایمنی و رفاه کاربران مسئولیتی اساسی برای پلتفرم ما است. بسیاری از حوزه‌های قضائی مقرراتی دارند که از پلتفرم‌های آنلاین مانند پلتفرم ما می‌خواهند که به نظارت و اقدام علیه آزار، زورگویی آنلاین و سایر محتوای مضر پرداخته و اقدامات لازم را انجام دهند. عدم پرداختن به این مسائل ممکن است پلتفرم‌ها را در معرض مسئولیت قانونی و تحریم‌های نظارتی قرار دهد.
    • می‌خواهیم به کاربران خود قدرت بدهیم تا تهدیدات فوری آسیب از طریق مکانیزم گزارش‌دهی قابل کشف و شهودی گزارش دهند تا اطمینان حاصل کنیم که می‌توانیم از این‌گونه حوادث آگاه شویم و در صورت لزوم اقدام سریع انجام دهیم. این گامی است به سوی ایجاد احساس امنیت در کاربران هنگام مشارکت در پلتفرم ما. این کار را با پیاده‌سازی سیستم گزارش‌دهی حوادث در ویکی‌های خود انجام می‌دهیم.
  • نتیجهٔ کلیدی WE4.2: تقویت دقت و کارایی ابزارهای ضد سوءاستفاده از طریق پیاده‌سازی دو بهبود تا پایان فصل دوم.
    • ما و جامعه‌مان نیاز داریم فعالیت‌های غیرواقعی و مخرب در ویکی‌ها را بهتر شناسایی و پیشگیری کنیم. این کار را با افزایش تعداد و کیفیت سیگنال‌های در دسترس پلتفرم، ترکیب این سیگنال‌ها در ابزارهایی که در اختیار کاربران با دسترسی گسترده قرار می‌دهیم، و شناسایی مواردی که می‌توانیم به‌صورت خودکار محدودیت‌های ایمن بر فعالیت‌های مشکوک اعمال کنیم، انجام خواهیم داد.
    • همچنین فرصت‌هایی برای بهبود دسترسی‌پذیری ویکی‌پدیا و سایر پروژه‌هایمان به‌صورت همزمان می‌بینیم. برای مثال، یکی از پروژه‌ها جایگزینی CAPTCHA سنتی و خودمدیریت‌شدهٔ ویکی‌ها است که کاربر را تا حل معما از ورود به سیستم بازمی‌دارد، با سرویسی برای امتیازدهی ریسک که به‌ندرت کاربران را به چالش می‌کشد. در عوض، این سرویس به‌طور خاموش حساب‌ها را با سطحی از مشکوک بودن برچسب‌گذاری می‌کند که می‌توانیم از آن برای غیرفعال کردن قابلیت‌ها استفاده کنیم و این وضعیت را برای ناظران با دسترسی بالا قابل مشاهده کنیم تا در کارشان کمک کند.
    • به‌طور کلی، پروژه‌های ویکی‌مدیا به شدت به مسدودسازی آدرس‌های آی‌پی برای کاهش سوءاستفاده از سوی بازیگران مخرب متکی هستند. این روش به‌طور فزاینده‌ای در جلوگیری از سوءاستفاده ناکارآمد شده و کاربران با حسن نیت را که تحت تأثیر مسدودسازی‌های آی‌پی و دامنه‌های آی‌پی قرار می‌گیرند، به‌طور منفی تحت تأثیر قرار می‌دهد. در این نتیجه کلیدی، هدف ما بهبود قابلیت‌های موجود و ارائه ابزارهای جدیدی است که امکان مسدودسازی دقیق‌تر و مؤثرتر بازیگران مخرب را فراهم کرده و آسیب‌های جانبی ناشی از مسدودسازی‌های آی‌پی و دامنه‌های آی‌پی را کاهش دهد.
    • برای ارزیابی اثربخشی خود، بازخورد کیفی از داوطلبان فعال در مبارزه با سوءاستفاده و شاخص‌های کمی مانند نرخ اعمال مسدودسازی‌های آی‌پی، پذیرش روش‌های کاهش سوءاستفاده مبتنی بر اعتبار آی‌پی و سیگنال‌های مرورگر، نرخ تعاملات محتمل انسانی هنگام مسدودسازی کاربر، و پذیرش سیگنال‌های جدید در ابزارهای ضدسوءاستفاده را بررسی خواهیم کرد.
    • کار در این نتیجهٔ کلیدی شامل بهبود شناسایی و مقابله با حساب‌های زاپاس و دورزدن بندایش‌ها، ارائهٔ اطلاعات دربارهٔ احتمال آسیب‌های جانبی، تقویت شناسایی ربات‌ها، نمایش سیگنال‌ها به داوطلبان ضدسوءاستفاده، افزایش کارایی در رابط‌های ابزارهای ضدسوءاستفاده، بهبود معیارهای مرتبط با سوءاستفاده، و ارائهٔ پیشنهادهای فعالیت مشکوک برای بررسی به بازرسان است.
  • نتیجهٔ کلیدی WE4.3: تا پایان سه‌ماههٔ چهارم (Q4)، تعداد حملات گسترده‌ای که نیازمند مداخلهٔ انسانی تیم SRE هستند را نسبت به سال قبل ۵۰٪ کاهش دهید.
    • تکامل چشم‌انداز اینترنت، از جمله ظهور بات‌نت‌های مقیاس بزرگ و حملات مکرر، روش‌های سنتی ما برای محدود کردن سوءاستفاده‌های مقیاس بزرگ را منسوخ کرده است. چنین حملاتی می‌توانند با انبوه کردن درخواست‌ها، دسترسی به سایت‌های ما را غیرقابل استفاده کنند یا توانایی جامعه ما را در مبارزه با وندالیسم‌های مقیاس بزرگ مختل کنند. این امر همچنین فشار غیرمنطقی بر ویرایشگران با امتیازات بالا و جامعه فنی ما وارد می‌کند.
    • به طور فوری نیاز داریم توانایی خود را برای شناسایی خودکار، مقابله و کاهش یا متوقف کردن چنین حملاتی بهبود بخشیم.
    • امسال بیشتر بر روی خودکار کردن شناسایی آدرس‌های IP و شبکه‌هایی که به طور مداوم به ما حمله می‌کنند تمرکز خواهیم کرد و میزان بارگذاری که این موجودات آسیب‌زا به طور مداوم بر روی سیستم‌های ما می‌گذارند را کاهش خواهیم داد.
  • نتیجهٔ کلیدی WE4.4: تا پایان سه‌ماههٔ دوم (Q2)، حساب‌های موقت را در ۱۰۰٪ پروژه‌ها مستقر کنید، به‌طوری‌که افشای اطلاعات شخصی قابل شناسایی ویراستاران ثبت‌نام‌نشده کمتر از ۰.۱٪ کاربران باشد.
    • حساب‌های موقت به‌منظور بهبود حریم خصوصی و در نتیجه، امنیت ویراستاران بدون ثبت‌نام ما طراحی شده‌اند تا اطلاعات شخصی شناسایی‌شده آن‌ها (آدرس آی‌پی) از دید عمومی محافظت شود و دسترسی به آن تنها برای کسانی که به‌منظور نظارت به آن نیاز دارند محدود گردد. علاوه بر این‌که این پروژه به‌عنوان یک بهبود بزرگ در زمینه امنیت کاربران است، همچنین برای انطباق با الزامات مختلف قانونی اهمیت دارد.
  • نتیجهٔ کلیدی WE4.5: تا پایان سه‌ماههٔ سوم (Q3)، تأثیر هوش مصنوعی مولد بر اعتماد و ایمنی را ارزیابی کرده و مداخلات محصول برای بهره‌برداری از فرصت‌ها و جلوگیری از تهدیدها در پروژه‌های ویکی‌مدیا را تعیین کنید.
    • استفاده از هوش مصنوعی و به‌ویژه هوش مصنوعی مولد به سرعت در سراسر اینترنت افزایش می‌یابد. با همه‌گیر شدن هوش مصنوعی، فرصت‌ها و تهدیدهای مرتبط با اعتماد و ایمنی نیز پدیدار می‌شوند. برای مثال، تولید محتوا آسان‌تر و ارزان‌تر شده، اما نظارت سخت‌تر است. به‌طور مشابه، پژوهش‌ها با تلاش بسیار کمتری انجام می‌شود، اما شناسایی خطاها یا توهمات هوش مصنوعی دشوارتر است.
    • این پروژه با هدف توسعهٔ ارزیابی تأثیر حقوق بشر در حوزهٔ یادگیری ماشینی/هوش مصنوعی، به بررسی تأثیر هوش مصنوعی بر جنبه‌های اعتماد و ایمنی در اکوسیستم ویکی‌مدیا می‌پردازد. این شامل موارد زیر است:
      • مشاوره با کاربران دارای دسترسی‌های گسترده.
      • شناسایی نمونه‌هایی از سوءاستفاده‌های همراه با هوش مصنوعی مولد و راهکارهای احتمالی کاهش آن‌ها.
      • شناسایی فرصت‌های یادگیری ماشینی برای کاهش بار کاری کاربران دارای دسترسی‌های گسترده.
      • اجرای آزمایش‌ها برای درک اینکه باید بر چه موضوعاتی تمرکز کنیم تا بیشترین تأثیر را داشته باشیم.
  • نتیجهٔ کلیدی WE4.6: تا پایان سه‌ماههٔ چهارم (Q4)، به‌صورت فنی تضمین کنید که ۱۰۰٪ دسترسی‌هایی که به کاربران امکان انجام اقدامات حساس امنیتی یا حریم خصوصی را می‌دهد، تنها توسط حساب‌هایی انجام شود که احراز هویت دو مرحله‌ای را فعال کرده‌اند.
    • نیاز داریم امنیت حساب‌های کاربری در ویکی‌های خود را به‌ویژه برای کاربران با دسترسی‌های حساس تقویت کنیم. یکی از تمرکزهای اصلی، الزام این است که هر اقدام حساس تنها توسط کاربرانی انجام شود که احراز هویت دو مرحله‌ای (2FA) را فعال کرده‌اند. ما سیستمی قابل توسعه‌تر برای اجرای دسترسی‌ها خواهیم ساخت که نیاز به حسابرسی و اعمال دستی 2FA را حذف کرده و دامنه دسترسی‌هایی که نیازمند فعال‌سازی 2FA هستند را در پلتفرم گسترش می‌دهد.
    • در این راستا، سیستم‌های احراز هویت و بازیابی خود را بهبود خواهیم داد تا بنیاد و کاربران بتوانند به‌راحتی موضع سختگیرانه‌تری نسبت به 2FA اتخاذ کنند. دسترسی عمومی احراز هویت دو مرحله‌ای را در سراسر پلتفرم گسترش می‌دهیم تا هر کاربر بتواند آن را فعال کند و پیش از اعطای دسترسی‌های حساس، فعال بودن آن تضمین شود. همچنین تمرکز خود را بر کاهش بار عملیاتی سیستم‌های بازیابی حساب و پشتیبانی می‌گذاریم تا فرایندهای بازنشانی و بازیابی ورود به حساب ساده‌تر شود. قصد داریم قابلیت استفاده از پیاده‌سازی 2FA را بهبود بخشیم و گزینه‌های بیشتری برای امنیت حساب کاربران فراهم کنیم تا از قفل شدن تصادفی حساب‌ها جلوگیری شود.
  • 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.

استفادهٔ مسئولانه از زیرساخت (WE5)

  • هدف اصلی: توسعه‌دهندگان و بازاستفاده‌کنندگان به محتوای دانش از طریق مسیرهای گزینش‌شده دسترسی دارند، به‌گونه‌ای که پایداری زیرساخت ما و استفادهٔ مسئولانه از محتوا تضمین شود. بحث
    • زمینهٔ هدف: این هدف بر ایجاد مسیرهایی برای استفادهٔ مسئولانه از محتوا تمرکز خواهد کرد.
    • ویکی‌مدیا بزرگ‌ترین مجموعهٔ دانش گزینش‌شده توسط انسان را در وب میزبانی می‌کند. این امر زیرساخت دانش ما را به مقصدی ارزشمند نه تنها برای انسان‌ها بلکه برای مصرف‌کنندگان خودکار داده تبدیل کرده است. محتوای ما در موتورهای جستجو، پلتفرم‌های شبکه‌های اجتماعی، تجارت الکترونیک و از زمان ظهور هوش مصنوعی برای آموزش مدل‌های بزرگ یادگیری ماشین استفاده می‌شود. مصرف‌کنندگان داده‌ها را از طریق وب‌اسکریپینگ صفحات، استفاده از اِی‌پی‌آی‌ها و دانلود محتوا به‌دست می‌آورند — معمولاً بدون ذکر منبع. در دنیای ترافیک بدون احراز هویت، نمی‌توانیم به‌طور قابل اعتماد یک کاربر را از دیگری تشخیص دهیم که این موضوع توانایی ما را برای فعال‌سازی و اجرای استفاده مسئولانه از زیرساخت محدود می‌کند: چگونه می‌توانیم به جامعه خود امکان ادامه فعالیت بدهیم و در عین حال محدودیت‌هایی برای مصرف خودکار محتوا تعیین کنیم؟ چگونه می‌توانیم کاربران را به کانال‌های ترجیحی و پشتیبانی‌شده هدایت کنیم؟ چه راهنمایی‌هایی برای تشویق استفاده مسئولانه از محتوا نیاز داریم؟ چگونه می‌توانیم به تجربه‌ای منسجم برای توسعه‌دهندگان دست یابیم و محصولاتی بسازیم که نیازهای توسعه‌دهندگان داوطلب، کارکنان و بازاستفاده‌کنندگان را به یکسان برآورده کند؟ اگرچه این پرسش‌ها همه جدید نیستند، فوریت پرداختن به آن‌ها به‌طور نمایی افزایش یافته است: از سال ۲۰۲۴ شاهد افزایش چشمگیر حجم درخواست‌ها هستیم که بیشتر آن ناشی از ربات‌های اسکریپ است که داده‌های آموزشی برای گردش‌کارها و محصولات مبتنی بر هوش مصنوعی جمع‌آوری می‌کنند. بار وارده بر زیرساخت ما پایدار نیست و دسترسی انسانی به دانش را در معرض خطر قرار می‌دهد: اکنون باید برای بازسازی تعادل سالم اقدام کنیم تا بتوانیم به‌طور مؤثر از پروژه‌های ویکی‌مدیا حمایت کرده و موفقیت پایدار مأموریت خود را تضمین کنیم.
      • نتیجهٔ کلیدی WE5.1: تا پایان سه‌ماههٔ چهارم (Q4)، ۵۰٪ از درخواست‌ها به کانال‌های دسترسی برنامه‌محور بتواند به توسعه‌دهنده یا برنامهٔ شناخته‌شده نسبت داده شود.
        • در حال حاضر راه‌های محدودی برای شناسایی مسئول ترافیک خودکار داریم و برخلاف ویکی، راه‌های محدودی برای تماس با کاربران یا تنظیم دسترسی آن‌ها وجود دارد. حجم قابل توجهی از ترافیک خودکار خارجی افزایش یافته است که این وضعیت برای ما پایدار نیست و دسترسی انسان‌ها به دانش را در معرض خطر قرار می‌دهد. هدف ما افزایش درصد ترافیک خودکاری است که به حساب شناخته‌شده نسبت داده می‌شود، از طریق الزام به احراز هویت و مجوزدهی بر اساس سطوح دسترسی طبقه‌بندی‌شده برای اسکریپینگ با حجم بالا و استفاده از API. این کار به ما کمک می‌کند کسانی که محتوا را به‌صورت گسترده بازاستفاده می‌کنند شناسایی کنیم، زیرساخت خود را محافظت کنیم و حاکمیت بهتری بر استفاده منصفانه اعمال کنیم، در حالی که نیازهای آن‌ها را مؤثرتر برآورده می‌سازد. همچنین به بررسی راه‌هایی برای حمایت بهتر از جامعه فنی با تجربه توسعه‌دهنده یکپارچه‌تر می‌پردازیم که دسترسی ترجیحی اعضای جامعه را حفظ کرده و قابلیت‌های جدیدی برای توسعه‌دهندگان فراهم می‌کند.
      • نتیجهٔ کلیدی WE5.2: تا پایان سه‌ماههٔ چهارم (Q4)، ۷۰٪ از نقطه‌پایانی‌های اِی‌پی‌آی وب ویکی‌مدیا توسط زیرساخت مشترک پشتیبانی خواهند شد.
        • هدف ما بهبود تجربه و پایداری مسیرهای توسعه‌دهندگان از طریق ارائهٔ اِی‌پی‌آی‌های وبی سازگارتر، پایدارتر و قابل کشف‌تر برای همه توسعه‌دهندگان ویکی‌مدیا است. با معرفی زیرساخت متمرکزتر برای قابلیت‌های اصلی اِی‌پی‌آی، عرضه‌های خود را ساده‌تر خواهیم کرد که این امکان را فراهم می‌کند مسیرها و حاکمیت یکسانی برای مشخصات و مستندسازی OpenAPI، شناسایی توسعه‌دهندگان و کنترل دسترسی، اجرای سیاست‌های اِی‌پی‌آی، مسیریابی، نسخه‌بندی و مدیریت خطاها داشته باشیم. با بهینه‌سازی عرضه‌های اِی‌پی‌آی، ساخت ابزارها، ربات‌ها، پروژه‌های پژوهشی و قابلیت‌هایی که به مأموریت ویکی‌مدیا خدمت می‌کنند سریع‌تر، آسان‌تر و لذت‌بخش‌تر خواهد شد. این رویکرد با کاهش هزینه‌های نگهداری زیرساخت اِی‌پی‌آی، افزایش شفافیت و کنترل دسترسی برای مقابله با بازیگران مخرب و تقویت جامعه توسعه‌دهندگان، از آینده چندنسلی مأموریت حمایت می‌کند.
      • نتیجهٔ کلیدی WE5.3: تا پایان فصل چهارم، چارچوب جدید انتساب برای وب، اپلیکیشن‌ها، دستیارهای صوتی و مدل‌های زبانی بزرگ (LLM) منتشر و در سراسر وب‌سایت‌های ویکی‌مدیا پیوند داده خواهد شد، با دو نمونهٔ نمایشی از استفادهٔ مجدد که موجب تعامل قابل اندازه‌گیری شوند، و یک شریک خارجی استفاده‌کننده از بهترین شیوه‌های انتساب.
        • برای افزایش انتساب صحیح محتوای ویکی‌مدیا، راهنمایی‌های روشن و مبتنی بر بهترین شیوه‌ها ارائه خواهیم داد که استفادهٔ مسئولانه از محتوا را ترویج می‌کند. این اقدام شامل ایجاد چارچوب انتساب برای پلتفرم‌های کلیدی (وب، اپلیکیشن‌ها، صدا و چندرسانه‌ای) و نمایش دست‌کم دو نمونهٔ عملی است که کاربردهای نمونه‌وار محتوای ویکی‌مدیا را برجسته می‌سازند. نمونه‌هایی از نتایج این کار می‌تواند شامل تشویق سازمان‌های رسانه‌ای به ذکر منبع برای تصاویر ویکی‌مدیا کامنز، کمک به موتورهای جستجو برای نمایش مؤثرتر داده‌های مرتبط با ویکی‌مدیا، یا ترغیب دستیارهای هوش مصنوعی به ادغام دانش ویکی‌پدیا به‌صورت شفاف و مسئولانه باشد تا اعتماد به قابلیت اتکای آن‌ها افزایش یابد. تقویت شیوه‌های انتساب نه‌تنها آگاهی عمومی را بالا می‌برد و تعامل با پروژه‌های ویکی‌مدیا را افزایش می‌دهد، بلکه به تثبیت روش‌های مسئولانه و نوآورانهٔ بازترکیب دانش و جلوگیری از سوءاستفاده نیز کمک می‌کند.
      • نتیجهٔ کلیدی WE5.4: میزان ترافیک ایجادشده توسط اسکریپرها را به میزان ۲۰٪ بر اساس نرخ درخواست‌ها و ۳۰٪ بر اساس پهنای باند کاهش دهید.
        • وب‌اسکریپینگ همیشه وجود داشته است: موتورهای جستجو دهه‌هاست که برای ارائهٔ اطلاعات به کاربران خود به ویکی‌پدیا متکی بوده‌اند؛ اما اخیراً انگیزهٔ بزرگی برای اسکریپ کردن داده‌های ما پدید آمده است: بزرگ‌ترین مجموعهٔ دانش چندزبانه و گزینش‌شده در اینترنت که ابزاری اساسی برای آموزش مدل‌های زبان بزرگ است. این موضوع هم برای محتوای دانشنامه‌ای ما و هم برای مخزن چندرسانه‌ای ما، ویکی‌انبار، صدق می‌کند که برای مدل‌های یادگیری ماشینی تولیدکنندهٔ تصویر بسیار ارزشمند است.
        • در نتیجه، در سال گذشته شاهد افزایش قابل توجهی در حجم ترافیک اسکریپرها و همچنین حوادث مرتبط با پایداری سایت بودیم: مهندسان قابلیت اطمینان سایت مجبور شده‌اند به صورت موردی محدودیت نرخ یا مسدودسازی ربات‌ها را برای حفاظت از زیرساخت بارها اعمال کنند. اسکریپینگ چنان برجسته شده است که پهنای باند خروجی ما در سال ۲۰۲۴ به میزان ۵۰٪ افزایش یافته است. علاوه بر این، تحلیل اخیر نشان داده است که دست‌کم ۶۵٪ از گران‌ترین درخواست‌های ما (آن‌هایی که نمی‌توانیم از سرورهای کش پاسخ دهیم و از پایگاه‌های داده اصلی ارائه می‌شوند) توسط ربات‌ها انجام می‌شوند.
        • منابع محاسباتی ما نسبت به حجم ترافیکی که ایجاد می‌کنیم بسیار محدود است، بنابراین باید اولویت‌بندی کنیم که این منابع به چه کسانی اختصاص یابد، و می‌خواهیم مصرف انسانی را ترجیح دهیم و حمایت از پروژه‌های ویکی‌مدیا و مشارکت‌کنندگان را با منابع کمیاب خود در اولویت قرار دهیم.

تسریع مسیر به نتایج محصول (WE6)

  • هدف: توسعه‌دهندگان ویکی‌مدیا محصولات خود را سریع و با اطمینان به دست کاربران نهایی می‌رسانند. بحث
    • زمینهٔ هدف: برای اثربخشی در دستیابی به چهار ستون راهبردی، توسعه‌دهندگان ویکی‌مدیا باید زمان و تلاش خود را صرف فعالیت‌های با اهرم بالا کنند که منجر به ارائهٔ محصولات باکیفیت در اسرع وقت شود. جریان‌های کاری بیش از حد پیچیده، نبود ابزارهای استاندارد و اجزای سیستم غیرپایدار مانع دستیابی به این نتایج می‌شوند.
    • این کار بر پایهٔ روند پیشرفتی است که در دو برنامه سالانهٔ گذشته در توسعهٔ مدیاویکی به‌عنوان یک پلتفرم و نرم‌افزارهای پشتیبان آن کسب کرده‌ایم. تمرکز کار امسال بر ارائهٔ محیط‌های توسعه‌دهنده قابل اعتمادتر، ساده‌سازی جریان‌های کاری پیش‌تولید و کاهش ریسک‌های پلتفرم و زیرساخت خواهد بود.
      • نتیجهٔ کلیدی WE6.1: تا پایان سه‌ماههٔ چهارم (Q4)، تعداد باگ‌های مسدودکننده روند توسعه که از ویکی‌های آزمایشی عبور می‌کنند، ۱۰٪ کاهش یابد.
        • در سال ۲۰۲۴، توسعه‌دهندگان ۱۴۴ بار مجبور شدند به کار خود بازگردند زیرا یک موقعیت اضطراری مانع استقرار مدیاویکی شده بود. در بسیاری از این موارد، باگ‌ها پس از استقرار در ویکی‌های آزمایشی شناسایی شدند، به این معنا که مشکل به جمعیتی بالقوه میلیاردها کاربر رسیده بود. نمی‌توانیم وجود باگ‌ها را کنترل کنیم، اما شناسایی زودهنگام آن‌ها به معنای کاهش نیاز به اقدامات اضطراری است. این همچنین اعتماد توسعه‌دهندگان را افزایش می‌دهد که هنگام ورود به تولید واقعی، مشکلی پیش نخواهد آمد.
        • این باگ‌ها را زودتر شناسایی خواهیم کرد با فراهم کردن محیط‌های لازم برای توسعه‌دهندگان تا با اطمینان کد خود را در طول چرخهٔ توسعه و استقرار تحویل و آزمایش کنند. همچنین باید اطمینان حاصل کنیم که این بهبودها به هزینهٔ سرعت توسعه‌دهنده تمام نشود.
      • نتیجهٔ کلیدی WE6.2: تا پایان سه‌ماههٔ چهارم (Q4)، اجرای ۴ مرحله از چک‌لیست بازبینی آمادگی تولید بدون نیاز به مداخلهٔ تیم SRE امکان‌پذیر باشد.
        • استقرار سرویس یا قابلیت جدید در تولید در حال حاضر به فهرستی از ۲۴ مرحله وابسته است که هر مرحله معمولاً نیاز به پشتیبانی از تیم‌های SRE دارد. ما برنامهٔ سفیران SRE را برای مداخله زودتر در چرخه توسعه و افزایش ظرفیت درون تیم‌های توسعه ایجاد کرده‌ایم، اما بسیاری از این وظایف باید کاملاً خودخدمت‌رسان باشند. در حال حاضر، این کارها دستی، تکراری، قابل خودکارسازی و با افزایش خطی تعداد تیم‌های توسعه افزایش می‌یابد. این وضعیت در بلندمدت برای تیم SRE پایدار نیست.
        • در گذشته، بخش عمده‌ای از این کارها از تیم‌های توسعه انتزاع شده بود با حفظ مجموعه‌ای از کتابخانه‌ها و بهترین شیوه‌های مشترک برای تعامل با پلتفرم ما. این موارد زمانی که به زیرساخت جدید کوبرنتیز منتقل شدیم کنار گذاشته شدند و جایگزین مستقیمی ندارند. با ارائه کتابخانه‌ها، مستندسازی و آموزش‌های مشابه که متناسب با روش فعلی ساخت و استقرار ما باشد، معتقدیم می‌توانیم میزان مشارکت لازم از سوی تیم SRE را پیش از استقرار سرویس یا قابلیت جدید در تولید کاهش دهیم.
      • نتیجهٔ کلیدی WE6.3: تا پایان سه‌ماههٔ چهارم (Q4)، ۱۰۰٪ بازدیدهای صفحات ویکی‌پدیا از طریق پارسید ارائه شوند.
        • پارسید قابلیت‌های پیشرفته‌ای برای تکامل ویکی‌تکست و آینده‌نگری پلتفرم ارائه می‌دهد. نگهداری همزمان دو پارسر در بلندمدت پایدار نیست، زیرا بدهی فنی و پیچیدگی را افزایش می‌دهد. علاوه بر این، موفقیت برخی پروژه‌های جدید مانند ویکی‌توابع وابسته به در دسترس بودن گستردهٔ پارسید است.
        • گسترش استقرار را به پروژه‌های کوچک‌تر افزایش داده‌ایم و امسال برای ویکی‌پدیاها آماده خواهیم بود. ارائهٔ تمام بازدیدهای صفحات ویکی‌پدیا از طریق پارسید مهم‌ترین گام بعدی است. علاوه بر خود استقرار، این کار شامل رفع مشکلات عملکردی و برقراری ارتباط مؤثر دربارهٔ تأثیر آن بر خوانندگان و ویراستاران نیز می‌شود.
      • نتیجهٔ کلیدی WE6.4: تا پایان سه‌ماههٔ دوم (Q2)، حداقل دو ریسک شناسایی‌شده که توانایی ما برای ادامه استقرار یا گسترش ویکی‌ها را تهدید می‌کنند، کاهش یافته یا به سطح قابل قبول رسیده باشند.
        • از طریق چند ابتکار هدفمند، چندین ریسک مقیاس‌پذیری، قابلیت اطمینان یا امنیت را که به‌عنوان تهدید احتمالی برای رشد و پایداری پلتفرم و پروژه‌های عمومی ما شناسایی کرده‌ایم، کاهش داده یا مدیریت خواهیم کرد.
        • برای مثال، ساختار پایگاه‌های داده اصلی ویکی‌انبار را بازطراحی خواهیم کرد تا اطمینان حاصل شود رشد آن در چند سال آینده محدود به ظرفیت سخت‌افزار سرور موجود نخواهد بود. همچنین زبان برنامه‌نویسی پی‌اچ‌پی که مدیاویکی و خدمات مرتبط را پشتیبانی می‌کند، به نسخه‌ای مدرن‌تر ارتقا خواهد یافت. سایر ریسک‌های شناسایی‌شده احتمالاً نیازمند اجرای اقدامات امنیتی اضافی برای حفاظت و مقاوم‌سازی زیرساخت ما خواهند بود.
      • 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.

خدمات سیگنال و داده (SDS)

معیارها (SDS1)

  • هدف: تصمیم‌گیرندگان از معیارهای بیشتر قابل اعتماد و به‌موقع برای اطلاع‌رسانی به تصمیمات محصول و راهبردی استفاده می‌کنند. بحث
    • زمینهٔ هدف: ما از معیارها برای اطلاع‌رسانی به تصمیمات بنیاد دربارهٔ اولویت‌بندی تلاش‌هایمان به‌منظور خدمت بهتر به جنبش استفاده می‌کنیم. با این حال، برخی از خطوط لوله داده‌های ما مستعد خرابی هستند که باعث تأخیر در تحویل می‌شود. هنگامی که مشکلات داده‌ای بروز می‌کنند، زمان شناسایی و حل آن‌ها بسیار بالا است. علاوه بر این، بسیاری از مجموعه‌داده‌های ما برای کاوش آسان روندها بهینه نشده‌اند و ابعادی که به‌تازگی به‌عنوان عوامل مهم در تفسیر داده‌ها شناخته شده‌اند، در آن‌ها وجود ندارد. این مشکلات سرعت و توانایی ما را در ارزیابی معیارها کاهش می‌دهد و محدود می‌کند.
    • در سال مالی ۲۵-۲۶، تمرکز ما بر موارد استفاده خاص برنامه سالانه برای رفع شکاف‌های کیفیت داده در خطوط لوله فعلی، راه‌اندازی زیرساخت‌ها و فرآیندهای نظارت و حل مسائل کیفیت داده، و ارائه ابزارهایی خواهد بود که به تصمیم‌گیرندگان امکان درک روندها را می‌دهد.
    • یکی از موارد استفاده مربوط به نحوه اندازه‌گیری ترافیک انسانی و ربات‌ها است. افزایش ترافیک خودکار در چند سال گذشته درک میزان تعامل و مشارکت انسان‌ها با پروژه‌های ویکی‌مدیا را دشوارتر کرده است. هدف ما بهبود توانایی در ارزیابی الگوهای ترافیک انسانی و ربات‌ها است که ورودی‌های حیاتی برای برنامه‌ریزی و تصمیمات محصول محسوب می‌شوند.
      • نتیجهٔ کلیدی SDS1.1: تا پایان فصل نخست، تحلیل‌گرانی که از شاخص‌های بازدید صفحه استفاده می‌کنند به معیارهای پایه‌ای کیفیت داده و سنجه‌های عملکردی تشخیص خودکار ترافیک دسترسی خواهند داشت.
        • با استفاده از فرضیات بررسی‌شده در این نتیجهٔ کلیدی، هدف ما شناسایی شکاف‌ها در نشانه‌شناسی‌های فعلی شناسایی ترافیک خودکار و درک نقاط ضعف آن‌ها در دسته‌بندی صحیح ترافیک مشاهده صفحه است. این بینش‌ها به بهبود خطوط لوله‌ای که معیارهای مشاهده صفحه را تولید و طبقه‌بندی می‌کنند، کمک خواهند کرد. علاوه بر این، ما معیارهای کیفیت داده‌ها را برای نظارت و اندازه‌گیری بهبود دقت داده‌ها تعریف خواهیم کرد.
        • این نتیجهٔ کلیدی زمینه‌ساز نتیجهٔ کلیدی بعدی خواهد بود که بر اجرای بهبودهای لازم در خط لولهٔ داده، شناسایی‌شده در این مرحله، تمرکز دارد. شاخص‌های کیفیت داده که در این مرحله تعیین می‌شوند، به‌عنوان معیارهایی پایه برای ارزیابی اثربخشی بهبودهای آینده مورد استفاده قرار خواهند گرفت.
      • نتیجهٔ کلیدی SDS1.2: تا پایان فصل نخست، محتوای مجموعه‌دادهٔ تاریخچهٔ محتوای مدیاویکی از طریق خروجی فایل با تضمین تحویل هفتگی (SLOs) در دسترس خواهد بود. داده‌های فایل خروجی از نظر محتوا با خط لولهٔ خروجی قدیمی XML Dumps 1 برابری خواهند داشت.
        • هدف از نتیجه کلیدی ۱.۴ در سال مالی ۲۴/۲۵ حذف وابستگی به مجموعهٔ داده‌های ماهانهٔ به‌روزرسانی‌شده mediawiki_wikitext_history و mediawiki_wikitext_history_current برای سه خط لوله پایین‌دستی مرتبط‌ترین و ارائهٔ یک مجموعهٔ دادهٔ جایگزین با تضمین‌های تحویل هفتگی (SLO) بوده است.
        • در حالی که نتیجهٔ کلیدی ۱.۴ سال مالی ۲۴/۲۵ به کاهش مشکلات قابلیت اطمینان برای مرتبط‌ترین خطوط لولهٔ وابسته کمک کرد، خطوط لوله‌ای باقی مانده‌اند که هنوز از منبع ورودی قدیمی و غیرقابل اعتماد استفاده می‌کنند. این‌ها نیز باید مهاجرت داده شوند، همچنین منبع ورودی مبتنی بر فایل به مجموعه داده تاریخچه ویکی‌متن خود منتقل شود.
      • نتیجهٔ کلیدی SDS1.3: تا پایان فصل دوم، سامانهٔ تشخیص ربات یک سیگنال اضافی جدید را در بر خواهد گرفت و هشدارهای خودکاری برای ناهنجاری‌ها ایجاد خواهد کرد.
        • در سراسر بنیاد، تیم‌ها تصمیم‌های محصولی و بودجه‌ای خود را بر پایهٔ توانایی در تشخیص تفاوت میان خوانندگان انسانی و ترافیک خودکار اتخاذ می‌کنند. پلتفرم داده به‌عنوان مخزن مرکزی برای سیگنال‌های تشخیص ربات و تحلیل‌های دسته‌ای عمل می‌کند. بر اساس فرضیه‌هایی که در فصل‌های نخست و دوم ترسیم کرده‌ایم، قصد داریم سیگنال‌های تازه‌ای برای تشخیص ربات معرفی کنیم تا دقت تحلیل ترافیک خودکار را افزایش دهیم و فرایند افزودن سیگنال‌های جدید را کارآمد و قابل تکرار سازیم.
      • نتیجهٔ کلیدی SDS1.4: تا پایان فصل دوم، تصمیم‌گیرندگان درک روشنی از وضعیت کنونی بینش‌های حاصل از شاخص‌های سازمانی ما خواهند داشت. موفقیت ما زمانی محقق می‌شود که مجموعه‌ای از اسلایدهای آماده برای نشست هیئت‌امنا ارائه دهیم که در آن تحلیل شاخص‌های ما هم در بستر زیست‌بوم ویکی‌مدیا و هم در چارچوب روندها و چالش‌های گسترده‌تر اینترنت و بازار جای گیرد.
        • بینش‌های به‌دست‌آمده از شاخص‌های سازمانی ما در سراسر بنیاد برای اتخاذ انواع تصمیم‌ها به کار می‌روند، از جمله تصمیم‌هایی دربارهٔ چگونگی توسعهٔ محصولات، تخصیص منابع زیرساختی، و روش‌های تأمین مالی. در همین حال، چشم‌انداز اینترنت در حال دگرگونی است و به‌ویژه ترافیک خودکار بر شاخص‌های ما تأثیر می‌گذارد. هدف آن است که رهبری بنیاد با روایتی روشن دربارهٔ تهدیدها و فرصت‌های درون زیست‌بوم ویکی‌مدیا، و با اتکا بر تحلیلی مطمئن از شاخص‌های درونی و روندهای بیرونی، وارد نشست دسامبر هیئت‌امنا شود. ما می‌توانیم این روایت را با گردآوری بینش‌ها، شاخص‌ها و داده‌هایی شکل دهیم که با اطمینان به ما نشان دهند:
          • روندهای شاخص‌های درونی ما در زمینهٔ میزان خوانده‌شدن (بازدید صفحه‌ها)
          • روندهای موجود در زیست‌بوم مشارکت‌کنندگان ما
          • روندهای به‌دست‌آمده از داده‌های بیرونی و معیارهای مقایسه با رقبا
          • بینش‌های حاصل از مطالعات درونی و بیرونی و پژوهش‌های معتبر
      • 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.

پلت‌فرم آزمایش (SDS2)

  • هدف: مدیران محصول می‌توانند تأثیرات تغییرات ویژگی‌های محصول در ویکی‌پدیا را به سرعت، به راحتی و با اطمینان ارزیابی کنند. بحث
    • متن هدف: برای تسهیل و تسریع تصمیم‌گیری‌های مبتنی بر داده در خصوص توسعه ویژگی‌های محصول، مدیران محصول به یک پلتفرم آزمایشگاهی نیاز دارند که در آن بتوانند ویژگی‌ها را تعریف کنند، گروه‌های آزمایشی از کاربران را انتخاب کنند و اندازه‌گیری‌های تأثیر را مشاهده کنند. تسریع زمان از راه‌اندازی تا تحلیل بحرانی است، زیرا کوتاه‌تر کردن زمان برای یادگیری باعث تسریع آزمایش‌ها و در نهایت نوآوری می‌شود. وظایف دستی و رویکردهای سفارشی برای اندازه‌گیری به عنوان موانع سرعت شناسایی شده‌اند. سناریوی ایده‌آل این است که مدیران محصول بتوانند از راه‌اندازی آزمایش تا کشف، با حداقل یا هیچ دخالتی از مهندسان و تحلیلگران، پیش روند.
    • ما در سال مالی آینده بر روی ویکی‌پدیا تمرکز خواهیم کرد زیرا اینجا جایی است که تجربیات اصلی علاقه‌مند به آزمایش هستند (استراتژی سازمانی ما بر دو برابر کردن تمرکز بر ویکی‌پدیا است)، و همچنین این امکان را به ما می‌دهد که تمرکز و سیگنال‌دهی واضح‌تری داشته باشیم در خصوص تیم‌ها و پروژه‌هایی که با آنها درگیر خواهیم بود. تیم‌های دیگر از اجزای پلتفرم آزمایش استفاده کرده‌اند و ممکن است همچنان از آن استفاده کنند، اما این استفاده تمرکز اصلی این هدف نخواهد بود.
      • نتیجهٔ کلیدی SDS2.1: تا پایان سه‌ماههٔ دوم (Q2)، امکان تکمیل حداقل ۲ چرخه کامل آزمایش با استفاده از پلتفرم آزمایش فراهم شود.
        • با توجه به تأکید فزاینده سازمان بر تصمیمات محصول مبتنی بر داده، باید آزمایش را برای همه تیم‌های محصول، نه فقط آن‌هایی که مهارت‌های تخصصی دارند، قابل دسترس کنیم. تیم‌های محصول به استانداردها، ابزارها و زیرساخت‌های مشترکی نیاز دارند که به آن‌ها امکان می‌دهد:
          • ایده‌ها را به‌سرعت در میان کاربران جهانی خود آزمایش کنند
          • تأثیر تغییرات محصول را با معیارهای استاندارد اندازه‌گیری کنند
          • نتایج را به‌صورت شفاف با ذی‌نفعان جنبش خود به اشتراک بگذارند
        • دلیل تغییر تمرکز از «تعداد تیم‌های فعال‌شده» به «آزمایش‌های انجام‌شده»:
        1. هماهنگی راهبردی: این معیار اصلی موفقیت پلتفرم است
        2. رویکرد مبتنی بر داده: تحقیقات کاربران ما (در حال انجام) نشان‌دهنده آمادگی متغیر تیم‌ها در سراسر سازمان است، در حالی که می‌دانیم تیم وب علاقه‌مندی خود را به دو آزمایش خاص تأیید کرده است.
        3. بهینه‌سازی منابع: استقرار پلتفرم حداقل محصول پذیرفتنی (MVP) ما نیازمند آموزش‌های نزدیک و پرمخاطب است، بنابراین در کوتاه‌مدت تمرکز بر فرصت‌های آزمایش کارآمدتر از گسترش گسترده در میان تیم‌های متعدد خواهد بود. ما برنامه داریم به سمت انتشار عمومی پیش برویم و در صورت امکان نمی‌خواهیم دوباره در آموزش تیم‌ها سرمایه‌گذاری کنیم.
        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.

مخاطبان آینده (FA)

مخاطبان آینده (FA1)

  • هدف: بنیاد ویکی‌مدیا با پیشنهاداتی برای سرمایه‌گذاری‌های استراتژیک که به حرکت ما کمک می‌کند تا در اینترنت در حال تغییر، مخاطبان جدید را جذب کند، تجهیز شده است. بحث
    • متن هدف: به دلیل تغییرات مداوم در فناوری و رفتار کاربران آنلاین (مثلاً افزایش تمایل به دریافت اطلاعات از طریق اپلیکیشن‌های اجتماعی، محبوبیت ویدئوهای کوتاه آموزشی-سرگرمی، و ظهور هوش مصنوعی تولیدی)، حرکت ویکی‌مدیا با چالش‌هایی در جذب و نگهداری خوانندگان و مشارکت‌کنندگان مواجه است. این تغییرات همچنین فرصت‌هایی برای خدمت‌رسانی به مخاطبان جدید از طریق ایجاد و ارائه اطلاعات به روش‌های جدید فراهم می‌آورد. با این حال، ما به عنوان یک حرکت، تصویری داده‌محور و واضح از مزایا و معایب استراتژی‌های مختلفی که می‌توانیم برای غلبه بر این چالش‌ها یا استفاده از فرصت‌های جدید دنبال کنیم، نداریم. به عنوان مثال، آیا باید...
      • در ویژگی‌های جدید بزرگ مانند ربات‌های چت سرمایه‌گذاری کنیم؟
      • دانش و مسیرهای مشارکت ویکی‌مدیا را به پلتفرم‌های ثالث محبوب منتقل کنیم؟
      • چیزهای دیگر؟
    • برای اطمینان از اینکه ویکی‌مدیا به یک پروژه چندنسلی تبدیل شود، ما فرضیات مختلفی را آزمایش خواهیم کرد تا بهتر درک کرده و استراتژی‌های امیدوارکننده‌ای را برای دنبال کردن پیشنهاد دهیم – هم برای بنیاد ویکی‌مدیا و هم برای جنبش ویکی‌مدیا – به منظور جذب و نگهداری مخاطبان آینده.
      • نتیجهٔ کلیدی FA1.1: نتیجه‌ای از آزمایش‌ها و توصیه‌های مخاطبان آینده، تا پایان سه‌ماهه سوم، حداقل یک هدف یا نتیجه کلیدی که توسط تیم‌های غیر از تیم مخاطبان آینده مالکیت می‌شود، در پیش‌نویس برنامه سالانه سال بعد گنجانده شده باشد.
        • از سال ۲۰۲۰، بنیاد ویکی‌مدیا روندهای خارجی را که ممکن است بر توانایی ما برای خدمت به نسل‌های آینده مصرف‌کنندگان و مشارکت‌کنندگان دانش و ماندگاری به‌عنوان یک حرکت دانش آزاد موفق و پایدار تأثیر بگذارد، پیگیری کرده است. تیم تحقیق و توسعه مخاطبان آینده، که تیم کوچکی است، قصد دارد:
          • آزمایش‌های سریع و زمان‌بندی‌شده انجام دهد (هدف انجام حداقل ۳ آزمایش در هر سال مالی) تا روش‌هایی برای مقابله با این روندها را بررسی کند.
          • بر اساس بینش‌های حاصل از آزمایش‌ها، پیشنهاداتی برای سرمایه‌گذاری‌های غیرآزمایشی جدید که باید توسط بنیاد ویکی‌مدیا دنبال شوند، ارائه دهد؛ به عبارت دیگر، محصولات یا برنامه‌های جدیدی که نیاز به تیم یا تیم‌های کامل دارند و باید در دوره برنامه‌ریزی سالانه ما پیگیری شوند.
        • این نتیجهٔ کلیدی زمانی محقق خواهد شد که حداقل یک هدف یا نتیجه کلیدی که متعلق به تیمی خارج از آینده مخاطبان است و توسط پیشنهادی از آینده مخاطبان هدایت می‌شود، در پیش‌نویس برنامه سالانه برای سال مالی بعدی قرار گیرد.

ویدئوهای اجتماعی (FA2)

  • هدف: جوانان (<۲۵ سال) از محتوای ویکی‌پدیا لذت می‌برند، از آن می‌آموزند، با آن درگیر می‌شوند و آن را در پلتفرم‌هایی که دوست دارند زمان خود را آنلاین بگذرانند، به اشتراک می‌گذارند. بحث
    • زمینهٔ هدف: آزمایشات گروه مخاطبان آینده با ویدئوهای کوتاه در این سال مالی نشان داده است که ما می‌توانیم به طور گسترده‌ای به مخاطبان جوان‌تر در این پلتفرم‌ها دسترسی پیدا کنیم، اما داده‌های سلامت برند ما نشان می‌دهد که سرمایه‌گذاری فعلی ما برای مقابله با کاهش آگاهی و تعلق‌خاطر در میان مخاطبان نسل زد (Gen-Z) کافی نیست.
    • برای اطمینان از اینکه به طور مؤثر به این نسل دسترسی پیدا کنیم و آن‌ها را جذب کنیم، معتقدیم که باید از تاکتیک‌های مختلفی استفاده کنیم و به‌طور قابل توجهی در زمینه‌هایی مانند بازاریابی پرداختی و تأثیرگذاران، کمپین‌های خلاقانه، واکنش به روندها و افزایش سطح آزمایش در این کانال‌ها سرمایه‌گذاری کنیم.
    • انتظار داریم که چالش‌هایی که با آن‌ها روبه‌رو هستیم نیاز به سرمایه‌گذاری بیشتری برای غلبه بر آن‌ها داشته باشد، به‌ویژه در تلاش‌های ارتباطی و بازاریابی برای ایجاد تعامل، همچنین همکاری میان‌بخشی برای ایجاد محصولات و تجربیات جدیدی که هدف آن‌ها افزایش حضور برند و محتوای ویکی‌پدیا در این پلتفرم‌ها است.
      • نتیجهٔ کلیدی FA2.1: تا پایان نیمهٔ نخست سال، دستیابی به ۹٬۵۰۰٬۰۰۰ بازدید از محتوای ویدئویی کوتاه در تمام کانال‌های تحت مالکیت.
        • امسال، حدود ۱ میلیون بازدید ظرف ۳ ماه پس از راه‌اندازی ویدیوهای کوتاه در کانال‌های @Wikipedia در تیک‌تاک، اینستاگرام و یوتیوب به‌دست آوردیم. انتظار داریم تا شروع سال مالی آینده، تعداد دنبال‌کنندگان کانال‌های متعلق به ما افزایش یابد و بینش‌های بیشتری درباره محتوای مؤثر و جذاب به‌دست آوریم که بتوانیم برای رسیدن به تعداد بازدیدکنندگان بیشتر به کار ببریم.
        • با تعیین هدفی بلندپروازانه در نیمه اول سال، امیدواریم به تأثیرگذاری بیشتری دست یابیم، امکان ایجاد راهبردها و فرآیندهای جدید برای تسهیل کار را فراهم کنیم و بتوانیم برای دستیابی به این هدف منابع بیشتری درخواست کنیم.
      • نتیجهٔ کلیدی FA2.2: افزایش دنبال‌کنندگان‌مان در پلتفرم تیک‌تاک از سطح میان‌رده (۱۰۰ تا ۲۵۰ هزار دنبال‌کننده) به سطح کلان (۲۵۰ هزار تا ۱ میلیون دنبال‌کننده) تا پایان سال مالی ۲۵/۲۶ (ژوئن ۲۰۲۶).
        • در حال حاضر ما در سطح میان‌ردهٔ دنبال‌کنندگان تیک‌تاک (۱۰۰ تا ۲۵۰ هزار دنبال‌کننده) قرار داریم و هدفمان این است که تا پایان سال مالی ۲۵/۲۶ (ژوئن ۲۰۲۶) به سطح کلان (۲۵۰ هزار تا ۱ میلیون دنبال‌کننده) برسیم. این سطوح — خرد، میان‌رده و کلان — معیارهای استاندارد صنعت برای سنجش اندازه و دامنهٔ مخاطبان هستند. برای دستیابی به این هدف، راهبرد محتوایی خود را بازنگری خواهیم کرد تا جذب دنبال‌کنندگان نسل Z به‌طور مؤثرتری انجام شود و از طریق مدیریت جامعه، میزان دیده‌شدن کلی خود را افزایش دهیم. عملکرد نیمهٔ نخست سال (H1) مبنای تنظیمات تاکتیکی در نیمهٔ دوم سال (H2) برای تسریع رشد و دستیابی به این نقطهٔ عطف خواهد بود.
      • نتیجهٔ کلیدی FA2.3: محصولی خارج از پلتفرم راه‌اندازی کنید که به روش‌های جدید یادگیری و مصرف رسانه‌ای مخاطبان آینده اختصاص دارد و آن را از طریق کمپین مشترک برندینگ و بازاریابی به بازار عرضه کنید.
        • بخش مخاطبان آینده معمولاً روی آزمایش‌های کوچک با بازاریابی حداقلی و ارگانیک کار می‌کند. امسال می‌خواهیم زمانی را برای محصول جدید و کمپین بازاریابی با مقیاس بزرگ‌تر که مخاطبان جوان‌تر را خارج از پلتفرم هدف قرار می‌دهد، اختصاص دهیم.

پشتیبانی محصول و مهندسی (PES)

پشتیبانی محصول و مهندسی (PES1)

  • هدف: تیم‌های محصول و مهندسی بنیاد ویکی‌مدیا به‌واسطه بهبود فرآیندها مؤثرتر عمل می‌کنند و تغییر مثبت در فرهنگ سازمانی را ترویج می‌دهند. بحث
    • زمینهٔ هدف: این هدف مربوط به سریع‌تر، هوشمندتر و بهتر کردن روش‌های کاری بنیاد ویکی‌مدیا است. همه چیز درباره نحوه کار کردن ماست. این به معنای کاهش اصطکاک و موانع (ناکارآمدی‌ها و خطاها) در فرآیندها و رسیدن سریع‌تر به تأثیر است. این هدف همچنین به یادگیری روش‌های کاری اشاره دارد که می‌توانند در سراسر دپارتمان و سازمان پذیرفته شوند.
      • نتیجهٔ کلیدی PES1.1: تا پایان سه‌ماههٔ دوم (Q2)، سطح هدف سرویس (SLO) برای ۶ سرویس تولیدی را بر اساس یک معیار اولویت‌بندی تعریف کنید که هدف آن حداکثر کردن یادگیری ما درباره نحوه تعریف و استفاده از SLO برای اتخاذ تصمیمات آگاهانه در اولویت‌بندی کارهای مرتبط با قابلیت اطمینان توسط تیم‌های ذی‌نفع است.
        • یک سطح هدف سرویس (SLO) توافقی است بین تیم‌های ذی‌نفع دربارهٔ سطح هدف‌گذاری‌شده‌ای از سرویس (قابلیت اطمینان/عملکرد) که تیم‌ها برای رسیدن به آن همکاری می‌کنند (و نه خیلی فراتر از آن). برای مثال، این کمک می‌کند تعیین شود که چه زمانی کارهای مرتبط با قابلیت اطمینان یا عملکرد باید توسط تیم توسعه اولویت‌بندی یا کاهش اولویت داده شوند، یا چه چیزی به‌عنوان یک مشکل محسوب می‌شود. تیم‌ها باید به شناسایی موارد فوری (هشداردهی/پاسخ به حادثه/باگ‌های بحرانی) در مقابل موارد غیر فوری اهمیت دهند. هدف کاهش اصطکاک بین وظایف با مذاکره برای تعیین اهداف و اطلاع‌رسانی دربارهٔ اولویت‌بندی مشترک و واضح است.
      • نتیجهٔ کلیدی PES1.2: تا پایان سه‌ماههٔ دوم (Q2)، سیگنال‌های جامعه (شامل فهرست آرزوها) بنیاد ویکی‌مدیا را به اولویت‌بندی حداقل ۵ جریان کاری محصول برای سه‌ماهه‌های سوم تا چهارم (Q3 - Q4) واداشته‌اند.
        • هدف ما شناسایی و تجلیل از زمانی است که تیم‌ها بر اساس درخواست‌های مبتنی بر شواهد جامعه، کارها را اولویت‌بندی می‌کنند.
        • دو فرضیهٔ برنامه‌ریزی‌شده به‌طور خاص بر فهرست آرزوها متمرکز هستند. این فرضیه‌ها برای افزایش اعتماد، ساده‌سازی فرآیندها و افزایش مشارکت کارکنان و داوطلبان طراحی شده‌اند. فرضیهٔ دیگری نیز آزمایشی است برای بررسی اینکه آیا سیگنال‌های ارزشمند کافی از منابعی مانند «قهوه‌خانه» وجود دارد و آیا هوش مصنوعی می‌تواند در جمع‌آوری این سیگنال‌ها به ما کمک کند.
      • نتیجهٔ کلیدی PES1.3: دو آزمایش میان‌دبخشی در مراحل اولیه، که توسط مخاطبان خارجی مصرف‌کننده، اهداکننده و مشارکت‌کننده ما تأیید شده‌اند، توسط بنیاد در برنامه سالانه گنجانده شوند.
        • این کار دربارهٔ ایجاد آزمایش‌ها و فرآیندهای آزمایشی برای پذیرش در سراسر سازمان ما است.
        • بنیاد فرهنگ آزمایش‌های میان‌دبخشی را با گنجاندن دو آزمایش اولیه تأییدشده در برنامه سالانه خود تقویت می‌کند. این ابتکار همکاری فراتر از تیم‌های ویژگی‌های دپارتمان محصول و فناوری را ترویج می‌دهد و نوآوری بیشتری با سایر دپارتمان‌های سازمان (مانند ارتباطات و پیشرفت) تشویق می‌کند. با ارائه ایده‌های جدید آزمایش‌نشده و ساده‌سازی فرآیندهای آزمایش، تیم‌ها بهره‌وری را افزایش داده و تأثیر را گسترش می‌دهند. موفقیت با انجام دو آزمایش میان‌دبخشی در سال، ادغام آن‌ها در کارهای آینده OKR و افزایش پذیرش روش‌های آزمایشی اندازه‌گیری می‌شود. نمونه‌هایی از خروجی‌ها شامل نمونه‌های اولیه جدید برای افزایش رشد و بهره‌وری ویراستاران جدید و ویژگی‌های آزمایشی است که ارتباط خوانندگان و اهداکنندگان با ویکی‌پدیا را عمیق‌تر می‌کند. یک فرصت خاص شناسایی‌شده اتصال کاوش‌های ویژگی کوچک به مناسبت جشن بیست و پنجمین سالگرد ویکی‌پدیا است.
      • 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.

فرضیه‌ها

سه‌ماههٔ نخست

سه‌ماههٔ نخست (Q1) از برنامهٔ سالانهٔ بنیاد ویکی‌مدیا، ماه‌های ژوئیه تا سپتامبر را در بر می‌گیرد.

فرضیه‌های تجربه‌های ویکی (WE)

[ نتایج کلیدی تجربه‌های ویکی (WE) ]

بحث

نام کوتاه فرضیه‌ها متن سه‌ماههٔ نخست (Q1) جزئیات و بحث
WE1.1.1 اگر از داوطلبان تازه‌وارد (یا نسبتاً تازه‌وارد) که متنی را از یک سایت خارجی کپی می‌کنند بخواهیم تأیید کنند که آیا خودشان نویسندهٔ محتوایی هستند که قصد افزودن آن را دارند یا نه، آنگاه شاهد کاهش ≥۱۰٪ در درصد ویرایش‌های محتوایی تازه‌واردان خواهیم بود که به‌دلیل نقض حق‌تکثیر (مطابق سیاست‌های مرتبط با WP:COPYVIO) واگردانی می‌شوند.
WE1.1.2 اگر نسخهٔ بتای اولیه‌ای از ویرایش پیشنهادی «بهبود لحن» ارائه کنیم، می‌توانیم دریابیم که آیا این قالب جدید از ویرایش‌های پیشنهادی راهی مؤثر برای افزایش ویرایش‌های سازندهٔ کاربران تازه‌وارد هست یا نه، بدون آن‌که بار نظارتی گشت‌زن‌ها یا بازبین‌ها افزایش یابد.
WE1.1.3 اگر یک «حالت پیشنهادی» جدید را که برای مشارکت‌کنندگان باسابقه طراحی شده، به‌عنوان یک ویژگی بتا در ویرایشگر دیداری (در نسخهٔ موبایل و دسکتاپ) با حداقل ۳ پیشنهاد ویرایش تازه ارائه کنیم، درمی‌یابیم که چه تغییراتی—در صورت نیاز—باید پیش از ارزیابی این تجربه با داوطلبان تازه‌وارد، در قالب یک آزمایش کنترل‌شده، اعمال شود.
WE1.1.4 اگر ابزار «بررسی منبع» (Reference Check) را از طریق یک آزمایش کنترل‌شده در ویکی‌پدیای انگلیسی فعال کنیم، شاهد افزایش ≥۱۰٪ در ویرایش‌های سازندهٔ کاربران تازه‌وارد خواهیم بود و همچنین درمی‌یابیم که آیا پشتیبانی کافی از سوی گشت‌زن‌ها و مدیران برای فعال‌سازی گسترده‌تر این قابلیت وجود دارد یا نه.
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 اگر هم‌زمان با انتشار پارسید (Parsoid)، ویکی‌تابع‌ها (Wikifunctions) را در بیشتر ویکی‌واژه‌ها و برخی ویکی‌پدیاهای کم‌ترافیک یکپارچه‌سازی کنیم، آزمون‌های لازم برای اجرای مطمئن در ویکی‌های بزرگ‌تر را به‌دست خواهیم آورد.
WE2.2.2 اگر امکان خروجی‌گرفتن جدول‌های اچ‌تی‌ام‌ال، استایل‌دهی و پیوندها را در ویکی‌توابع فعال کنیم، می‌توانیم با ارائهٔ تابعی که یک جدول صرف فعل را نمایش می‌دهد، توانایی این پروژه را در تولید دانش کاملاً جدید در ویکی‌واژه‌ها فراتر از تبدیل‌های ساده به نمایش بگذاریم.
WE2.2.3 اگر پشتیبانی از موجودیت‌های ویکی‌داده را در فراخوانی توابع توکار اضافه کنیم، بیش از ۲۰۰ تابع جدید امکان‌پذیر خواهد شد که می‌توانند جملات کامل را با استفاده از موجودیت‌های ویکی‌داده تولید کنند، و این باعث می‌شود استفاده از توابع در پروژه‌های ویکی‌مدیا ساده‌تر شود.
WE2.2.4 اگر یک طرح معماری برای محل استقرار محتوای انتزاعی و نحوهٔ تعامل آن با ویکی‌پدیا تهیه کنیم، آمادگی بیشتری برای پیاده‌سازی سکوی ویکی‌پدیای انتزاعی خواهیم داشت تا محتوای دانشنامه‌ای باکیفیت بیشتری فراهم کنیم.
WE2.2.5 اگر نیازهای محصول در زمینهٔ ارجاع‌هایی را که برای محتوای انتزاعی لازم هستند تعریف کرده و آن‌ها را در میان تیم‌های محصول و فناوری مطرح و هماهنگ کنیم، می‌توانیم همکاری میان‌پروژه‌ای در ویکی‌مدیا را برای ارائهٔ اطلاعات منشأ در محتوای انتزاعی پیش ببریم؛ امری که برای پذیرش موفق این محتوا در ویکی‌های مختلف حیاتی است.
WE2.2.6 اگر قالب درخواست داخلی در بک‌اند را گویا‌تر و فشرده‌تر کنیم، می‌توانیم پایداری سامانه را افزایش دهیم و از این طریق زمینه را برای گسترش وسیع‌تر فراهم سازیم.
WE2.2.7 اگر قطعه‌کدهای اولیه‌ای ارائه کنیم که با استفاده از فراخوانی‌های ویکی‌داده و ویکی‌توابع جملات طبیعی تولید می‌کنند، آمادگی پروژه را نشان خواهیم داد و برای استفاده از آن در آموزش هوش مصنوعی نیز آماده خواهیم بود، تا انسان‌ها ناچار نباشند زیاد دربارهٔ توابع فکر کنند.
WE2.2.8 اگر امکان واردکردن گزاره‌های ویکی‌داده همراه با خصیصه‌ها (qualifiers) را فراهم کنیم، تولید گزاره‌های چندوجهی ممکن خواهد شد—یعنی گزاره‌هایی که بیان آن‌ها به بیش از صرفاً موضوع/محمول/مقدار نیاز دارد—که برآورد می‌شود حدود ۵۰٪ از محتوای دانشنامه‌ای ویکی‌داده را در بر می‌گیرد.
WE2.2.9 اگر بازیابی موجودیت‌های ویکی‌داده را در حافظهٔ موقت (کش) ذخیره کنیم، میانگین زمان اجرای توابع مبتنی بر محتوای ویکی‌داده را دست‌کم ۵۰٪ کاهش خواهیم داد که این امر به کاهش خطاهای زمان‌پایان (timeout) و نارضایتی کاربران منجر می‌شود.
WE2.2.10 اگر یک مؤلفهٔ مرتبط با معنی تکواژه‌های ویکی‌داده (lexeme sense) را در رابط کاربری ویکی‌توابع ارائه کنیم، مشارکت‌کنندگان خواهند توانست تکواژه‌های مرتبط را بدون ترک سکوی ویکی‌توابع شناسایی و انتخاب کنند—که این کار باعث کاهش پرش ذهنی بین محیط‌ها و تسهیل در ساخت سریع‌تر و موفق‌تر توابع زبانی می‌شود.
WE2.2.11 اگر به یافته‌های مرتبط با قابلیت استفاده از سوی جامعهٔ دگبانی در زمینهٔ یکپارچه‌سازی ویکی‌توابع در ویکی‌پدیا رسیدگی کنیم، مشاهده خواهیم کرد که کاربران در هنگام درج یک تابع در مقاله، در مرحلهٔ آزمایش با مشکلات مهم یا بحرانی در زمینهٔ کاربری روبه‌رو نمی‌شوند یا این مشکلات به حداقل می‌رسد.
WE3.1.1 اگر نسخهٔ بهبودیافته‌ای از قابلیت مرور برگه‌ای، در نرم‌افزار آی‌اواس را با آزمون A/B بررسی کنیم، شاهد افزایش ۵٪ در استفادهٔ چندروزهٔ کاربران این قابلیت خواهیم بود.
WE3.1.3 اگر روش جدیدی برای مرور محتوای تصویری یا ویدیویی مرتبط درون صفحات مقاله فراهم کنیم، شاهد نرخ کلیک حداقل ۳٪ در میان کاربرانی خواهیم بود که این قابلیت برایشان نمایش داده می‌شود.
WE3.1.4 اگر چند مفهوم مختلف برای پیمایش در شبکهٔ دانش ویکی‌ها را به خوانندگان نشان دهیم، در نهایت فهرستی اولویت‌بندی‌شده از این مفاهیم برای توسعهٔ بیشتر به‌دست خواهیم آورد.
WE3.1.5 اگر به خوانندگان وب این امکان را بدهیم که نسخه‌ای ماشینی ترجمه‌شده از محتوای ویکی‌پدیا را—در مواردی که به زبان آن‌ها موجود نیست—مشاهده کنند، خواهیم آموخت که آیا فعالیت خواندن افزایش می‌یابد یا نه؛ این موضوع با شاخص افزایش ۳٪ در تعاملات صفحه اندازه‌گیری می‌شود و می‌تواند خوانندگان را به ویکی محلی جذب کرده و احتمالاً به افزایش فعالیت ویرایشی محلی بینجامد. این قابلیت در قالب یک آزمایش کنترل‌شدهٔ A/B به‌مدت حداکثر شش ماه و در ۱۳ ویکی‌پدیا با رضایت قبلی ارائه خواهد شد، و از خدمات ترجمهٔ ماشینیِ باز استفاده خواهد کرد که در حال حاضر در دسترس ویرایشگران ویکی‌پدیا هستند.
WE3.2.1 اگر با تیم جذب کمک مالی همکاری کنیم، اسلایدهای جذاب‌تر، یکپارچه‌تر و شخصی‌سازی‌شده‌تری برای «مرور سال» در آی‌اواس توسعه خواهیم داد که از طریق آزمون کاربری ارزیابی می‌شود. در سه‌ماههٔ دوم، این اقدام با یک فرضیه دنبال خواهد شد تا سنجیده شود که آیا نسخهٔ بهبود‌یافتهٔ «مرور سال» ۵٪ کمک مالی بیشتری نسبت به نسخهٔ سال ۲۰۲۴ دریافت کرده است یا نه.
WE3.2.2 اگر از خوانندگان در نرم‌افزار اندروید در بازارهایی که کمپین جمع‌آوری کمک مالی در آن‌ها فعال نیست بخواهیم که یادآوری اختیاری و قابل تنظیم (از نظر مبلغ و تناوب) برای اهدای کمک براساس میزان استفاده‌شان از ویکی‌پدیا تنظیم کنند، شاهد افزایش ۵٪ در کمک‌های مالی از طریق منوی برنامه در آن بازارها خواهیم بود.
WE3.2.3 اگر آزمایش A/B را روی کاربران خارج‌شده از سیستم اجرا کنیم تا نسخه‌های ملایمی از نقطه ورود به صفحهٔ اهدای کمک مالی را هم در موبایل و هم دسکتاپ نمایش دهیم، شاهد ۲٪ افزایش تعداد کمک‌ها از مسیرهای آزمایشی نسبت به مسیر کنترل خواهیم بود.
WE3.3.1 اگر عناصر شخصی‌سازی‌شده با تلاش کم تا متوسط که توسط کاربران آی‌اواس در سال ۲۰۲۴ درخواست شده‌اند را به «مرور سال» ۲۰۲۵ اضافه کنیم، افزایش ۳٪ در رضایت کاربران نسبت به سال گذشته خواهیم داشت که از طریق آزمون قابلیت استفاده یا آزمون بتا اندازه‌گیری می‌شود.
WE3.3.2 اگر زبانهٔ ویرایش موجود در اندروید را به یک مرکز فعالیت شخصی‌سازی‌شده توسعه دهیم که شامل بینش‌هایی دربارهٔ خواندن و مشارکت بدون ویرایش باشد، افزایش ۵٪ در تعامل چندروزه با این زبانه نسبت به نسخهٔ اولیه مشاهده خواهیم کرد.
WE3.3.3 اگر حداقل یک آواتار قابل بازشدن در برنامهٔ اندروید برای دارندگان حساب معرفی کنیم—که از طریق اقدامات معنادار خوانندگان مانند ذخیرهٔ تعداد مشخصی مقاله به‌دست می‌آید—تعامل مکرر کاربران واردشده با این اقدام طی چند روز، ۱۰٪ افزایش خواهد یافت.
WE3.3.4 اگر به خوانندگان واردشده امکان ذخیرهٔ مقالات در فهرست مطالعهٔ خصوصی داده شود، انتظار می‌رود تعامل با سایت افزایش یابد؛ این افزایش از طریق ۵٪ رشد در ترافیک ارجاع داخلی برای کاربرانی که از این قابلیت استفاده می‌کنند و افزایش معنادار آماری برای همهٔ کاربران اندازه‌گیری خواهد شد.
WE3.3.5 اگر مطالعه‌ای روی کاربران وب انجام دهیم که به آن‌ها امکان ساخت مجموعه‌هایی با استفاده از محتوای ویکی‌پدیا را می‌دهد، دست‌کم ۱۰٪ از شرکت‌کنندگان حداقل دو نوع متفاوت از محتوا (مانند مقاله، بخش‌هایی از مقاله، رسانه) را در یک مجموعه ذخیره خواهند کرد.
WE3.4.1 اگر به سمت استقرار ترکیبی PoP/CDN پیش برویم، این امکان را خواهیم داشت که بسته به نیاز، هم PoPهای کامل و هم مینی PoPهای فیزیکی و ابری را راه‌اندازی کنیم که زمینه را برای استقرار نمونهٔ اولیه مینی PoP در آینده فراهم می‌کند.
WE3.6.1 اگر آزمایش A/A روی نرخ ماندگاری کاربران خارج‌شده انجام دهیم، پایه‌ای برای نرخ ماندگاری ایجاد خواهیم کرد که می‌توانیم برای سه‌ماهه‌های آینده از آن استفاده کنیم.
WE3.6.2 اگر تعریف «خوانندهٔ واردشده» را ایجاد و منتشر کنیم، قادر خواهیم بود این تعریف را در تمام تیم‌ها و فرضیه‌های مرتبط با نتایج کلیدی WE 3.3 به کار ببریم.
WE3.6.3 اگر جوامع را در گفت‌وگو دربارهٔ نیازهای در حال تحول خوانندگان و تغییر ماهیت دانش در اینترنت درگیر کنیم، می‌توانیم تمرکز مشترکی بر نحوهٔ خدمت‌رسانی به خوانندگان ایجاد کنیم و با هم بر سر این‌که کدام ایده‌هایمان را چگونه و آیا باید آزمایش کنیم توافق کنیم (از جمله ایده‌هایی دربارهٔ چندرسانه‌ای، جستجو و کشف، و یادگیری ماشین).
WE3.6.4 اگر انگیزه‌ها، رفتارها و نیازهای متمایز مربوط به زمان، دلیل و نحوهٔ استفادهٔ خوانندگان از ویکی‌پدیا و دیگر پلتفرم‌های دانش را بررسی کنیم، یافته‌هایی خواهیم داشت که می‌توانیم از آن‌ها برای اطلاع‌رسانی و توسعهٔ استراتژی کاربران بهره بگیریم.
WE4.1.1 اگر یک نمونهٔ اولیهٔ حداقلی از روند غیرضروری ایجاد کنیم و در حین توسعه با کاربران دارای دسترسی‌های گسترده، یک چرخهٔ بازخورد تکرارشونده باز نگه داریم، این گروه‌ها از گسترش استقرار این روند حمایت خواهند کرد. Project page
WE4.2.1 اگر سطح ریسک hCaptcha مرتبط با ایجاد حساب را به مسئولان مورد اعتماد نشان دهیم، زمان شناسایی بازیگران بد را کاهش داده و تعداد حساب‌های بازیگران بد ایجادشده در پلتفرم را افزایش خواهیم داد. موفقیت این فرضیه را می‌توان با بررسی نرخ مسدودسازی حساب‌ها، تطابق سطح ریسک hCaptcha با مسدودسازی‌های حساب‌ها و بازخورد کیفی از سوی مسئولان ارزیابی کرد.
WE4.2.2 اگر تحقیقات پیشنهادی برای پیگیری توسط بازرسان تولید کنیم، زمان لازم برای شناسایی حساب‌های بازیگران بد کاهش یافته و تعداد حساب‌های شناسایی‌شده افزایش خواهد یافت. موفقیت را زمانی می‌دانیم که استفادهٔ منظم از ویژگی «تحقیقات پیشنهادی»، افزایش اقدامات اصلاحی بر حساب‌های شناسایی‌شده از طریق این تحقیقات، و بازخورد کیفی نظرسنجی مشاهده شود.
WE4.2.3 اگر داده‌های آزمایش ایجاد حساب با hCaptcha را تحلیل کنیم، روند ایجاد حساب، اثربخشی معماها و امتیازهای hCaptcha را درک خواهیم کرد و داده‌های لازم برای تصمیم‌گیری دربارهٔ گسترش بیشتر استفاده از hCaptcha در ایجاد حساب‌ها را به‌دست خواهیم آورد.
WE4.2.4 اگر کارت اطلاعات کاربر (UserInfoCard) را در تمام ویکی‌ها مستقر کنیم، به مسئولان و ناظران کمک خواهیم کرد تا حساب‌های بازیگران بد را سریع‌تر شناسایی و مدیریت کنند. Project page
WE4.2.5 اگر پژوهش انجام داده، با جوامع مشورت کنیم و راه‌حل‌های فنی را بررسی کنیم، قادر خواهیم بود مجموعه‌ای از دلایل ساختاریافته برای مسدودسازی تعریف کنیم که در تمام ویکی‌های بنیاد ویکی‌مدیا قابل استفاده باشند.
WE4.2.6 اگر قابلیت استقرار خوشه‌های مبتنی بر OpenSearch را در بستر داده‌ها توسعه دهیم، تیم‌های مهندسی ویژگی‌های محصول قادر خواهند بود سیستم‌هایی را با این قابلیت توسعه دهند که از استقلال، پایداری و جداسازی بالایی نسبت به سایر سیستم‌های جستجو برخوردار باشند. اولین و اصلی‌ترین بهره‌بردار این سیستم، سرویس IPoid خواهد بود.
WE4.2.7 اگر ادغام شرکت hCaptcha را به‌عنوان یک آزمایش پایلوت در چند ویکی‌پدیای تولیدی مستقر کنیم، قادر خواهیم بود داده‌هایی درباره اثربخشی و ارزش شرکت hCaptcha در زمینه‌های ضدسوءاستفاده، شناسایی ربات‌ها، قابلیت استفاده و دسترسی‌پذیری جمع‌آوری کنیم.
WE4.3.1 اگر پشتیبانی از کوکی جدید اج یونیکس (Edge Uniques) را در ریکوئست‌سی‌تی‌ال (requestctl)، موتور قوانین لبه‌ای ما برای SREها مبارزه با سوءاستفاده، ادغام کنیم، بهتر قادر خواهیم بود از حملات DDoS و بازاستفاده از محتوا دفاع کنیم.
WE4.4.1 اگر بتوانیم بر اساس بازخوردهای پایلوت بهبودهایی ایجاد کنیم و حساب‌های موقت را در تمام پروژه‌ها مستقر کنیم، قادر خواهیم بود افشای اطلاعات شناسایی‌پذیر شخصی (آدرس‌های آی‌پی) کاربران ثبت‌نام‌نشده را در تمام پروژه‌هایمان به کمتر از ۰.۱٪ از کل کاربران (ثبت‌نام‌شده) محدود کنیم. Project page
WE4.4.2 اگر با ذی‌نفعان مرتبط جنبش (شامل جوامع ویکی و مسئولان جهانی) به‌صورت شفاف و به‌موقع ارتباط برقرار کنیم، قادر خواهیم بود در تمام ویکی‌های باقی‌مانده مستقر شویم، بار کاری کشف‌شده در آخرین لحظه را کاهش دهیم و از بازگرداندن استقرار جلوگیری کنیم.
WE4.4.3 اگر فیلتر کردن عملیات و مشاهدهٔ فعالیت حساب‌های موقت بر اساس آدرس‌های آی‌پی برای بازرس‌ها آسان‌تر شود، آنگاه امکان استقرار موفق حساب‌های موقت در تمام ویکی‌ها فراهم خواهد شد.
WE4.4.4 اگر فیلتر کردن عملیات و مشاهده فعالیت حساب‌های موقت بر اساس آدرس‌های آی‌پی برای بازرس‌ها آسان‌تر شود، آنگاه امکان استقرار موفق حساب‌های موقت در تمام ویکی‌ها فراهم خواهد شد.
WE4.5.1 اگر پژوهش کیفی انجام دهیم تا نمونه‌هایی از سوءاستفاده‌های بازیگران مخرب که با کمک هوش مصنوعی مولد انجام می‌شود (مانند هرزنامه، آزار و اذیت، سوءاستفاده‌های بلندمدت، ویرایش‌های پولی افشانشده یا کمپین‌های اطلاعات نادرست) را شناسایی کنیم، قادر خواهیم بود ریسک‌های مدل‌های جامعه‌مان را ارزیابی کرده و ایده‌هایی برای کاهش انواع مختلف سوءاستفاده‌های همراه با هوش مصنوعی مولد ارائه دهیم.
WE4.6.1 اگر فرایند همگام‌سازی حساب در زندسک برای بازنشانی رمز عبور خودکار شود، این امر بار کاری تیم اعتماد و ایمنی (T&S) را کاهش داده و به آن‌ها امکان می‌دهد تعداد بیشتری درخواست بازنشانی ورود دو مرحله‌ای را مدیریت کنند.
WE4.6.2 اگر از کاربران حمایت کرده و آن‌ها را تشویق کنیم که عوامل احراز هویت چندگانه ثبت کنند، کاربران با ورود دو مرحله‌ای فعال کمتر احتمال دارد که خود را از حسابشان قفل کنند.
WE4.6.3 اگر به همه کاربران دارای آدرس ایمیل تأییدشده اجازه دهیم تا احراز هویت دو مرحله‌ای را برای حساب‌های خود فعال کنند، اما این تغییر را به‌صورت پیشگیرانه به کاربران اطلاع ندهیم، بار کاری بخش پشتیبانی بازیابی ما در سطح قابل‌تحمل باقی خواهد ماند.
WE5.1.1 اگر برای نشست‌های احراز شده و ناشناس از زیرساخت‌های ذخیره‌سازی متفاوت استفاده کنیم، قادر خواهیم بود Sessionstore را از حملات DDoS و اسکریپرهای با حجم بالا محافظت کنیم، زیرا بار بیش از حد ناشی از نشست‌های ناشناس که برای جلوگیری از CSRF در صفحات احراز هویت ایجاد می‌شوند را کاهش می‌دهد. T398814
WE5.1.2 اگر کوکی‌های نشست مدیاویکی را به قالب ساختاریافته‌ای با امضای رمزنگاری‌شده تغییر دهیم، قادر خواهیم بود از وجود یک نشست به‌عنوان عاملی برای محافظت در برابر اسکریپرها استفاده کنیم، با فعال‌سازی تأیید اعتبار قابل اعتماد نشست‌ها در لبه شبکه به شکلی پرکارآمد و بسیار مقیاس‌پذیر. T398815
WE5.1.3 اگر راه‌حلی برای محدودسازی نرخ در دروازهٔ اِی‌پی‌آی با استفاده از محیط توسعهٔ محلی مبتنی بر کوبرنتیز ایجاد کنیم، قادر خواهیم بود بهترین گزینه برای آزمایش با ترافیک تولید را با مقایسه عملکرد و قابلیت‌های حداقل سه سرویس محدودسازی نرخ مختلف تعیین کنیم. T398913
WE5.2.1 اگر رابط کاربری محیط آزمایش REST اِی‌پی‌آی را بازطراحی کنیم تا بهتر نیازهای اطلاعاتی توسعه‌دهندگان را برآورده کند، با آزمون قابلیت استفاده، وضوح مستندات را بهبود خواهیم داد.
WE5.2.2 اگر تمام اِی‌پی‌آی‌ها زیر rest.php را از طریق یک دروازه مرکزی مسیریابی کنیم، امکانات مدیریت متمرکز اِی‌پی‌آی را فراهم کرده و می‌توانیم به‌طور مستمر ترافیک و الگوهای استفاده REST ای‌پی‌آی را اندازه‌گیری کنیم تا بینش‌هایی برای تصمیم‌گیری‌ها و اقدامات آینده به دست آوریم.
WE5.2.3 اگر داشبوردها و هشدارهای نظارتی برای REST ای‌پی‌آی مدیاویکی پیاده‌سازی کنیم، ممکن است روشی پایدار، مفید و قابل تکرار برای بهبود دید سیستم‌های خود و شناسایی سریع‌تر مشکلات، به‌ویژه در زمان تغییرات بحرانی، ارائه دهیم.
WE5.3.1 اگر دستورالعمل‌های نسبت‌دهی تجربه کاربری (UX) را گسترش داده و ساده کنیم و در عین حال دستورالعمل‌های موجود را به‌روزرسانی کنیم، مجموعه‌ای اصلی از دستورالعمل‌های بهبود یافته ایجاد خواهیم کرد که آماده آزمایش داخلی و پالایش تدریجی برای استفاده عمومی گسترده‌تر باشد.
WE5.3.2 اگر پیشنهادی تهیه کنیم که مزایای نسبت‌دهی ویکی‌پدیا به بازاستفاده‌کنندگان محتوای شخص ثالث و کاربران نهایی آن‌ها را نشان دهد، می‌توانیم با فعال‌کردن حداقل یک شریک بازاستفاده اضافی برای توافق بر حضور در مطالعه موردی یا دمو نسبت‌دهی تا پایان سه‌ماههٔ اول (Q1)، از WME4.1 و WME4.2 حمایت کنیم.
WE5.4.1 اگر اطمینان حاصل کنیم که اکثریت درخواست‌های وب کوکی اج یونیکس (Edge Uniques) دریافت می‌کنند، شناسایی ربات‌ها و درخواست‌های جعل‌شده آسان‌تر خواهد شد.
WE5.4.2 اگر روش مقیاس‌پذیری برای شناسایی مشتریان شناخته‌شده بسازیم، می‌توانیم استثناهایی برای محدودیت‌های کلی نرخ برای ربات‌های دارای منشأ تأییدشده فراهم کنیم و به سمت اجرای سیستماتیک قوانین خود حرکت کنیم.
WE5.4.3 اگر فیلتر کردن درخواست‌های متنی در CDN را حول رویکرد فهرست مجاز/فهرست ممنوع سازمان‌دهی کنیم، می‌توانیم محدودیت نرخ کلی سخت‌گیرانه‌تری برای ربات‌ها اعمال کرده و فرآیند فیلتر کردن ترافیک را ساده‌تر کنیم.
WE5.4.4 اگر یک استراتژی اندازه‌گیری یکپارچه توسعه دهیم، امکان ارزیابی استراتژی چندساله «استفاده مسئولانه از زیرساخت» را فراهم کرده و نقشه‌راهی برای راهنمایی توسعه معیارها و قابلیت‌های گزارش‌دهی تعریف خواهیم کرد.
WE6.1.1 اگر ساخت‌های روزانه تصاویر را به سرور استقرار منتقل کنیم و به‌روزرسانی تصاویر را که توسط برخی اقدامات استقرار فعال می‌شوند اضافه کنیم، محدودیت‌ها را کشف کرده و پایه‌ای برای زمان لازم جهت انجام استقرارهای پیوسته‌تر ایجاد خواهیم کرد.
WE6.1.3 اگر ویکی‌فارم‌ها را به محیط تست پیش از ادغام اضافه کنیم، این امکان را برای تیم‌های توسعه فراهم می‌کند که هنگام ساخت روی محیط تولید و نیاز به چند ویکی دارند، پچ‌های خود را به‌صورت جداگانه آزمایش کنند، که به افزایش اطمینان پیش از تولید و کاهش خروجی‌های دارای اشکال منجر می‌شود.
WE6.2.1 اگر چک‌لیست آمادگی تولید خود را بازبینی و منتشر کنیم که پیش‌نیازهای لازم برای آماده‌بودن یک سرویس برای تولید را به‌وضوح تعریف می‌کند، همراه با وظایف خودخدمت‌رسان، انتظارات بین SREها و تیم‌های توسعه را هماهنگ کرده و کارایی عملیاتی و مقیاس‌پذیری کلی ما را بهبود خواهیم داد.
WE6.2.2 اگر اعلام کنیم که در حال ایجاد کتابخانه‌هایی برای Golang و Node.js هستیم که بسیاری از وظایف دشوار را برای توسعه‌دهندگان ساده می‌کند، آن‌ها با ارائه بازخورد و ابراز علاقه پاسخ خواهند داد.
WE6.2.3 اگر یک چک‌لیست یا برگهٔ کاری تهیه کنیم، توسعه‌دهندگان می‌توانند به‌طور کامل پیشاپیش برای بازبینی طراحی ماندگاری داده‌ها آماده شوند.
WE6.3.1 اگر حداقل ۷۰ ویکی‌پدیای کم‌ترافیک را در سه‌ماههٔ اول (Q1) بدون احتساب ویکی‌هایی با پشتیبانی از گونه‌های زبانی راه‌اندازی کنیم، اطمینان ما برای راه‌اندازی نهایی در ۱۰ ویکی برتر که تأثیر بیشتری بر بازدید صفحات از طریق پارسید خواهد داشت، افزایش خواهد یافت.
WE6.4.1 اگر جداسازی جدول پیوندهای ویکی‌انبار را در خوشه‌ای مجزا مستقر کنیم، احتمال پایداری رشد پایگاه داده ویکی‌انبار افزایش خواهد یافت. T398709
WE6.4.2 اگر SREها به تیم‌های مهندسی مدیاویکی با ایجاد مستندات، آماده‌سازی زیرساخت‌های لازم (مانند بسته‌های PHP، تصاویر کانتینر) و ارائه راهنمایی و بازبینی کمک کنند، آن‌ها قادر خواهند بود با اطمینان ارتقاء PHP به نسخه ۸.۳ را تا آغاز سه‌ماههٔ دوم (Q2) آغاز کنند. T360995
WE6.4.3 اگر برای ورود SSH کاربران دارای دسترسی‌های سیستمی ارتقا یافته، استفاده از عامل دوم فیزیکی (کلید امنیتی سخت‌افزاری) را الزام کنیم، ریسک نفوذ شدید ناشی از لپ‌تاپ‌های به خطر افتاده کاهش خواهد یافت.
WE6.4.4 اگر دامنه‌های خود را یکپارچه کنیم و همهٔ بازدیدهای صفحات در وب‌گاه‌های مدیاویکی را از طریق یک دامنهٔ معیار ارائه دهیم، با حذف تغییرمسیر زیر‌دامنهٔ موبایل، پیچیدگی پلتفرم و خطرهای مربوط به بهینه‌سازی برای موتورهای جستجو (SEO) کاهش خواهد یافت. میزان تکمیل این هدف با کاهش تغییرمسیرها برای بازدیدهای موبایلی در دامنه‌های معیار از ۱۰۰٪ به ۰٪ سنجیده می‌شود. 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
فرضیه‌های سرویس‌های سیگنال و داده (SDS)

[ نتایج کلیدی سرویس‌های سیگنال و داده (SDS) ]

بحث

نام کوتاه فرضیه‌ها متن سه‌ماههٔ نخست (Q1) جزئیات و بحث
SDS1.1.1 اگر اثربخشی روش‌های کشف خودکار ترافیک در مجموعهٔ داده‌های بازدید صفحات خود را تحلیل کنیم، قادر خواهیم بود معیارهای کیفیت داده برای توصیف عملکرد آن‌ها توسعه داده و نیاز به سرمایه‌گذاری بیشتر در این روش‌ها را تعیین کنیم.
SDS1.2.2 اگر فرآیند خروجی‌های XML را از زیرساخت فعلی «Dumps 1» به خط لوله داده‌ای که از خط لوله‌های محتوای مدیاویکی بهره می‌برد منتقل کنیم، قادر خواهیم بود سطح سرویس‌های مورد انتظار (SLO) را تضمین کرده و صادرات XML مبتنی بر «Dumps 1» را غیرفعال کنیم.
SDS1.2.3 اگر مرور و بازبینی SLOهای تاریخچه محتوای مدیاویکی و پلتفرم رویداد / دروازه رویداد را انجام دهیم، می‌توانیم مشتریان، معیارها و ذی‌نفعان وابسته را تأیید کرده و بهبودهای احتمالی مورد نیاز برای SLOها را شناسایی کنیم که به ما در شفاف‌سازی هرگونه شکاف در تضمین‌های تحویل هفتگی کمک خواهد کرد.
SDS2.1.1 اگر به‌طور نزدیک با تیم‌های اجرای آزمایش‌ها همکاری کنیم، خواهیم آموخت چگونه سیستم را در آینده خودخدمت‌رسان‌تر کنیم و با چه چالش‌های مفهومی یا فنی ممکن است روبه‌رو شوند.
SDS2.1.2 اگر بتوانیم اشکال‌زدایی بهتری برای ثبت رویدادها پیاده‌سازی کنیم، تیم‌های محصول خواهند دانست که آزمایش آن‌ها داده‌های رویداد را طبق انتظار جمع‌آوری می‌کند و این باعث افزایش اعتماد مالکان آزمایش خواهد شد.
SDS2.1.3 اگر ثبت لاگ و قابلیت مشاهدهٔ سیستم آزمایش A/B (xLab) و اجزای مرتبط مدیاویکی را بهبود بخشیم، قادر خواهیم بود پایه‌هایی برای عملکرد سیستم تعیین کرده و به خطاهای مرتبط با آزمایش پاسخ دهیم.
SDS2.1.4 اگر هر ماه داستان‌ها و نتایج آزمایش‌ها را در سراسر سازمان به اشتراک بگذاریم (از طریق جلسات عملیات محصول، جلسات تیم طراحی و ارائه‌های بین‌تیمی)، پذیرش طبیعی پلتفرم آزمایش را ایجاد خواهیم کرد.
SDS2.1.5 اگر به کاربران اطلاع دهیم که ابزار آن‌ها، در صورت ایجاد در xLab، شامل مجموعه‌ای از ویژگی‌ها است که دسته‌بندی ریسک را تغییر می‌دهد، از جمع‌آوری بیش از حد داده توسط کاربران ابزار جلوگیری کرده و وضوح بیشتری دربارهٔ ترکیب ویژگی‌هایی که نیازمند بررسی حریم خصوصی هستند ایجاد خواهیم کرد.
فرضیه‌های مخاطبان آینده (FA)

[ نتایج کلیدی مخاطبان آینده (FA) ]

بحث

نام کوتاه فرضیه‌ها متن سه‌ماههٔ نخست (Q1) جزئیات و بحث
FA1.1.1 اگر ۱) به گردآورندگان رسانه در سایر پلتفرم‌ها (مانند Letterboxd، Goodreads و RateMyMusic) امکان دهیم که مجموعه‌های خود را با دانش اختصاصی ویکی‌پدیا غنی کنند، یا ۲) به این گردآورندگان رسانه، محتوای جذاب قابل اشتراک‌گذاری در شبکه‌های اجتماعی ارائه کنیم، قادر خواهیم بود دسترسی ویکی‌پدیا را فراتر از پلتفرم افزایش دهیم.
FA2.1.1 اگر در سه‌ماههٔ اول (Q1) ظرفیت داخلی خود را برای تولید محتوای ویدیویی کوتاه با افزایش اندازه تیم و بررسی و شناسایی فرصت‌های افزایش بهره‌وری در فرآیند تولید فعلی افزایش دهیم، قادر خواهیم بود از آموخته‌های محتوای تولیدشده در سال مالی ۲۰۲۴-۲۰۲۵ بهره‌برداری کنیم و به دسترسی سالانه بالاتری برای محتوای تولیدشده در سه‌ماههٔ دوم سال مالی ۲۰۲۵-۲۰۲۶ دست یابیم.
فرضیه‌های پشتیبانی محصول و مهندسی (PES)

[ نتایج کلیدی پشتیبانی محصول و مهندسی (PES) ]

بحث

نام کوتاه فرضیه‌ها متن سه‌ماههٔ نخست (Q1) جزئیات و بحث
PES1.1.1 اگر از xLab، Charts و ToneCheck در تعریف معیارهای شاخص سطح سرویس (Service Level Indicators) در Prometheus حمایت کنیم و آن اهداف سطح خدمات (SLOs) را در Pyrra راه‌اندازی کنیم، محدودیت‌ها و موارد خاص ابزارهای خود را در چندین سناریوی پیچیده خواهیم شناخت و همچنین مشخص خواهیم کرد که چه اصلاحاتی برای قالب SLO لازم است، که این به ما کمک می‌کند بهتر از ۶ SLO برنامه‌ریزی‌شده برای نتیجه کلیدی حمایت کنیم.
PES1.1.2 اگر از گروه بستر داده‌ها در بازبینی و بازنگری سطح هدف سرویس (SLO) پروژه تاریخچه محتوای مدیاویکی حمایت کنیم، خواهیم آموخت چگونه از SLOها برای پشتیبانی از مالکیت سرویس بهره ببریم وقتی ترکیبی از خدمات پردازش دسته‌ای و جریانی با هم هماهنگ می‌شوند تا مجموعه داده را به‌روز، سازگار و در دسترس کاربران پایین‌دستی نگه دارند.
PES1.1.3 اگر به گروه ویکی‌پدیا انتزاعی در تهیه پیش‌نویس SLO (اهداف سطح خدمات) برای پروژه ویکی‌توابع ادامه دهیم، یاد خواهیم گرفت چگونه فهرستی از اهداف SLO (همراه با معیارهای شاخص سطح سرویس مرتبط) را برای ویژگی پیچیده‌ای که در حال حاضر به یک جریان کاری حیاتی کاربر اضافه می‌شود، تعریف کنیم: رندر کردن مقالات ویکی. همچنین یاد خواهیم گرفت چگونه بودجه‌های خطای مرتبط را به‌درستی مصور کرده و با استفاده از داشبوردها و مانیتورهای ارائه‌شده توسط SRE هشدار دهیم.
PES1.1.4 اگر از گروه پلتفرم داده در بازبینی و تکرار اهداف سطح خدمات (SLO) پروژه تاریخچه محتوای مدیاویکی حمایت کنیم، یاد خواهیم گرفت چگونه از SLOها برای حمایت از مالکیت سرویس زمانی استفاده کنیم که ترکیبی از خدمات پردازش دسته‌ای و جریان داده با هم هماهنگ شده‌اند تا مجموعه داده را به‌روزرسانی کنند و آن را برای کاربران پایین‌دستی سازگار و در دسترس نگه دارند.
PES1.2.1 اگر ۳ بهبود هدفمند در فهرست آرزوها ایجاد کنیم، تعداد شرکت‌کنندگان یکتای فهرست آرزوها را ۳۰٪ افزایش خواهیم داد.
PES1.2.2 اگر خواسته‌های ورودی را در ۷۲ ساعت بررسی اولیه کنیم و یک نگهدارنده (مانند مدیران محصول) برای آن‌ها تعیین کنیم (شامل رد کردن، روشن‌سازی، علامت‌گذاری خدمات بدون نگهدار و غیره)، با تطبیق خواسته‌های جدید با جدول نگهدارندگان و تخصیص «دسته نگهدارنده» به مرتبط‌ترین تیم یا فرد محصول، نگهدارندگان قادر خواهند بود خواسته‌ها را ظرف ۱۰ روز یا کمتر ارزیابی و پاسخ دهند.
PES1.2.3 اگر کار آزمایشی برای شناسایی سیگنال‌های کلی جامعه انجام دهیم، صدای بیشتری از داوطلبان را در تلاش‌های اولویت‌بندی مبتنی بر جامعه وارد خواهیم کرد.
PES1.2.4 اگر فرآیند بررسی سه‌ماههٔ آرزوها و سیگنال‌های جامعه را با ۳ تیم در سه‌ماههٔ اول (Q1) آزمایش کنیم، مدیران محصول را درگیر خواهیم کرد تا سیگنال‌های جامعه را در فرآیندهای برنامه‌ریزی سه‌ماهه و سالانه خود ادغام کنند.
PES1.3.1 اگر تا پایان سه‌ماههٔ اول (Q1) سه جلسهٔ برنامه‌ریزی عملکردی با بخش ارتباطات و تیم‌های محصول برای هماهنگی در پیام‌رسانی، نیازهای خلاقانه و جدول زمانی کمپین‌های ابتکارات WP25 برگزار کنیم، خلاصه‌های خلاقانه برای هر سه آزمایش کمپین (25YiR، Easter Eggs، WikiRun) نهایی خواهد شد.
PES1.3.2 اگر کمیتهٔ راهبری با نمایندگان طراحی و مهندسی ویژگی‌ها تشکیل دهیم، قادر خواهیم بود معیارهای پایه‌ای درباره مشارکت‌ها در کدکس تعریف کنیم: آگاهی، استفاده، کیفیت مشارکت و کمیت. بینش‌های به‌دست‌آمده از ارزیابی این معیارهای پایه به ما کمک می‌کند نقشه‌راهی برای رشد فدرالی و تنوع‌بخشی به پایگاه مشارکت‌کنندگان کدکس تعیین کنیم.

Q2

فصل دوم (Q2) از برنامهٔ سالانهٔ بنیاد ویکی‌مدیا، دورهٔ اکتبر تا دسامبر را در بر می‌گیرد.

فرضیه‌های تجربه‌های ویکی

[ نتایج کلیدی تجربه‌های ویکی ]

بحث

نام کوتاه فرضیه‌ها متن سه‌ماههٔ دوم (Q2) جزئیات و بحث
WE1.1.1 اگر مجموعه‌ای از شاخص‌های پیش‌نگر از پیش تعیین‌شده را دست‌کم دو هفته پس از آغاز آزمایش A/B ویژگی Paste Check تحلیل کنیم، خواهیم توانست تشخیص دهیم کدام جنبه‌ها — در صورت وجود — از تجربهٔ سرتاسری نیاز به تنظیم یا بررسی دارند تا پیش از ارزیابی تأثیر این ویژگی، اطمینان لازم را به دست آوریم.
WE1.1.4 اگر ویژگی Reference Check را از طریق یک آزمایش کنترل‌شده در ویکی‌پدیای انگلیسی اجرا کنیم، شاهد افزایش ≥۴٪ در تعداد ویرایش‌های سازنده‌ای خواهیم بود که داوطلبان تازه‌تر منتشر می‌کنند و همچنین درمی‌یابیم که آیا پشتیبانی کافی از سوی گشت‌زن‌ها و مدیران برای فعال‌سازی گسترده‌تر این ویژگی وجود دارد یا نه.
WE1.1.7 اگر مجموعه‌ای از شاخص‌های پیش‌نگر از پیش تعیین‌شده را دست‌کم دو هفته پس از آغاز آزمایش A/B ویژگی Tone Check تحلیل کنیم، خواهیم توانست تشخیص دهیم کدام جنبه‌ها — در صورت وجود — از تجربهٔ سرتاسری نیاز به تنظیم یا بررسی دارند تا پیش از ارزیابی تأثیر این ویژگی، اطمینان لازم را به دست آوریم.
WE1.1.8 اگر مدل Tone Check را بر مقاله‌های منتشرشده اعمال کنیم، درمی‌یابیم که آیا می‌توانیم ≥۱۰٬۰۰۰ مورد مشکل لحن (هر یک با امتیاز احتمال ۰٫۸ یا بالاتر) را شناسایی کنیم یا نه؛ این مجموعه برای ایجاد یک مخزن پیشنهادهای باکیفیت (با دقت ≥۷۰٪) به‌منظور راهنمایی ویرایشگران در بهبود لحن مقاله‌ها مورد نیاز است.
WE1.1.10 اگر حدود ۱۰ داوطلب باتجربه در ویکی‌پدیای انگلیسی و فرانسوی را که برای خودکارسازی فرایندهای گشت‌زنی و مدیریت، فیلترهای سوءاستفاده (AbuseFilters) و سایر ابزارها/اسکریپت‌ها/الگوها/اعلان‌های ویرایشی می‌نویسند، مصاحبه کنیم، دست‌کم ۳ الگو یا نیاز را شناسایی خواهیم کرد که به شکل‌گیری پیشنهاد ارزشِ ویرایش‌بررسی‌های ساخته‌شده توسط جامعه کمک خواهد کرد.
WE1.1.11 اگر پرسش‌نامه‌ای را میان ≥۵۰۰ تازه‌وارد موفق[i] توزیع کنیم و داده‌های باکیفیت و نماینده‌ای از جمعیت گسترده‌تر تازه‌واردان موفق به دست آوریم، خواهیم توانست دست‌کم ۴ بینش کاربردی شناسایی کنیم که بتوان از آن‌ها برای اولویت‌بندی جنبه‌هایی از تجربهٔ آغاز به کار که نیاز به بهبود دارند، استفاده کرد.
WE1.1.12 اگر برای هر یک از ۱۰ زبان جدیدی که قصد گسترش ویژگی Tone Check به آن‌ها را داریم، دست‌کم ۳ داوطلب را قادر سازیم تا هرکدام ≥۳۰ نمونه ویرایش را ارزیابی کنند، درمی‌یابیم که داوطلبان تا چه اندازه با پیش‌بینی‌های مدل موافق‌اند و می‌توانیم تصمیم بگیریم با کدام ویکی‌های جدید برای استقرار Tone Check وارد همکاری شویم.
WE1.1.13 با توجه به این‌که ویژگی «افزودن یک پیوند» را برای ۱۰۰٪ از داوطلبان تازه‌وارد در ویکی‌پدیای انگلیسی گسترش داده‌ایم، فعال‌سازی و نگهداشت سازندهٔ تازه‌واردان بهبود خواهد یافت، که این امر موجب افزایش ≥۴٪ در ویرایش‌های سازندهٔ انجام‌شده توسط داوطلبان تازه‌وارد می‌شود.
WE1.2.3 اگر شرط داشتن دسترسی «سازمان‌دهندهٔ رویداد» برای استفاده از قابلیت ثبت‌نام رویداد در ویکی‌های کوچک و متوسط را حذف کنیم، تا پایان سال مالی شاهد ایجاد دست‌کم X رویداد بیشتر* در این ویکی‌ها خواهیم بود.
  • محاسبهٔ خط مبنا/هدف در انتظار است.
WE1.2.4 اگر نسخهٔ اولیهٔ قابلیت «مشارکت‌های همکارانه» (MVP) را با دست‌کم ۲ بهبود بازبینی کنیم، شمار همکاری‌هایی که از طریق قابلیت ثبت‌نام رویداد ایجاد می‌شوند افزایش خواهد یافت.
WE1.2.5 اگر در اوایل فصل دوم یک راهبرد پذیرش برای قابلیت ثبت‌نام رویداد در ویکی‌مدیای کامنز تعیین کنیم، خواهیم توانست آن را با سازمان‌دهندگان دست‌کم یک کارزار بزرگ آزمایش کرده و ۵ سازمان‌دهندهٔ محلی را برای استفاده از این قابلیت توانمند سازیم.
WE1.3.3 اگر آزمایشی را برای نمایش یک پیشخوان مدیریتی به ویرایشگران تازه‌تر راه‌اندازی کنیم، ۱۰٪ از مشارکت‌کنندگانی که از آن بازدید می‌کنند، دو هفتهٔ پیاپی این کار را تکرار خواهند کرد.
WE1.4.1 اگر بهبودهای تعریف‌شده در T396489 را اعمال کنیم، تعداد کوئری‌های کند مربوط به تغییرات اخیر در ویکی‌های بزرگ را دست‌کم ۳۰٪ کاهش خواهیم داد، که این امر به تیم فناوری جامعه (Community Tech) امکان می‌دهد قابلیت برچسب‌های فهرست پی‌گیری را بدون ایجاد بار اضافی بر پایگاه دادهٔ تغییرات اخیر اجرا کند.
WE1.4.3 اگر ابزار ثبت داده را برای تغییرات اخیر و فهرست پی‌گیری فعال کنیم، می‌توانیم خط مبنایی برای بسامد کلیک کاربران بر روی صفحه‌ها تعریف کنیم.
WE1.5.1 اگر یک داشبورد برای بررسی ۷ شاخص مشارکت‌کنندگان پیاده‌سازی کنیم و محاسبهٔ دست‌کم یکی از شاخص‌ها را با استفاده از dbt استاندارد کنیم، خواهیم توانست تیم‌های محصول مرتبط با مشارکت‌کنندگان را قادر سازیم تا به‌صورت مستقل به بینش‌های شاخص‌ها دست یابند و همچنین استانداردی برای ذخیرهٔ منطق محاسبهٔ شاخص‌ها ایجاد کنیم.
WE1.5.2 اگر در فصل دوم مشخص کنیم کدام اقدامات مدیریتی باید در تعریف «مدیر» گنجانده شوند، تیم بینش‌های جنبش (Movement Insights) خواهد توانست در فصل‌های سوم و چهارم شاخص «مدیران فعال ماهانه» را توسعه دهد.
WE2.1.3 اگر دربارهٔ تجربهٔ ویرایشگران هنگام ایجاد مقاله‌ها و بخش‌های جدید (از جمله انگیزه‌ها، چالش‌ها و واکنش آن‌ها به ایده‌های تازه برای پشتیبانی بهتر) آگاهی یابیم، می‌توانیم نیازها و رفتارهای کاربران را شناسایی کنیم که بینش‌ها و راهبردهای کاربردی برای آگاه‌سازی تیم‌های محصول، طراحی و مهندسی در جهت بهبود تجربهٔ ایجاد مقاله فراهم می‌کنند.
WE2.2.12 اگر ویکی‌توابع را در ویکی‌هایی که پارسوید در آن‌ها فعال است گسترش دهیم، خواهیم توانست به آزمایش ادامه دهیم تا اطمینان یابیم سامانه در گسترش‌های فزاینده همچنان کارا و قابل استفاده باقی می‌ماند.
WE2.2.13 اگر در دسترس بودن تابع جدول صرف را با جامعهٔ ویکی‌واژه در میان بگذاریم، بازخوردهای ارزشمندی دربارهٔ نحوهٔ استفاده از این تابع و بینش‌هایی دربارهٔ الگوهای کاربران به دست خواهیم آورد که می‌توانیم در گسترش‌های آینده از آن‌ها بهره ببریم.
WE2.2.14 اگر به کار جامعه در پروژهٔ Databox برای استفاده از ویکی‌داده در جعبه‌های اطلاعات بپردازیم و بررسی کنیم که آیا ویکی‌توابع می‌تواند کمکی در این زمینه باشد یا نه، خواهیم توانست نخستین آزمایش ویکی‌توابع در جعبه‌های اطلاعات را شناسایی کنیم.
WE2.2.15 اگر آگاهی جامعه را دربارهٔ امکان ایجاد و ترجمهٔ پیام‌های خطا در ویکی‌توابع افزایش دهیم، شاهد افزایش تعداد پیام‌های خطای سودمند خواهیم بود.
WE2.2.16 اگر توابع معناییِ موجود را برای جامعه نمایش دهیم، شاهد افزایش ۵۰٪ در تعداد توابع دستوری خواهیم بود.
WE2.2.17 اگر یک مؤلفهٔ سفارشی برای نمایش گزاره‌های ویکی‌داده در ویکی‌توابع فراهم کنیم، کاربران بهتر خواهند توانست داده‌های واکشی‌شده از ویکی‌داده را درک کنند و احساس سردرگمی کمتری خواهند داشت.
WE2.2.18 اگر بتوانیم جهش‌های ۱۰ برابری در مصرف حافظه را جلوگیری کنیم، هماهنگ‌ساز (orchestrator) بهتر خواهد توانست با اشیای ویکی‌داده کار کند و در نتیجه، کارایی ویکی‌توابع را به‌عنوان بستری برای ویکی‌پدیای انتزاعی تقویت خواهد کرد.
WE2.2.19 اگر کاربران را قادر سازیم پیوندهای مستقیم به فراخوانی‌های خاص توابع — شامل ورودی‌های آن‌ها — به اشتراک بگذارند، مشارکت‌کنندگان خواهند توانست رفتار توابع را آسان‌تر بازتولید، بررسی و دربارهٔ آن گفت‌وگو کنند، که این امر به نوبهٔ خود روند اشکال‌زدایی را تسریع کرده، جریان‌های کاری آزمایش را بهبود می‌بخشد و حل مسئلهٔ همکارانه را در سراسر جامعهٔ ویکی‌توابع تقویت می‌کند.
WE2.3.1 اگر تصمیم برای ایجاد یک ویکی جدید را نهایی کنیم و همراه با جامعه نام آن را تعیین نماییم، خواهیم توانست ایجاد این ویکی تازه را در سطح گسترده‌تری با ذی‌نفعان در میان بگذاریم و برای امور اجرایی مربوط به تغییر احتمالی نام محصول آماده شویم.
WE2.3.2 اگر یک نسخهٔ حداقلی (MVP) از نمونهٔ اولیهٔ ویکی انتزاعی تعریف کنیم که شامل ساده‌ترین تجربهٔ ممکن برای آزمودن توانمندی‌های پشتیبان (Back-end) و تولید زبان طبیعی (NLG) باشد و امکان طراحی تکرارشونده را فراهم کند، خواهیم توانست در فصل سوم یک نمونهٔ زنده راه‌اندازی کنیم.
WE2.3.3 اگر گفت‌وگو با جامعه را آغاز کنیم و طرح‌های احتمالی برای تجربهٔ کاربری ویکی انتزاعی را بررسی نماییم، خواهیم توانست روند پیشرفت کار را در فصل سوم ادامه دهیم.
WE2.4.1 اگر موارد استفاده از ویکی‌داده و سامانهٔ پرس‌وجوی ویکی‌داده (WDQS) را از تیم‌های ویکی‌مدیای آلمان و بنیاد ویکی‌مدیا گردآوری کنیم، خواهیم توانست نیازمندی‌های محصول را برای بهبود زیرساخت تعریف کنیم.
WE2.4.2 اگر نمایی تجمیعی از گزارش شاخص‌های کلیدی عملکرد (KPI) همراه با اهداف سطح خدمت موجود (SLO) برای ویکی‌داده و سامانهٔ پرس‌وجوی ویکی‌داده (WDQS) تهیه کنیم، خواهیم توانست معیارهای موفقیت برای بهبود زیرساخت فنی پشتیبانِ مورد استفادهٔ حیاتی ویکی‌داده را به‌روشنی تعریف و پایش کنیم.
WE2.4.3 اگر بتوانیم در طول این فصل گزینه‌های جایگزین برای Blazegraph را با استفاده از معیارهایی منطبق بر شرایط واقعی تولید ارزیابی و مقایسه کنیم، خواهیم توانست تصمیمی مبتنی بر داده برای مهاجرت اتخاذ کنیم و یک نقشهٔ راه مشخص همراه با جدول زمانی و نیازهای منابع تدوین نماییم.
WE3.1.1 اگر نسخهٔ بهبودیافته‌ای از ویژگی مرور زبانه‌ای (Tabbed browsing) را در قالب یک آزمایش A/B بیازماییم، شاهد افزایش ۵٪ در میزان استفادهٔ چندروزه در میان کاربران زبانه‌ها خواهیم بود.
WE3.1.3 اگر روشی تازه برای کاربران فراهم کنیم تا بتوانند در میان محتوای تصویری مرتبط درون صفحه‌های مقاله مرور کنند و آن را از طریق یک آزمایش A/B در مجموعه‌ای از ویکی‌ها برای بخشی از خوانندگان خارج از حساب کاربری بیازماییم، شاهد دست‌کم ۳٪ نرخ کلیک در میان کاربرانی خواهیم بود که این ویژگی برایشان نمایش داده می‌شود.
WE3.1.4 اگر چند مفهوم برای پیمایش در شبکهٔ دانشی ویکی‌ها را به خوانندگان نمایش دهیم، در نهایت فهرستی اولویت‌بندی‌شده از این مفاهیم برای توسعهٔ بیشتر به دست خواهیم آورد.
WE3.1.5 اگر به خوانندگان نسخهٔ وب گزینه‌ای بدهیم تا نسخه‌ای ترجمه‌شدهٔ ماشینی از محتوای ویکی‌پدیا را که در زبانشان موجود نیست مشاهده کنند، خواهیم آموخت که آیا فعالیت خواندن افزایش می‌یابد یا نه؛ این موضوع با افزایش ۳٪ در میزان تعامل با صفحه‌ها اندازه‌گیری خواهد شد. این ویژگی همچنین می‌تواند موجب جلب خوانندگان به ویکیِ زبان محلی و افزایش بالقوهٔ فعالیت‌های ویرایشی در آن شود. این آزمایش در قالب تنظیمات کنترل‌شدهٔ A/B و برای مدتی حداکثر ۶ ماه اجرا خواهد شد و در ۱۳ ویکی‌پدیا که از پیش رضایت داده‌اند، با استفاده از خدمات ترجمهٔ ماشینی آزادِ در حال حاضر در دسترس ویرایشگران ویکی‌پدیا انجام می‌گیرد.
WE3.1.6 اگر نمونه‌ای اولیه برای جست‌وجوی معنایی و پرسش‌وپاسخ درون‌مقاله‌ای تولید کنیم و آن را در قالب یک رابط نمایشی ارائه دهیم که روش کنونی را با رویکردهای اکتشافی جدید مقایسه می‌کند، تیم‌های خوانندگان خواهند توانست به‌صورت کیفی ارزیابی کنند که هر رویکرد در مسیرهای مختلف کاربر چگونه عمل می‌کند و کاستی‌ها یا فرصت‌های لازم برای تکرار و بهبود بیشتر را شناسایی کنند.
WE3.1.7 اگر پژوهش‌های موجود دربارهٔ نحوهٔ تعامل خوانندگان با ابزارهای جست‌وجو و ناوبری در ویکی‌پدیا، و نیز چگونگی استفادهٔ آنان از جست‌وجوهای بیرونی برای یافتن دانش در ویکی‌پدیا را بررسی کنیم، خواهیم توانست دست‌کم ۳ توصیه و یافتهٔ کاربردی در اختیار تیم‌های خوانندگان قرار دهیم تا بتوانند یک نسخهٔ حداقلی (MVP) برای جست‌وجو و کشف محتوا طراحی کنند که شکاف‌های موجود در انتظارات و نیازهای خوانندگان را برطرف سازد.
WE3.1.8 اگر دو نمونهٔ اولیه از جست‌وجوی معنایی (جست‌وجوی زبان طبیعی و پرسش‌وپاسخ) را با شرکت‌کنندگان بیرونی ارزیابی کنیم، خواهیم آموخت که آیا کاربران برای ابزارهای جست‌وجوی بهبودیافته ارزشی قائل‌اند یا نه، و می‌توانیم توصیه‌ای برای تیم‌های خوانندگان در مورد چگونگی پیشبرد نسخهٔ حداقلی (MVP) جست‌وجو و کشف محتوا ارائه دهیم.
WE3.1.9 اگر در یک مطالعهٔ کیفی، مفاهیم طراحی دقیق و پیشرفته‌ای را برای کشف محتوا از طریق جست‌وجوی معنایی به ۱۰ تا ۲۰ خوانندهٔ معمولی ویکی‌پدیا نشان دهیم، شاهد بازخورد مثبت نسبت به این ویژگی خواهیم بود و اطمینان لازم را برای پیشبرد نسخهٔ حداقلی (MVP) جست‌وجو و کشف محتوا که بر خلاصه‌های کوتاه و انسان‌نویس متکی است، به دست خواهیم آورد.
WE3.1.10 اگر در یک مطالعهٔ کاربریِ بدون ناظر، نمونهٔ زنده‌ای از تجربهٔ جدید مرور تصویر را به ۱۰ خوانندهٔ معمولی نشان دهیم، دست‌کم یک مورد بهبود در تجربهٔ کاربری (UX) برای تکرارهای آیندهٔ این ویژگی شناسایی خواهیم کرد.
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 اگر اسلایدهای مربوط به اهداکنندگان را در بخش «مرور سال» نسخهٔ iOS یکپارچه‌تر و شخصی‌سازی‌شده‌تر کنیم، شاهد افزایش ۵٪ در میزان اهداها نسبت به سال ۲۰۲۴ خواهیم بود.
WE3.3.3 اگر دست‌کم یک آواتار قابل باز شدن را در نسخهٔ اندروید برای دارندگان حساب کاربری معرفی کنیم — که از طریق انجام کنش‌های معنادار مانند ذخیرهٔ تعداد مشخصی از مقاله‌ها به دست می‌آید — تعامل تکرارشوندهٔ کاربران واردشده با کنش‌های مرتبط را در طول چند روز تا ۱۰٪ افزایش خواهیم داد.
WE3.3.4 اگر به خوانندگان واردشده امکان دهیم تا مقاله‌ها را در یک فهرست مطالعهٔ خصوصی ذخیره کنند، انتظار داریم میزان تعامل در سایت افزایش یابد؛ این افزایش با رشد ۵٪ در ترافیک ارجاع درونی برای کاربرانی که از این ویژگی استفاده می‌کنند و افزایشی معنادار از نظر آماری برای همهٔ کاربران سنجیده خواهد شد.
WE3.3.6 اگر داده‌های استنباط موضوع مقاله را از طریق سرویسی که الزامات توافق‌شدهٔ مقیاس‌پذیری و دسترس‌پذیری را برآورده می‌کند (به‌همراه هرگونه بازپرکردن دادهٔ لازم) در دسترس قرار دهیم، بدین‌ترتیب زیربنای فنی لازم برای پشتیبانی از تجربه‌های شخصی‌سازی‌شدهٔ آتیِ خوانندگان که به این داده وابسته‌اند، ایجاد خواهد شد.
WE3.3.7 اگر از توان پردازشی پلتفرم داده برای تجمیع شاخص‌های اختصاصی ویرایشگران و داده‌های تأثیر استفاده کنیم و داده‌های تجمیع‌شده را از طریق خدماتی مناسب با اهداف سطح خدمت (SLO) تعریف‌شده ارائه دهیم، خواهیم توانست تکرارهای آیندهٔ ویژگی «مرور سال» (WE3.3.1) و زبانهٔ فعالیت (WE3.3.2) را بهبود بخشیم.
WE3.3.9 اگر ویژگی «مرور سال» را در نسخهٔ اندروید منتشر کنیم و از طریق آزمایش A/B به کاربران فعال پاداشی برای ذخیرهٔ یک فهرست مطالعهٔ سفارشی پیشنهاد دهیم، شاهد افزایش ۱٪ در نرخ نگهداشت کلی برنامه در میان خوانندگانی خواهیم بود که این پاداش را دریافت کرده‌اند، در مقایسه با کسانی که دریافت نکرده‌اند.
WE3.3.10 اگر از طریق آزمایش A/B الزام داشتن حساب کاربری برای مشاهدهٔ بینش‌های مطالعهٔ شخصی‌شده در بخش «مرور سال» را بیازماییم، شاهد افزایش ۱٪ در نرخ نگهداشت کلی کاربران خواهیم بود که داشتن حساب برایشان الزامی بوده است، در مقایسه با کاربرانی که چنین الزامی نداشته‌اند.
WE3.3.11 اگر نسخهٔ بهبودیافته‌ای از زبانهٔ «فعالیت» را در iOS که رفتارهای مطالعه، ویرایش و سایر مشارکت‌ها را برجسته می‌کند در قالب یک آزمایش A/B بیازماییم، شاهد افزایش ۵٪ در بازدیدهای چندروزهٔ خوانندگان واردشده از این زبانه نسبت به نسخهٔ اولیه خواهیم بود.
WE3.4.1 اگر به‌سوی استقرار ترکیبی نقطهٔ حضور (PoP/CDN) پیش برویم، این امکان را خواهیم داشت که بسته به نیاز، هم نقاط حضور کامل و هم نقاط حضور کوچک (به‌صورت فیزیکی یا ابری) را راه‌اندازی کنیم و بدین‌ترتیب پایه‌ای برای اجرای نمونهٔ اولیهٔ استقرار یک نقطهٔ حضور کوچک در آینده فراهم سازیم.
WE3.5.1 اگر تیم‌های محصول و فناوری و نیز تأمین مالی به‌صورت مشترک رویکردهای فنی شناسایی اهداکنندگان در پلتفرم‌های خود را ارزیابی و مستندسازی کنند، خواهیم توانست راه‌حلی کوتاه‌مدت و بلندمدت پیشنهاد دهیم که میان حفظ حریم خصوصی، امکان‌پذیری و میزان تأثیر تعادل برقرار کند. این درک مشترک به هم‌سویی در تصمیم‌گیری‌ها، شناسایی مداوم اهداکنندگان در میان پلتفرم‌ها، و همچنین انجام آزمایش‌های هدفمندتر در ویژگی‌های مرتبط با تأمین مالی در آینده کمک خواهد کرد.
WE3.6.3 اگر با جامعه‌ها دربارهٔ نیازهای در حال تحول خوانندگان و ماهیت در حال تغییر دانش در اینترنت گفت‌وگو کنیم، می‌توانیم تمرکزی مشترک بر چگونگی خدمت‌رسانی به خوانندگان ایجاد کنیم و در کنار هم دربارهٔ این‌که آیا و چگونه ایده‌های گوناگون خود (از جمله در زمینهٔ چندرسانه‌ای، جست‌وجو و کشف محتوا، و یادگیری ماشینی) را بیازماییم، همکاری کنیم.
WE3.6.4 اگر انگیزه‌ها، رفتارها و نیازهای متمایزِ مرتبط با زمان، علت و شیوهٔ استفادهٔ خوانندگان از ویکی‌پدیا و دیگر پلتفرم‌های دانشی را پژوهش کنیم، خواهیم توانست حوزه‌های اولویت‌دار و ابتکارهای مشخصی را برای راهبرد مخاطبان (consumer strategy) پیشنهاد دهیم.
WE3.6.5 اگر تیم‌های محصول و فناوری و تأمین مالی بر سر راهبردی مشترک برای تنوع‌بخشی به فرصت‌های اهدا درون پلتفرم و نیز هدایت و قدردانی از خوانندگانی که اهدا می‌کنند همکاری کنند، اهداف و شاخص‌های روشنی تعیین خواهیم کرد که با راهبردهای مخاطبان و تأمین مالی ما هم‌راستا باشند.
WE3.6.6 اگر یک راهبرد سنجش یکپارچه تدوین کنیم، ارزیابی راهبرد چندسالهٔ مخاطبان را ممکن خواهیم ساخت و نقشهٔ راهی برای هدایت توسعهٔ شاخص‌ها و قابلیت‌های گزارش‌دهی تعریف خواهیم کرد.
WE4.1.1 اگر یک روند حداقلیِ غیراضطراری (MVP) طراحی کنیم و در جریان توسعهٔ آن، چرخه‌ای باز و تکرارشونده از بازخورد با کاربران دارای دسترسی‌های گسترده برقرار نگه داریم، این گروه‌ها از گسترش استقرار این روند پشتیبانی خواهند کرد.
WE4.1.3 اگر تا پایان ماه اکتبر ۷ ویکی‌پدیا (فرانسوی، آلمانی، اسپانیایی، مجاری، ایتالیایی، لهستانی و پرتغالی) را به‌روزرسانی کنیم، فاز نخست اجرای پابرگ حقوقی جدید را در پاسخ به الزامات قانون خدمات دیجیتال (DSA) به پایان خواهیم رساند.
WE4.1.4 اگر نسخهٔ حداقلی (MVP) سامانهٔ گزارش رویداد را در دست‌کم ۱۵ ویکی، با تمرکز بر جامعه‌های بزرگ و پیچیده، پیاده‌سازی کنیم، شاهد خواهیم بود که این سامانه همان‌گونه که جامعه انتظار دارد مورد استفاده قرار می‌گیرد و یک الگوی عملی برای گزارش رویدادهای غیراضطراری ارائه خواهیم داد.
WE4.1.5 اگر نمودار جریان (flow diagram) برای گزارش رویدادهای سوءاستفاده در ویکی‌هایی که فرایندهای تثبیت‌شده‌ای برای رسیدگی به این موارد ندارند طراحی کنیم، این اقدام موجب تشویق به پذیرش سامانهٔ گزارش رویداد در آن ویکی‌ها خواهد شد و به کاربران آن‌ها امکان می‌دهد مسیر پشتیبانی‌ای روشن و کارآمد در اختیار داشته باشند.
WE4.2.3 اگر داده‌های حاصل از آزمایش ایجاد حساب با hCaptcha را تحلیل کنیم، درک بهتری از فرایند ایجاد حساب، کارایی پازل و امتیازهای hCaptcha به دست خواهیم آورد و داده‌های لازم برای تصمیم‌گیری دربارهٔ گسترش بیشتر استفاده از hCaptcha در فرایند ایجاد حساب‌های کاربری را فراهم خواهیم کرد.
WE4.2.5 اگر پژوهش انجام دهیم، با جامعه‌ها مشورت کنیم و راهکارهای فنی را بررسی نماییم، خواهیم توانست مجموعه‌ای از دلایل مسدودسازی ساخت‌یافته تعریف کنیم که بتوان از آن‌ها در همهٔ ویکی‌های بنیاد ویکی‌مدیا استفاده کرد.
WE4.2.6 اگر امکان استقرار خوشه‌های مبتنی بر OpenSearch را در پلتفرم داده ایجاد کنیم، تیم‌های مهندسی ویژگی‌های محصول توانمند خواهند شد تا سامانه‌هایی را توسعه دهند که این قابلیت را در خود ادغام می‌کنند، با سطح بالایی از خودمختاری، پایداری و جداسازی از سایر سامانه‌های مبتنی بر جست‌وجو. نخستین و اصلی‌ترین کاربر این سامانه، سرویس IPoid خواهد بود.
WE4.2.7 اگر ادغام نسخهٔ سازمانی hCaptcha را به‌صورت آزمایشی در چند ویکی‌پدیای عملیاتی پیاده‌سازی کنیم، خواهیم توانست داده‌هایی دربارهٔ کارایی و ارزش hCaptcha Enterprise در زمینه‌های مقابله با سوءاستفاده، شناسایی ربات‌ها، قابلیت استفاده و دسترس‌پذیری گردآوری کنیم.
WE4.2.8 اگر با بهبود میزان دسترس‌پذیری و قابلیت پایش، پراکسی hCaptcha را برای استفاده در محیط عملیاتی آماده کنیم، در فصل نخست خدمتی پایدارتر و قابل‌اعتمادتر به ویکی‌پدیاهای عملیاتی ارائه خواهیم داد.
WE4.2.9 اگر کیت توسعهٔ نرم‌افزاری (SDK) hCaptcha را در اپلیکیشن‌های بومی موبایل ادغام کنیم، تجربهٔ کاربری در این اپ‌ها را ارزیابی کنیم و امکان فعال‌سازی چالش‌های hCaptcha را به‌عنوان بخشی از رابط برنامه‌نویسی ایجاد حساب بررسی نماییم، درک کافی برای تصمیم‌گیری دربارهٔ گسترش بیشتر استفاده از hCaptcha در رابط ایجاد حساب کاربری به دست خواهیم آورد.
WE4.2.11 اگر hCaptcha را برای شناسایی ربات‌ها در سناریوهای ویرایشی با ریسک بالاتر فعال کنیم، مشاهده خواهیم کرد که hCaptcha می‌تواند میزان سوءاستفادهٔ خودکار را کاهش دهد.
WE4.2.16 اگر با تیم‌های مرتبط در بنیاد ویکی‌مدیا مشورت کنیم، خواهیم توانست برنامه‌ای مورد توافق برای مدیریت دسترسی جزئی‌تر کاربران به داده‌های غیرعمومی تدوین کنیم و از استقرار قوانین نرم‌افزاری دفاعی غیرعمومی پشتیبانی نماییم.
WE4.2.17 اگر نمونه‌های واقعی را تحلیل کنیم و با بازرسان کاربری مصاحبه انجام دهیم تا دست‌کم دو نشانه از رفتارهای بالقوه سوءاستفاده‌آمیز را در نمونهٔ اولیهٔ تاریخچهٔ ویرایشگر شناسایی کنیم، تیم ایمنی و یکپارچگی محصول (Product Safety and Integrity) خواهد توانست این نشانه‌ها را با اطمینان بیشتری مبنی بر سودمندی آن‌ها در ویژگی «پیشنهاد تحقیقات» (Suggested Investigations) به کار گیرد.
WE4.3.2 اگر اثرانگشت‌های JA4H را که رفتار کلاینت HTTP را خلاصه می‌کنند پیاده‌سازی کنیم، توانایی بیشتری در شناسایی و دسته‌بندی ترافیک ربات‌ها خواهیم داشت.
WE4.4.1 اگر بتوانیم بر پایهٔ بازخوردهای نسخه‌های آزمایشی بهبودهایی اعمال کنیم و حساب‌های موقت را در همهٔ پروژه‌ها پیاده‌سازی نماییم، خواهیم توانست نمایش اطلاعات هویتی قابل‌شناسایی (مانند نشانی‌های آی‌پی) کاربران ثبت‌نام‌نکرده را در تمامی پروژه‌ها محدود کنیم به کمتر از ۰٫۱٪ از کل کاربران (ثبت‌نام‌شده).
WE4.4.2 اگر با ذی‌نفعان مرتبط در جنبش (از جمله جامعه‌های ویکی و مسئولان سراسری) به‌صورت شفاف و به‌موقع ارتباط برقرار کنیم، خواهیم توانست استقرار را در همهٔ ویکی‌های باقی‌مانده انجام دهیم، حجم کارهای غیرمنتظره در لحظهٔ آخر را کاهش دهیم و از بازگردانی استقرار جلوگیری کنیم.
WE4.4.5 اگر موانع پیشِ روی گشت‌زن‌ها برای شناسایی خرابکارانی را که از حساب‌های موقت برای ویرایش‌های مخرب استفاده می‌کنند کاهش دهیم، خواهیم توانست از افزایش خرابکاری جلوگیری کنیم؛ این موضوع از طریق عدم افزایش نرخ واگردانی در تمام ویکی‌هایی که از حساب‌های موقت استفاده می‌کنند سنجیده خواهد شد.
WE4.4.6 اگر افزونهٔ LiquidThreads را کنار بگذاریم، مسیر استقرار حساب‌های موقت در تمام پروژه‌هایی که هم‌اکنون از این افزونه استفاده می‌کنند هموار خواهد شد.
WE4.6.1 اگر فرایند همگام‌سازی حساب را در سامانهٔ Zendesk برای بازنشانی گذرواژه‌ها خودکار کنیم، بار کاری از دوش تیم اعتماد و ایمنی (T&S) برداشته خواهد شد و آن‌ها خواهند توانست درخواست‌های بیشتری برای بازنشانی احراز هویت دومرحله‌ای (2FA) رسیدگی کنند.
WE4.6.3 اگر به همهٔ کاربرانی که نشانی ایمیلشان تأیید شده است اجازه دهیم احراز هویت دومرحله‌ای (2FA) را برای حساب خود فعال کنند، اما این تغییر را به‌صورت فعالانه به کاربران اطلاع ندهیم، حجم درخواست‌های پشتیبانی بازیابی حساب در سطحی پایدار باقی خواهد ماند.
WE4.6.4 اگر بازنگری در تجربهٔ کاربری سامانهٔ احراز هویت دومرحله‌ای (2FA) را ادامه دهیم و پشتیبانی از گذرکلیدها (passkeys) را اضافه کنیم، کاربران بیشتری عوامل چندگانهٔ احراز هویت ثبت خواهند کرد و در برابر از دست دادن دسترسی به حساب خود بهتر محافظت خواهند شد.
WE4.6.5 اگر چارچوبی کلی برای تعریف الزامات لازم برای عضویت در گروه‌های محلی یا سراسری طراحی و ایجاد کنیم، از این چارچوب برای اطمینان از آن استفاده خواهیم کرد که اعضای گروه «مشاهده‌گر نشانی IP حساب‌های موقت» الزامات سیاست‌های موجود را رعایت می‌کنند.
WE4.6.6 اگر بررسی کنیم که کاربران دارای دسترسی‌های گسترده (UWER) تا چه اندازه به اسکریپت‌های کاربری متکی هستند، خواهیم توانست طرحی پیشنهاد دهیم که جامعهٔ UWER از آن پشتیبانی کند تا یک یا چند اقدام فنی مهم برای ایمن‌سازی مؤثر سامانهٔ اسکریپت‌های کاربری انجام شود.
WE4.6.7 اگر تجربهٔ کاربری و تغییرات فنی لازم در اپلیکیشن‌های بومی موبایل را برای هم‌تراز کردن تجربهٔ ورود در موبایل با پلتفرم وب از طریق بررسی سازوکارهای جایگزین مانند OAuth ارزیابی کنیم، خواهیم توانست میزان امکان‌پذیری این یکپارچه‌سازی را تعیین کنیم تا تجربه‌ای امن‌تر و یکدست‌تر برای کاربران فراهم آوریم.
WE4.6.8 اگر تأثیر فرم‌های Zendesk و مدیاویکی را که در فصل نخست ایجاد کردیم پایش کنیم، خواهیم توانست برای فصل‌های آینده مداخله‌های فنی‌ای پیشنهاد دهیم که بخش‌های باقی‌ماندهٔ فرایند بازیابی حساب را به‌طور مؤثرتری خودکار کنند.
WE5.1.2b اگر چندین روش شناسایی و احراز هویت توسعه‌دهندگان را در دروازهٔ API ادغام کنیم، خواهیم توانست برای هر درخواست، بر اساس شناسایی دقیق درخواست‌هایی که از گروه‌های کاربری متفاوت می‌آیند، محدودیت نرخ (rate limit) مناسبی تعیین کنیم.
WE5.1.3b اگر یک اجرای آزمایشی (dry run) برای محدودسازی نرخ (rate limiting) در دست‌کم سه مسیر از دروازهٔ REST انجام دهیم، خواهیم توانست امکان‌پذیری محدودسازی نرخ را از نظر میزان مصرف منابع ارزیابی کنیم و مجموعه‌ای اولیه از محدودیت‌ها را تعریف نماییم که بتوان آن‌ها را با کمترین تأثیر بر کاربران اعمال کرد.
WE5.1.4b اگر سازوکارهای پیشنهادی بخش‌بندی کاربران API را با مجموعه‌داده‌های گسترده‌تر و بازبینی‌های دستی گروه‌های شناسایی‌شده اعتبارسنجی کنیم، خواهیم توانست گروه‌های کاربری را نهایی کنیم، روش‌های به‌کاررفته در محاسبه را دقیق‌تر سازیم و درک بهتری از کارایی آن‌ها به دست آوریم.
WE5.1.5 اگر با تیم پلتفرم مدیاویکی در زمینهٔ شناسایی ترافیک و محدودسازی نرخ همکاری کنیم، خواهیم توانست با پشتیبانی از تیم پلتفرم در ایجاد و استقرار این قابلیت، محدودسازی نرخ را برای آزمایش آزمایشی (dry run) در محیط عملیاتی پیاده‌سازی کنیم.
WE5.2.1b اگر با کاربران بالقوهٔ ابزار جدید «کاوشگر API مبتنی بر REST» تعامل داشته باشیم، این کار به ما کمک خواهد کرد تا بینش‌های کلیدی در زمینهٔ قابلیت استفاده به دست آوریم که نشان می‌دهند آیا طراحی جدید کاربرپسند است و با مدل ذهنی توسعه‌دهندگان هم‌خوانی دارد یا نه.
WE5.2.2b اگر API عملیاتی (Action API) را از طریق دروازهٔ مرکزی API هدایت کنیم، می‌توانیم اندازه‌گیری منسجم ترافیک و الگوهای استفاده را آغاز کنیم تا بینش‌هایی به دست آوریم که تصمیم‌ها و اقدامات آینده را آگاه سازند.
WE5.2.4 اگر الگوهای استاندارد مستندسازی را برای دو API پیاده‌سازی کنیم، خواهیم توانست راهنماهای محتوایی را بهبود دهیم، نیازهای مالکان API را برای پذیرش این راهنماها درک کنیم و میزان تلاش لازم برای اجرای آن‌ها در مستندات سایر APIهای ویکی‌مدیا را برآورد نماییم.
WE5.2.5 اگر در تعریف و به‌کارگیری قوانین lint برای مشخصات OpenAPI در APIهای REST مدیاویکی آزمایش کنیم، روشی برای اعمال خودکار راهنماهای نگارشی API ارائه خواهیم داد که به بهبود کیفیت و یکپارچگی APIهای منتشرشده در سراسر ویکی‌مدیا و جامعه‌های آن کمک می‌کند.
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 اگر راهنماهای انتساب در تجربهٔ کاربری (UX) را گسترش داده و هم‌زمان راهنماهای موجود را به‌روزرسانی و منسجم کنیم، مجموعه‌ای اصلی از راهنماهای بهبود‌یافته ایجاد خواهیم کرد که برای آزمون داخلی و اصلاح تکرارشونده آماده باشند تا در نهایت برای استفادهٔ عمومی گسترده مهیا شوند.
WE5.3.1b اگر پیش‌نویس راهنماها و نمونه‌های تجربهٔ کاربری (UX) را منتشر کرده و به‌صورت تکرارشونده بهبود دهیم، چارچوبی اصلی ایجاد خواهیم کرد که برای آزمون داخلی و اصلاح تدریجی آماده باشد تا در نهایت برای استفادهٔ عمومی گسترده مهیا شود.
WE5.3.2 اگر ارائه‌ای طراحی کنیم که مزایای انتساب ویکی‌پدیا را برای استفاده‌کنندگان ثانویهٔ محتوا و کاربران نهایی آن‌ها نشان دهد، می‌توانیم با ترغیب دست‌کم یک شریک جدیدِ استفادهٔ مجدد به حضور در یک مطالعهٔ موردی یا نسخهٔ نمایشیِ انتساب تا پایان فصل نخست، از اهداف WME4.1 و WME4.2 پشتیبانی کنیم.
WE5.4.2b اگر روشی مقیاس‌پذیر برای شناسایی کلاینت‌های شناخته‌شده ایجاد کنیم، می‌توانیم برای ربات‌هایی با منشأ تأییدشده استثناهایی نسبت به محدودیت‌های کلی نرخ اعمال کنیم و به‌سوی اجرای نظام‌مند قوانین خود گام برداریم.
WE5.4.5 اگر محدودیت‌های نرخ را متناسب با دسته‌های مختلف از کلاینت‌های منفرد اعمال کنیم، بار ناشی از خزیدن (crawling) بر زیرساخت خود را کاهش خواهیم داد.
WE5.4.6 اگر تا پایان فصل دوم برترین N خزنده (spider) را به‌عنوان ربات‌های شناخته‌شده طبقه‌بندی کنیم، خواهیم توانست میزان منابعی را که آن‌ها مصرف می‌کنند محدود سازیم.
WE5.4.7 اگر مجموعه‌ای استاندارد از اندازه‌های مجاز تصاویر بندانگشتی را در زیرساخت رسانه‌ای خود تعیین کنیم، و پرهزینه‌ترین آن‌ها را از پیش تولید کرده و تولید اندازه‌های گوناگون را با محدودیت نرخ کنترل کنیم، بار وارد بر زیرساخت ارائهٔ رسانه را کاهش خواهیم داد.
WE6.1.2 اگر ویکی‌فارم‌ها را به محیط آزمون پیش از ادغام (pre-merge) اضافه کنیم، تیم‌های توسعه‌ای که برای تولید نیاز به چند ویکی دارند خواهند توانست وصله‌های خود را به‌صورت مجزا آزمایش کنند، که این امر موجب افزایش اطمینان پیش‌ازتولید و کاهش خطاهای نادیده‌مانده خواهد شد.
WE6.2.1 اگر فهرست بررسی آمادگی برای تولید (Production Readiness Checklist) را بازبینی و منتشر کنیم، به‌گونه‌ای که پیش‌نیازهای لازم برای آماده‌به‌کار بودن یک سرویس را به‌روشنی تعریف کند و شامل وظایف قابل‌انجام به‌صورت سلف‌سرویس باشد، انتظارات میان مهندسان قابلیت اطمینان سامانه (SRE) و تیم‌های توسعه هم‌راستا خواهد شد و کارایی و مقیاس‌پذیری عملیاتی کلی ما بهبود خواهد یافت.
WE6.2.2 اگر ایجاد یک کتابخانهٔ Golang و Node.js را اعلام کنیم که بسیاری از وظایف زمان‌بر را برای توسعه‌دهندگان ساده‌سازی می‌کند، آن‌ها با ارائهٔ بازخورد و ابراز علاقه واکنش نشان خواهند داد.
WE6.2.4 اگر بازبینی طراحی ماندگاری داده (Data Persistence Design Review) را اجرا کرده و به‌صورت فعال از آن پشتیبانی کنیم، ممکن است مسیرهای استاندارد و آماده‌ای برای انتقال به محیط تولید شناسایی کنیم.
WE6.3.2 اگر شاخص‌های جدیدی توسعه دهیم، زیرساخت کش پارسوید را بهبود بخشیم و آن را در دو ویکی‌پدیای «ده‌تای برتر» مستقر کنیم، معیارهای عملکردی برای چارچوب اطمینان (confidence framework) ایجاد خواهیم کرد که به ما کمک می‌کند آمادگی خود را برای استقرار در دیگر ویکی‌های بزرگ ارزیابی کرده و توانایی‌مان در مدیریت حجم بالای ترافیک در مقیاس وسیع را نشان دهیم.
WE6.3.3 اگر بهبودهای حیاتی در پشتیبانی از گونه‌های زبانی را پیاده‌سازی کنیم و پارسوید را در فصل دوم با موفقیت در دست‌کم ۳ ویکی دارای گونهٔ زبانی مستقر سازیم، چالش‌های فنی کلیدی لازم برای گسترش مطمئن به سایر ویکی‌های دارای گونهٔ زبانی را شناسایی و برطرف خواهیم کرد.
WE6.4.6 اگر تیم مهندسی قابلیت اطمینان سامانه (SRE) از تیم‌های مهندسی مدیاویکی پشتیبانی کند — از طریق مدیریت ظرفیت و ترافیک، آماده‌سازی و بازبینی تغییرات پیکربندی، و همکاری در بررسی و رفع مشکلات — در کنار یکدیگر ارتقای PHP 8.3 در محیط تولید را در فصل دوم به انجام خواهیم رساند و مجموعه‌ای از توصیه‌ها را برای کاهش وابستگی‌های حیاتی به تیم SRE در ارتقاهای آینده مستند خواهیم کرد. T360995
WE6.4.7 اگر دست‌کم ۹۰٪ از کاربران دارای دسترسی ریشهٔ سراسری را به استفاده از کلید SSH پشتیبانی‌شده با سخت‌افزار برای دسترسی به سرورهای تولیدی ویکی‌مدیا منتقل کنیم، خطر بروز نفوذ امنیتی شدید بر اثر به خطر افتادن یک لپ‌تاپ کاهش خواهد یافت.
WE6.4.8 اگر تیم مهندسی مدیاویکی به‌طور فعال مشکلات مرتبط با ارتقای PHP را در مدیاویکی پایش و برطرف کند، این اقدام به تیم قابلیت اطمینان سامانه (SRE) امکان خواهد داد تا ارتقای PHP 8.3 را در محیط تولید تا نوامبر ۲۰۲۵ به پایان برساند. T360995
فرضیه‌های خدمات سیگنال و داده (SDS)

[ نتایج کلیدی خدمات سیگنال و داده (SDS) ]

بحث

نام کوتاه فرضیه‌ها متن سه‌ماههٔ دوم (Q2) جزئیات و بحث
SDS1.2.1 اگر فرایند تهیهٔ فایل‌های XML Dumps را از زیرساخت فعلی «Dumps 1» به یک خط لولهٔ داده منتقل کنیم که از خط لوله‌های محتوای مدیاویکی بهره می‌برد، خواهیم توانست اهداف سطح خدمت (SLO) را تضمین کنیم و خروجی مبتنی بر «Dumps 1» را غیرفعال سازیم.
SDS1.2.2 اگر بازبینی و مرور جامعی بر اهداف سطح خدمت (SLO) برای تاریخچهٔ محتوای مدیاویکی و پلتفرم رویداد / دروازهٔ رویداد انجام دهیم، می‌توانیم مشتریان، شاخص‌ها و ذی‌نفعان وابسته را اعتبارسنجی کنیم و بهبودهای احتمالی مورد نیاز در SLOها را شناسایی نماییم، که این کار به ما کمک خواهد کرد هرگونه شکاف در تضمین‌های تحویل هفتگی خود را روشن سازیم.
SDS1.3.1 اگر سیگنال‌های سمتِ کلاینت را معرفی کنیم و آن‌ها را در مقایسه با لاگ‌های webrequest سمتِ سرور ممیزی کنیم، الگوهای اضافیِ ربات را کشف خواهیم کرد که می‌توان آن‌ها را مشخص و طبقه‌بندی کرد.
SDS1.3.2 اگر توزیع کنونی میان ربات‌ها و انسان‌ها را به‌عنوان خط مبنا در نظر بگیریم و برای تغییرات این توزیع هشدارهای خودکار ایجاد کنیم، زمان شناسایی الگوهای پیش‌بینی‌نشدهٔ بعدی در ترافیک خودکار را از چند هفته به چند دقیقه کاهش خواهیم داد.
SDS1.3.3 اگر سازوکار پرکردن خودکار داده‌های گذشته (backfill) را برای webrequest خودکارسازی کنیم و آن را بر روی لاگ‌های ماه مه اجرا نماییم، زمان رفع خطا در رویدادهای آینده را از چند ماه به چند روز کاهش خواهیم داد و رویداد «افزایش بازدید صفحه‌ها در ماه مه» را برطرف خواهیم کرد.
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 اگر ثبت گزارش‌ها و قابلیت پایش را برای بخش سامانهٔ آزمون A/B (xLab) در پلتفرم آزمایش و همچنین اجزای مرتبط آن در مدیاویکی بهبود دهیم، خواهیم توانست خطوط مبنا برای عملکرد سامانه تعیین کنیم و به خطاهای مرتبط با آزمایش‌ها پاسخ دهیم.
SDS2.1.4 اگر داستان‌ها و نتایج آزمایش‌ها را ماهی یک‌بار در سراسر سازمان — از طریق نشست‌های عملیات محصول (Product Ops)، جلسات تیم طراحی و ارائه‌های میان‌تیمی — به اشتراک بگذاریم، به‌صورت طبیعی موجب پذیرش و گسترش استفاده از پلتفرم آزمایش خواهیم شد.
SDS2.1.5 اگر به کاربران اطلاع دهیم که ابزارشان، در صورتی که در xLab ساخته شود، شامل مجموعه‌ای از ویژگی‌ها است که ردهٔ ریسک را تغییر می‌دهد، از گردآوری بیش‌ازحد داده توسط کاربران ابزار جلوگیری خواهیم کرد و شفافیت بیشتری دربارهٔ ترکیب ویژگی‌هایی که نیاز به بازبینی حریم خصوصی دارند ایجاد خواهیم نمود.
SDS2.1.6 اگر تیم رشد بر ابزارسازی دو مورد استفاده (یکی همراه با آزمون A/B برای کسب بینش دربارهٔ قابلیت‌های دسته‌بندی و دیگری با ابزارسازی بلندمدت برای بررسی پشتیبانی از شاخص‌هایی مشابه KPI) با استفاده از آزمایشگاه Experiment Lab کار کند، خواهیم توانست ارزیابی کنیم که آیا این سامانه به‌قدر کافی نیازها را برای جایگزینی با تنظیمات اختصاصی آزمایش‌ها در GrowthExperiments برآورده می‌کند یا نه.
فرضیه‌های مخاطبان آینده (FA)

[ نتایج کلیدی مخاطبان آینده (FA) ]

بحث

نام کوتاه فرضیه‌ها متن سه‌ماههٔ دوم (Q2) جزئیات و بحث
FA1.1.4 [ادامه از سال مالی گذشته] اگر تجربه‌ای تازه از ویکی‌پدیا را در پلتفرم Roblox ایجاد کنیم، خواهیم آموخت که آیا این روش می‌تواند شیوه‌ای مؤثر برای معرفی برند ما به مخاطبان جوان‌تر (نسل آلفا) باشد یا نه.
FA1.1.2 اگر یک مرکز اصلی برای تجربه‌های تازهٔ ویکی‌پدیا در itch.io ایجاد کنیم، خواهیم توانست مخاطبانی متشکل از بیش از ۵۰ نفر غیر ویکی‌پدیایی علاقه‌مند جذب کنیم که با ارائهٔ بازخورد به ما کمک می‌کنند دریابیم چه چیزهایی در بازی‌ها مؤثر است و چه چیزهایی نیست.
FA2.2.1 اگر در مدیریت جامعه در پلتفرم‌های ویدئوی کوتاه سرمایه‌گذاری کنیم، تا پایان سه‌ماههٔ دوم (دسامبر ۲۰۲۵) شاهد افزایش ۳۰٪ فصلی در درصد بازدیدهای «بینندگان تازه» در تیک‌تاک خواهیم بود — و در مجموعِ تمام پلتفرم‌های ویدئوی کوتاه، ۵۰٬۰۰۰ تعامل (لایک و پاسخ به دیدگاه‌ها) در کامنت‌های برندمان که زیر محتوای خارجی گذاشته می‌شود به‌دست خواهیم آورد؛ امری که به افزایش دیده‌شدن و جذب مشارکت از سوی مخاطبانی که تاکنون به آن‌ها دست نیافته‌ایم کمک خواهد کرد.
FA2.2.2 اگر یک راهبرد درونی برای «برنامهٔ همکاری با خالقان ویکی‌پدیا» تدوین کنیم و تأیید نهایی آن را بگیریم — همراه با مواد قابل انتشار بیرونی (شامل شرح ارزش ما برای خالقان، معیارهای همکاری، فرایند عقد قرارداد، و چگونگی نمایش محتوای خالقان در کانال‌های خود و کانال‌های آنان) — قادر خواهیم بود یک راهبرد نیرومند برای همکاری با خالقان ایجاد کنیم که به ما کمک خواهد کرد از طریق رسانه‌های اجتماعی، با محتوای دانشی خود به مخاطبان تازه‌ای دست یابیم.
فرضیه‌های پشتیبانی محصول و مهندسی (PES)

[ نتایج کلیدی پشتیبانی محصول و مهندسی (PES) ]

بحث

نام کوتاه فرضیه‌ها متن سه‌ماههٔ دوم (Q2) جزئیات و بحث
PES1.1.5 اگر اهداف سطح خدمات (SLO) مربوط به «تاریخچهٔ محتوای مدیاویکی» و «ویکی‌توابع» را در سامانهٔ Sloth/Pyrra پیاده‌سازی کنیم، دو هدف سطح خدمات دیگر را وارد مرحلهٔ اجرا خواهیم کرد.
PES1.1.6 اگر سامانهٔ Sloth را با داده‌های گذشته‌نگر مربوط به اهداف سطح خدمات (SLO) موجود آزمایش کنیم، خواهیم فهمید که آیا Pyrra یا Sloth (یا ابزار دیگری) گزینهٔ مناسب‌تری برای رویکرد «پنجرهٔ ثابت بودجهٔ خطا» است یا نه. همچنین خواهیم آموخت چگونه می‌توان از طریق رویکرد «خدمت‌رسانی خودکار» در سنجش شاخص‌های SLO از مالکان سرویس پشتیبانی کرد و از این شاخص‌ها در تصمیم‌گیری بهره گرفت.
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.

برنامه‌ریزی مشترک

بروزرسانی ژانویهٔ ۲۰۲۵.

Portrait of Selena

برنامهٔ سالانه توصیفی از آن چیزی است که بنیاد ویکی‌مدیا امیدوار است در سال پیش‌رو به آن دست یابد. ما سخت تلاش می‌کنیم تا این برنامه، مشارکتی، الهام‌بخش و قابل‌دستیابی باشد. هر سال، از مشارکت‌کنندگان می‌خواهیم دیدگاه‌ها، امیدها و درخواست‌های مشخص خود را با ما به اشتراک بگذارند تا در شکل‌دهی به برنامه سهیم باشند. برخی از روش‌هایی که از طریق آن‌ها این بازخوردها را دریافت می‌کنیم شامل گفتگوهای تیم‌های محصول با جوامع، فهرست آرزوهای جامعه، گفتگوهای جامعه مانند سری گفتگوهای پروژه‌های مشترک، کنفرانس‌ها و صفحات ویکی مشابه این صفحه است.

برای برنامهٔ سالانهٔ بعدی خود، از ژوئیهٔ ۲۰۲۵ تا ژوئن ۲۰۲۶، در حال اندیشیدن به این هستیم که چگونه می‌توانیم به بهترین شکل به یک چشم‌انداز چندنسلی خدمت کنیم، با توجه به تغییرات سریع در جهان و اینترنت و تأثیر آن بر مأموریت دانشِ آزادِ ما.

همان‌طور که سال گذشته گفتم، باید بر چیزی که ما را متمایز می‌کند تمرکز کنیم: توانایی ما در ارائهٔ محتوای قابل‌اعتماد، حتی با گسترش اطلاعات نادرست و گمراه‌کننده در اینترنت و پلتفرم‌هایی که برای جلب توجه نسل‌های جدید رقابت می‌کنند. این امر شامل اطمینان از دستیابی به مأموریت ما برای گردآوری و ارائهٔ مجموع دانش بشری به جهان از طریق گسترش پوشش اطلاعاتی است که ممکن است به‌دلیل نابرابری، تبعیض و تعصب نادیده گرفته شده باشند. محتوای ما همچنین باید در اینترنتی که به‌وسیلهٔ هوش مصنوعی و تجربیات غنی هدایت می‌شود، همچنان کاربردی و حیاتی باقی بماند، و در نهایت، باید راه‌هایی برای تأمین مالی پایدار جنبش خود بیابیم؛ از طریق ایجاد یک راهبرد مشترک برای محصولات و جمع‌آوری کمک‌های مالی، تا بتوانیم از این تلاش‌ها در بلندمدت حمایت کنیم.

برای تصمیم‌گیری و اولویت‌بندی دربارهٔ تمرکز تلاش‌های خود در سال آینده، پرسش‌هایی را گردآوری کردیم و به این فکر کردیم که چگونه منابع محدود خود را برای دستیابی به بیشترین تأثیر تخصیص دهیم.

اگر به‌طور خاص به این علاقه‌مند هستید که بخش محصول و فناوری بر اساس اولویت‌های تعیین‌شده در اینجا چه ویژگی‌ها یا خدماتی را ایجاد خواهد کرد، فرصتی در ماه مارس وجود خواهد داشت تا دربارهٔ اهداف و نتایج کلیدی مشخص نظر دهید. (برای مرجع، اینجا اهداف و نتایج کلیدی برنامهٔ سالانهٔ جاری آورده شده است.)

اگر می‌خواهید دربارهٔ چالش‌ها و فرصت‌ها در محیط فنی ما فکر کنید و جهتی که باید در برنامهٔ سالانهٔ بعدی تعیین کنیم، لطفاً سوالات زیر را در نظر بگیرید.

به‌طور مداوم اطلاعات مربوط به این سوالات را از طریق روش‌های مختلف جمع‌آوری می‌کنیم — از جمله گفتگوهای جامعه، داده‌هایی که جمع‌آوری می‌کنیم، مصاحبه‌های تحقیقاتی که انجام می‌دهیم و موارد دیگر. این اولین بار نیست که در مورد این مسائل سوال می‌کنیم و دربارهٔ بسیاری از آن‌ها یاد می‌گیریم — و قبلاً در مورد بسیاری از آن‌ها کار کرده‌ایم! اکنون می‌خواهیم دوباره این سوالات را مطرح کنیم و همچنان یاد بگیریم، زیرا در این مرحله از برنامه‌ریزی‌های ما، جزو اولویت‌های اصلی هستند.

پرسش‌ها:

  • معیارها و داده‌ها
    • چه روش‌هایی وجود دارد که داده‌ها و معیارها بتوانند بهتر از کار شما به‌عنوان ویرایشگر حمایت کنند؟ آیا می‌توانید داده‌هایی در مورد ویرایش، خواندن یا سازماندهی فکر کنید که به شما کمک کند زمان خود را چگونه صرف کنید یا زمانی که چیزی نیاز به توجه دارد، چه زمانی باید به آن رسیدگی کنید؟ این می‌تواند داده‌هایی دربارهٔ فعالیت خودتان یا فعالیت دیگران باشد.
  • ویرایش
    • چه زمانی ویرایش برای شما پاداش‌دهنده و لذت‌بخش‌ترین احساس می‌شود؟ چه زمانی احساس می‌کنید که بیشترین سردرگمی و دشواری را تجربه می‌کنید؟
    • می‌خواهیم مشارکت‌کنندگان بازخورد و شناخت بیشتری برای کار خود دریافت کنند تا احساس نکنند که هیچ‌کس تلاشی که برای ویکی‌ها صرف می‌کنند را متوجه نمی‌شود. چه نوع بازخورد و قدرشناسی برای شما انگیزه‌بخش است؟ چه چیزی شما را ترغیب می‌کند که به ویرایش ادامه دهید؟
    • از آنجا که ویکی‌ها بسیار بزرگ هستند، ممکن است برای ویرایشگران دشوار باشد که تصمیم بگیرند کدام کار ویکی برایشان در هر روز مهم‌ترین است. چه اطلاعات یا ابزارهایی می‌تواند به شما کمک کند تا زمان خود را صرف چه کاری کنید؟ آیا داشتن یک مکان مرکزی و شخصی‌سازی‌شده که به شما این امکان را بدهد که فرصت‌های جدید را پیدا کنید، وظایف خود را مدیریت کنید و تأثیر خود را درک کنید، مفید خواهد بود؟
    • می‌خواهیم تجربهٔ همکاری در ویکی‌ها را بهبود ببخشیم، به‌طوری‌که مشارکت‌کنندگان راحت‌تر یکدیگر را پیدا کرده و روی پروژه‌ها به‌طور مشترک کار کنند، چه از طریق تلاش‌های پشت‌صحنه، همایه‌ها، ویکی‌پروژه‌ها یا حتی دو ویرایشگر که با هم همکاری می‌کنند. به نظر شما چگونه می‌توانیم به مشارکت‌کنندگان بیشتری کمک کنیم که یکدیگر را پیدا کرده، ارتباط برقرار کنند و با هم کار کنند؟
  • خواندن/یادگیری
    • بارگذاری ویکی‌ها بسته به مکان زندگی افراد در جهان سریع‌تر یا کندتر است. آیا مناطقی از جهان وجود دارد که فکر می‌کنید بهبود عملکرد در آن‌ها بیشتر مورد نیاز باشد؟
    • چگونه می‌توانیم به نسل‌های جدید خوانندگان کمک کنیم تا محتوای ویکی‌پدیا را جالب و جذاب ببینند؟ قبلاً ایده‌هایی در مورد محتوای تعاملی و ویدئو مطرح کرده‌ایم و در سال جاری تمرکز خود را بر روی نمودارها و آزمایش روش‌های جدید برای نمایش محتوای موجود ویکی‌پدیا قرار داده‌ایم. چگونه می‌توانیم این مسیر را ادامه دهیم تا از محتوای موجود خود به شیوه‌های جدیدی استفاده کنیم که منحصر به ویکی‌مدیا باشد؟
  • مدیران
    • چه چیزی ممکن است در ویکی‌پدیا تغییر کند تا افراد بیشتری تمایل داشته باشند در نقش‌های پیشرفتهٔ داوطلبانه مانند گشت‌زنی یا مدیریت مشغول به فعالیت شوند؟
    • چه اطلاعات یا زمینه‌ای دربارهٔ ویرایش‌ها یا کاربران می‌تواند به شما کمک کند تا تصمیمات گشت‌زنی یا مدیریتی را سریع‌تر و راحت‌تر اتخاذ کنید؟
  • ترندهای بیرونی
    • مهم‌ترین تغییراتی که در دنیای بیرون از ویکی‌مدیا متوجه می‌شوید چیست؟ این تغییرات می‌توانند روندهایی در فناوری، آموزش یا نحوهٔ یادگیری افراد باشند.
    • خارج از جنبش ویکی‌مدیا، در چه جوامع آنلاین دیگری شرکت می‌کنید؟ چه درس‌هایی می‌توانیم از ابزارها و فرآیندهای پلتفرم‌های دیگر جوامع آنلاین بگیریم؟
    • چگونه از ابزارهای هوش مصنوعی در داخل و خارج از کار ویکی‌مدیا خود استفاده می‌کنید؟ هوش مصنوعی را برای چه کارهایی مفید می‌بینید؟
  • ویکی‌انبار
    • چه تصمیماتی می‌توانیم با جامعهٔ ویکی‌انبار بگیریم تا پروژه‌ای پایدار ایجاد کنیم که از تولید دانش حمایت کند؟
  • ویکی‌داده
    • چگونه دوست دارید ویکی‌داده در آینده تکامل یابد؟ چگونه می‌تواند بیشترین کارایی را در ساخت محتوای دانشنامه‌ای قابل اعتماد داشته باشد؟

–– Selena Deckelmann

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Wikimedia_Foundation_Annual_Plan/2025-2026/Product_%26_Technology_OKRs/fa&oldid=30715854"