برنامه سالانه بنیاد ویکی‌مدیا/۲۰۲۴-۲۰۲۵/اهداف و نتایج نهایی (OKRs) محصول و فناوری
این سند اولین بخش از فرآیند برنامه ریزی سالانه ۲۰۲۴-۲۵ را برای بخش محصولات و فناوری بنیاد ویکی‌مدیا نشان می‌دهد. در پیش‌نویس «ادارات» «اهداف و نتایج کلیدی» (OKRs) را توضیح می‌دهد. این ادامه ساختار پرتفولیوهای کاری (به نام «سطل») است که سال گذشته آغاز شد.
.jpg)
با همهٔ شما در نوامبر در مورد آنچه که فکر می‌کنم مهم‌ترین سؤالی است که جنبش ویکی‌مدیا با آن مواجه است صحبت کرده‌بودم: چگونه اطمینان حاصل کنیم که ویکی‌پدیا و همهٔ پروژه‌های ویکی‌مدیا چندنسلی هستند؟ مایلم از همهٔ کسانی که وقت گذاشتند و واقعاً این سؤال را در نظر گرفتند و مستقیماً به من پاسخ دادند، تشکر کنم، و اکنون که این فرصت را داشتم که مدتی را صرف تأمل در پاسخ های شما بکنم، و آنچه را که آموخته‌ام به اشتراک خواهم گذاشت.
نخست اینکه، هیچ دلیل واحدی وجود ندارد که چرا داوطلبان در پروژه‌های ویکی‌مدیا مشارکت می‌کنند. برای پرورش چند نسل از داوطلبان، باید دلایل بسیاری که چرا افراد وقت خود را در پروژه‌های ما اختصاص می‌دهند را بهتر درک کنیم. در مرحلهٔ بعد، باید بر آنچه که ما را متمایز می‌کند، تمرکز کنیم: توانایی ما برای ارائهٔ محتوای قابل اعتماد به دلیل گسترش اطلاعات نادرست و افکار غلط در سراسر اینترنت و پلتفرم‌هایی که برای جلب توجه نسل‌های جدید رقابت می‌کنند، تهدید شده است. این شامل حصول اطمینان از دستیابی به مأموریت جمع‌آوری و ارائهٔ مجموع دانش بشری به جهان با گسترش پوشش اطلاعاتی از دست رفته است، که ممکن است ناشی از بی‌عدالتی، تبعیض یا تعصب باشد. محتوای ما نیز باید در اینترنت، در حال تغییر و با استفاده از هوش مصنوعی و تجربیات غنی، مفید و حیاتی باشد. در نهایت، ما باید راه‌هایی برای تأمین مالی پایدار جنبش خود با ایجاد یک استراتژی مشترک برای محصولات و درآمد خود پیدا کنیم تا بتوانیم این کار را برای بلندمدت تأمین مالی کنیم.
این ایده‌ها در برنامه سالانهٔ ۲۰۲۴-۲۰۲۵ بنیاد ویکی‌مدیا بازتاب داده خواهند شد، اولین بخش از آن را امروز در قالب پیش‌نویس اهداف کار محصول و فناوری با شما به اشتراک می‌گذارم. مانند سال گذشته، کل برنامهٔ سالانهٔ ما حول محور نیازهای فناوری مخاطبان و پلتفرمهای ما متمرکز خواهند شد، و مایلیم بازخورد شما را بدانیم که آیا روی مشکلات درست تمرکز می‌کنیم یا خیر. این اهداف، ایده‌هایی را ایجاد می‌کنند که در طول چند ماه گذشته از اعضای انجمن از طریق Talking:2024، در میلینگ لیست، و صفحات گفتگو، و در رویدادهای جامعه دربارهٔ محصول و استراتژی فناوری ما برای سال آینده شنیده‌ایم. می‌توانید لیست کامل پیش‌نویس اهداف را در زیر مشاهده کنید.
«هدف» سطح بالایی است که پروژه‌های محصول و فناوری را که برای سال مالی آینده انجام می‌دهیم، شکل می‌دهد. این اهداف عمداً گسترده‌اند و جهت استراتژی‌مان را نشان می‌دهند، و مهمتر از همه، چالش‌هایی را برای اولویت‌بندی در بین بسیاری از حوزه‌های تمرکز برای سال آینده پیشنهاد می‌کنیم. اکنون این پیش‌نویس را به اشتراک می‌گذاریم تا اعضای انجمن بتوانند به شکل‌دهی تفکر اولیهٔ‌مان و قبل از تعیین بودجه و اهداف قابل اندازه‌گیری برای سال کمک کنند.
بازخورد
یکی از زمینه‌هایی که به‌ویژه در آن بازخورد می‌خواهیم، کارمان است که تحت عنوان «تجربه‌های ویکی» گروه‌بندی شده‌اند. «تجربه‌های ویکی» دربارهٔ نحوهٔ ارائه، بهبود و نوآوری کارآمد است که مردم چگونه مستقیماً از ویکی‌ها استفاده می‌کنند، چه به‌عنوان مشارکت‌کننده، مصرف‌کننده یا اهداکننده. این شامل کار برای پشتیبانی از فناوری و قابلیت‌های اصلی ما و اطمینان از اینکه می‌توانیم تجربهٔ ویراستاران داوطلب - به‌ویژه، ویراستارانی با دسترسی‌های گسترده‌تر - را از طریق ویژگی‌ها و ابزارهای بهتر، خدمات ترجمه، و ارتقای پلتفرم بهبود بخشیم.
در اینجا برخی از بازتاب‌ها از بحث‌های برنامه‌ریزی اخیر ما، و چند سؤال برای همهٔ شما وجود دارد تا به ما در اصلاح ایده‌هایمان کمک کند:
- داوطلب شدن در پروژه‌های ویکی‌مدیا باید لذت‌بخش باشد. همچنین فکر می‌کنیم که تجربهٔ همکاری آنلاین باید بخش عمده‌ای از چیزی باشد که داوطلبان را به بازگشت به پروژه ترغیب می‌کند. چه چیزی لازم است تا داوطلبان برای ویرایش‌کردن ترغیب شوند و برای ایجاد محتوای قابل اعتماد با یکدیگر بهتر کار کنند؟
- قابل اعتماد بودن محتوایمان بخشی از کمک منحصر به فرد ویکی‌مدیا به جهان است و باعث می‌شود مردم به پلتفرم ما بیایند و از محتوایمان استفاده کنند. چه چیزی می‌توانیم انجام دهیم که به رشد سریع‌تر محتوای قابل اعتماد کمک کند، در عین حال که همچنان در چارچوب‌های با کیفیتی که جوامع در هر پروژه تعیین می‌کنند، حفظ شود؟
- برای مرتبط ماندن و رقابت با دیگر پلتفرمهای آنلاین بزرگ، ویکی‌مدیا به نسل جدیدی از مصرف‌کنندگان نیاز دارد تا احساس کنند با محتوای ما مرتبط هستند. چگونه می‌توانیم محتوای خود را برای کشف و تعامل با آن برای خوانندگان و اهداکنندگان آسان‌تر کنیم؟
- در دنیایی که سوء استفادهٔ آنلاین در حال رشد است، باید اطمینان حاصل کنیم که جوامع، پلتفرم‌ها و سیستم‌های سرویس‌دهی ما محافظت می‌شوند. ما همچنین با تعهدات انطباق در حال تغییر و تحول هستیم، جایی که سیاست‌گذاران جهانی به دنبال شکل دادن به حریم خصوصی، هویت و اشتراک‌گذاری اطلاعات آنلاین هستند. چه پیشرفت‌هایی در قابلیت‌های مبارزه با سوء استفاده ما به ما کمک می‌کند تا این چالش‌ها را برطرف کنیم؟
- مدیاویکی، پلتفرم نرم‌افزاری و رابط‌هایی که به ویکی‌پدیا اجازهٔ عملکرد می‌دهد، برای ایجاد، تعدیل، ذخیره‌سازی، کشف و مصرف محتوای باز و چندزبانه در مقیاس، نیاز به پشتیبانی مداوم برای دههٔ آینده دارد. امسال، می‌توانیم تصمیم‌ها و بهبودهایی را انجام دهیم که اطمینان حاصل کنند مدیاویکی پایدار باقی می‌ماند.
اهداف اولیه
در حال حاضر بالاترین سطح برنامه‌ریزی منتشر شده است - «اهداف»
سطح بعدی - پیش‌نویس «نتایج کلیدی» (KR) برای هر هدف نهایی در زیر ارائه شده است.
«فرضیهٔ» اساسی برای هر KR در صفحات ویکی‌پروژه/تیم مربوطه در طول سال به روز می‌شود تا در طول سال با آموختن درس‌ها به روز شود.
| پیش‌نویس اهداف ویکی تجربه (WE) | ||||
|---|---|---|---|---|
| هدف | حوزهٔ هدف | هدف | مفاد هدف | متولی |
| WE1 | تجربهٔ مشارکت‌کننده | مشارکت‌کنندگان با تجربه و جدید به صورت آنلاین گرد هم می‌آیند تا یک دانشنامهٔ قابل اعتماد را با سهولت بیشتر و سرخوردگی کمتری ایجاد کنند. | برای اینکه ویکی‌پدیا در سال‌های آینده پر جنب و جوش باشد، باید کاری انجام دهیم که نسل‌های متعددی از داوطلبان را پرورش دهد و باعث شود تا در کاری که افراد می‌خواهند انجام دهند، مشارکت داشته باشیم. نسل‌های مختلف داوطلبان به سرمایه‌گذاری‌های متفاوتی نیاز دارند - مشارکت‌کنندگان با تجربه‌تر به ساده‌سازی و تعمیر جریان‌های کاری قدرتمندشان نیاز دارند، در حالی که مشارکت‌کنندگان جدیدتر به روش‌های جدیدی برای ویرایش نیاز دارند که برای آنها منطقی باشد، و در طول این نسل‌ها، همهٔ مشارکت‌کنندگان باید بتوانند با یکدیگر ارتباط برقرار کرده و برای انجام مؤثرترین کار خود با یکدیگر همکاری کنند. با این هدف، جریان‌های کاری حیاتی را برای مشارکت‌کنندگان باتجربه بهبود خواهیم داد، موانع مشارکت سازنده برای تازه‌واردان را کاهش خواهیم داد، و در راه‌هایی سرمایه‌گذاری خواهیم کرد که داوطلبان بتوانند با یکدیگر در حول علایق مشترک ارتباط برقرار کنند. | Marshall Miller |
| WE2 | مطالب دانشنامه‌ای | جوامع برای بستن موثر شکاف‌های دانش از طریق ابزارها و سیستم‌های پشتیبانی که دسترسی، تطبیق و بهبود آنها آسان‌تر است، حمایت می‌شوند و از رشد بیشتر محتوای دانشنامه‌ای قابل اعتماد اطمینان حاصل می‌کنند. | محتوای دانشنامه‌ای عمدتاً در ویکی‌پدیا را می‌توان از طریق مشارکت مداوم و نوآوری افزایش داد و بهبود بخشید. ابزارها و منابعی (اعم از فنی و غیر فنی) که برای مشارکت‌کنندگان در دسترسند تا برای رفع نیازهایشان از آنها استفاده کنند، می‌توانند قابل دسترس‌تر و قابل اعتمادتر شوند. این ابزارها باید توسط بنیاد ویکی‌مدیا بهتر پشتیبانی شوند، از طریق بهبود ویژگی‌هایی که در چرخه‌های کوتاه قابل دستیابی هستند. با توجه به روندهای اخیر در مورد تولید محتوا با کمک هوش مصنوعی و تغییر رفتار کاربر، ما همچنین زمینهٔ تغییرات اساسی (مانند ویکی‌توابع) را که می‌تواند به رشد مقیاس‌پذیر در ایجاد محتوا و استفادهٔ مجدد کمک کند، بررسی خواهیم کرد. مکانیسم‌های شناسایی شکاف‌های محتوا باید آسان‌تر کشف و برنامه‌ریزی شوند. منابعی که از رشد محتوای دانشنامه‌ای پشتیبانی می‌کنند، از جمله محتوای پروژه‌های خواهر، پروژه‌هایی مانند کتابخانهٔ ویکی‌پدیا، و کمپین‌ها را می‌توان بهتر با جریان‌های کاری مشارکت ادغام کرد. در عین حال، روش‌های مورد استفاده برای رشد باید دارای حفاظ‌هایی در برابر تهدیدهای فزاینده باشند، که می‌تواند اطمینان حاصل کند که همچنان به این فرآیند اعتماد وجود دارد و در عین حال به اصول اساسی محتوای دانشنامه‌ای که در پروژه‌های ویکی‌مدیا شناخته شده است، وفادار می‌ماند.
مخاطب: ویراستاران، مترجمان |
Runa Bhattacharjee |
| WE3 | تجربهٔ مصرف‌کننده (خواندن و رسانه) | نسل جدیدی از مخاطبان به ویکی‌پدیا می‌آیند تا مقصدی ترجیحی برای کشف، تعامل و ایجاد ارتباط پایدار با محتوای دانشنامه‌ای پیدا کنند. | اهداف
حفظ نسل فعلی و جدید مصرف‌کنندگان و حامیان. با آسان‌تر کردن روند کشف و تعامل محتوایمان، ارتباط را با نسل‌های فعلی و جدید مصرف‌کنندگان افزایش دهیم. برای تطبیق تجربیات و محتوای موجود در پلتفرم‌ها کار کنیم، به طوری که محتوای دایرةالمعارفی بتواند توسط نسل جدیدی از مصرف‌کنندگان و حامیان، کاوش و مدیریت شود. |
Olga Vasileva |
| WE4 | حمایت و امنیت | زیرساخت‌ها، ابزارها و فرآیندهای خود را بهبود بخشیم تا از جوامع، پلتفرم و سیستم‌های خدمات‌دهی خود در برابر انواع مختلف سوءاستفاده‌های مقیاس‌یافته و هدایت‌شده محافظت کنیم و در عین حال از یک محیط نظارتی در حال تحول پیروی کنیم. | برخی از جنبه‌های قابلیت‌های مبارزه با سوء استفادهٔ ما نیاز به ارتقا دارند. کاهش سوء استفاده مبتنی بر IP در حال کمتر شدن است، چندین ابزار مدیریت نیاز به بهبود کارایی دارند، و باید یک استراتژی یکپارچه تنظیم کنیم که به ما کمک کند با استفاده از سیگنال‌ها و مکانیسم‌های مختلف کاهش (کپچا، بلوک و غیره) با سوء استفاده مقیاس‌پذیر مبارزه کنیم. در طول این یک سال، پیشرفت در بزرگترین مشکلات در این فضا را آغاز خواهیم کرد. علاوه بر این، این سرمایه‌گذاری در حفاظت از سوء استفاده باید با سرمایه‌گذاری در درک و بهبود سلامت جامعه متعادل شود، که چندین جنبه از آن در الزامات مختلف نظارتی گنجانده شده است. | Suman Cherukuwada |
| WE5 | پلتفرم دانش ۱ (تکامل پلتفرم) | پلتفرم مدیاویکی و رابط‌های آن را برای پاسخگویی بهتر به نیازهای اصلی ویکی‌پدیا توسعه دهیم. | هدف اصلی ایجاد مدیاویکی، فراهم کردن امکاناتی برای ایجاد، ویرایش، ذخیره، کشف و مصرف محتوای باز و چند زبانه در مقیاس بزرگ بود. در دومین سال از راه‌اندازی پلتفرم دانش، قصد داریم به بهبود و توسعهٔ آن بپردازیم تا به بهترین شکل ممکن از نیازهای پروژه‌های ویکی‌مدیا در دههٔ آینده، با ویکی‌پدیا به عنوان نقطهٔ شروع، پاسخ دهیم. این اقدامات شامل ادامهٔ کار بر روی تعریف پلتفرم تولید دانش، افزایش پایداری سیستم، تمرکز بر سیستم افزونه‌ها و قلاب‌ها برای بهبود و ساده‌سازی فرآیند توسعهٔ ویژگی‌ها، و ادامهٔ سرمایه‌گذاری در اشتراک‌گذاری دانش و توانمندسازی افراد برای مشارکت در مدیاویکی است. | Birgit Müller |
| WE6 | پلتفرم دانش ۲ (خدمات توسعه‌دهنده) | کارکنان فنی و توسعه‌دهندگان داوطلب، ابزارهای مورد نیاز خود را برای پشتیبانی مؤثر از پروژه‌های ویکی‌مدیا در اختیار داشته‌باشند. | به کارِ آغازشده برای بهبود (و مقیاس) توسعه، آزمایش و استقرار گردش‌های کاری در تولید ویکی‌مدیا ادامه می‌دهیم و تعریف را برای گنجاندن خدمات برای توسعه‌دهندگان ابزار گسترش خواهیم داد. همچنین هدف ما بهبود توانایی خود در پاسخگویی به سوالات متداول در زمینهٔ گردش کار توسعه‌دهنده/مهندسی و مخاطبان و در دسترس قرار دادن داده‌های مرتبط برای امکان تصمیم‌گیری آگاهانه است. بخشی از این کار، نگاهی به شیوه‌هایی است (یا فقدان آنها) که در حال حاضر چالشی برای اکوسیستم‌مان هستند. | Birgit Müller |
| پیش‌نویس اهداف سیگنال‌ها و خدمات داده (SDS). | ||||
|---|---|---|---|---|
| هدف | حوزهٔ هدف | هدف | مفاد هدف | متولی |
| SDS1 | Shared insights | تصمیمات ما در مورد چگونگی حمایت از هدف و جنبش ویکی‌مدیا بر اساس معیارها و بینش‌های سطح بالا است. | برای اینکه بتوانیم به طور موثر و کارآمد، فناوری تولید کنیم، از داوطلبان حمایت کنیم، و از سیاست‌هایی حمایت کنیم که دسترسی به دانش را حافظت می‌کنند و پیشرفت می‌دهد، باید اکوسیستم ویکی‌مدیا را بشناسیم و با آنچه موفقیت به نظر می‌رسد هماهنگ باشیم. این به معنای ردیابی مجموعه‌ای از معیارهای متداول است که به موقع قابل اعتماد، قابل درک و در دسترس هستند. همچنین به معنای آشکارسازی تحقیقات و بینش‌هایی است که به ما کمک می‌کند چرایی‌ها و چگونگی‌های پشتِ اندازه‌گیری‌هایمان را درک کنیم. | Kate Zimmerman |
| SDS2 | پلتفرم آزمایش | مدیران محصول می‌توانند به سرعت، به راحتی و با اطمینان، اثرات ویژگی‌های محصول را ارزیابی کنند. | مدیران محصول برای فعال کردن و تسریع در تصمیم‌گیری مبتنی بر داده‌ها در مورد توسعهٔ ویژگی‌های محصول، به یک پلتفرم آزمایشی نیاز دارند که در آن بتوانند ویژگی‌ها را تعریف کنند، مخاطبان را انتخاب کنند و اندازه‌گیری تأثیر را ببینند. تسریع زمان از راه‌اندازی تا تجزیه و تحلیل بسیار مهم است، زیرا کوتاه کردن جدول زمانی برای یادگیری، آزمایش و در نهایت نوآوری را تسریع می‌کند. وظایف دستی و رویکردهای سفارشی اندازه‌گیری به عنوان موانع سرعت شناسایی شده‌اند. سناریوی ایده‌آل این است که مدیران محصول بتوانند با مداخلهٔ دستیِ کم یا بدون دخالت دستی مهندسان و تحلیلگران، از راه‌اندازی آزمایش تا کشف پیش بروند. | Tajh Taylor |
| پیش‌نویس اهداف مخاطبان آینده (FA) | ||||
|---|---|---|---|---|
| هدف | حوزهٔ هدف | هدف | مفاد هدف | متولی |
| FA1 | فرضیه‌های آزمون | توصیه‌هایی در مورد سرمایه‌گذاری‌های استراتژیک برای بنیاد ویکی‌مدیا ارائه دهید – بر اساس بینش‌های حاصل از آزمایش‌ها که درک ما را از نحوهٔ اشتراک‌گذاری و مصرف آنلاین دانش تقویت می‌کند – که به جنبش ما در خدمت به مخاطبان جدید در اینترنت در حال تغییر کمک می‌کند. | به دلیل تغییرات مداوم در فناوری و رفتار کاربران آنلاین (به عنوان مثال، افزایش اولویت برای دریافت اطلاعات از طریق شبکه‌های اجتماعی، محبوبیت ویدیوهای کوتاه آموزشی-سرگرمی، ظهور هوش مصنوعی مولد)، جنبش ویکی‌مدیا با چالش‌هایی در جذب و حفظ خوانندگان و مشارکت‌کنندگان مواجه است. این تغییرات همچنین فرصت‌هایی را برای خدمت به مخاطبان جدید با ایجاد و ارائهٔ اطلاعات به روش‌های جدید به ارمغان می‌آورد. با این حال، ما به‌عنوان یک جنبش، تصویر واضحی از مزایا و معاوضه‌های استراتژی‌های بالقوهٔ متفاوتی که می‌توانیم برای غلبه بر چالش‌ها یا استفاده از فرصت‌های جدید دنبال کنیم، نداریم. به عنوان مثال، آیا ما باید ...
برای اطمینان از اینکه ویکی‌مدیا به یک پروژهٔ چندنسلی تبدیل می‌شود، فرضیه‌هایی را برای درک بهتر و توصیهٔ استراتژی‌های امیدوارکننده - برای بنیاد ویکی‌مدیا و جنبش ویکی‌مدیا - برای جذب و حفظ مخاطبان آینده آزمایش خواهیم کرد. |
Maryana Pinchuk |
| پیش‌نویس اهداف پشتیبانی محصول و مهندسی (PES). | ||||
|---|---|---|---|---|
| هدف | حوزهٔ هدف | هدف | مفاد هدف | متولی |
| PES1 | کارایی عملیات | کار بنیاد را سریع‌تر، ارزان‌تر و تأثیرگذارتر کنیم. | کارکنان در کارهای منظم خود کارهای زیادی انجام می‌دهند تا عملیات ما سریع‌تر، ارزان‌تر و تأثیرگذارتر شود. این هدف ابتکارات خاصی را برجسته می‌کند که هم الف) دستاوردهای قابل توجهی را در جهت سریع‌تر، ارزان‌تر یا تأثیرگذارتر ایجاد می‌کند، و ب) تلاش هماهنگ و تغییر رویه‌های رسمی و غیر رسمی در بنیاد. اساساً، KRهای گنجانده‌شده در این هدف سخت‌ترین و بهترین پیشرفت‌هایی هستند که می‌توانیم امسال در بهره‌وری عملیاتی کار در ارتباط با محصولات و فناوری خود انجام دهیم. | Amanda Bittaker |
پیش‌نویس نتایج کلیدی
پیش‌نویس «نتایج کلیدی» (KR) برای هر هدف نهایی در اینجا آمده است. آنها با هر یک از اهداف بالا مطابقت دارند.
'فرضیه‌های' اساسی برای هر KR در صفحات ویکی پروژه یا تیم مربوطِ در طول سال با آموختن درس‌ها به‌روز می‌شود.
| نتایج کلیدی پیش‌نویس تجربیات ویکی (WE).
[ پیش‌نویس اهداف ] | |||
|---|---|---|---|
| نام کوتاه کلیدی نتیجه | متن کلیدی نتیجه | زمینهٔ کلیدی نتیجه | متولی |
| WE1.1 | یک جریان کاری را توسعه دهید یا بهبود بخشید که به مشارکت‌کنندگان با علایق مشترک کمک می‌کند تا با یکدیگر ارتباط برقرار کرده و با یکدیگر همکاری داشته باشند. | فکر می‌کنیم که فضاهای اجتماعی و تعاملات در ویکی‌ها، باعث می‌شوند تا مشارکت‌کنندگان شادتر و سازنده‌تر باشند. به‌علاوه، فضاهای اجتماعی به تازه‌واردها کمک کرده و آنها را راهنمایی می‌کنند. این امر باعث می‌شود تا بهترین شیوه‌های مشارکت را مدل‌سازی کنند و به رفع شکاف‌های دانش کمک نمایند. با این حال، منابع، ابزارها و فضاهای موجود که از ارتباط انسانی در ویکی‌ها پشتیبانی می‌کنند، در سطح پایین‌تری قرار دارند و چالش‌ها و نیازهای اکثر ویراستاران امروزی را برآورده نمی‌کنند. در همین حال، کار تیم کمپین‌ها نشان داده است که بسیاری از سازمان‌دهندگان مشتاق هستند تا ابزارهای جدیدی را با جریان‌های کاری ساختاریافته که به آنها در کارهای اجتماعی کمک می‌کند، بپذیرند و آزمایش نمایند. به این دلایل، می‌خواهیم بر تشویق و ترویج حس تعلق در میان مشارکت‌کنندگان در ویکی‌ها تمرکز کنیم. | Ilana Fried |
| WE1.2 | فعال‌سازی سازنده: سالانه #% افزایش در تازه‌واردانی که ≥1 ویرایش سازنده را در فضای نام اصلی دستگاه تلفن همراه منتشر می‌کنند. |
تجارب فعلی ویرایش تمام‌صفحه نیاز به زمینه، صبر، و آزمون و خطای بسیار زیادی دارد تا بسیاری از تازه‌واردان بتوانند به‌طور سازنده مشارکت کنند. برای حمایت از نسل جدیدی از داوطلبان، تعداد و در دسترس بودن گردش‌های کاری ویرایشی کوچکتر، ساختاریافته و خاص‌تر را افزایش می‌دهیم (به عنوان مثال بررسی ویرایش و وظایف ساختاریافته).
توجه: خطوط پایه فقط در پایان سه‌ماههٔ چهارم سال مالی جاری ایجاد می‌شوند، پس از آن درصد متریک هدف KR ما نیز تعیین می‌شود. |
Peter Pelberg |
| WE1.3 | افزایش رضایت کاربر در ۴ محصول تعدیل‌شده تا X٪. | ویراستاران با حقوق گسترده از طیف وسیعی از ویژگی‌ها، برنامه‌های افزودنی، ابزارها و اسکریپت‌های موجود برای انجام وظایف تعدیل در پروژه‌های ویکی‌مدیا استفاده می‌کنند. امسال می‌خواهیم به جای انجام پروژه‌هایی برای ایجاد قابلیت‌های جدید در این فضا، بر روی بهبود این ابزار تمرکز کنیم. قصد داریم در طول سال تعدادی از محصولات را آزمایش کنیم و می‌خواهیم پیشرفت‌های مؤثری در هر کدام ایجاد کنیم. امیدواریم با انجام این کار، تجربهٔ مدیریت محتوا را به‌طور کلی بهبود بخشیم. ما X% را با اندازه‌گیری خطوط پایه برای برخی از ابزارهای متداول ناظر که ممکن است با این جریان کاری هدف قرار دهیم، تعریف می‌کنیم. فهرست آرزوهای اجتماع کمک قابل توجهی در تصمیم‌گیری در مورد اولویت‌های این KR خواهد بود. We will define baselines for common moderator tools that we may target with this workstream to determine increase in satisfaction per tool. The Community Wishlist will be a substantial contributor to deciding on the priorities for this KR. |
Sam Walton |
| WE2.1 | تا پایان سه‌ماههٔ دوم، سازمان‌دهندگان، مشارکت‌کنندگان و مؤسسات را با ابزارها، بینش‌ها و رویکردهای سازمان‌دهی خاصی که پوشش محتوای با کیفیت را در حوزه‌های موضوعی کلیدی [TBD] تا X درصد افزایش می‌دهد، پشتیبانی کنیم. | این KR در مورد بهبود پوشش موضوع به منظور کاهش شکاف‌های دانش موجود است. ثابت کرده‌ایم که جوامع از ابزارهای مؤثر همراه با کمپین‌هایی که هدفشان افزایش کیفیت محتوا در پروژه‌های ما است، سود می‌برند. امسال می‌خواهیم روی بهبود ابزارهای موجود و آزمایش روش‌های جدید برای اولویت‌بندی حوزه‌های موضوعی کلیدی که به شکاف‌های دانشی می‌پردازند، تمرکز کنیم. افزایش X% هدف ما در پوشش با نگاهی به خطوط پایه موجود برای ایجاد محتوای با کیفیت تعیین خواهد شد. همچنین، حوزه‌های موضوعی که با جوامع و موسسات بر روی آنها تمرکز خواهیم کرد تا سه‌ماهه آینده مشخص خواهد شد. Our target 138 articles will be determined by looking at existing baselines of quality content creation. |
Purity Waigi & Fiona Romeo |
| WE2.2 | تا پایان سه‌ماههٔ دوم، دو توصیهٔ اجتماعی و فنی را برای پشتیبانی از ورود زبان برای جوامع زبانی کوچک، با ارزیابی تجزیه و تحلیل بازخورد جامعه، اجرا و آزمایش کنیم. | نسخه‌های ویکی‌پدیا به حدود ۳۰۰ زبان وجود دارند. و با این حال، بسیاری از زبان‌های دیگر وجود دارند که میلیون‌ها نفر به آنها صحبت می‌کنند، که در آنها نه ویکی‌پدیا و نه ویکی وجود دارد. این مانعی برای تحقق دیدگاه ما است: اینکه هر انسان می‌تواند آزادانه در مجموع همهٔ دانش سهیم باشد. ویکی‌رشد ویکی‌مدیا، جایی است که ویکی‌های بالقوهٔ پروژه‌های ویکی‌مدیا در نسخه‌های جدید زبان را می‌توان مرتب کرد، نوشت، آزمایش کرد و ارزش میزبانی توسط بنیاد ویکی‌مدیا را ثابت کرد. ویکی‌رشد در سال ۲۰۰۶ با این فرض راه‌اندازی شد که کاربران آن، دانش پیشینی دربارهٔ ویرایش ویکی را داشته باشند. این مشکل با این واقعیت تشدید می‌شود که قرار است این فرایند بیشتر توسط افرادی انجام شود که جدیدترین و کم‌تجربه‌ترین در جنبش ما هستند. در حالی که ویرایش در ویکی‌های ویکی‌مدیا از آن زمان به‌طور چشمگیری بهبود یافته است، ویکی‌رشد این به‌روزرسانی‌ها را دریافت نکرده است. به محدودیت‌های فنی در حال حاضر، چندین هفته طول می‌کشد تا یک ویکی از ویکی‌رشد خارج شود و تنها حدود ۱۲ ویکی در هر سال ایجاد می‌شوند، که همین امر، نشان‌دهندهٔ یک تنگنای قابل توجه است.
تحقیقات و مواد موجود چالش‌های فنی را در هر مرحله از راه‌اندازی زبان نشان می‌دهد: افزودن زبان‌های جدید به ویکی‌رشد، پیچیدگی‌ها در توسعه و بررسی محتوا، و روند کند در ایجاد یک سایت ویکی هنگامی که زبانی از ویکی‌رشد خارج می‌شود. هر مرحله، آهسته، دستی و پیچیده است که نشان‌دهندهٔ لزوم بهبود است. پرداختن به این مشکل به ایجاد ویکی‌ها به زبان‌های جدید سریع‌تر و آسان‌تر اجازه می‌دهد و به انسان‌های بیشتری اجازه می‌دهد تا دانش را به اشتراک بگذارند. ذینفعان، تحقیقات و منابع مختلف توصیه‌های پیشنهادی اجتماعی و فنی را برجسته کرده‌اند. این نتیجهٔ کلیدی آزمایش دو توصیهٔ اجتماعی و فنی و ارزیابی بازخورد جامعه را پیشنهاد می‌کند. |
Satdeep Gill & Mary Munyoki |
| WE2.3 | تا پایان سه‌ماههٔ دوم، ۲ ویژگی جدید مشارکت‌کنندگان را راهنمایی می‌کند تا منابع منبعی را اضافه کنند که با دستورالعمل‌های پروژه مطابقت دارد، و ۳ تا ۵ شریک، منبعی را ارائه کرده‌اند که به شکاف‌های زبانی و جغرافیایی می‌پردازد. | برای افزایش دسترسی به مواد منبع با کیفیت که برای حل شکاف های محتوای استراتژیک مورد نیاز است، ما:
|
Fiona Romeo & Alexandra Ugolnikova |
| WE2.4 | تا پایان سه‌ماههٔ دوم، تماس‌های Wikifunctions را با حداقل یک زبان کوچکتر ویکی‌پدیا فعال کنید تا روشی مقیاس‌پذیرتر برای ایجاد محتوای جدید ارائه دهد. | برای کاهش مؤثر شکاف‌های دانشی، باید جریان‌های کاری را بهبود بخشیم که از رشد مقیاس‌پذیر در محتوای با کیفیت، به ویژه در جوامع زبانی کوچکتر پشتیبانی می‌کند. | Amy Tsay |
| WE3.1 | با هدف افزایش ۵٪ حفظ خوانندگان از سیستم خارج‌شده کاربران تجربه، دو تجربه مرور و یادگیری انتخاب شده، در دسترس و مبتنی بر جامعه را برای ویکی‌های نماینده منتشر کنید. | این KR بر افزایش حفظ نسل جدیدی از خوانندگان در وب‌سایت‌مان تمرکز می‌کند، و به نسل جدید اجازه می‌دهد تا ارتباط پایداری با ویکی‌پدیا ایجاد کنند، با کاوش در فرصت‌هایی برای خوانندگان برای کشف آسان‌تر و یادگیری از محتوای مورد علاقه‌شان. کاوش‌ها و توسعه تجربه‌های مرور و یادگیری جدید، شخصی‌سازی‌شده، و جامعه محور (به عنوان مثال، فیدهای محتوای مرتبط، توصیه‌ها و پیشنهادات محتوای موضوعی، فرصت‌های کاوش محتوای انتخاب‌شده توسط جامعه، و غیره).
برای شروع سال مالی با آزمایش یک سری آزمایش از تجربیات مرور برنامه‌ریزی می‌کنیم تا مشخص کنیم که کدام یک را می‌خواهیم برای استفاده در تولید مقیاس بندی کنیم، و در کدام پلت فرم (وب، برنامه‌ها یا هر دو). سپس بر مقیاس‌بندی این آزمایش‌ها و آزمایش اثربخشی آنها در افزایش ماندگاری در محیط‌های تولید تمرکز خواهیم کرد. هدف ما تا پایان سال راه‌اندازی حداقل دو تجربه در ویکی‌های نماینده و اندازه‌گیری دقیق افزایش ۵ درصدی در حفظ خواننده برای خوانندگانی است که در این تجربیات مشغول هستند. برای مؤثر بودن بهینه در دستیابی به این KR، به توانایی تست A/B با کاربرانی که از سیستم خارج شده‌اند، و همچنین ابزار دقیقی که قادر به اندازه‌گیری حفظ خواننده هستند نیاز داریم. همچنین ممکن است به APIها یا خدمات جدیدی نیاز داشته باشیم که برای ارائه توصیه‌ها و سایر مکانیسم‌های مراقبت لازم است. |
Olga Vasileva |
| WE3.2 | ۵۰ درصد افزایش در تعداد کمک‌های مالی از طریق نقاط لمسی خارج از بنر سالانه و درخواست‌های ایمیل در هر پلتفرم. | هدف ما این است که منابع درآمدی متنوعی را فراهم کنیم و در عین حال کمک‌کنندگان موجود خود را بشناسیم. بر اساس بازخورد و داده‌ها، تمرکزمان بر افزایش تعداد کمک‌ها فراتر از روش‌هایی است که بنیاد در گذشته به آنها تکیه کرده است، به‌ویژه درخواست‌های بنر سالانه. می‌خواهیم نشان دهیم که با سرمایه‌گذاری در تجربیات اهداکنندگان یکپارچه‌تر، می‌توانیم کار خود را حفظ کرده و با ارائهٔ جایگزینی برای اهداکنندگان کنونی و اهداکنندگان بالقوه که به درخواست‌های بنر پاسخ نمی‌دهند، تأثیر خود را گسترش دهیم. ۵۰٪ تخمین اولیه بر اساس کاهش دید دکمهٔ اهدا در وب در نتیجهٔ وکتور ۲۰۲۲، و افزایش تعداد کمک‌های مالی از پروژهٔ آزمایشی سال مالی ۲۰۲۳–۲۰۲۴ در برنامه‌های ویکی‌پدیا برای بهبود تجربیات اهداکنندگان است (۵۰٫۱٪). ارزیابی این معیار بر اساس پلتفرم به ما کمک می‌کند تا روندها را در پلتفرم‌ها درک کنیم و اینکه آیا تاکتیک‌های متفاوتی باید در آینده بر اساس تفاوت در رفتار براساس مخاطبان پلتفرم به کار گرفته شود یا خیر. | Jazmin Tanner |
| WE3.3 | By the end of Q2 2024-25, volunteers will start converting legacy graphs to the new graph extension on production Wikipedia articles. | The Graph extension has been disabled for security reasons since April 2023, leaving readers unable to view many graphs that community members have invested time and energy into over the last 10 years. Data visualization plays a role in creating engaging encyclopedic content, so in FY 2024-25, we will build a new secure service to replace the Graph extension that will handle the majority of simple data visualization use cases on Wikipedia article pages. This new service will be built in an extensible way to support more sophisticated use cases if WMF or community developers choose to do so in the future. We will know we’ve achieved success when community members are successfully converting legacy graphs and publishing new graphs using the new service. We will determine which underlying data visualization library to use and which graph types to support during the initial phase of the project. |
Christopher Ciufo |
| WE3.4 | Develop the capability model to improve website performance through smaller scale cache site deployments that take one month to implement while maintaining technical capabilities, security and privacy. |
The Traffic team is responsible for maintaining the Content Delivery Network (CDN). This layer caches frequently accessed content, pages, etc, in memory and on disk. This reduces the time it takes to process requests for users. The second bit is storing content closer to the user in a physical sense. That reduces the time it takes for data to reach the user (latency). Last year, we enabled one site in Brazil meant to reduce latency in the Southern American region. Setting up new data centers would be great but it is expensive, time consuming, and requires a lot of work to get done – for example, last year’s work spanned the full year. We would love to have centers in Africa and Southeast Asia, and we would love to have them all around the world. Our hypothesis is to spin up smaller sites in other places around the world where traffic is lower. These would require fewer servers, of not more than four or five servers. This reduces our cost. It would still help us reduce latency for users in these regions, while being more lightweight in terms of time and effort to maintain them. |
Kwaku Ofori |
| WE4.1 | ارائهٔ پیشنهادی متشکل از ۳ اقدام متقابل برای آزار و اذیت و محتوای مضر که بر اساس داده‌ها و مطابق با محیط نظارتی در حال تحول توسط Q3 است. | تضمین ایمنی و رفاه کاربر یک مسئولیت اساسی پلتفرمهای آنلاین است. بسیاری از حوزه‌های قضایی قوانین و مقرراتی دارند که پلتفرمهای آنلاین را ملزم می‌کنند تا علیه مزاحمت، مزاحمت سایبری و سایر محتوای مضر اقدام کنند. عدم رسیدگی به این موارد ممکن است پلتفرم‌ها را در معرض مسئولیت قانونی و تحریم‌های نظارتی قرار دهد.
در حال حاضر ایدهٔ خیلی خوبی در مورد بزرگی این مشکلات یا دلایل پشت سر آنها نداریم. ما به شدت به شواهد حکایتی و فرآیندهای دستی تکیه می‌کنیم که ما را در معرض خطرات قانونی و همچنین سایر پیامدهای گسترده قرار می‌دهد: دست کم گرفتن مشکل، تشدید آسیب، آسیب به شهرت و کاهش اعتماد کاربران. باید یک فرهنگ قوی برای سنجش میزان بروز آزار و اذیت و محتوای مضر ایجاد کنیم و اقدامات متقابل را به‌طور فعال اجرا کنیم. |
Madalina Ana |
| WE4.2 | حداقل دو سیگنال را برای استفاده در جریان‌های کاری ضد سوء استفاده ایجاد کنید تا دقت اقدامات روی بازیگران بد را در Q3 بهبود بخشد. | ویکی‌ها به شدت به مسدود کردن آی‌پی به عنوان مکانیزمی برای مسدود کردن خرابکاری، هرزنامه و سوء استفاده متکی هستند. اما آدرس‌های آی‌پی به‌طور فزاینده‌ای به‌عنوان شناسه‌های پایدار یک بازیگر فردی مفید نیستند، و مسدود کردن آدرس‌های آی‌پی اثرات منفی ناخواسته‌ای بر روی کاربرانی که با حسن نیت خود آدرس آی‌پی مشابهی را با بازیگران بد به اشتراک می‌گذارند، دارد. ترکیبی از کاهش پایداری آدرس‌های آی‌پی و اتکای شدید ما به مسدود کردن آی‌پی منجر به دقت و اثربخشی کمتری در هدف‌گیری بازیگران بد، در ترکیب با افزایش سطوح آسیب جانبی برای کاربران حسن نیت می‌شود. ما می‌خواهیم وضعیت معکوس را ببینیم: کاهش سطح آسیب‌های جانبی و افزایش دقت در اقدامات کاهشی که بازیگران بد را هدف قرار می‌دهد.
برای حمایت بهتر از کار ضد سوء استفاده کارمندان و فراهم کردن بلوک‌های ساختمانی برای استفاده مجدد در ابزارهای موجود (مانند CheckUser, Special:Block) و ابزارهای جدید، در این KR پیشنهاد می‌کنیم راه‌هایی را برای ارتباط قابل اعتماد یک فرد با اقدامات آنها بررسی کنیم. و سیگنال‌های موجود (مانند آدرس‌های IP، سابقه حساب، ویژگی‌های درخواست) را برای هدف‌یابی دقیق‌تر اقدامات روی بازیگران بدترکیب کنید. |
Kosta Harlan |
| WE4.3 | اثربخشی یک حمله توزیع شده در مقیاس بزرگ را تا ۵۰٪ کاهش دهید، همان‌طور که با زمان اندازه‌گیری شده برای تطبیق اقدامات خود و حجم ترافیکی که می‌توانیم در یک شبیه‌سازی حفظ کنیم، اندازه‌گیری می‌شود. | تکامل چشم‌انداز اینترنت، از جمله ظهور بات نت‌های بزرگ و حملات مکرر، روش‌های سنتی ما برای محدود کردن سوء استفاده در مقیاس بزرگ را منسوخ کرده است. چنین حملاتی می‌تواند سایت‌های ما را با پر کردن زیرساخت‌های ما با درخواست‌ها از دسترس خارج کند، یا توانایی جامعه ما را برای مبارزه با خرابکاری در مقیاس بزرگ تحت تأثیر قرار دهد. این همچنین فشار غیرمنطقی بر ویراستاران با امتیاز بالا و جامعه فنی ما وارد می‌کند.
ما فوراً نیاز به بهبود توانایی خود برای شناسایی خودکار، مقاومت در برابر و کاهش یا توقف چنین حملاتی داریم. برای اندازه‌گیری پیشرفت‌هایمان، نمی‌توانیم صرفاً بر فرکانس/شدت حملات واقعی تکیه کنیم، زیرا به اقدامات خارجی وابسته هستیم و به سختی می‌توان تصویر کمی روشن از پیشرفت‌مان به دست آورد. با راه‌اندازی چندین حملهٔ شبیه‌سازی‌شده با ماهیت/پیچیدگی/مدت مختلف برای اجرای ایمن علیه زیرساخت‌های ما، و اجرای آنها در هر سه‌ماهه، می‌توانیم اقدامات متقابل جدید خود را در حالی که مورد حمله قرار نگرفته‌ایم آزمایش کنیم و به‌طور عینی از پیشرفت‌های خود گزارش دهیم. |
Giuseppe Lavagetto |
| WE4.4 | Launch temp accounts to 100% of all wikis. | Temporary accounts are a solution for complying with various regulatory requirements around the exposure of IPs on our platform on various surfaces. This work involves updating many products, data pipelines, functionary tools, and various volunteer workflows to cope with the existence of an additional type of account. | Madalina Ana |
| WE5.1 | تا سه‌ماههٔ سوم، حداقل ۵ مداخله را که برای افزایش پایداری پلت فرم در نظر گرفته شده است، تکمیل کنید. | پایداری پلتفرم مدیاویکی یک تلاش همیشه سبز برای توانایی ما در مقیاس، افزایش یا اجتناب از کاهش رضایت توسعه‌دهندگان و رشد جامعه فنی ما است. اندازه‌گیری این امر دشوار است و به عوامل فنی و اجتماعی بستگی دارد. با این حال، ما دانش ضمنی در مورد زمینه‌های خاص بهبودهایی داریم که برای پایداری استراتژیک هستند. مداخلات برنامه‌ریزی شده ممکن است به افزایش پایداری و قابلیت نگهداری پلت فرم کمک کند یا از تخریب آن جلوگیری کند. ما قصد داریم تأثیر این کار را در سه‌ماهه چهارم با توصیه‌هایی برای اهداف پایداری در حال حرکت به جلو ارزیابی کنیم. نمونه‌هایی از مداخلات پایداری عبارتند از: ساده‌سازی دامنه‌های کد پیچیده‌ای که هسته اصلی مدیاویکی هستند، اما تعداد انگشت شماری از مردم می‌دانند که چگونه کار می‌کند. افزایش استفاده از ابزار تجزیه و تحلیل کد برای اطلاع از کیفیت پایگاه کد ما. فرآیندهایی مانند بسته‌بندی و انتشار را ساده کنید. | Mateus Santos |
| WE5.2 | تا Q2 شناسایی کنید و تا Q4 یک یا چند مداخله را برای تکامل رابط‌های برنامه‌نویسی اکوسیستم مدیاویکی برای توانمندسازی توسعه ویژگی‌های جداشده، ساده‌تر و پایدارتر تکمیل کنید. | هدف اصلی KR 5.2 بهبود و شفاف‌سازی تعامل بین پلتفرم اصلی مدیاویکی و برنامه‌های افزودنی، پوسته‌ها و سایر بخش‌های آن است. هدف ما ارائه پیشرفت‌های کاربردی در معماری مدیاویکی است که ماژولار بودن و قابلیت نگهداری عملی را ممکن می‌سازد، که توسعه برنامه‌های افزودنی برای آن آسان‌تر است، و توانمندسازی الزامات چشم‌انداز محصول مدیاویکی گسترده‌تر. این کار همچنین با هدف اطلاع دادن به آنچه باید در هسته، برنامه‌های افزودنی یا رابط‌های بین آنها وجود داشته باشد (یا نه) است. سال به دو مرحله تقسیم خواهد شد: یک مرحله تحقیقاتی و آزمایشی ۵ ماهه که مرحله دوم را که در آن مداخلات خاص اجرا می‌شود، اطلاع‌رسانی می‌کند. | Jonathan Tweed |
| WE5.3 | تا پایان سه‌ماههٔ دوم، یک ابتکار جمع‌آوری داده و یک آزمایش بهبود عملکرد را تکمیل کنید تا از مداخلات بعدی محصول و پلتفرم مطلع شوید تا از قابلیت‌هایی استفاده کنید که توسط مدل‌سازی مدیاویکی از صفحه به‌عنوان ترکیبی از قطعات ساختاریافته باز شده است. | هدف اصلی در اینجا، توانمندسازی توسعه‌دهندگان و مدیران محصول برای استفاده از قابلیت‌های پلتفرم مدیاویکی جدید برای برآوردن نیازهای فعلی و آتی محتوای دایره‌المعارفی از طریق امکان‌پذیر ساختن پیشنهادات محصول جدید است که در حال حاضر پیاده‌سازی آنها دشوار است و همچنین بهبود عملکرد و انعطاف‌پذیری پلتفرم.
به‌طور خاص، در سطح پلتفرم مدیاویکی، می‌خواهیم مدل پردازش مدیاویکی را از تلقی یک صفحه به‌عنوان یک واحد یکپارچه به یک صفحه به‌عنوان ترکیبی از واحدهای محتوای ساختاریافته تغییر دهیم. نماهای خواندنی مبتنی بر پارسوئید، ادغام ویکی‌داده، و ادغام توابع ویکی در ویکی‌ها، همه حرکت‌های ضمنی به سمت آن هستند. به‌عنوان بخشی از این KR، ما می‌خواهیم عمداً با آزمایش و جمع‌آوری داده‌ها به مداخلات آینده بر اساس این قابلیت‌های جدید اطلاع دهیم تا اطمینان حاصل کنیم که می‌توانیم به زیرساخت‌های مورد نظر و تأثیرات محصول دست یابیم. |
Subramanya Sastry |
| WE5.4 | By the end of Q2, execute the 1.43 LTS release with a new MW release process that synchronizes with PHP upgrades. | The MediaWiki software platform relies on regular updates to the next PHP version to remain secure and sustainable, which is a pain point in our process and important for the modernization of our infrastructure. At the same time, we regularly release new versions of the MediaWiki software, which e.g. translatewiki.net depends on, the platform used to translate software messages for the Wikimedia projects and many other open source projects. There’s an opportunity to improve the MediaWiki release process, including technical documentation and synchronization with PHP upgrades in alignment with the MediaWiki product strategy before the next release, which will be a long term support version (LTS). This work is part of our strategic investment in the sustainability of the MediaWiki platform (see also: 5.1) and aims to improve developer experience and infrastructure management. |
Mateus Santos |
| WE6.1 | ۵ سؤال را حل کنید تا کارایی و تصمیمات آگاهانه در مورد گردش کار و خدمات توسعه دهنده و مهندسی را فعال کنید و داده‌های مربوطه را تا پایان سه‌ماههٔ چهارم در دسترس قرار دهید. | «پیچیده است» پاسخ مکرر به سؤالاتی است مانند «کدام مخازن برای تولید ویکی‌مدیا مستقر شده‌اند». در این KR ما برخی از «همیشه سبز» خود را در زمینه بهره‌وری و تجربه مهندسی بررسی خواهیم کرد - سوالات تکراری که آسان به نظر می‌رسند اما پاسخ دادن به آنها سخت است، سوالاتی که می‌توانیم به آنها پاسخ دهیم، اما داده‌ها قابل دسترسی نیستند و نیاز به سوالات سفارشی بر اساس موضوع دارند. کارشناسان موضوع، یا سوالاتی که به دلیل شکاف فرآیندی یا دلایل دیگر برای دریافت پاسخ دشوار است. ما معنای «حل» را برای هر یک از سؤالات تعریف خواهیم کرد: برای برخی این ممکن است فقط به معنای دسترسی به داده‌های موجود و دقیق باشد. سؤالات دیگر به تحقیق و زمان مهندسی بیشتری برای پرداختن به آنها نیاز دارند. هدف کلی این کار کاهش زمان، راه‌حل‌ها و تلاشی است که برای به دست آوردن بینش در مورد جنبه‌های کلیدی تجربه توسعه‌دهنده نیاز است و ما را قادر می‌سازد تا در جریان‌های کاری و خدمات مهندسی و توسعه‌دهنده پیشرفت کنیم. | [TBD] |
| WE6.2 | تا Q4، پروژه موجود را ارتقا دهید و حداقل دو آزمایش را با هدف ارائه محیط‌های قابل نگهداری و هدفمند انجام دهید که ما را به سمت تحویل ایمن و نیمه پیوسته سوق می‌دهد. | توسعه‌دهندگان و کاربران به خوشه بتای ویکی‌مدیا (بتا) وابسته هستند تا اشکالات را قبل از اینکه روی کاربران در تولید تأثیر بگذارند، پیدا کنند. با گذشت زمان، استفاده از بتا افزایش یافته و در تضاد قرار گرفته است - کاربردها بسیار متنوع هستند و نمی‌توانند در یک محیط واحد قرار بگیرند. ما یک محیط جایگزین موجود را بهبود خواهیم بخشید و آزمایش‌هایی را با هدف جایگزینی یک نیاز آزمایشی با اولویت بالا که در حال حاضر توسط بتا برآورده شده است، با یک محیط جایگزین قابل نگهداری که بهتر نیازهای هر مورد استفاده را برآورده می‌کند، انجام خواهیم داد. | Tyler Cipriani |
| WE6.3 | Develop a Toolforge sustainability scoring framework by Q3. Apply it to improve at least one critical platform aspect by Q4 and inform longer-term strategy. | Toolforge، پلت فرم کلیدی برای ابزارهای داوطلبانه ویکی‌مدیا، از ویرایش تا ضد خرابکاری نقش مهمی ایفا می‌کند. هدف ما افزایش قابلیت استفاده از Toolforge، کاهش موانع مشارکت، بهبود شیوه‌های جامعه و ترویج پایبندی به سیاست‌های تعیین شده است. برای این منظور، ما یک سیستم امتیازدهی توسط Q2 برای ارزیابی پایداری پلتفرم Toolforge با تمرکز بر جنبه‌های فنی و اجتماعی معرفی می‌کنیم. با استفاده از این سیستم به عنوان راهنما، هدف ما بهبود یکی از عوامل فنی کلیدی تا ۵۰٪ است. | Slavina Stefanova |
| نتایج کلید پیش‌نویس سیگنال‌ها و خدمات داده (SDS).
[ پیش‌نویس اهداف ] | |||
|---|---|---|---|
| نام کوتاه کلیدی نتیجه | متن کلیدی نتیجه | زمینهٔ کلیدی نتیجه | متولی |
| SDS1.1 | رهبران ۲ برنامه یا ابتکارات مبتنی بر KR مستندات به اشتراک گذاشته شده‌ای را ارائه کرده‌اند که پیوند منطقی بین کار تیمشان و تأثیر آن بر یک یا چند معیار اصلی بنیاد را توضیح می‌دهد. | معیارهای اصلی سازمانی ما به عنوان مبنایی برای ارزیابی پیشرفت بنیاد به سمت اهدافش عمل می‌کند. همان‌طور که ما منابع را به برنامه‌ها تخصیص می‌دهیم و جریان‌های کاری مبتنی بر نتایج کلیدی (KR) را طراحی می‌کنیم، این معیارهای سطح بالا باید نحوه پیوند این سرمایه‌گذاری‌ها را به اهداف کلی بنیاد همان‌طور که در برنامه سالانه تعریف شده است راهنمایی کند. کار در این نتیجه کلیدی تصدیق می‌کند که بنیاد به عنوان یک کل در مرحله اولیه توانایی خود برای پیوند کمی تأثیرات همه مداخلات برنامه‌ریزی شده به معیارهای سطح بالا یا اصلی است. در تعقیب این هدف نهایی، این KR قصد دارد فرآیندی را توسعه دهد که از طریق آن ما پیوندهای منطقی و نظری بین ابتکارات خود و معیارهای سطح بالای خود را به اشتراک می‌گذاریم. در عمل، این به معنای مشارکت با صاحبان ابتکار در سراسر بنیاد است تا بفهمیم چگونه خروجی کار آنها در سطح پروژه با معیارهای اصلی ما در سطح بنیاد مرتبط است و بر آن تأثیر می‌گذارد. چارچوب‌ها و تمرین‌های نگاشت تأثیر مانند «نقشه‌برداری تئوری تغییر» و ساخت نمودار علّی برای اطمینان از ثبات و دقت در مستندسازی تأثیر بالقوه کار استفاده می‌شود. برای اجرای این نتیجه کلیدی، ما همچنین نیاز به توسعه مواد پشتیبانی داریم که به صاحبان ابتکار کمک می‌کند تا معیارهای سازمانی را درک کنند و بفهمند که چگونه می‌توانند نظریه‌های تغییر مرتبط با کار خود را بسازند. |
Omari Sefu |
| SDS1.2 | به ۲ سؤال تحقیق باز استراتژیک تا دسامبر ۲۰۲۴ به منظور ارائه توصیه‌ها یا اطلاع‌رسانی برنامه‌ریزی سالانه مالی ۲۶ پاسخ دهید. | بسیاری از سوالات تحقیقاتی باز در اکوسیستم ویکی‌مدیا وجود دارد، و پاسخ به برخی از آنها برای بنیاد ویکی‌مدیا یا شرکت‌های وابسته راهبردی است. پاسخ به این سؤالات می‌تواند به توسعه محصول یا فناوری آینده کمک کند یا می‌تواند از تصمیم‌گیری/حمایت در فضای سیاست پشتیبانی کند. در حالی که برخی از این سؤالات را می‌توان با استفاده از تحقیقات صرفاً یا تخصص مهندسی پژوهشی پاسخ داد، با توجه به ماهیت اجتماعی و فنی پروژه‌های ویکی‌مدیا برای رسیدن به بینش‌های قابل اعتماد اغلب نیاز به همکاری بین تیمی برای جمع‌آوری داده‌ها، ایجاد زمینه، تعامل با کاربر، طراحی دقیق آزمایشات و موارد دیگر از طریق این KR هدف ما این است که برخی از منابع خود را برای پاسخ به یک یا چند مورد از این سؤالات اولویت بندی کنیم.
کار در این KR شامل اولویت بندی لیستی از سوالات باز استراتژیک و همچنین انجام کار آزمایشی برای یافتن پاسخ برای X عدد (در حال حاضر ۲ تخمین زده می‌شود) از آنها است. نوع ایده‌آل سوالاتی که در این KR به آنها می‌پردازیم، سوالاتی هستند که پس از پاسخ به آنها می‌توانند با فعال کردن چندین تیم یا گروه دیگر برای انجام کارهای محصول، فناوری یا خط‌مشی (بهتر؟ آگاهانه) اثر بازگشایی داشته باشند. ما قصد داریم کار در این KR مکمل KRهای زیر باشد:
|
Leila Zia |
| SDS1.3 | دستیابی به حداقل ۵۰٪ کاهش در میانگین زمان مورد نیاز برای ذینفعان داده برای درک و ردیابی جریان داده برای ۳ معیار اصلی و ضروری | برای استانداردهای حاکمیت داده مورد نیاز است.
ردیابی تبدیل و منبع مجموعه داده‌ها دشوار است و نیاز به دانش مخازن و سیستم‌های مختلف دارد. ما باید درک چگونگی جریان داده‌ها در اطراف سیستم‌هایمان را آسان کنیم تا ذینفعان داده بتوانند به روش خود سرویس بیشتری کار کنند. این کار از گردش‌های کاری پشتیبانی می‌کند که در آن داده‌ها تبدیل شده و برای تجزیه و تحلیل، ویژگی‌ها، API و کارهای کیفیت داده استفاده می‌شوند. یک پیگیری KR پیرامون مستندسازی معیارها وجود خواهد داشت. |
Luke Bowmaker |
| SDS2.1 | تا پایان سه‌ماهه دوم، ما می‌توانیم از ۱ تیم محصول برای ارزیابی یک ویژگی یا محصول از طریق آزمایش پایه A/B پشتیبانی کنیم که زمان آنها را به داده‌های تعامل کاربر تا ۵۰٪ کاهش می‌دهد. | فکر می‌کنیم که استفاده از ابزارهای مشترک، اعتماد تیم‌های محصول را در تصمیم‌گیری مبتنی بر داده افزایش می‌دهد، کارایی و بهره‌وری را بهبود می‌بخشد و استراتژی و نوآوری محصول را افزایش می‌دهد. ما به اتخاذ زمان فردی تیم برای مبانی داده‌های تعامل با کاربر نگاه خواهیم کرد و آن را تا ۵۰٪ بهبود خواهیم داد. ما همچنین بررسی خواهیم کرد که چگونه می‌توانیم این دستاوردها را در زمینه کامل‌تر همه تیم‌های محصول، زمینه‌سازی کنیم. انتظار داریم که یاد بگیریم چگونه می‌توانیم تجربه را بهبود بخشیم و بر اساس بازخورد تیم پذیرنده و نتایج SDS2.2، بهبود قابلیت‌ها را شناسایی و اولویت بندی کنیم. |
Virginia Poundstone |
| SDS2.2 | تا پایان سه‌ماهه دوم، ما ۲ معیار اساسی برای تجزیه و تحلیل آزمایش‌ها (تست‌های A/B) خواهیم داشت تا از آزمایش فرضیه‌های محصول/ویژگی مربوط به KRs-FY24-25 پشتیبانی کنیم. | وقتی یک مدیر محصول (یا طراح) این فرضیه را دارد که یک محصول/ویژگی مشکل/نیاز کاربران یا سازمان را برطرف می‌کند، آزمایش این است که چگونه آن فرضیه را آزمایش می‌کند و در مورد تأثیر بالقوه ایده خود بر یک متریک یادمی‌گیرد. نتایج آزمایش به مدیر محصول اطلاع می‌دهد و به او کمک می‌کند تا در مورد اقدام بعدی تصمیم بگیرد (این ایده را رها کنید و فرضیه دیگری را امتحان کنید، اگر آزمایش در اوایل چرخه توسعه انجام شده بود، توسعه را ادامه دهید، یا محصول/ویژگی را منتشر کنید. برای کاربران بیشتر). مدیران محصول باید بتوانند چنین تصمیمی را با اطمینان و با شواهدی که به آنها اعتماد دارند و درک می‌کنند، اتخاذ کنند.
یک مانع عمده برای این امر این است که تیم‌های محصول در حال حاضر فرضیه‌های خود را با معیارهای خاص پروژه سفارشی فرموله می‌کنند که برای تعریف، اندازه‌گیری، تجزیه و تحلیل و گزارش در مورد آنها نیاز به پشتیبانی تحلیلگر اختصاصی دارد. تغییر به مجموعه‌ای از معیارهای اساسی برای فرمول‌بندی همه گزاره‌های فرضیه محصول/ویژگی قابل آزمایش باعث می‌شود:
ما فکر می‌کنیم که مجموعه‌ای از معیارهای اساسی که به‌طور گسترده درک شده و به‌طور مداوم مورد استفاده قرار می‌گیرند - و با معیارهای استاندارد صنعت آگاه/تأثیر می‌شوند - همچنین سواد داده‌های سازمانی را بهبود می‌بخشد و فرهنگ مرور، آزمایش و یادگیری را ترویج می‌کند. ما بر معیارهای اساسی تمرکز می‌کنیم که (۱) برای بهترین اندازه‌گیری و ارزیابی موفقیت/تاثیر محصولات/ویژگی‌های مرتبط با ۲ تجربه ویکی KR - WE3.1 و WE1.2 - و (۲) منعکس‌کننده یا نقشه‌برداری به صنعت مورد نیاز هستند. معیارهای استاندارد مورد استفاده در تجزیه و تحلیل وب |
Mikhail Popov |
| SDS2.3 | Deploy a unique agent tracking mechanism to our CDN which enables the A/B testing of product features with anonymous readers. | Without such a tracking mechanism, it is not reasonable to implement A/B testing of product features with anonymous readers.
This is basically a milestone-based result to create a new technical capability that others can build measurable things on top of. The key priority use-case will be A/B testing of features with anonymous readers, but this work also enables other important future things, which may create follow-on hypotheses later in WE4.x (for request risk ratings and mitigating large-scale attacks) and for metrics/research about unique device counts as their resourcing and priorities allow. |
Brandon Black |
| نتیجهٔ کلید پیش‌نویس مخاطبان آینده (FA).
[ پیش‌نویس اهداف ] | |||
|---|---|---|---|
| نام کوتاه کلیدی نتیجه | متن کلیدی نتیجه | زمینهٔ کلیدی نتیجه | متولی |
| FA1.1 | در نتیجه بینش‌ها و توصیه‌های تجربی مخاطبان آینده، تا پایان سه‌ماهه سوم حداقل یک نتیجه هدف یا کلیدی متعلق به یک تیم غیرآینده در پیش‌نویس برنامه سالانه سال بعد وجود دارد. | از سال ۲۰۲۰، بنیاد ویکی‌مدیا روندهای خارجی را دنبال می‌کند که ممکن است بر توانایی ما برای خدمت به نسل‌های آینده از مصرف‌کنندگان دانش و مشارکت‌کنندگان دانش تأثیر بگذارد و برای نسل‌های آینده یک جنبش دانش آزاد و پررونق باقی بماند. مخاطبان آبنده، یک تیم کوچک تحقیق و توسعه:
|
Maryana Pinchuk |
| نتایج کلیدی پیش نویس پشتیبانی محصول و مهندسی (PES).
[ پیش‌نویس اهداف ] | |||
|---|---|---|---|
| نام کوتاه کلیدی نتیجه | متن کلیدی نتیجه | زمینهٔ کلیدی نتیجه | متولی |
| PES1.1 | فرهنگ مرور: در یک نظرسنجی سه‌ماهه، نمرات احساسات کارکنان P+T مربوط به تحویل، همسویی، جهت‌گیری و سلامت تیم را افزایش دهید. | فرهنگ مرور یک فرهنگ توسعه محصول است که بر اساس چرخه‌های کوتاه‌تر تکرار، یادگیری و انطباق است. این بدان معناست که سازمان ما ممکن است اهداف سالانه خود را تعیین کند، اما آنچه ما برای دستیابی به این اهداف انجام می‌دهیم، در طول سال با یادگیری تغییر می‌کند و تطبیق می‌یابد. دو جزء برای ایجاد فرهنگ مرور وجود دارد: فرایندها و رفتارها. این KR روی دومی تمرکز دارد. تغییرات رفتاری می‌تواند باعث رشد و تقویت فرهنگ مرور ما شود. این شامل تغییراتی در عادات و روال‌های فردی است که ما به سمت توسعه محصول تکراری تر حرکت می‌کنیم. این KR بر اساس تغییرات خود گزارش شده در رفتارهای فردی و اندازه‌گیری تغییرات ناشی از آن، در صورت وجود، در احساسات کارکنان خواهد بود. | Amy Tsay |
| PES1.2 | تا پایان سه‌ماهه دوم، فهرست آرزوهای جدید ایده‌ها و درخواست‌های جنبش را بهتر به فعالیت‌های بنیاد P+T مرتبط می‌کند: موارد از لیست خواسته‌های معوقه از طریق یک KR 2024-5 بررسی می‌شوند، بنیاد ۱۰ آرزوی کوچکتر را تکمیل کرده است، و بنیاد با آن شریک شده است. داوطلبان برای شناسایی بیش از ۳ زمینه فرصت برای سال مالی ۲۰۲۵–۲۶. | فهرست آرزوهای اجتماع بخش باریکی از جنبش را نشان می‌دهد. تقریباً ۱۰۰ نفر شرکت می‌کنند که بیشتر آنها مشارکت کننده یا مدیر هستند. مردم اغلب با نوشتن درخواست‌های ویژگی و گزارش‌های باگ از طریق فبریکاتور، لیست خواسته‌ها را دور می‌زنند، جایی که تشخیص درخواست‌های بنیاد ویکی‌مدیا یا جامعه دشوار است. برای شرکت کنندگان، فهرست آرزوها یک سرمایه‌گذاری زمانی پرهزینه با حداقل بازده است. آنها همچنان با فهرست علاقه‌مندان درگیر هستند زیرا احساس می‌کنند این تنها وسیله‌ای است که توجه را به اشکالات تأثیرگذار و بهبود ویژگی‌ها جلب می‌کند یا نیاز به فرصت‌های استراتژیک گسترده‌تر را نشان می‌دهد. آرزوها اغلب به عنوان راه حل نوشته می‌شوند، در مقابل مشکلات. راه حل‌ها ممکن است روی کاغذ معقول به نظر برسند، اما لزوماً پیچیدگی فنی یا پیامدهای استراتژی حرکت را در نظر نمی‌گیرند.
دامنه و وسعت آرزوها گاهی از دامنه و ظرفیت انجمن فناوری یا یک تیم فراتر می‌رود، که ناامیدی را تداوم می‌بخشد، که منجر به RFCها و فراخوان‌هایی برای از بین بردن لیست خواسته‌ها می‌شود. در حالی که اعضای جامعه ترجیح می‌دهند از فهرست خواسته‌ها برای ایده‌های پروژه استفاده کنند، تیم‌های بنیاد برای اولویت‌بندی به فهرست خواسته‌ها و سایر فرآیندهای دریافتی نگاه می‌کنند، تا حدی به این دلیل که آرزوها برای برنامه‌ریزی سالانه به موقع نیستند و به سختی در نقشه‌های راه / OKR گنجانده می‌شوند. فهرست آرزوهای آینده باید پلی بین جامعه و بنیاد باشد، جایی که جوامع به روشی ساختاریافته اطلاعات ارائه می‌کنند، به طوری که ما قادر به انجام اقدامات و در نتیجه خوشحال کردن داوطلبان هستیم. ما در حال ایجاد یک فرایند پذیرش جدید برای هر داوطلبی هستیم که وارد سیستم شده است تا ۳۶۵ روز در سال درخواست ارسال کند. آرزوها می‌توانند یک اشکال را گزارش کنند یا برجسته کنند، درخواست بهبود کنند یا در مورد یک ویژگی جدید ایده بگیرند. هر کسی می‌تواند در مورد یک آرزو برای تأثیرگذاری بر اولویت‌بندی نظر بدهد، کارگاه آموزشی انجام دهد یا از آن حمایت کند. بنیاد آرزوها را به عنوان «خیلی بزرگ» یا «خیلی کوچک» طبقه‌بندی نمی‌کند. آرزوهایی که به صورت موضوعی به یک منطقه مشکل بزرگتر ترسیم می‌شوند می‌توانند بر برنامه‌ریزی سالانه و نقشه راه تیم تأثیر بگذارند و جهت‌ها و فرصت‌های استراتژیک را ارائه دهند. آرزوها برای جنبش در داشبوردی قابل مشاهده خواهند بود که آرزوها را بر اساس پروژه، محصول/منطقه مشکل و نوع آرزو دسته‌بندی می‌کند. بنیاد به خواسته‌ها به موقع پاسخ می‌دهد و با جامعه برای دسته‌بندی و اولویت بندی خواسته‌ها شریک می‌شود. ما با ویکی‌مدین‌ها برای شناسایی و اولویت‌بندی سه حوزه بهبود، که در برنامه سالانه ۲۰۲۵–۲۰۲۶ بنیاد گنجانده شده‌اند، شریک می‌شویم، که باید نرخ پذیرش و تحقق آرزوهای تأثیرگذار را بهبود بخشد. ما آرزوهای مناسب برای جامعه توسعه دهندگان داوطلب و تیم‌های بنیاد را علامت گذاری می‌کنیم، که منجر به مشارکت بیشتر تیم و توسعه دهنده و برآورده شدن آرزوهای بیشتر، و رضایت جامعه می‌شود. پرداختن به خواسته‌های بیشتر، شادی، کارآمدی و حفظ مشارکت‌کنندگان را بهبود می‌بخشد، که باید ویرایش‌های باکیفیت‌تر، محتوای با کیفیت بالاتر و خوانندگان بیشتری ایجاد کند. |
Jack Wheeler |
| PES1.3 | دو آزمایش را از محصولات/ویژگی‌های اکتشافی موجود انجام دهید و به نتیجه برسانید که داده‌ها/بینش‌هایی را در مورد چگونگی رشد ویکی‌پدیا به‌عنوان مقصدی دانش برای مصرف‌کنندگان فعلی و مخاطبان داوطلب در Q1 و Q2 به ما ارائه می‌دهد. تا پایان سه‌ماهه سوم، آموخته‌ها و توصیه‌ها را برای پذیرش احتمالی برای کارهای آینده OKR در سطل تجربیات ویکی تکمیل و به اشتراک بگذارید. | این کار همتای هدف مخاطبان آینده است، اما در عوض بر کشف فرصت‌هایی برای افزایش و تعمیق تعامل مخاطبان فعلی ما (مصرف‌کنندگان و مشارکت‌کنندگان ویکی‌پدیا) از طریق آزمایش دقیق‌تر ایده‌های محصول روی پلتفرم تمرکز دارد.
این در PES1 زندگی می‌کند زیرا انرژی‌زا و چند برابر می‌کند - زمانی را که افراد و تیم‌ها «از قبل» به هک کردن/آزمایش پروژه‌های جانبی اختصاص داده‌اند را هدایت می‌کند تا ویژگی‌های امیدوارکننده‌تر را در کانون توجه قرار دهد. به‌جای اینکه این پروژه‌های جانبی از بین بروند (استفاده مناسب از منابع محدود ما نیست)، این KR مسیری را برای برخی از این ایده‌ها فراهم می‌کند تا به طور بالقوه از طریق آزمایش‌های اثبات‌شده، آنها را به یک مجموعه برنامه‌های کاربردی بزرگتر تبدیل کنند، بنابراین با استفاده کارآمدتر از زمان کارکنان و ایجاد انگیزه برای خلاقیت و خلاقیت آنها. بهره وری. طبا اجرای بیشتر این پروژه‌های کوچکتر و کوتاه‌تر، ما همچنین گسترش «شرط‌بندی» خود را برای یادگیری بیشتر و آزمایش‌های ایده‌هایی که ممکن است ویکی‌پدیا را مطابق با نیازها و انتظارات مخاطبان فعلی‌مان تغییر دهند، متنوع می‌کنیم. این کار ما را مؤثرتر و سریع‌تر می‌کند، زیرا به بنیاد کمک می‌کند تا در زمان کمتری با هدف درست هماهنگ شود. |
Rita Ho |
| PES1.4 | نحوه تنظیم، نظارت و تصمیم‌گیری در مورد SLOها را بیاموزید. حداقل یک چیز جدید را برای تعریف SLOها در هنگام انتشار آن انتخاب کنید. برای تعریف آن SLO با تیم (های) مربوطه (معمولاً: محصول، تیم‌های توسعه، SRE) همکاری کنید. دستورالعمل‌هایی را برای اینکه چه نسخه‌هایی باید SLO در آینده داشته باشند و نحوه تنظیم آنها منعکس و مستند کنید. | KR آینده:
فرایند و ابزارهای ابتدایی را برای تنظیم و نظارت بر SLOها برای نسخه‌های جدید تنظیم کنید. به صورت فصلی گزارش دهید و از آن برای تصمیم‌گیری در مورد اولویت بندی کار (و نه) برای رفع مشکل استفاده کنید. گزارش را با جامعه به اشتراک بگذارید چرا: نمی‌دانیم چه زمانی باید کار را اولویت بندی کنیم تا چیزی را اصلاح کنیم. و ما کدهای زیادی داریم. با ادامه رشد این ردپا، موقعیت‌های بیشتری وجود دارد که ممکن است لازم باشد بین پرداختن به مسائل یا تمرکز بر نوآوری و عدم اطمینان بیشتر در مورد اینکه چه زمانی باید تصمیم بگیریم. همچنین، برای کارکنان و جامعه مشخص نیست که سطح پشتیبانی/تعهد ما در مورد قابلیت اطمینان و عملکرد برای همه ویژگی‌ها و عملکردهای متفاوتی که با آنها تعامل دارند، چقدر است. اگر سطح مورد انتظار خدمات را تعریف کنیم، می‌توانیم بدانیم چه زمانی باید منابع را به آن اختصاص دهیم یا خیر. |
Mark Bergsma |
| PES1.5 | Define ownership and commitments (including SLOs) on services and learn how to track, report and make decisions as a standard and scalable practice by trialing it in 3 teams across senior leaders in the department. | After collaboratively defining an SLO for the EditCheck feature as part of PES1.5, we will now trial and learn from using the SLO in practice to help prioritisation of reliability work. We will also document roles and responsibilities for ownership of code/services, allowing us to make clear shared commitments on the level of ongoing support. We will try to use these as practices in 3 teams across the department. | Mark Bergsma |
Hypotheses
The hypotheses below are the specific things we are doing each quarter to address the associated key results above.
Each hypothesis is an experiment or stage in an experiment we believe will help achieve the key result. Teams make a hypothesis, test it, then iterate on their findings or develop an entirely different new hypothesis. You can think of the hypotheses as bets of the teams’ time–teams make a small bet of a few weeks or a big bet of several months, but the risk-adjusted reward should be commensurate with the time the team puts in. Our hypotheses are meant to be agile and adapt quickly. We may retire, adjust, or start a hypothesis at any point in the quarter.
To see the most up-to-date status of a hypothesis and/or to discuss a hypothesis with the team please click the link to its project page below.
Q1
The first quarter (Q1) of the WMF annual plan covers July-September.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| WE1.1.1 | If we expand the Event List to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | |
| WE1.1.2 | If we identify at least 15 WikiProjects in 3 separate Wikipedias to be featured in the Community List, then we will be able to advise Campaigns Product in the key characteristics needed to build an MVP of the Community List that includes WikiProjects. | |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.2.1 | If we build a first version of the Edit Check API, and use it to introduce a new Check, we can evaluate the speed and ease with other teams and volunteers could use the API to create new Checks and Suggested Edits. | |
| WE1.2.2 | If we build a library of UI components and visual artefacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.3 | If we conduct user tests on two or more design prototypes introducing structured tasks to newcomers within/proximate to the Visual Editor, then we can quickly learn which designs will work best for new editors, while also enabling engineers to assess technical feasibility and estimate effort for each approach. | mw:Growth/Constructive activation experimentation |
| WE1.2.4 | If we train an LLM on detecting "peacock" behavior, then we can learn if it can detect this policy violation with at least >70% precision and >50% recall and ultimately, decide if said LLM is effective enough to power a new Edit Check and/or Suggested Edit. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | mw:Wikimedia Apps/iOS Suggested edits project/Alt Text Experiment |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Automoderator |
| WE1.3.2 | If we are able interpret subsets of wishes as moderator-related focus areas and share these focus areas for community input in Q1-Q2, then we will have a high degree of confidence that our selected focus area will improve moderator satisfaction, when it is released in Q3. | |
| WE2.1.1 | If we build a country-level inference model for Wikipedia articles, we will be able to filter lists of articles to those about a specific region with >70% precision and >50% recall. | m:Research:Language-Agnostic Topic Classification/Countries |
| WE2.1.2 | If we build a proof-of-concept providing translation suggestions that are based on user-selected topic areas, we will be set up to successfully test whether translators will find more opportunities to translate in their areas of interest and contribute more compared to the generic suggestions currently available. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. | mw: Translation suggestions: Topic-based & Community-defined lists |
| WE2.2.1 | If we expand Wikimedia's State of Languages data by securing data sharing agreements with UNESCO and Ethnologue, at least one partner will decide to represent Wikimedia’s language inclusion progress in their own data products and communications. On top of being useful to our partner institutions, our expanded dataset will provide important contextual information for decision-making and provide communities with information needed to identify areas for intervention. | |
| WE2.2.2 | If we map the language documentation activities that Wikimedians have conducted in the last 2 years, we will develop a data-informed baseline for community experiences in onboarding new languages. | |
| WE2.2.3 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | mw:Future of Language Incubation |
| WE2.3.1 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include defining designs for further UX improvements to the release rights step in the Upload Wizard on Commons and rolling out an MVP of logo detection in the upload flow. | |
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2 (see hypothesis 1). | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.1 | Designing and qualitatively evaluating three proofs of concept focused on building curated, personalized, and community-driven browsing and learning experiences will allow us to estimate the potential for increased reader retention (experiment 1: providing recommended content in search and article contexts, experiment 2: summarizing and simplifying article content, experiment 3: making multitasking easier on wikis. | |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | |
| WE3.1.4 | If we analyze the projected performance impact of hypothesis WE3.1.1 and WE3.1.2 on the Search API, we can scope and address performance and scalability issues before they negatively affect our users. | |
| WE3.1.5 | If we enhance the search field in the Android app to recommend personalized content based on a user's interest and display better results, we will learn if this improves user engagement by observing whether it increases the impression and click-through rate (CTR) of search results by 5% in the experimental group compared to the control group over a 30-day A/B test. This improvement could potentially lead to a 1% increase in the retention of logged out users. | |
| WE3.2.1 | If we create a clickable design prototype that demonstrates the concept of a badge representing donors championing article(s) of interest, we can learn if there would be community acceptance for a production version of this method for fundraising in the Apps. | Fundraising Experiment in the iOS App |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% Year over Year | phab:T368765 |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | |
| WE3.3.1 | If we select a data visualization library and get an initial version of a new server-rendered graph service available by the end of July, we can learn from volunteers at Wikimania whether we’re working towards a solution that they would use to replace legacy graphs. | |
| WE4.1.1 | If we implement a way in which users can report potential instances of harassment and harmful content present in discussions through an incident reporting system, we will be able to gather data around the number and type of incidents being reported and therefore have a better understanding of the landscape and the actions we need to take. | |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | phab:T368388 |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | WE4.2.9 Talk page |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts | WE4.2.2 Talk page |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | phab:T368389 |
| WE4.3.2 | If we limit the load that known IP addresses of persistent attackers can place on our infrastructure, we'll reduce the number of impactful cachebusting attacks by 20%, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.4 | If we make usability improvements and also perform some training exercises on our 'requestctl' tool, then SREs will report higher confidence in using the tool. | phab:T369480 |
| WE4.4.1 | If we run at least 2 deployment cycles of Temp Accounts we will be able to verify this works successfully. | |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.2 | If we disable unused Graphite metrics, target migrating metrics using the db-prefixed data factory and increase our outreach efforts to other teams and the community in Q1, then we would be on track to achieve our goal of making Graphite read-only by Q3 FY24/25, by observing an increase of 30% in migration progress. | |
| WE5.1.3 | If we implement a canonical url structure with versioning for our REST API then we can enable service migration and testing for Parsoid endpoints and similar services by Q1. | phab:T344944 |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the coverage of Sonar Cloud to include key MediaWiki Core repos, we will be able to improve the maintainability of the MediaWiki codebase. This hypothesis will be measured by spliting the selected repos into test and control groups. These groups will then be compared over the course of a quarter to measure impact of commit level feedback to developers. | |
| WE5.2.1 | If we make a classification of the types of hooks and extension registry properties used to influence the behavior of MediaWiki core, we will be able to focus further research and interventions on the most impactful. | [۱] |
| WE5.2.2 | If we explore a new architecture for notifications in MW core and Echo, we will discover new ways to provide modularity and new ways for extensions to interact with core. | [۲] |
| WE5.3.1 | If we instrument parser and cache code to collect template structure and fine-grained timing data, we can quantify the expected performance improvement which could be realized by future evolution of the wikitext parsing platform. | T371713 |
| WE5.3.2 | On template edits, if we can implement an algorithm in Parsoid to reuse HTML of a page that depends on the edited template without processing the page from scratch and demonstrate 1.5x or higher processing speedup, we will have a potential incremental parsing solution for efficient page updates on template edits. | T363421 |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.1 | If we design and complete the initial implementation of an authorization framework, we’ll establish a system to effectively manage the approval of all LDAP access requests. | |
| WE6.1.2 | If we research available documentation metrics, we can establish metrics that measure the health of Wikimedia technical documentation, using MediaWiki Core documentation as a test case. | mw:Wikimedia Technical Documentation Team/Doc metrics |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | Wikimedia Release Engineering Team/SpiderPig |
| WE6.2.4 | If we migrate votewiki, wikitech and commons to MediaWiki on Kubernetes we reap the benefits of consistency and no longer need to maintain 2 different infrastructure platforms in parallel, allowing to reduce the amount of custom written tooling, making deployments easier and less toilous for deployers. This will be measured by a decrease in total deployment times and a reduction in deployment blockers. | وظیفه T292707 |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | SingleVersion MW: Routing options |
| WE6.3.1 | By consulting toolforge maintainers about the least sustainable aspects of the platform, we will be able to gather a list of potential categories to measure. | |
| WE6.3.2 | By creating a "standard" tool to measure the number of steps for a deployment we will be able to assess the maximal improvement in the deployment process. | |
| WE6.3.3 | If we conduct usability tests, user interviews, and competitive analysis to explore the existing workflows and use cases of Toolforge, we can identify key areas for improvement. This research will enable us to prioritize enhancements that have the most significant impact on user satisfaction and efficiency, laying the groundwork for a future design of the user interface. | |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | phab:T368791 |
| SDS1.2.1 | If we gather use cases from product and feature engineering managers around the use of AI in Wikimedia services for readers and contributors, we can determine if we should test and evaluate existing AI models for integration into product features, and if yes, generate a list of candidate models to test. | phab:T369281 |
| SDS1.3.1 | If we define the process to transfer all data sets and pipeline configurations from the Data Platform to DataHub we can build tooling to get lineage documentation automatically. | |
| SDS 1.3.2 | If we implement a well documented and understood process to produce an intermediary table representing MediaWiki Wikitext History, populated using the event platform, and monitor the reliability and quality of the data we will learn what additional parts of the process are needed to make this table production ready and widely supported by the Data Platform Engineering team. | |
| SDS2.1.2 | If we investigate the data products current sdlc, we will be able to determine inflection points where QTE knowledge can be applied in order to have a positive impact on Product Delivery. | |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | phab:T329506 |
| SDS2.2.1 | If we define a metric for logged-out mobile app reader retention, which is applicable for analyzing experiments (A/B test), we can provide guidance for planning instrumentation to measure retention rate of logged out readers in the mobile apps and enable the engineering team to develop an experiment strategy targeting logged out readers. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.2.3 | If we define a standard way of measuring and analyzing clickthrough rate (CTR) in our products/features, it will help us design experiments that target CTR for improvement, standardize click-tracking instrumentation, and enable us to make CTR available as a target metric to users of the experimentation platform. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | m:Future Audiences/Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q1 text | Details & Discussion |
| PES1.1.1 | If the P&T leadership team syncs regularly on how they’re guiding their teams towards a more iterative software development culture, and we collect baseline measurements of current development practices and staff sentiment on how we work together to ship products, we will discover opportunity areas for change management. The themes that emerge will enable us to build targeted guidance or programs for our teams in coming quarters. | |
| PES1.2.2 | If the Moderator Tools team researches the Community Wishlist and develops 2+ focus areas in Q1, then we can solicit feedback from the Community and identify a problem that the Community and WMF are excited about tackling. | |
| PES1.2.3 | If we bundle 3-5 wishes that relate to selecting and inserting templates, and ship an improved feature in Q1, then CommTech can take the learnings to develop a Case Study for the foundation to incorporate more "focus areas" in the 2025-26 annual plan. | |
| PES1.3.1 | If we provide insights to audiences about their community and their use of Wikipedia over a year, it will stimulate greater connection with Wikipedia – encouraging greater engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. Success will be measured by completing an experimental project that provides at least one recommendation about “Wikipedia insights” as an opportunity to increase onwiki engagement. | mw: New Engagement Experiments#PES1.3.1_Wikipedia_user_insights |
| PES1.3.2 | If we create a Wikipedia-based game for daily use that highlights the connections across vast areas of knowledge, it will encourage consumers to visit Wikipedia regularly and facilitate active learning, leading to longer increased interaction with content on Wikipedia. Success will be measured by completing an experimental project that provides at least one recommendation about gamification of learning as an opportunity to increase onwiki engagement. | mw: New Engagement Experiments#PES_1.3.2:_Wikipedia_games |
| PES1.3.3 | If we develop a new process/track at a Wikimedia hack event to incubate future experiments, it will increase the impact and value of such events in becoming a pipeline for future annual plan projects, whilst fostering greater connection between volunteers and engineering/design staff to become more involved with strategic initiatives. Success will be measured by at least one PES1.3 project being initiated and/or advanced to an OKR from a foundation-supported event. | mw: New Engagement Experiments#PES_1.3.3:_Incubator_space |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
Q2
The second quarter (Q2) of the WMF annual plan covers October-December.
| Wiki Experiences (WE) Hypotheses
[ WE Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| WE1.1.1 | If we expand the Event list to become a Community List that includes WikiProjects, then we will be able to gather some early learnings in how to engage with WikiProjects for product development. | Campaigns/Foundation Product Team/Event list |
| WE1.1.2 | If we launch at least 1 consultation focused on on-wiki collaborations, and if we collect feedback from at least 20 people involved in such collaborations, then we will be able to advise Campaigns Product on the key characteristics needed to develop a new or improved way of connecting. | Campaigns/WikiProjects |
| WE1.1.3 | If we consult 20 event organizers and 20 WikiProject organizers on the best use of topics available via LiftWing, then we can prioritize revisions to the topic model that will improve topical connections between events and WikiProjects. | |
| WE1.1.4 | If we integrate CampaignEvents into Community Configuration in Q2, then we will set the stage for at least 5 more wikis opting to enable extension features in Q3, thereby increasing tool usage. | |
| WE1.2.2 | If we build a library of UI components and visual artifacts, Edit Check’s user experience can extend to accommodate Structured Tasks patterns. | |
| WE1.2.5 | If we conduct an A/B/C test with the alt-text suggested edits prototype in the production version of the iOS app we can learn if adding alt-text to images is a task newcomers are successful with and ultimately, decide if it's impactful enough to implement as a suggested edit on the Web and/or in the Apps. | |
| WE1.2.6 | If we introduce new account holders to the “Add a Link” Structured Task in Wikipedia articles, we expect to increase the percentage of new account holders who constructively activate on mobile by 10% compared to the baseline. | |
| WE1.3.1 | If we enable additional customisation of Automoderator's behaviour and make changes based on pilot project feedback in Q1, more moderators will be satisfied with its feature set and reliability, and will opt to use it on their Wikimedia project, thereby increasing adoption of the product. | mw:Moderator_Tools/Automoderator |
| WE1.3.3 | If we improve the user experience and features of the Nuke extension during Q2, we will increase administrator satisfaction of the product by 5pp by the end of the quarter. | mw:Extension:Nuke/2024_Moderator_Tools_project |
| WE2.1.3 | If we offer list-making as a service, we’ll enable at least 5 communities to make more targeted contributions in their topic areas as measured by (1) change in standard quality coverage of relevant topics on the relevant wiki and (2) a brief survey of organizer satisfaction with topic area coverage on-wiki. | |
| WE2.1.4 | If we developed a proof of concept that adds translation tasks sourced from WikiProjects and other list-building initiatives, and present them as suggestions within the CX mobile workflow, then more editors would discover and translate articles focused on topical gaps. By introducing an option that allows editors to select translation suggestions based on topical lists, we would test whether this approach increases the content coverage in our projects. |
|
| WE2.1.5 | If we expose topic-based translation suggestions more broadly and analyze its initial impact, we will learn which aspects of the translation funnel to act on in order to obtain more quality translations. | |
| WE2.2.4 | If we provide production wiki access to 5 new languages, with or without Incubator, we will learn whether access to a full-fledged wiki with modern features such as those available on English Wikipedia (including ContentTranslation and Wikidata support, advanced editing and search results) aids in faster editing. Ultimately, this will inform us if this approach can be a viable direction for language onboarding for new or existing languages, justifying further investigation. | |
| WE2.2.5 | If we move addwiki.php to core and customize it to Wikimedia, we will improve code quality in our wiki creation system making it testable and robust, and we will make it easy for creators of new wikis and thereby make significant steps towards simplifying wiki creation process. | phab:T352113 |
| WE2.3.2 | If we make two further improvements to media upload flow on Commons and share them with community, the feedback will be positive and it will help uploaders make less bad uploads (with the focus on copyright) as measured by the ratio of deletion requests within 30 days of upload. This will include release of further UX improvements to the release rights step in the Upload Wizard on Commons and automated detection of external sources. | |
| WE2.3.3 | If the BHL-Wikimedia Working Group creates Commons categories and descriptive guidelines for the South American and/or African species depicted in publications, they will make 3,000 images more accessible to biodiversity communities. (BHL = Biodiversity Heritage Library) |
|
| WE2.4.1 | If we build a prototype of Wikifunctions calls embedded within MediaWiki content and test it locally for stability, we will be ready to use MediaWiki’s async content processing pipeline and test its performance feasibility in Q2. | phab:T261472 |
| WE2.4.2 | If we create a design prototype of an initial Wikifunctions use case in a Wikipedia wiki, we will be ready to build and test our integration when performance feasibility is validated in Q2, as stated in Hypothesis 1. | phab:T363391 |
| WE2.4.3 | If we make it possible for Wikifunctions users to access Wikidata lexicographical data, they will begin to create natural language functions that generate sentence phrases, including those that can handle irregular forms. If we see an average monthly creation rate of 31 for these functions, after the feature becomes available, we will know that our experiment is successful. | phab:T282926 |
| WE3.1.3 | If we develop models for remixing content such as a content simplification or summarization that can be hosted and served via our infrastructure (e.g. LiftWing), we will establish the technical direction for work focused on increasing reader retention through new content discovery features. | Research |
| WE3.1.6 | If we introduce a personalized rabbit hole feature in the Android app and recommend condensed versions of articles based on the types of topics and sections a user is interested in, we will learn if the feature is sticky enough to result in multi-day usage by 10% of users exposed to the experiment over a 30-day period, and a higher pageview rate than users not exposed to the feature. | |
| WE3.1.7 | If we run a qualitative experiment focused on presenting article summaries to web readers, we will determine whether or not article summaries have the potential to increase reader retention, as proxied by clickthrough rate and usage patterns | |
| WE3.1.8 | If we build one feature which provides additional article-level recommendations, we will see an increase in clickthrough rate of 10% over existing recommendation options and a significant increase in external referrals for users who actively interact with the new feature. | |
| WE3.2.2 | Increasing the prominence of entry points to donations on the logged-out experiences of the Vector web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | mw:Readers/2024_Reader_and_Donor_Experiences |
| WE3.2.3 | If we make the “Donate” button in the iOS App more prominent by making it one click or less away from the main navigation screen, we will learn if discoverability was a barrier to non banner donations. | Navigation Refresh |
| WE3.2.4 | If we update the contributions page for logged-in users in the app to include an active badge for someone that is an app donor and display an inactive state with a prompt to donate for someone that decided not to donate in app, we will learn if this recognition is of value to current donors and encourages behavior of donating for prospective donors, informing if it is worth expanding on the concept of donor badges or abandoning it. | Private Donor Recognition Experiment |
| WE3.2.5 | If we create a Wikipedia in Review experiment in the Wikipedia app, to allow users to see and share personalized data about their reading, editing, and donation habits, we will see 2% of viewers donate on iOS as a result of this feature, 5% click share and, 65% of users rating the feature neutral or satisfactory. | Personalized Wikipedia Year in Review |
| WE3.2.7 | Increasing the prominence of entry points to donations on the logged-out experiences of the Minerva web mobile and desktop experience will increase the clickthrough rate of the donate link by 30% YoY. | |
| WE3.3.2 | If we develop the Charts MVP and get it working end-to-end in production test wikis, at least two Wikipedias + Commons agree to pilot it before the code freeze in December. | |
| WE3.4.1 | If we were to explore the feasibility by doing an experiment of setting up smaller PoPs in cloud providers like Amazon, we can expand our data center map and reach more users around the world, at reduced cost and increased turn-around time. | |
| WE4.1.2 | If we deploy at least one iteration of the Incident Reporting System MVP on pilot wikis, we will be able to gather valuable data around the frequency and type of incidents being reported. | https://meta.wikimedia.org/wiki/Incident_Reporting_System# |
| WE4.2.1 | If we explore and define Wikimedia-specific methods for a unique device identification model, we will be able to define the collection and storage mechanisms that we can later implement in our anti-abuse workflows to enable more targeted blocking of bad actors. | |
| WE4.2.9 | If we provide contextual information about reputation associated with an IP that is about to be blocked, we will see fewer collateral damage IP and IP range blocks, because administrators will have more insight into potential collateral damage effects of a block. We can measure this by instrumenting Special:Block and observing how behavior changes when additional information is present, vs when it is not. | |
| WE4.2.2 | If we define an algorithm for calculating a user account reputation score for use in anti-abuse workflows, we will prepare the groundwork for engineering efforts that use this score as an additional signal for administrators targeting bad actors on our platform. We will know the hypothesis is successful if the algorithm for calculating a score maps with X% precision to categories of existing accounts, e.g. a "low" score should apply to X% of permanently blocked accounts. | |
| WE4.2.3 | If we build an evaluation framework using publicly available technologies similar to the ones used in previous attacks we will learn more about the efficacy of our current CAPTCHA at blocking attacks and could recommend a CAPTCHA replacement that brings a measurable improvement in terms of the attack rate achievable for a given time and financial cost. | |
| WE4.3.1 | If we apply some machine learning and data analysis tools to webrequest logs during known attacks, we'll be able to identify abusive IP addresses with at least >80% precision sending largely malicious traffic that we can then ratelimit at the edge, improving reliability for our users. | |
| WE4.3.3 | If we deploy a proof of concept of the 'Liberica' load balancer, we will measure a 33% improvement in our capacity to handle TCP SYN floods. | |
| WE4.3.5 | By creating a system that spawns and controls thousands of virtual workers in a cloud environment, we will be able to simulate Distributed Denial of Service (DDoS) attacks and effectively measure the system's ability to withstand, mitigate, and respond to such attacks. | |
| WE4.3.6 | If we integrate the output of the models we built in WE 4.3.1 with the dynamic thresholds of per-ip concurrency limits we've built for our TLS terminators in WE 4.3.2, we should be able to increase our ability to neutralize automatically attacks with 20% more volume, as measured with the simulation framework we're building. | |
| WE4.3.7 | If we roll out a user-friendly web application that enables assisted editing and creation of requestctl rules, SREs will be able to mitigate cachebusting attacks in 50% less time than our established baseline. | |
| WE4.4.2 | If we deploy Temporary Accounts to a set of small-to-medium sized projects, we will be able to the functionality works as intended and will be able to gather data to inform necessary future work. | mw:/wiki/Trust_and_Safety_Product/Temporary_Accounts |
| WE5.1.1 | If we successfully roll out Parsoid Read Views to all Wikivoyages by Q1, this will boost our confidence in extending Parsoid Read Views to all Wikipedias. We will measure the success of this rollout through detailed evaluations using the Confidence Framework reports, with a particular focus on Visual Diff reports and the metrics related to performance and usability. Additionally, we will assess the reduction in the list of potential blockers, ensuring that critical issues are addressed prior to wider deployment. | |
| WE5.1.3 | If we reroute the endpoints currently exposed under rest_v1/page/html and rest_v1/page/title paths to comparable MW content endpoints, then we can unblock RESTbase sunsetting without disrupting clients in Q1. | |
| WE5.1.4 | If we complete the remaining work to mitigate the impact of browsers' anti-tracking measures on CentralAuth autologin and move to a more resilient authentication infrastructure (SUL3), we will be ready to roll out to production wikis in Q2. | |
| WE5.1.5 | If we increase the number of relevant SonarCloud rules enabled for key MediaWiki Core repositories and refine the quality of feedback provided to developers, we will optimize the developer experience and enable them to improve the maintainability of the MediaWiki codebase in the future. This will be measured by tracking developer satisfaction levels and whether test group developers feel the tool is becoming more useful and effective in their workflow. Feedback will be gathered through surveys and direct input from developers to evaluate the perceived impact on their confidence in the tool and the overall development experience. | |
| WE5.1.7 | If we represent all content module endpoint responses (10 in total) in our MediaWiki REST API OpenAPI spec definitions, we will be able to implement programmatic validation to guarantee that our generated documentation matches the actual responses returned in code. | |
| WE5.1.8 | If we introduce support for endpoint description translation (ie: does not include actual object definitions or payloads) into our generated MediaWiki REST API OpenAPI specs, we can lay the foundation to support Wikimedia’s expected internationalization standards. | |
| WE5.2.3 | If we conduct an experiment to reimplement at least [1-3] existing Core and Extension features using a new Domain Event and Listener platform component pattern as an alternative to traditional hooks, we will be able to confirm our assumption of this intervention enabling simpler implementation with more consistent feature behavior. | |
| WE5.3.3 | If we instrument both parsers to collect availability of prior parses and timing of template expansions, and to classify updates and dependencies, we can prioritize work on selective updates (Hypothesis 5.3.2) informed by the quantification of the expected performance benefits. | |
| WE5.3.4 | If we can increase the capability of our prototype selective update implementation in Parsoid using the learnings from the 5.3.1 hypothesis, we can leverage more opportunities to increase the performance benefit from selective update. | |
| WE5.4.1 | If the MediaWiki engineering group is successful with release process accountability and enhances its communication process by the end of Q2 in alignment with the product strategy, we will eliminate the current process that relies on unplanned or volunteer work and improve community satisfaction with the release process. Measured by community feedback on the 1.43 LTS release coupled with a significant reduction in unplanned staff and volunteer hours needed for release processes. | |
| WE5.4.2 | If we research and build a process to more regularly upgrade PHP in conjunction with our MediaWiki release process we will increase speed and security while reducing the complexity and runtime of our CI systems, by observing the success of PHP 8.1 upgrade before 1.43 release. | |
| WE6.1.3 | If we collect insights on how different teams are making technical decisions we are able to gather good practices and insights that can enable and scale similar practices across the organization. | |
| WE6.1.4 | If we research solutions for indexing the code of all projects hosted in WMF’s code repositories, we will be able to pick a solution that allows our users to quickly discover where the code is located whenever dealing with incident response or troubleshooting. | |
| WE6.1.5 | If we test a subset of draft metrics on an experimental group of technical documentation collections, we will be able to make an informed decision about which metrics to implement for MediaWiki documentation. | Wikimedia_Technical_Documentation_Team/Doc_metrics |
| WE6.2.1 | If we publish a versioned build of MediaWiki, extensions, skins, and Wikimedia configuration at least once per day we will uncover new constraints and establish a baseline of wallclock time needed to perform a build. | mw:Wikimedia Release Engineering Team/Group -1 |
| WE6.2.2 | If we replace the backend infrastructure of our existing shared MediaWiki development and testing environments (from apache virtual servers to kubernetes), it will enable us to extend its uses by enabling MediaWiki services in addition to the existing ability to develop MediaWiki core, extensions, and skins in an isolated environment. We will develop one environment that includes MediaWiki, one or more Extensions, and one or more Services. | wikitech:Catalyst |
| WE6.2.3 | If we create a new deployment UI that provides more information to the deployer and reduce the amount of privilege needed to do deployment, it will make deployment easier and open deployments to more users as measured by the number of unique deployers and number of patches backported as a percentage of our overall deployments. | mw:SpiderPig |
| WE6.2.5 | If we move MultiVersion routing out of MediaWiki, we 'll be able to ship single version MediaWiki containers, largely cutting down the size of containers allowing for faster deployments, as measured by the deployment tool. | https://docs.google.com/document/d/1_AChNfiRFL3VdNzf6QFSCL9pM2gZbgLoMyAys9KKmKc/edit |
| WE6.2.6 | If we gather feedback from QTE, SRE, and individuals with domain specific knowledge and use their feedback to write a design document for deploying and using the wmf/next OCI container, then we will reduce friction when we start deploying that container. | T379683 |
| WE6.3.4 | If we enable the automatic deployment of a minimal tool, we will be able to evaluate the end to end flow and set the groundwork to adding support for more complex tools and deployment flows. | phab:T375199 |
| WE6.3.5 | By assessing the relative importance of each sustainability category and its associated metrics, we can create a normalized scoring system. This system, when implemented and recorded, will provide a baseline for measuring and comparing Toolforge’s sustainability progress over time. | phab:T376896 |
| WE6.3.6 | If we conduct discovery, such as target user interviews and competitive analysis, to identify existing Toolforge pain points and improvement opportunities, we will be able to recommend a prioritized list of features for the future Toolforge UI. | Phab:T375914 |
| Signals & Data Services (SDS) Hypotheses
[ SDS Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| SDS 1.1.1 | If we partner with an initiative owner and evaluate the impact of their work on Core Foundation metrics, we can identify and socialize a repeatable mechanism by which teams at the Foundation can reliably impact Core Foundation metrics. | |
| SDS1.2.1.B | If we test the accuracy and infrastructure constraints of 4 existing AI language models for 2 or more high-priority product use-cases, we will be able to write a report recommending at least one AI model that we can use for further tuning towards strategic product investments. | Phab:T377159 |
| SDS1.2.2 | If we study the recruitment, retention, and attrition patterns among long-tenure community members in official moderation and administration roles, and understand the factors affecting these phenomena (the ‘why’ behind the trends), we will better understand the extent, nature, and variability of the phenomenon across projects. This will in turn enable us to identify opportunities for better interventions and support aimed at producing a robust multi-generational framework for editors. | Learn more. |
| SDS1.2.3 | If we combine existing knowledge about moderators with quantitative methods for detecting moderation activity, we can systematically define and identify Wikipedia moderators. | T376684 |
| SDS1.3.1.B | If we integrate the Spark / DataHub connector for all production Spark jobs, we will get column-level lineage for all Spark-based data platform jobs in DataHub. | |
| SDS1.3.2.B | If we implement a frequently run Spark-based MariaDB MW history data querying job, reconciliate missing events and enrich them, we will provide a daily updated MW history wikitext content data lake table. | |
| SDS2.1.1 | If we create an integration test environment for the proposed 3rd party experimentation solution, we can collaborate practically with Data SRE, SRE, QTE, and Product Analytics to evaluate the solution’s viability within WMF infrastructure in order to make a confident build/install/buy recommendation. | mw:Data_Platform_Engineering/Data_Products/work_focus |
| SDS2.1.3 | If the Growth team learns about the Metrics Platform by instrumenting a Homepage Module on the Metrics Platform, then we will be prepared to outline a measurement plan in Q1 and complete an A/B test on the new Metrics platform by the end of Q2. | |
| SDS2.1.4 | If we conduct usability testing on our prototype among pilot users of our experimentation process, we can identify and prioritize the primary pain points faced by product managers and other stakeholders in setting up and analyzing experiments independently. This understanding will lead to the refinement of our tools, enhancing their efficiency and impact. | |
| SDS2.1.5 | If we design a documentation system that guides the experience of users building instrumentation using the Metrics Platform, we will enable those users to independently create instrumentation without direct support from Data Products teams, except in edge cases. | وظیفه T329506 |
| SDS2.1.7 | If we provide a function for user enrollment and a mechanism to capture and store CTR events to a monotable in a pre-declared event stream we can ship MPIC Alpha in order to launch an basic split A/B test on logged in users. | |
| SDS2.2.2 | If we define a standard approach for measuring and analyzing conversion rates, it will help us establish a collection of well-defined metrics to be used for experimentation and baselines, and start enabling comparisons between experiments/projects to increase learning from these. | |
| SDS2.3.1 | If we conduct a legal review of proposed unique cookies for logged out users, we can determine whether there are any privacy policy or other legal issues which inform the community consultation and/or affect the technical implementation itself. | |
| Future Audiences (FA) Hypotheses
[ FA Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| FA1.1.1 | If we make off-site contribution very low effort with an AI-powered “Add a Fact” experiment, we can learn whether off-platform users could help grow/sustain the knowledge store in a possible future where Wikipedia content is mainly consumed off-platform. | Experiment:Add a Fact |
| Product and Engineering Support (PES) Hypotheses
[ PES Key Results ] | ||
|---|---|---|
| Hypothesis shortname | Q2 text | Details & Discussion |
| PES1.2.4 | If we research the Task Prioritization focus area in the Community Wishlist in early Q2, we will be able to identify and prioritize work that will improve moderator satisfaction, which we can begin implementing in Q3. | |
| PES1.2.5 | If we are able to publish and receive community feedback on 6+ focus areas in Q2, then we will have confidence in presenting at least 3+ focus areas for incorporation in the 2025-26 annual plan. | |
| PES1.2.6 | By introducing favouriting templates, we will improve the number of templates added via the template dialog by 10%. | |
| PES1.3.4 | If we create an experience that provides insights to Wikipedia Audiences about their community over the year, it will stimulate greater connection with Wikipedia – encouraging engagement in the form of social sharing, time spent interacting on Wikipedia, or donation. | |
| PES1.4.1 | If we draft an SLO with the Editing team releasing Edit Check functionality, we will begin to learn and understand how to define and track user-facing SLOs together, and iterate on the process in the future. | |
| PES1.4.2 | If we define and publish SLAs for putting OOUI into “maintenance mode”, growth of new code using OOUI across Wikimedia projects will stay within X% in Q1. | |
| PES1.4.3 | If we map ownership using the proposed service catalog for known owned services in Q1, we will be able to identify significant gaps in service catalog as it helps in solving the SLO culture by the end of the year. | |
| PES1.5.1 | If we finalize and publish the Edit Check SLO draft, practice incorporating it in regular workflows and decisions, and draft a Citoid SLO, we’ll continue learning how to define and track user-facing and cross-team SLOs together. | |
| PES1.5.2 | If we clarify and define in writing a document with set of roles and responsibilities of stakeholders throughout the service lifecycle, this will enable teams to make informed commitments in the Service Catalog, including SLOs | |
توضیح سطل‌ها
تجربیات ویکی
هدف این سطل ارائه کارآمد، بهبود و نوآوری در تجربیات ویکی است که امکان توزیع دانش رایگان در سراسر جهان را فراهم می‌کند. این سطل با توصیه‌های استراتژی حرکت #۲ (بهبود تجربه کاربر) و #۳ (ارائه ایمنی و گنجاندن) مطابقت دارد. مخاطبان ما شامل همه همکاران در وب سایت‌های ما، و همچنین خوانندگان و سایر مصرف‌کنندگان دانش رایگان هستند. ما از ۱۰ وب سایت برتر جهانی و بسیاری دیگر از منابع مهم فرهنگی رایگان پشتیبانی می‌کنیم. این سیستم‌ها دارای الزامات عملکردی و آپتایمی همتراز با بزرگترین شرکت‌های فناوری در جهان هستند. ما برای ویکی‌ها، ترجمه، APIهای توسعه‌دهنده (و بیشتر!) و برنامه‌های کاربردی و زیرساخت‌های پشتیبانی که همگی پلتفرمی قوی برای همکاری داوطلبان برای تولید دانش رایگان در سرتاسر جهان ایجاد می‌کنند، رابط کاربری ارائه می‌کنیم. اهداف ما برای این سطل باید ما را قادر سازد که فناوری و قابلیت‌های اصلی خود را بهبود بخشیم، اطمینان حاصل کنیم که به‌طور مستمر تجربه ویرایشگران و ناظران داوطلب پروژه‌های خود را بهبود می‌دهیم، تجربه همه مشارکت‌کنندگان فنی را که برای بهبود یا ارتقای تجربیات ویکی کار می‌کنند، بهبود می‌بخشیم، و اطمینان حاصل کنیم که تجربه عالی برای خوانندگان و مصرف‌کنندگان دانش رایگان در سراسر جهان. ما این کار را از طریق کار محصول و فناوری و همچنین از طریق تحقیق و بازاریابی انجام خواهیم داد. ما انتظار داریم حداکثر پنج هدف برای این سطل داشته باشیم.
دانش توسط افراد ساخته می‌شود! و در نتیجه، برنامهٔ سالانهٔ ما بر روی محتوا و همچنین افرادی که به محتوا کمک می‌کنند و کسانی که به آن دسترسی دارند و می‌خوانند تمرکز خواهد کرد.
هدف ما تولید یک برنامه عملیاتی مبتنی بر استراتژی موجود، عمدتاً فرضیه‌های ما در مورد مشارکت‌کننده، مصرف‌کننده و «چرخ پرواز» است. تغییر اولیه ای که من درخواست می‌کنم، تأکید بر بخش محتوای چرخ لنگر، و کاوش در مورد آنچه مدیران و کارمندان ما ممکن است در حال حاضر از ما نیاز داشته باشند، با هدف شناسایی معیارهای سلامت جامعه در آینده است.
سیگنال‌ها و خدمات داده
به منظور برآورده کردن توصیه‌های استراتژی حرکت برای تضمین برابری در تصمیم‌گیری (توصیهٔ شمارهٔ ۴)، بهبود تجربه کاربر (توصیهٔ شمارهٔ ۲)، و ارزیابی، تکرار و تطبیق (توصیهٔ شمارهٔ ۱۰، تصمیم‌گیرندگان از سراسر جنبش ویکی‌مدیا باید به داده‌ها، مدل‌ها، بینش‌ها و ابزارهای قابل اعتماد، مرتبط و به موقع دسترسی داشته باشند که می‌تواند به آنها در ارزیابی تأثیر (هم تحقق یافته و هم بالقوه) کارشان کمک کند. و کار جوامع خود را قادر می‌سازد تا تصمیمات استراتژیک بهتری اتخاذ کنند.
در سطل خدمات سیگنال‌ها و داده‌ها، ما چهار مخاطب اصلی را شناسایی کرده‌ایم: کارکنان بنیاد ویکی‌مدیا، وابسته‌ها و گروه‌های کاربری ویکی‌مدیا، توسعه‌دهندگانی که از محتوای ما استفاده مجدد می‌کنند، و محققان ویکی‌مدیا، و ما به داده‌ها و نیازهای بینش این مخاطبان اولویت‌بندی می‌کنیم و به آنها رسیدگی می‌کنیم. کار ما طیف وسیعی از فعالیت‌ها را در بر می‌گیرد: تعریف شکاف‌ها، توسعه معیارها، ایجاد خطوط لوله برای محاسبه معیارها، و توسعه تجربیات و مسیرهای اکتشاف داده‌ها و سیگنال‌ها که به تصمیم‌گیرندگان کمک می‌کند تا با داده‌ها و بینش‌ها تعامل مؤثرتر و لذت‌بخش‌تری داشته باشند.
مخاطبان آینده
.svg)
هدف از این سطل کشف استراتژی‌هایی برای گسترش فراتر از مخاطبان موجود ما از مصرف‌کنندگان و مشارکت‌کنندگان است تا به‌عنوان زیرساخت اصلی اکوسیستم دانش رایگان به همه افراد در جهان دسترسی پیدا کنیم. این سطل با توصیه استراتژی حرکت شماره ۹ (در دانش رایگان نوآوری کنید) مطابقت دارد. بیشتر و بیشتر، افراد اطلاعاتی را در تجربیات و اشکالی مصرف می‌کنند که با ارائه سنتی ما از یک وب‌سایت حاوی مقالات متفاوت است - مردم از دستیارهای صوتی استفاده می‌کنند، وقت خود را با ویدیو می‌گذرانند، با هوش مصنوعی درگیر می‌شوند و موارد دیگر. در این سطل، فرضیه‌هایی را در مورد آینده‌های بالقوه بلندمدت برای اکوسیستم دانش آزاد و اینکه چگونه زیرساخت اصلی آن خواهیم بود، پیشنهاد و آزمایش خواهیم کرد. ما این کار را از طریق کار محصول و فناوری و همچنین از طریق تحقیق، مشارکت و بازاریابی انجام خواهیم داد. همان‌طور که ما کشورهای آینده امیدوار کننده را شناسایی می‌کنیم، آموخته‌های حاصل از این سطل از طریق سطل‌های شماره ۱ و شماره ۲ در برنامه‌های سالانه متوالی تأثیر می‌گذارد و گسترش می‌یابد و محصولات و فناوری‌های ما را به سمت جایی که باید برای خدمت به جویندگان دانش در آینده باشد سوق می‌دهد. اهداف ما برای این سطل باید ما را به آزمایش و کاوش سوق دهد، زیرا چشم‌اندازی از آینده دانش رایگان را در کانون توجه قرار می‌دهیم.
زیر-سطل‌ها
ما همچنین دو سطل فرعی دیگر داریم که شامل بخش‌هایی از عملکردهای حیاتی است که باید در بنیاد برای پشتیبانی از عملیات اساسی ما وجود داشته باشد و برخی از آنها با هر سازمان نرم‌افزاری مشترک است. این «سطل‌های فرعی» اهداف سطح بالای خود را نخواهند داشت، اما در مورد اهداف سطح بالای سایر گروه‌ها ورودی خواهند داشت و از آن پشتیبانی خواهند کرد. آنها هستند:
- بنیادهای زیرساخت. این سطل تیم‌هایی را پوشش می‌دهد که مراکز داده، پلتفرمهای محاسباتی و ذخیره‌سازی ما، سرویس‌هایی که برای کار با آنها انجام می‌شوند، ابزارها و فرآیندهایی که عملکرد سایت‌ها و خدمات عمومی ما را قادر می‌سازند، حفظ و تکامل می‌دهند.
- پشتیبانی محصول و مهندسی. این سطل شامل تیم‌هایی است که در مقیاس عمل می‌کنند و خدماتی را به تیم‌های دیگر ارائه می‌دهند که بهره‌وری و عملیات تیم‌های دیگر را بهبود می‌بخشد.