الخطة السنوية لمؤسسة ويكيميديا/2025-2026/الأهداف والنتائج الرئيسة في قسم المنتجات والتقنية

مؤسسة ويكيميديا
الخطة السنوية 2025-2026

الخطة السنوية لمؤسسة ويكيميديا ​​2025-2026

• ملخص
• التوجهات العالميَّة
• التقدم
• الأهداف
  • البنية التحتية
  • دعم المتطوعين
  • الفعالية
• النموذج المالي
• موجز الميزانية
• التعاون

نظرة على العام المقبل

على الرغم من كل ما يشهده العالم من تغيّرات، تبقى مؤسسة ويكيميديا ثابتة على هدفها: توفير معرفة مفيدة من مشاريع ويكيميديا عبر الإنترنت مجانًا، والاستمرار في ذلك عبر الأجيال. نطمح أن يبقى مبدأ المعرفة الحرة متاحًا ومتجددًا ليصل إلى الأجيال القادمة دون قيود.

يتغير الإنترنت بسرعة كبيرة. فالأجيال الجديدة تحصل على المعلومات من خلال فيديوهات التواصل الاجتماعي وتجارب الذكاء الاصطناعي، بينما يقل عدد الذين يعرفون ويكيبيديا مقارنة بالأجيال الأكبر سنًا. ونشهد أيضًا انخفاضًا في عدد زوار مواقعنا وعدد المساهمين. وفي الوقت نفسه، تعتمد منصات كثيرة على محتوى ويكيميديا لدعم خدمات البحث والذكاء الاصطناعي لديها. هذه التغيرات تمثل تحديات حقيقية، لكنها تبرز أيضًا أهمية ما نقوم به من إنتاج معرفة حرة وموثوقة. اليوم، أكثر من أي وقت مضى، يحتاج العالم إلى مصدر معلومات يعتمد على مراجعة بشرية موثوقة، وهذا ما تواصل مشاريع ويكيميديا إثبات قدرتها على تقديمه.

لمواجهة هذه التحديات في العام القادم، سنبني مسارات تضمن استفادة مستدامة من محتوى ويكيميديا، وسنحرص على وصول هذا المحتوى إلى المساحات الاجتماعية عبر الإنترنت التي تقضي فيها الأجيال الجديدة معظم وقتها. سنطور مواقعنا حتى يشعر القراء بالرغبة في العودة إليها، والتفاعل معها بعمق، والمساهمة فيها بطرق تحمل معنى لهم. كما سنستثمر في تعزيز قدرتنا على التجريب السريع بالتقنيات الجديدة، حتى يواكب تطويرنا المتواصل سرعة التغير الذي يشهده العالم.

يوضح هدف البنية التحتية كيف ستدعم المنصة وتجربة المستخدم مواجهة هذه التحديات والوصول إلى غالبية المشاركين في الحركة. ولا يقتصر الأمر على سرد للمشاريع، بل هو مجموعة من التوجهات التي تهدف إلى دعم نمو المتطوعين، وتمكينهم من بناء محتوى موسوعي موثوق، وضمان تمويل مستدام لمهمتنا، وتطوير عروضنا بما يواكب شكل الإنترنت المتغير. يمكنكم قراءة المزيد عن ذلك في ركائزنا الاستراتيجية الأربعة.

تحفيز نمو المتطوعين

إن مجتمع المتطوعين هو العنصر الأساسي في نجاح مشاريع ويكيميديا، ومن الضروري أن يظل هذا المجتمع قويًا وينمو باستمرار. ومع ذلك، شهدنا خلال العام الماضي استمرار انخفاض عدد المحررين الجدد والعائدين إلى المشاريع. ولفهم احتياجات المتطوعين الحاليين والتجاوب معها بشكل أفضل، جددت المؤسسة قائمة أمنيات المجتمع، حيث انتقلت من استبيان سنوي إلى منصة مفتوحة دائمًا لاستقبال المقترحات. يتيح ذلك دمج احتياجات المستخدمين وأفكارهم في عمل فرق متعددة داخل المؤسسة. جمعنا هذه الأمنيات ضمن مجالات تركيز محددة، وأدرجنا ثلاثة منها ضمن النتائج الرئيسة في الخطة السنوية. كما بدأنا في تجربة مجلس استشاري للمنتجات والتقنية لدعم النقاشات المستمرة التي تجريها فرق المؤسسة مع أفراد المجتمع داخل الويكي وخارجه على مدار العام. إضافة إلى ذلك، حددنا فرصًا لجذب الأجيال الجديدة إلى مشاريعنا، خاصة مع مشاركتهم النشطة في المساحات الاجتماعية عبر الإنترنت التي توفر لهم طرقًا سهلة ومتوافقة مع الهواتف للتفاعل حول المواضيع التي تهمهم.

في العام المقبل، سنحفز نمو المتطوعين من خلال جعل المساهمة أسهل وأكثر جاذبية للأجيال الجديدة. سنبدأ بتوسيع نطاق التجربة الموجهة للهاتف المحمول، وتقديم طرق تحرير جديدة تسمى المهام المهيكلة، وإضافة مسارات عمل ذكية تجعل التحرير البنّاء عبر الهاتف المحمول تجربة مبسطة وسهلة للمساهمين الجدد مثل فحوصات التحرير. ولتعزيز مشاركة المتطوعين الحاليين والاحتفاظ بهم، سنوفر لهم إجراءات ومهام مقترحة، ونعرضها في مركز محوري يساعدهم على تنظيم الأنشطة داخل الويكي. كما سنستخدم الذكاء الاصطناعي بشكل مدروس لدعم عمل المتطوعين مع الحفاظ على الرقابة البشرية وضمان الشفافية. أما بالنسبة للمتطوعين الجدد وذوي الخبرة معًا، فسنبني سبلًا للتواصل والعمل المشترك على مواقعنا، مستوحاة من الحملات الناجحة ومشاريع الويكي. يتيح ذلك لهم العثور على محررين يشاركونهم الاهتمامات وتحسين المحتوى المتعلق بها، وذلك بما يتماشى مع مجال التركيز هذا في قائمة الأمنيات.

تقديم محتوى موسوعي جديرة بالثقة

مع تزايد المحتوى الذي ينتجه الذكاء الاصطناعي عبر الإنترنت، أصبح العالم بحاجة أكبر إلى محتوى موسوعي موثوق. ونسعى إلى تعزيز قدرات المتطوعين في ثلاثة مسارات أساسية هي إنشاء محتوى جديد، وضمان استمرار موثوقية المحتوى القائم، وتقديم هذا المحتوى الموثوق لجيل جديد من القراء بمتطلبات وتفضيلات مختلفة.

لمساعدة المتطوعين على إنشاء محتوى جديد، سنطور الأدوات ومسارات العمل الموجهة الحالية مثل أداة ترجمة المحتوى، حتى تتمكن المجتمعات الكبيرة والصغيرة من إنشاء وتغطية المحتوى الحيوي. ولضمان بقاء المحتوى الحالي جديرًا بالثقة، سنساعد المتطوعين ذوي الخبرة على إدارة أعباء عملهم المتزايدة بشكل أفضل، وذلك من خلال توسيع الأدوات التي تساعدهم على تحديد المهام التي تحتاج إلى تدخلهم. سيجعل هذا من السهل عليهم تحديث المقالات وإلغاء التعديلات غير المفيدة، بما يتماشى مع مجال التركيز هذا في قائمة الأمنيات.

سنقدم أيضًا دعمًا أكبر لمشرفي حماية المحتوى، وذلك من خلال توفير إشارات جديدة تتجاوز مجرد عناوين بروتوكول الإنترنت، تساعد في تحديد الجهات المسيئة بدقة أكبر. يتيح هذا للمشرفين اتخاذ إجراءات الحظر بطريقة تقلل من الأخطاء وتحد من حظر المحررين ذوي النوايا الحسنة.

ولتقديم محتوى موسوعي يناسب جيلًا جديدًا من القراء، سنطور ميزات تساعدهم على فهم المقالات بسهولة، والعثور على المعلومات التي تهمهم، والمشاركة بطرق تفاعلية أثناء القراءة. تهدف هذه التحديثات إلى تشجيع القراء الجدد على الاستمرار في استخدام ويكيبيديا بانتظام، وأن يتحول بعضهم مع الوقت إلى متبرعين، وذلك بما يتماشى مع مجال التركيز هذا في قائمة الأمنيات.

إن تقديم محتوى موثوق يشمل أيضًا دعم نموذج الخدمة المعرفية، وهو النموذج الذي يجعل الإنترنت بأكمله يعتمد على محتوى ويكيميديا. ففي هذا الإطار، لا تقتصر قيمة بنيتنا التحتية على كونها موردًا للبشر الذين يزورون مواقعنا، بل أصبحت أيضًا مصدرًا تعتمد عليه شركات البحث والذكاء الاصطناعي، إذ تصل تلقائيًا إلى محتوانا ليكون جزءًا أساسيًا من مدخلات ومخرجات منتجاتها. ويمثل هذا النوع من الشركات مثالًا واحدًا فقط على استخدامات عديدة تفرض ضغطًا متزايدًا وغير مستدام على بنيتنا التحتية. ففي العام الماضي، أدت الزيادة الكبيرة في الطلبات القادمة من أدوات كشط الويب والروبوتات إلى ضرورة عاجلة لمعالجة هذا الوضع. كما أننا بحاجة إلى إنشاء مسارات مستدامة تتيح للمطورين والمستخدمين إعادة استخدام محتوى المعرفة، مع ضمان أن تكون الأولوية دائمًا للبشر قبل الروبوتات.

تمويل مستقبل الموسوعة الحرة

يلعب قسم المنتجات والتقنية دورًا أساسيًا في ضمان استدامة الحركة. وفي العام القادم، سنعمل بشكل وثيق مع فريق جمع التبرعات لضمان تقديم تجربة واضحة ومجزية للمتبرعين. نسعى عبر مواقعنا وتطبيقات الهاتف المحمول إلى توفير فرص للقراء للتعبير عن تقديرهم لويكيبيديا من خلال التبرع، كما سنطور أساليب جديدة تضمن شعور المتبرعين بالتقدير وتشجعهم على الاستمرار في دعمنا عامًا بعد عام.

تشكيل إنترنت متغير

لإيصال المعرفة الحرة إلى الجميع، علينا الوصول إلى الناس حيثما يوجدون، وتقديم تجارب تساعدهم على التعلّم. فالأفراد بين 18 و24 عامًا لديهم وعي واستخدام أقل لويكيبيديا مقارنة بالأجيال السابقة، إذ يعتمدون في التعلم والتفاعل على منصات الفيديو القصير، والشخصيات الموثوقة على الإنترنت، وتجارب الألعاب الاجتماعية، وتطبيقات الذكاء الاصطناعي. خلال هذا العام، سنعمل على جعل ويكيبيديا حاضرة في الأماكن التي يقضي فيها هؤلاء الشباب وقتهم عبر الإنترنت، ليكونوا على دراية بها كمصدر موثوق للمعرفة التي ينشئها البشر. كما سنعزز وجودنا في منصات الفيديو الشائعة لنشر محتوى ويكيبيديا وبناء مجتمع نشط داخل تلك المساحات، وسنستكشف فرص توصيل معرفة ويكيبيديا إلى منصات الألعاب والمنصات الاجتماعية.

ضمن إطار البنية التحتية، ينقسم هذا العمل إلى ثلاث محافظ رئيسة تسمى سلال، وهي تجارب الويكي، والإشارات وخدمات البيانات، وجمهور المستقبل. وهي المحافظ نفسها التي اعتمدناها خلال العام الماضي والعام الذي قبله.

في المحصلة، نؤمن أن هذه الخطة تستجيب لمرحلة حاسمة في تاريخ الإنترنت، وتمنحنا القدرة على ضمان بقاء محتوى المعرفة الحرة متاحًا لجميع الأجيال ومساهمًا في تشكيله. يمكنكم الاطلاع على أهدافنا وأبرز نتائجنا لمعرفة الهيكل الكامل ومحتوى الخطة بمزيد من التفاصيل. ونتطلع إلى الاستماع إلى أسئلة المجتمع وأفكاره.

بناء البنية التحتية لمشاريع ومتطوعي ويكيميديا وتحسينها واستدامتها، انطلاقًا من قيمنا الراسخة

"ستعمل المؤسسة على إتاحة المعرفة المفيدة من مشاريعها على شبكة الإنترنت مجانًا، والاستمرار في إتاحتها إلى الأبد"

تخصص فرق المنتجات والتقنية أولوية دائمة وعلى مدار العام لبناء البنية التحتية التي تخدم مشاريع ويكيميديا، وتحسينها والمحافظة عليها. نستثمر في استضافة مشاريع ويكيميديا، وتطوير البرمجيات مفتوحة المصدر وأنظمة التصميم، بالإضافة إلى صيانة وتحسين البنية التحتية لمنتجات البيانات ونماذج الذكاء الاصطناعي.

يركّز جزء من عملنا الأساسي على أساسيات تطوير واستضافة موقع إلكتروني كبير وشعبي. نستضيف مشاريع ويكيميديا في مراكز بيانات، على خوادم وأجهزة نشتريها ونركبها ونصونها، وتكون موصولة ببعضها البعض وبقية شبكة الإنترنت عبر شبكة عالية السرعة. نراقب السعة ونضيفها حيثما تدعو الحاجة، ونُحدّث المعدات عندما تصبح قديمة جدًا. على سبيل المثال، نتوقع هذا العام توسيع سعتنا وتحديث عتادنا في مراكز بياناتنا الموجودة في آشبورن وفيرجينيا وكارولتون وتكساس.

نصمم برمجيات مفتوحة المصدر وتطويرها (أبرزها ميدياويكي). كما نستخدم وننشر العديد من التطبيقات والمكتبات وأطر العمل المفتوحة المصدر لأطراف ثالثة موجودة مسبقًا. تُحدد أولويات الأخطاء المهمة في برامجنا والعمل على إصلاحها. تتطلب صيانة البرمجيات مفتوحة المصدر عملًا عالي المهارة من أشخاص ذوي خبرة متخصصة في تطوير البرمجيات مفتوحة المصدر، وهندسة موثوقية المواقع (SRE)، وإدارة المنتجات، وإدارة البرامج، والتصميم، وغيرها. يعمل موظفونا على ضمان حداثة برامجنا وأنظمتنا وتكييفها مع بيئة دائمة التغير. ويشمل ذلك تحديث برمجيتنا للاستمرار في الاستفادة من تصحيحات الأمان وللعمل بكفاءة مع البرمجيات الجديدة التابعة لأطراف ثالثة. على سبيل المثال، برنامج ميدياويكي مكتوب بلغة PHP، وفي العام الماضي انتقلنا من الإصدار 7.4 إلى 8.1، وهو ما تطلب تغييرات في كل من النص البرمجي والبنية التحتية التي نستضيف عليها مواقعنا وخدماتنا.

في هذا العام، سنبني على هذا الجهد وسننتقل إلى الإصدار 8.3، مستفيدين من الدروس المستخلصة والأدوات التي طُوِّرت خلال ترقية الإصدار 8.1. سيجعل هذا التحديث أنظمتنا أسرع للقراء، وأسهل لاستخدام الموظفين والمتطوعين، وأكثر أمانًا للجميع. كما سيوفر وقت التطوير المستقبلي بفضل تحسينات الأمان والأداء والدعم التي تأتي مع تحديثات اللغة.

لضمان أن تظل مشاريعنا ومحتوياتنا متاحة على الإنترنت، اليوم وإلى الأبد، تكرس فرقنا قدرًا كبيرًا من الجهد لضمان التوافر العالي لمواقعنا وخدماتنا. يركز أحد جوانب هذا العمل على التعافي من الكوارث الناتجة عن الأحداث الكارثية أو الخبيثة. على سبيل المثال، نضمن أن لدينا نسخًا احتياطية للبيانات المهمة، وأننا قادرون على الاسترداد منها. وبالمثل، نختبر مرتين سنويًا قدرتنا على تحويل مواقعنا بين مراكز البيانات لدينا بطريقة مؤتمتة، ونعمل على إصلاح أي مشكلات نكتشفها. يركّز جانب آخر من هذا العمل على تحديد الاتجاهات المتطورة في أنواع وحجوم حركة المرور التي نتلقاها والتكيف معها. فمع النمو غير المسبوق في عمليات الكشط المؤتمتة، نعطي الأولوية للعمل على ضمان بقاء مواقعنا وخدماتنا متاحة للمستخدمين البشريين، متبعين منهجًا نظاميًا لترسيخ المعايير حول الاستخدام المسؤول لبنيتنا التحتية.

لا نخطط لكل شيء بفترة طويلة مسبقًا، فهناك أحداث وطوارئ غير متوقعة تتطلب استجابة فورية، مثل انقطاعات المواقع، وحوادث الأمان، وهجمات التخريب واسعة النطاق على المشاريع. نراقب أداءنا باستمرار، ونرصد العوائق التي تحد من الوصول إلينا حول العالم، بما في ذلك مشاكل الاتصال أو حجب الرقابة، ونتحقق من أي خلل يظهر. تؤدي بعض هذه الأحداث المفاجئة أو المشكلات المتكررة إلى تحويل تركيز الموظفين نحو مشاريع قصيرة المدى تهدف إلى تخفيف الأثر السلبي أو منعه بالكامل. وقد كانت هذه الجهود أساسية في قدرة مشاريع ويكيميديا على استيعاب الزيادات المفاجئة في حركة المرور الناتجة عن أحداث إخبارية كبيرة مثل وفيات شخصيات مشهورة، وذلك عبر تحسين الأداء، وإعادة تصميم البنية في المناطق التي تشكل اختناقات، وزيادة السعة. كما أن التحسينات الأخيرة في قابلية استخدام الأدوات والأنظمة الخاصة بإدارة حركة المرور عززت قدرتنا على التحرك بسرعة وفعالية حسب الظروف المتغيرة. هذا النوع من العمل التكيفي عنصر أساسي في الاستجابة للأحداث الطارئة في فترات زمنية قصيرة، وضمان بقاء مشاريعنا ومحتوياتها متاحة للجميع.

أهداف المنتجات والتقنية

الأهداف المعروضة هنا ما تزال في صيغتها الأولية بصفتها مسودة، وهي مفتوحة الآن لإبداء التعليقات والمناقشة.

• تمثل الأهداف توجهًا عالي المستوى.
• تمثل "النتائج الرئيسة" طريقة قابلة للقياس لتتبع نجاح الأهداف المذكورة.
• تمثل "الفرضيات" الكامنة وراء كل نتيجة رئيسة العمل الفعلي الذي نقوم به لمحاولة تحقيق النتائج الرئيسة المرتبطة بها. وستُحدّث هذه الفرضيات في هذه الوثيقة وفي صفحات الويكي الخاصة بالفريق أو المشروع ذي الصلة كلما اكتسبنا رؤى جديدة على مدار العام.
• يمثل العمل الذي تمنحه المؤسسة الأولوية ضمن قائمة أمنيات المجتمع.

تجارب الويكي

تجارب المساهمين

• الهدف: تزداد المساهمات نتيجة لتقديم فرص جذابة للمتطوعين وفهمهم لتأثير عملهم. ناقش
  • السياق: سيكون هذا الهدف الأساسي لتحقيق استراتيجية المساهمين الجدد بأركانها الثلاثة: 1) توفير طريقة مركزية للمتطوعين لتنظيم أنشطتهم داخل الويكي، 2) تقديم مهام منفصلة وأصغر لزيادة الوضوح ومساعدة المتطوعين على تحقيق إمكاناتهم، و3) جعل المساهمة ذات مغزى أكبر. في السنة المالية 2025/2026، نخطط لتوفير البنية التحتية الأساسية لمساعدة المتطوعين على تنظيم أنشطتهم داخل الويكي بطريقة مركزية، بدءًا من التدخلات التي تركز تحديدًا على المحررين والمشرفين ذوي الخبرة. وفي السنوات اللاحقة، سنضيف تدخلات تشمل جميع أدوار المساهمين وسنضم المزيد من نطاقات المشكلات. إضافة إلى ذلك، سنستمر في الاستثمار في فحص التحرير والمهام المهيكلة، وبناء أساس لكيفية استخدام الذكاء الاصطناعي بطريقة قابلة للتوسع، سواء التوجيه أثناء عملية التحرير أو طريق توجيه المتطوعين نحو فرص جذابة. وأخيرًا، سنستثمر في جعل تأثير المتطوعين أكثر وضوحًا لخلق تجربة ذات مغزى أكبر بالنسبة لهم.
    • النتائج الرئيسة لتجارب ويكي رقم 1.1: زيادة معدل نشر المحررين الذين يمتلكون 100 تعديل تراكمي أو أقل لتعديلات بنّاءة على الويب الموجه للهاتف المحمول [i] بنسبة 4% [ii]، ويُقاس ذلك عبر تجارب مضبوطة (بحلول نهاية الربع الثاني).
      • i. "التعديلات البنّاءة" = هي التعديلات على صفحات في النطاق الرئيس لأي ويكيبيديا والتي لا يُتراجع عنها في غضون 48 ساعة من تاريخ نشرها.
      • ii. T389403#10960480
      • يعاني المتطوعون الجدد في بدء التحرير بنجاح. وينطبق هذا بشكلٍ خاص على الأشخاص الذين يستخدمون الأجهزة المحمولة، حيث تكون مساحة الشاشة محدودة ويكون الانتباه في كثير من الأحيان مجزأً.
      • قد يُصاب البعض بالإرهاق من السياق والصبر والمحاولة والخطأ أثناء المساهمة بشكل بنّاء. بينما لم يصادف آخرون بعد فرصة جذابة للمحاولة.
      • ستعمل النتائج الرئيسة لتجارب ويكي 1.1 على معالجة هذه القضايا من خلال ما يلي:
        • إظهار اقتراحات التعديل
        • تقديم إرشادات قابلة للتنفيذ أثناء التحرير
        • بناء مسارات عمل للتحرير أكثر تخصصاً بالمهام
      • في جوهر هذه الجهود تكمن الحاجة إلى طرق قابلة للتوسع للكشف عن كيفية تحسين التعديلات الجارية والمحتوى الحالي. ولتنمية هذه القدرة، سنواصل التجريب بالتعلم الآلي لنتعلم كيف يمكنه أن يخدم المحررين على أفضل وجه، عبر مختلف الأدوار ومستويات الخبرة.
      • المنهجية المقترحة لتسجيل نقاط أبرز النتائج: على أساس كل منصة على حدة، سنحسب نسبة التدخلات التي نشرناها وقيّمناها عبر تجارب مضبوطة والتي حققت أو تجاوزت هدف التعديلات البنّاءة الذي حددناه في بداية هذا العام. (انظر phab:T379285#10782051 للاطلاع على المنهجية).
        • ملاحظة: اعتباراً من 30 يونيو 2025، خُطط لتجربتين مضبوطتين ضمن تجربة الويكي 1.1.
    • النتائج الرئيسة لتجارب ويكي 2.1: زيادة في عدد التعاونات على مواقع الويكي بنسبة 55% بحلول نهاية الربع الرابع.
      • غالبًا ما يواجه المساهمون صعوبة في العثور على فرص للتعاون فيما بينهم، لا سيما فيما يتعلق بالمواضيع والمهام التي يهتمون بها. قد يؤدي هذا إلى شعور الوافدين الجدد بالعزلة في مواقع الويكي، ويمكن أن يؤدي إلى الإرهاق لدى المحررين ذوي الخبرة. بالإضافة إلى ذلك، غالبًا ما يكون تأثير الأنشطة التعاونية غير واضح، مما يقلل من رغبة الأفراد في الانضمام إلى التعاونات أو تنظيمها أو دعمها في مواقع الويكي.
      • نهدف إلى توضيح قيمة التعاون من خلال القيام بما يلي:
      1. ابتكار طرق جديدة لمشاركة تأثير الأنشطة التعاونية على مواقع الويكي
      2. البدء في جمع البيانات على مستوى الحركة حول تأثير الأنشطة التعاونية
      3. إعداد البنية التحتية الأساسية لتتبع المساهمات التعاونية، لكي نتمكن من توفير طرق جديدة ومبتكرة للاعتراف بالمساهمات ومكافأتها في المستقبل
      • سيجري قياس التعاونات عبر الأنشطة الجديدة التي تُنشأ باستخدام أداة تسجيل الفعاليات ضمن إضافة فعاليات الحملات. والهدف هو الوصول إلى ارتفاع في عدد مستخدمي أدوات الإضافة وتوفير طرق جديدة لإظهار أثر التعاون مع نهاية هذه النتيجة الرئيسة. هذا التطور يهيئنا لربط بنيتنا التحتية الحالية بوسائل أخرى للاعتراف بالعمل ومكافأته داخل مواقع الويكي، مثل وحدة التأثير ورسائل الشكر وغيرها.
      • مجال التركيز في قائمة الأمنيات: قائمة أمنيات المجتمع/مجالات التركيز/ربط المساهمين
    • النتائج الرئيسة لتجارب ويكي 3.1: بحلول نهاية الربع الثالث، 10% من المساهمين الذين عُرضت عليهم صفحة رئيسة موجهة نحو المشرفين الجدد زاروها أسبوعين متتاليين.
      • نرى أن إظهار فرص المساهمة للمتطوعين يحتاج إلى تطوير أكبر. وعلى المدى الطويل، نؤمن بأن الصفحة الرئيسة قادرة على مساعدة أي محرر في تنظيم عمله، واكتشاف فرص جديدة، وفهم أثر مساهماته. هدفنا في السنة المالية 2025/2026 هو إبراز فرص إضافية للمحررين ذوي الخبرة للاضطلاع بمهام الإشراف، خاصة تلك التي قد لا ينتبهون إليها أو لا يصلون إليها بسهولة في الوضع الحالي.
      • سنختبر هذه النظرية أولاً من خلال فهم مدى تفاعل المحررين ذوي الخبرة مع صفحة رئيسة، مشابهة لتلك التي يمكن للوافدين الجدد الوصول إليها.
      • بعد ذلك، سنُظهر أنشطة إشراف محددة (ستُحدد تفاصيلها لاحقاً) للمساهمين الجدد على هذا النوع من إجراءات الإشراف، بهدف المساعدة في تخفيف العبء عن المحررين ذوي الخبرة من خلال تقليل الأعمال المتراكمة (تحت أبرز النتائج الجديدة).
      • إذا نجح مفهوم الصفحة الرئيسة، فإننا نخطط لجعل هذه الصفحة نمطية لتلبية احتياجات المجتمعات. يمكن أن تشتمل هذه النماذج على أمور مثل تسهيل فهم المحررين لتأثير عملهم.
      • ملاحظات حول المنهجية:
      • سيكون لدينا فرضية لتحديد جمهورنا، وستكون هذه الفرضية جزءًا من تجارب ويكي 1.3.1.
      • سيُتّبع تعريف المشرفين المعتمد في Research:Develop a working definition for moderation activity and moderators، مع الحاجة إلى متابعة إضافية لاحقًا للوصول إلى تحديد كمي أكثر دقة.
      • يُعرَّف "الأسبوع الثاني" بطريقة نسبية وفقًا لتوقيت الزيارة الأولى لكل مستخدم. وفي هذا السياق، تُراجع زيارات جميع المشرفين الجدد الذين دخلوا إلى الصفحة الرئيسة خلال إطار زمني محدد، ثم عادوا لزيارة أخرى واحدة على الأقل بعد فترة تتراوح بين 7 و14 يومًا.
      • مجال التركيز في قائمة الأمنيات: قائمة أمنيات المجتمع/مجالات التركيز/تحديد أولويات المهام
    • النتائج الرئيسة لتجارب ويكي 4.1: تحسين النسبة المئوية للزوار الفريدين لصفحتي قائمة المراقبة أو أحدث التغييرات الذين ينقرون لعرض تعديل.
      • هدفنا مساعدة المحررين الذين يملكون 100 تعديل أو أكثر على العثور على التعديلات المتعلقة باهتماماتهم وفتحها بكفاءة أعلى. سوف نعمل على استكشاف مجال التركيز لتحديد أولويات المهام، وتنفيذ الأمنيات المرتبطة به، وجمع ملاحظات إضافية من المتطوعين حول تحسين هذه الواجهات. ويمكن قياس النجاح من خلال رفع فعالية كل صفحة مخصّصة "لإيجاد العمل"، ويُقاس ذلك عبر مقياس معدلات النقر إلى الظهور.
    • النتائج الرئيسة لتجارب ويكي 5.1: تحديد وتفعيل سبعة مقاييس [1] ذات أولوية عالية واللازمة لتتبع التقدم نحو تحقيق الأهداف الموضحة في استراتيجية المساهمين بحلول نهاية الربع الرابع، وذلك عبر إنشاء لوحة تحكم وتفعيل مقاييس المشرفين النشطين شهريًا.
      [1]المقاييس هي: المحررون المحتفظ بهم، والتفعيل البنّاء، والتعديلات البنّاءة، والمسجلون الجدد المحتفظ بهم، والمحررون النشطون حسب مدة الخدمة، والمحررون النشطون حسب مستوى الخبرة.
      • تتوخى استراتيجية تجربة المساهمين جهدًا يمتد من 3 إلى 5 سنوات "gدعم نمو المتطوعين" و"زيادة الاحتفاظ والتفعيل" لكل من المساهمين الجدد والحاليين، وذلك عبر ثلاثة مجالات رئيسة من الأنشطة:
      1. تبسيط كيفية حصول المتطوعين على التوصيات، وإدارة مهامهم واهتماماتهم، والاطلاع على ما يجري في مواقع الويكي، وفهم تأثير عملهم.
      2. تقديم مهام مصممة بشكل مناسب لزيادة الوضوح ومساعدة المتطوعين على تحقيق إمكاناتهم، وذلك من خلال تحسين مسارات العمل التي يصلون إليها، بما يشمل الاستمرار في توفير إرشادات منظمة وأتمتة المهام المتكررة، مع تركيز خاص على تجربة الويب عبر الهاتف المحمول.
      3. جعل المساهمة ذات مغزى من خلال إظهار تأثير عمل المتطوعين لهم، وعبر الاستثمار في سبل التواصل البشري وتوفير بيئة قائمة على التغذية الراجعة الإيجابية.
      • بعد ذلك، رسم مشروع استراتيجية القياس شبكة واسعة من المقاييس لتتبع نظرية التغيير هذه. وقد خلص المشروع إلى أن المقياس الأساسي للنجاح ("المقياس المحوري") يجب أن يكون عدد المحررين المحتفظ بهم، ويكمله مقاييس مؤشر أضيق مثل التفعيل البناء ونية المساهمين في العودة، والمقاييس "اللاحقة" الأوسع نطاقًا مثل المحررين النشطين والمحتوى عالي الجودة. نحن بحاجة إلى التأكد من أن هذه المقاييس مُفعلة تشغيليًا ومرئية في لوحة تحكم، لكي نتمكن من تتبع تقدمنا نحو تحقيق الاستراتيجية.
    • Key result WE1.6: By the end of Q3, watchlist users can more easily organize their work and act more effectively on taking patrolling or editing action, as measured by qualitative feedback.
      • Our goal is to help editors with 100+ edits to more efficiently find edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces.
    • Key result WE1.7: Primary: Achieve a ≥ 10% relative increase in the edit completion rate of qualified newcomer and Junior Contributor mobile edit sessions, based on controlled A/B test(s).[i]
      [i] Qualified edit session = edit session in which a logged-in user with ≤100 cumulative edits spent at least ≥2 seconds in VE's "ready" state.
      Guardrail: No meaningful decreases in constructive edit rate among mobile edits published by newcomer and Junior Contributors, based on controlled A/B test(s).
      • 150,000–200,000 times/day, someone will tap "Edit" on mobile web, wait for the editing interface to load, look around for at least 2 seconds, and then leave without doing anything. No keystrokes, no taps on the toolbar…nothing.
      • WE 1.7 will meet these "curious clicks" with clear, compelling, and structured edit suggestions that cause the people making them to experience the satisfaction, joy, and meaning that can come with making Wikipedia, the resource they chose to visit, a bit better.
    • Key result WE1.8: By the end of Q4, target a 5 percent overall relative increase in the mobile web account creation completion rate, with success measured by at least three controlled experiments achieving a minimum 2 percent relative improvement each.
      • Account creation is the gateway to meaningful participation on Wikimedia projects, yet it remains an outdated experience in the newcomer journey. The current flows impose high cognitive load, present limited or confusing value propositions, and rely on legacy interface patterns that no longer reflect contemporary expectations. As a result, many potential contributors disengage before they have a chance to join the community.
      • This initiative aims to modernize account creation, reduce friction for good faith contributors, and introduce thoughtful experiments that encourage registration at the moments where motivation is naturally highest. The work lays essential groundwork for long term improvements in newcomer activation, retention, and editor diversity.
      • We estimate a 5 percent relative increase in account creation on Wikipedia on mobile would translate to several thousand additional new accounts per month, and several hundred more retained new editors per month, based on current registration volumes.
    • Key result WE1.9: By the end of Q4, deliver one tangible product recommendation each for goal setting, newcomer progression, and recognition to enable junior contributors to stay engaged and evolve.
      • Background: we know that retention of junior contributors is quite low despite recent gains (data). We believe that a fundamental challenge for overcoming this low junior contributor retention is developing our platforms to help editors stay highly motivated to contribute – i.e. not just reducing the barrier to contribute but also making the experience rewarding. This is not trivial though – e.g., editors enter the project with varying motivations; interventions such as gamification that may boost initial engagement might not help with long-term retention.
      • Why now: much of the focus of Contributors Product teams to date has been related to reducing technical barriers to activation/engagement but there are a suite of upcoming projects that are more retention-focused – e.g., Progression System and Recognition. The research under this KR aims to get ahead of this implementation work and provide clear recommendations to Product teams in this space about how they should design their platforms to better support the diverse motivations of editors and increase long-term retention. This links back to key questions related to newcomers and junior editors in the Contributor Strategy.
      • Proposed KR scoring methodology: for each identified project (goal setting; progression system; recognition), we will make at least one concrete recommendation with implications for design. Research is experimental work and the projects may evolve over the course of the KR but we will keep in close communication with the relevant product teams. In practice, these recommendations may include insights about what is most demotivating for newcomers (things to avoid) what is most satisfying (things to emphasize), common "tripping points" in journeys that need to be addressed, strategies for getting through these challenges, etc. The recommendation should help the PM identify clear next steps for design and/or engineering.
    • Key result WE1.10: By the end of Q4, implement a new guided article creation flow where the survival rate of articles created by junior editors on mobile is 5% greater on each deployed wiki than articles created by other means while the volume of surviving articles stays the same or higher, as measured by a controlled experiment.
      • The Article guidance initiative aims to develop new approaches that support editors in creating initial, well-structured contributions to Wikipedia that align with community policies and content quality. As an initial intervention, a new workflow for article creation was implemented last quarter, based on community-editable outlines that encapsulate the guidance for specific types of articles. In Q4, the goal is to run an A/B test experiment to measure the impact on a set of pilot wikis to evaluate the impact. Since the guidance is community-dependent, the experiment preparations will requires collaboration with the communities of the pilot wikis to adapt the system to their needs.

---

المعرفة الحيوية (تجارب ويكي 2)

• الهدف: جعل المزيد من المعرفة الحيوية متاحة وموضحة جيدًا عبر اللغات والمواضيع المختلفة. ناقش
  • سياق الهدف: سيدفع هذا الهدف نمو المحتوى الذي يستجيب لكل من اهتمامات المساهمين بمواضيع ولغات معينة، وطلب القرّاء على المعرفة الحيوية الموضحة جيدًا. المعرفة الحيوية هي مجموعة من المقالات التي توفر اتساع وعمق المواضيع اللازمين لمشروع لغة ويكيبيديا قابل للاستخدام. تعرف المجتمعان هذه المعرفة بالرجوع إلى الأهمية، والصلة بالموضوع، ونسبة القراءة المتوقعة، والروابط بين المقالات.
  • سوف نعتمد نهجًا اجتماعيًا تقنيًا لتحسين فعالية الميزات والأدوات والعمليات الاجتماعية. سنبني على ميزات المنتجات عالية التأثير مثل المهام المقترحة والبحث عن الوسائط وترجمة المحتوى، ولكننا سنعمل أيضًا على تسهيل انضمام وتطوير ويكيبيديا اللغات الأصغر. سوف ندعم منظّمي ويكيميديا الذين يقومون يجندون المساهمين ويدربونهم ويدعمونهم للعمل على أهداف المحتوى المشترك من خلال أطر تعاونية مثل مشاريع الويكي والحملات. (نقدر أن ما لا يقل عن 300 منظّم نشط في كل ربع سنة). سنعمل أيضًا على تطوير علاقات مع الناشرين الأكثر صلة لإزالة الحواجز أمام المصادر. (لدينا حاليًا شراكات مع أكثر من 100 من أفضل قواعد بيانات الاشتراك في العالم).
  • لضمان أن يكون لتدخلاتنا تأثير إيجابي على المعرفة الحيوية، سنقيس كل من زيادة المحتوى ذي الأولوية المجتمعية وجودة ذلك المحتوى، وذلك بالنظر إلى عوامل مثل معدلات الإبطال وعدد المصادر والاستشهادات والصور.
    • النتائج الرئيسة لتجارب ويكي 1.2: بحلول نهاية الربع الثاني، تجربة وتقييم 3 تدخلات تساعد المساهمين على تحسين حالة المحتوى الحيوي في مشاريع ويكيبيديا الخاصة بهم.
      • ستسلط النتائج الرئيسة الضوء على فجوات المحتوى في آليات التحرير، مثل اكتشاف الصور على ويكيبيديا، وترجمة المحتوى، وإنشاء مقالات جديدة موجهة. سننفذ أيضًا ونختبر تدخلًا اجتماعيًا وتقنيًا لدعم أنشطة إنشاء المحتوى للمجتمعات اللغوية الصغيرة. سوف يُقاس النجاح ضمن كل فرضية.
    • النتائج الرئيسة لتجارب ويكي 2.2: بحلول نهاية الربع الرابع، بناء قدرات المنصة اللازمة للتحقق من أنه يمكننا دعم رؤية ويكيبيديا المجردة على نطاق واسع. سنعرف أننا ناجحون إذا أظهرنا أن النظام ينتج محتوى موسوعيًا غنيًا ومتعدد اللغات باستخدام ويكي بيانات وتوليد اللغة الطبيعية، يتحكم فيه مجتمع ويكيميديا، ويظل محافظًا على أدائه العالي في عمليات النشر الواسعة.
      • الآن وبعد أن أصبح بإمكاننا استخدام ويكي بيانات لإنتاج محتوى نصي أساسي وبسيط في مشاريع ويكيبيديا، فإن الخطوة التالية هي الاستمرار في بناء قدرات المنصة التي يمكن أن تدعم ويكيبيديا المجردة على نطاق واسع. سيتعين على المنصة أن تدعم محتوى غنيًا ومتعدد اللغات يمكن أن يتحكم فيه المجتمع ويحافظ على أدائه العالي على نطاق واسع. تعتبر هذه النتيجة الرئيسة بمثابة إنجاز محوري لأننا ننتقل فيها من الصفر إلى الواحد.
    • النتائج الرئيسة لتجارب ويكي 2.3: بحلول نهاية الربع الرابع، نشر شكل أولي من الويكي الجديد لتمكين المجتمع من البدء المبكر في إنشاء مقالات ويكيبيديا المجردة.
      • تُجهزنا هذه النتائج الرئيسة لاختبار قدرات منصة ويكيبيديا المجردة في العام القادم. سيستضيف الويكي الجديد والمستقل مكتبة المقالات المجردة المبنية على ويكي دوال، وسيوفر قدرات المنصة اللازمة لدمج المقالات المجردة لاحقًا في ويكيبيديا في المستقبل.
    • النتيجة الرئيسة WE2.4: توحيد الرؤية بين مؤسسة ويكيميديا وويكيميديا ألمانيا حول تعريف النجاح المتعلق بتحسينات البنية التحتية التقنية الداعمة لحالة استخدام حيوية في ويكي بيانات، وذلك بحلول نهاية الربع الثاني، بما يشمل المقاييس والأهداف الخاصة بالسنة المالية 2025–2026.
      • أُنشئ فريق منصة ويكي بيانات التابع لمؤسسة ويكيميديا في أغسطس 2025، ويضم قائدًا للمنتج وقائدًا تقنيًا. وبما أن هذا الفريق يُعد إضافة جديدة إلى برنامج ظل لسنوات طويلة تحت تطوير وإدارة المالكين التقنيين ومالكي المنتجات في مؤسسة ويكيميديا وويكيميديا ألمانيا على التوالي، يعكس هذا الهدف نيتنا نقل الملكية تدريجيًا من خلال المواءمة على حالات الاستخدام، والتبعيات، ومعايير النجاح الرئيسة. تضع هذه النتائج الرئيسة الأساس لتفاهم مشترك حول مساحة المشكلة، وهو الأساس الذي سيُبنى عليه العمل خلال بقية السنة المالية حتى مايو 2026.
    • Key result WE2.5: By the end of Q4, our backend replacement has been stood up in parallel to Blazegraph and is capable of supporting the cutover of select users. We define “migration ready” for this KR as capable of supporting the pilot phase of our migration in Q1 of FY26-27.
      • Following the progress made towards defining the success criteria as a part of WE2.4, we are now shifting into execution mode. In the next two quarters, we will outline all of the variables associated with the Blazegraph cutover in a migration plan, determine which are critical for pilot launch, implement them in a new RDF database, and define the migration timeline for all requirements beyond our pilot personas. Our work between now and our target launch of a new WDQS backend (est. July 2026) will be guided by the requirements laid out in this plan.

---

تجارب المستهلك (تجارب ويكي 3)

• الهدف: انخراط القراء من مختلف الأجيال في ويكيبيديا، واستمرار انخراطهم بها، مما يؤدي إلى زيادات قابلة للقياس في كل من الاحتفاظ ونشاط التبرعات. ناقش
  • سياق الهدف: سيركّز هذا الهدف على الاحتفاظ بالقرّاء الجدد من خلال تنسيقات المحتوى المبتكرة، والاحتفاظ بالجماهير الرئيسة عبر تقوية تجارب القراءة المألوفة لديهم، وضمان الاستدامة طويلة الأجل من خلال تعميق الروابط مع القراء وتنويع مصادر التبرعات. سيشمل ذلك مواصلة عملنا لجعل اكتشاف المحتوى أسهل من خلال ميزات جديدة وأكثر تجريبية مثل الملخصات المُنشأة بالذكاء الاصطناعي أو مسارات التنقيب الشخصية. كما سيشمل العمل على الاحتفاظ بتجربة القراءة وتحسين جودتها في المراحل الأعمق من مسار القراءة، واستكشاف تنظيم القراءة من خلال قوائم القراءة وأشكال المشاركة غير التحريرية الأخرى. وبالنسبة للمتبرعين، سيستمر هذا العمل في التركيز على تنويع مصادر الإيرادات من داخل المنصة.
    • النتائج الرئيسة لتجارب ويكي 1.3 : بحلول نهاية الربع الثاني، إظهار زيادة ذات أهمية عملية في الاحتفاظ بالقراء غير المسجلين، ويقاس ذلك من خلال اختبار أ/ب لميزة واحدة لكل منصة.
      • ستركز هذه النتائج الرئيسة على مواصلة الاستثمار في التجارب التي تطوّر أساليب جديدة لتصفح المحتوى وتعلّمه، وذلك عبر الاستفادة من التقنيات والتنسيقات الحديثة، بما يعني تقديم المحتوى الحالي بطرق أكثر جاذبية وتنوعًا. وفي هذه السنة المالية، نهدف إلى مواصلة التجريب في الميزات الجديدة مع التركيز على توسيع نطاق التجارب التي أثبتت نجاحها عبر مشاريع الويكي والمنصات المختلفة. يشمل العمل ضمن هذه النتائج مواقع الويب على الهاتف المحمول وأجهزة المكتب، إلى جانب تطبيقات آي أو إس وأندرويد. ويركز هذا العمل على تحسين اكتشاف المحتوى، سواء من خلال نقاط دخول التصفح أو التوصيات، إضافة إلى تطوير تنسيقات تعلم مرنة مثل الملخصات المدعومة آليًا وإعادة مزج المحتوى.
      • مجال التركيز في قائمة الأمنيات: تجارب مستهلك جديدة
    • النتائج الرئيسة لتجارب ويكي 2.3: زيادة عدد التبرعات من خلال طرق غير الشعارات أو البريد الإلكتروني بنسبة 5% على أساس سنوي لكل منصة، وذلك من خلال تدخلات المنتج التي تعزز الروابط الأعمق وتقلل الاحتكاك للمتبرعين بحلول نهاية الربع الثاني.
      • سترى النتائج الرئيسة هذه أننا نواصل استكشاف نقاط دخول جديدة للتبرع وفرصًا أخرى لتحويل القرّاء إلى متبرعين والاحتفاظ بهم من خلال تعميق روابطهم بمشاريع الويكي، بما في ذلك تقديم محتوى أكثر تخصيصًا. سترّكز النتائج الرئيسة على تقديم نقاط دخول جديدة وتحسين النقاط الحالية على التطبيقات والويب، بالتعاون مع فريق جمع التبرعات.
    • النتائج الرئيسة لتجارب ويكي 3.3: بحلول نهاية الربع الثاني، إظهار زيادة ذات أهمية عملية في الاحتفاظ بالقراء المسجلين، ويقاس ذلك من خلال اختبار أ/ب لميزة واحدة لكل منصة.
      • ستركز هذه النتائج الرئيسة على تحسين تجربة القراءة والتعلم للقراء الحاليين وذوي الخبرة، بهدف الحفاظ على جمهورنا وتعميق علاقتهم بالموقع، بما يساعدهم على التعلّم بشكل أوسع ويجعلهم أكثر استعدادًا للانخراط مستقبلًا في التبرع أو التحرير. وسوف يشمل العمل في هذا المجال تحسين تجربة القراءة عبر الويب والتطبيقات، من خلال تعزيز سهولة القراءة وتطوير أساليب التصفح واكتشاف المحتوى، إضافة إلى تحسين وتوسيع قدراتنا في مجال التنظيم والتخصيص، مثل قوائم القراءة، والاقتراحات المخصصة، وسجل المستخدم والمقالات، وغيرها من الميزات.
    • أبرز نتائج تجارب ويكي 4.3: بحلول نهاية الربع الرابع، إزالة جميع المعوقات المحددة أمام عمليات النشر في مواقع التخزين المؤقت الصغيرة، مع ضمان توافقها مع معايير جودة الخدمة والأمن المعمول بها في عمليات نشر مواقع التخزين المؤقت الحالية.
      • ستركز هذه النتائج الرئيسة على إثبات إمكانية تحسين أداء الموقع وتقليل زمن الاستجابة للقراء من خلال تبسيط البنية التحتية للتخزين المؤقت، إضافة إلى تحسين عمليات نشر مواقع التخزين المؤقت عبر خفض متوسط زمن النشر من نحو عام كامل إلى ربع سنة كحد أقصى. ويركّز العمل هنا على استكمال عملية التبسيط، وتقديم إثبات المفهوم، وإجراء مراجعة أمنية، وإعداد ملخص قرار يحدد ما إذا كان من الملائم المضي في نشر التخزين المؤقت الحافي في السُحُب العامة. ويُتوقَّع أن يسهم تقليل زمن الاستجابة في زيادة مثبتة في عدد مشاهدات الصفحة وتحقيق قاعدة قراء أكثر تنوعًا من الناحية الجغرافية.
    • النتائج الرئيسة لتجارب ويكي 5.3: تحسين عملية تحديد هوية المتبرعين، وضمان القدرة على التعرّف على جميع القرّاء المسجّلين الذين وافقوا على تحديد هويتهم بحسب حالة التبرع، بهدف تقديم تجربة مخصّصة، وذلك بحلول نهاية الربع الرابع.
      • سننفّذ استراتيجيات لتحديد هوية المتبرعين بما يضمن القدرة على التعرّف على جميع القرّاء المسجّلين الذين وافقوا على تحديد هويتهم وفق حالة التبرع، بما يتيح تجربة أكثر تخصيصًا وجاذبية. وتُعطى جهود تحديد هوية المتبرعين أولوية خلال الربع الرابع لدعم مبادرات التخصيص والتفعيل بشكل أكثر فعالية في المستقبل.
    • النتائج الرئيسة لتجارب ويكي 3.6: وضع الصيغة النهائية لاستراتيجية تجربة قارئ ومستهلك ويكيبيديا عبر المنصات، ونشرها، وإبلاغها للمجتمع بحلول نهاية الربع الرابع، مع تحديد الأهداف والمقاييس الأساسية بالتعاون مع أصحاب المصلحة والمجتمع، لتوجيه العمل حتى عام 2030.
      • سيستمر العمل على استراتيجية المستهلك مع التركيز على تطوير الاستراتيجية والتواصل بشأنها داخل المؤسسة ومع المجتمع، إضافة إلى تحديد المقاييس الأساسية الخاصة بالمستهلكين ووضع نقاط الأساس لكل مقياس.
    • Key result WE3.7: Increase the number of donations through non-banner or email methods by 10% YoY per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q4.
      • This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team.
    • Key result WE3.8: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for active readers in a test environment, monitoring a guardrail appropriate for the feature.
      • This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
    • Key result WE3.9: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for logged-out casual readers in a test environment, monitoring a guardrail appropriate for the feature.
      • In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
    • Key result WE3.10: By the end of Q4, perform at least one experiment per platform (web and apps) that shows a practically significant improvement in logged-out casual reader retention or another indicator metric over control (with casual reader retention defined as 21-day cumulative retention for web, and 14-day cumulative retention for apps).
      • We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

---

السلامة والأمان (تجارب ويكي 4)

• الهدف: تعمل أنظمتنا على توفير حماية أفضل لحسابات محررينا ومعلوماتهم الخاصة بشكل افتراضي، مع توفير مسارات أكثر للمحررين والمستخدمين ذوي الصلاحيات الممتدة لمنع النشاط المسيء والاستجابة له. ناقش
• النتائج الرئيسة لتجارب ويكي 4.1: نشر نظام عملي وفعّال للإبلاغ عن الحوادث عبر جميع مشاريع الويكي الخاصة بنا، يكون مُستخدمًا ومقبولًا لمجتمعاتها، بحلول نهاية الربع الثاني.
  • إن ضمان سلامة المستخدمين ورفاهيتهم هو مسؤولية أساسية لمنصتنا. لدى العديد من السلطات القضائية لوائح تتطلب من المنصات الإلكترونية مثل منصتنا مراقبة المضايقات والتنمر الإلكتروني والمحتوى الضار الآخر على منصتها واتخاذ إجراءات ضده. وقد يؤدي الفشل في معالجة هذه الأمور إلى تعريض المنصات للمسؤولية القانونية والعقوبات التنظيمية.
  • نسعى إلى تمكين مستخدمينا من الإبلاغ عن التهديدات الفورية بالضرر من خلال آلية إبلاغ سهلة الاكتشاف وبديهية، لضمان قدرتنا على معرفة مثل هذه الحوادث واتخاذ إجراءات فورية عند الضرورة. هذه خطوة نحو جعل مستخدمينا يشعرون بالأمان عند المساهمة في منصتنا. وننفذ ذلك عن طريق نظام للإبلاغ عن الحوادث في مشاريع الويكي الخاصة بنا.
• النتائج الرئيسة لتجارب ويكي 2.4: تعزيز دقة وفعالية أدوات مكافحة الإساءة، عن طريق نشر تحسينين بحلول نهاية الربع الثاني.
  • نحن والمجتمع بحاجة إلى تطوير قدرتنا على اكتشاف الأنشطة الزائفة والخبيثة على مشاريع الويكي ومنعها. يتحقق ذلك عبر تعزيز عدد وجودة الإشارات المتاحة للمنصة، ودمج هذه الإشارات في الأدوات المخصّصة للمستخدمين ذوي الصلاحيات الممتدة، إضافة إلى تحديد المواضع التي يمكن فيها فرض قيود آلية على النشاط المشبوه بطريقة آمنة.
  • نرى فرصًا لتحسين إمكانية الوصول إلى ويكيبيديا ومشاريع الويكي في الوقت نفسه. ومن الأمثلة على ذلك العمل على استبدال نظام اختبار الكابتشا التقليدي الذي تديره المشاريع ذاتيًا، والذي يمنع المستخدم من تسجيل الدخول حتى يحل اللغز، بخدمة تعتمد على تسجيل المخاطر التي نادرًا ما تتطلب تحققًا مباشرًا من المستخدم. تعمل هذه الخدمة بصمت على تصنيف الحسابات بحسب مستوى الاشتباه، مما يتيح لنا تعطيل بعض الوظائف عند الحاجة، ويجعل حالة الحساب مرئية للمشرفين ذوي الامتيازات العالية لدعمهم في أداء مهامهم.
  • تعتمد مشاريع ويكيميديا بشكل كبير على حجب عناوين بروتوكول الإنترنت للحد من الإساءة الصادرة عن الجهات الفاعلة السيئة. إلا أن هذا الأسلوب بات أقل فعالية مع مرور الوقت، كما أنه يسبب ضررًا للمستخدمين ذوي النية الحسنة الذين يتأثرون بحجب العناوين أو النطاقات.

وفي إطار هذه النتائج الرئيسة، نركّز على تحسين القدرات الحالية وتطوير أدوات جديدة تسمح باستهداف الجهات المسيئة بدقة وفعالية أكبر، مع الحد من الأضرار الجانبية الناتجة عن حجب عناوين ونطاقات بروتوكول الإنترنت.

• • لقياس فعاليتنا، سنعتمد على الملاحظات النوعية من المتطوعين المشاركين في مكافحة الإساءة، وعلى مؤشرات كمية تشمل ما يلي: معدل نشر حجب عناوين بروتوكول الإنترنت، ومستوى اعتماد آليات التخفيف التي تعتمد على سمعة عنوان بروتوكول الإنترنت وإشارات المتصفح، ومعدل التفاعلات الشبيهة بالبشر عند حجب مستخدم ما، ومدى اعتماد الإشارات الجديدة في أدوات مكافحة الإساءة.
  • يشمل العمل في هذه النتائج الرئيسة مجموعة واسعة من التحسينات الأمنية، من بينها تطوير قدرات اكتشاف أنشطة الحسابات الدمية وجهود التحايل على الحظر والحد منها. ويهدف العمل أيضًا إلى إظهار المعلومات المتعلقة باحتمالية حدوث أضرار جانبية، وتعزيز اكتشاف الروبوتات، وتوفير الإشارات اللازمة للمتطوعين العاملين في مكافحة الإساءة. وتتضمن التحسينات كذلك رفع كفاءة واجهات أدوات مكافحة الإساءة، وتحسين المقاييس المرتبطة برصد الإساءة، وتزويد مدققي المستخدمين باقتراحات تساعدهم على التحقيق في الأنشطة المشبوهة للحسابات.
• النتائج الرئيسة لتجارب ويكي 3.4: خفض عدد الهجمات واسعة النطاق التي تحتاج إلى تدخل بشري من مهندسي موثوقية الموقع بنسبة 50 في المئة مقارنة بالسنة المالية السابقة، وذلك بحلول نهاية الربع الرابع.
  • إن تطوّر مشهد الإنترنت، بما في ذلك انتشار شبكات الروبوتات واسعة النطاق وتكرار الهجمات، جعل الأساليب التقليدية للحد من الإساءة واسعة النطاق غير فعّالة. يمكن لمثل هذه الهجمات أن تجعل مواقعنا غير متاحة من خلال إغراق بنيتنا التحتية بسيل من الطلبات، أو عبر إرباك قدرة مجتمعنا على مواجهة التخريب واسع النطاق. كما تفرض هذه الهجمات ضغوطًا كبيرة وغير معقولة على المحررين ذوي الامتيازات العالية وعلى مجتمعنا التقني.
  • إننا بحاجة ماسة إلى تحسين قدرتنا على اكتشاف مثل هذه الهجمات تلقائيًا، والصمود في وجهها، والتخفيف من حدتها أو إيقافها.
  • سنركّز هذا العام على أتمتة اكتشاف عناوين بروتوكول الإنترنت والشبكات التي تشارك بانتظام في الهجمات، وتقليل مستوى التحميل الذي تستطيع هذه الجهات الضارة فرضه على أنظمتنا بشكل مستمر.
• النتائج الرئيسة لتجارب ويكي 4.4: نشر الحسابات المؤقتة في مئة في المئة من مشاريعنا، بحيث تصبح البيانات الشخصية التعريفية للمحررين غير المسجلين متاحة لأقل من 0.1 في المئة من المستخدمين، وذلك بحلول نهاية الربع الثاني.
  • تهدف الحسابات المؤقتة إلى تعزيز خصوصية المحررين غير المسجلين وحمايتهم، وذلك من خلال حجب بياناتهم الشخصية التعريفية مثل عنوان بروتوكول الإنترنت عن الظهور العلني، وحصر الوصول إليها على من يحتاجونها فقط لأغراض المراقبة. وإلى جانب كون هذا الإجراء خطوة مهمة لتعزيز سلامة المستخدم، فإنه يعد أيضًا عنصرًا أساسيًا للامتثال لمتطلبات تنظيمية متعددة.
• النتائج الرئيسة لتجارب ويكي 5.4: تقييم تأثير الذكاء الاصطناعي التوليدي على الثقة والسلامة، وتحديد تدخلات المنتج اللازمة للاستفادة من الفرص ومنع التهديدات التي قد تطال مشاريع ويكيميديا، وذلك بحلول نهاية الربع الثالث.
  • يتزايد استخدام الذكاء الاصطناعي، ولا سيما الذكاء الاصطناعي التوليدي، بوتيرة سريعة على الإنترنت. ويصاحب هذا الانتشار ظهور فرص جديدة تتعلق بالثقة والسلامة، إلى جانب بروز تهديدات محتملة. فعلى سبيل المثال، أصبح إنشاء المحتوى أسهل وأقل تكلفة، بينما بات الإشراف على هذا المحتوى أكثر إرهاقًا. وبالمثل، باتت عملية إجراء الأبحاث تتطلب جهدًا أقل بكثير، إلا أن حالات الهلوسة التي ينتجها الذكاء الاصطناعي أصبحت أصعب في الاكتشاف.
  • يهدف هذا المشروع إلى البناء على تقييم الأثر الحقوقي لتعلّم الآلة والذكاء الاصطناعي، من خلال دراسة تأثير الذكاء الاصطناعي على جوانب الثقة والسلامة داخل منظومة ويكيميديا، ويشمل ذلك ما يلي:
    • التشاور مع المستخدمين ذوي الصلاحيات الممتدة
    • تحديد أمثلة على الإساءة المدعومة بالذكاء الاصطناعي التوليدي، ووضع التدابير الممكنة للحد منها.
    • تحديد فرص تعلّم الآلة التي يمكن أن تخفف العبء عن المستخدمين ذوي الصلاحيات الممتدة.
    • إجراء تجارب لفهم ما يجب أن نركز عليه، وذلك لتحقيق أكبر تأثير ممكن.
• النتائج الرئيسة لتجارب ويكي 4.6: فرض تقييد تقني يضمن أن مئة في المئة من الامتيازات التي تتيح للمستخدمين اتخاذ إجراءات حساسة تتعلق بالأمن أو الخصوصية لا يمكن تنفيذها إلا من خلال حسابات فعّلت المصادقة الثنائية، وذلك بحلول نهاية الربع الرابع.
  • نحتاج إلى رفع مستوى أمان حسابات المستخدمين في مشاريع الويكي، وخاصة أولئك الذين يملكون صلاحيات حساسة. ويشكّل اشتراط تفعيل المصادقة الثنائية لأداء أي إجراء حساس محورًا أساسيًا في هذا الجانب. يتركّز العمل هنا على بناء نظام أكثر قابلية للتوسع لفرض الامتيازات، بحيث تُلغى الحاجة إلى التدقيق والتنفيذ اليدوي للمصادقة الثنائية، مع توسيع نطاق الامتيازات التي يشترط استخدامها تفعيل المصادقة الثنائية على المنصة.
  • كجزء من هذا العمل، يجري تحسين أنظمة المصادقة واستعادة الحسابات بحيث يتمكّن كل من مؤسسة ويكيميديا والمستخدمين من دعم موقف أكثر صرامة تجاه المصادقة الثنائية بسهولة أكبر. يتوسع نطاق الإتاحة العامة للمصادقة الثنائية عبر المنصة، بحيث يصبح بإمكان كل مستخدم تفعيلها عند الحاجة، مع ضمان تفعيلها قبل منح أي صلاحيات حساسة. كما يجري تقليل العبء التشغيلي الواقع على أنظمة الدعم واستعادة الحسابات، الأمر الذي يسهم في تبسيط عمليات إعادة الضبط والاسترداد الخاصة بتسجيل الدخول. بالإضافة إلى ذلك، تُحسَّن سهولة استخدام تطبيقات المصادقة الثنائية عبر توفير خيارات إضافية تُمكّن المستخدمين من تأمين حساباتهم وتجنب حالات قفل الحساب غير المقصودة.
• Key result WE4.7: Publicly conclude our bot detection trial, by the end of Q4.
  • This KR is a focused, one-quarter effort to evaluate the results of this trial, to decide inside WMF about whether to maintain and expand this system across our wikis, and to publicly publish the results of the trial and our path forward.
• Key result WE4.8: Simplify the patrolling of temporary accounts, by making it quicker to identify and address abuse, by the end of Q4.
  • The purpose of temporary accounts is to continue to safely support participation from good-faith unregistered editors. However, some anti-vandalism workflows became more complicated by the release of temporary accounts. To ensure temporary account vandalism can be sustainably managed, we will make it easier and quicker for patrollers to understand and respond to temporary-account activity, both good- and bad-faith.
    We will surface clusters of related temporary accounts to patrollers, while also exploring other interventions that could improve early identification and rapid response.
• Key result WE4.9: Empower volunteer investigators to deter and block more inauthentic activity on wikis where they actively review flagged accounts, as measured by a 20% increase in the rate of mitigating actions on those accounts, by the end of Q4.
  • For Q3 and Q4, recognizing the strategic potential that Suggested Investigations has demonstrated, we will invest in deploying new signals independent of bot detection, and will set aside time to prioritize a variety of efficiency and quality-of-life features that have been requested by SI users since its original MVP release.
• Key result WE4.10: By the end of Q4, we'll increase hCaptcha bot detection coverage from 18% to 100% of account creations and from 18% to 90% of higher risk edits.
  • In Q3, we concluded our hCaptcha trial, during which we enabled hCaptcha during account creation, and later expanded it to include new users on the desktop wikitext editor, on eight large Wikipedias, including English Wikipedia. Based on the results of that trial, we’re now expanding hCaptcha to more editing interfaces and more wikis. Our main priority will be expanding what we currently have to all wikis, but we’ll also focus on new avenues to (discussion tools, uploads), as well as categories of users whose actions will be protected by hCaptcha.
• Key result WE4.11: By the end of Q4, complete an IRS trial on enwiki with a graduated deployment, reaching at least 50% of logged in users and resulting in 5 new reporting metrics.
  • We are trialing an incident reporting system (IRS) on English Wikipedia that is designed to help less experienced community members more easily report potentially bad behavior to the community-managed place that can best deal with it. For more rare and severe cases, it also provides a form to directly report imminent threats of harm to the WMF Trust and Safety team.
  • This trial will be primarily focused on calibrating the first use case: helping editors report potentially bad behavior, without overloading the system.
  • During the trial, we will focus on monitoring the volume of new reports, checking that reports are routed correctly, and identifying any immediate issues. We will be coordinating closely with all community members to fix bugs if they arise, and to otherwise streamline the process. For example, we are exploring some ways to tighten the user experience and help people more directly submit their reports, which we may deploy and measure during the trial as well.
• Key result WE4.12: By end of Q4, we will have defined a detection pipeline for classifiers that automatically detect English Wikipedia policy-prohibited content, and evaluated the impact of at least one classifier detecting at least one type of prohibited content, validated against community datasets, on its potential for reducing volunteer workload.
  • We want to support volunteers and UWERs by reducing work needed to remove harmful content from the projects, to enable volunteers to handle more difficult cases.
  • In this quarter, we want to gain experience in defining repeatable processes for building detection pipelines for different types of content, and take first steps to evaluate these pipelines safely on large projects (A/B tests, log-only mode deployments, etc). We will start with a focus on content that should very likely be suppressed, such as threats, or disclosure of personal information.
  • We plan to expand on these initiatives in FY26-27 work as part of an overhaul of anti-abuse tooling that supports UWERs and volunteers in reducing the time to mitigation for bad-faith activity.

---

الاستخدام المسؤول للبنية التحتية (تجارب ويكي 5)

• الهدف: إتاحة المحتوى المعرفي للمطورين وللمستخدمين الذين يعيدون استخدامه عبر مسارات منظَّمة، بما يضمن استدامة البنية التحتية وإعادة استخدام المحتوى بطريقة مسؤولة. ناقش
  • سياق الهدف: سيركّز هذا الهدف على إنشاء مسارات لإعادة استخدام المحتوى بمسؤولية.
  • تستضيف ويكيميديا أكبر مجموعة من المعرفة المُنظَّمة بشريًا على الإنترنت، وهو ما جعل بنيتنا التحتية المعرفية وجهة بالغة الأهمية ليس فقط للبشر، بل أيضًا للأنظمة التي تستهلك البيانات تلقائيًا. يُعاد استخدام محتوانا في محركات البحث، ومنصات التواصل الاجتماعي، ومواقع التجارة الإلكترونية، ومع انتشار الذكاء الاصطناعي أصبح محتوى ويكيميديا جزءًا أساسيًا في تدريب النماذج الكبيرة لتعلّم الآلة. تحصل الجهات المستهلكة للبيانات على محتوى مشاريعنا عبر التنقيب الآلي في صفحات الويب، أو من خلال قنوات الوصول المنظمة، أو عن طريق تنزيل المحتوى دفعة واحدة، وغالبًا من دون أي إسناد للمصدر. وفي ظل الزيارات غير الموثقة، يصعب التمييز بدقة بين المستخدم البشري والأنظمة الآلية، الأمر الذي يحد بشكل كبير من قدرتنا على تعزيز وإلزام الاستخدام المسؤول لبنيتنا التحتية. يطرح هذا أسئلة مهمة: كيف ندعم مجتمع المتطوعين ونحمي وصولهم، وفي الوقت ذاته نضع حدودًا واضحة أمام الاستهلاك الآلي للمحتوى؟ كيف نوجّه الجهات التي تعيد استخدام المحتوى إلى قنوات مفضلة ومدعومة؟ ما الإرشادات التي نحتاج إليها لضمان إعادة استخدام مسؤولة للمحتوى؟ وكيف نصل إلى تجربة متماسكة للمطورين تلبّي احتياجات المتطوعين وفرق العمل والجهات التي تعيد استخدام المحتوى؟ قد لا تكون هذه الأسئلة جديدة بالكامل، لكنها أصبحت أكثر إلحاحًا من أي وقت مضى. فمنذ عام 2024 نلاحظ زيادة حادة في حجم الطلبات على بنيتنا التحتية، ويأتي الجزء الأكبر منها من روبوتات التنقيب التي تجمع بيانات تدريب للأنظمة والمنتجات المعتمدة على الذكاء الاصطناعي. هذا الضغط المتزايد على بنيتنا التحتية غير قابل للاستمرار، ويهدد قدرة البشر على الوصول إلى المعرفة. أصبح من الضروري التحرك الآن لإعادة التوازن وضمان قدرة مشاريع ويكيميديا على خدمة مهمتنا بشكل فعّال ومستدام.
    • النتائج الرئيسة لتجارب ويكي 1.5: بحلول نهاية الربع الرابع، القدرة على إسناد خمسين في المئة من الطلبات الموجّهة إلى قنوات الوصول البرمجي إلى مطوّر أو تطبيق معروف.
      • لدينا حاليًا قدرات محدودة لتحديد الجهات المسؤولة عن الزيارات المؤتمتة، وعلى خلاف ما هو متاح داخل مشاريع الويكي، تتوفر لنا خيارات أقل للتواصل مع المستخدمين الخارجيين أو لتنظيم مستوى وصولهم. وقد شهدنا ارتفاعًا كبيرًا في حجم الزيارات المؤتمتة القادمة من خارج مشاريع الويكي، وهو ارتفاع غير قابل للاستمرار ويهدد قدرة البشر على الوصول إلى المعرفة. يتمثل هدفنا في رفع نسبة الزيارات المؤتمتة التي تُنسب إلى حساب معروف، وذلك عبر اشتراط أساليب موثوقة للمصادقة ومنح التراخيص وفق مستويات وصول متدرجة للتنقيب واسع النطاق وللاستخدام المنظّم لقنوات الوصول إلى البيانات. ويساعدنا هذا في معرفة الجهات التي تعيد استخدام المحتوى على نطاق واسع، مما يتيح حماية بنيتنا التحتية وتحسين حوكمة الاستخدام العادل، مع تلبية احتياجات هذه الجهات بفعالية أعلى. كما سنستكشف طرقًا جديدة لدعم المجتمع التقني، من خلال توفير تجربة أكثر تماسكًا للمطورين تحافظ على الوصول التفضيلي لأعضاء المجتمع، وتمنح المطورين وظائف جديدة تساعدهم على بناء أدوات ومنتجات مفيدة.
    • النتائج الرئيسة لتجارب ويكي 2.5: بحلول نهاية الربع الرابع، دعم سبعين في المئة من نقاط نهاية واجهة برمجة تطبيقات الويب الخاصة بويكيميديا عبر بنية تحتية مشتركة.
      • نهدف إلى تحسين تجربة المطورين واستدامة مسارات التطوير من خلال توفير واجهات برمجة تطبيقات ويب أكثر اتساقًا واستقرارًا وسهولة في الاكتشاف لجميع مطوري ويكيميديا. ويجري تبسيط عروض واجهات برمجة التطبيقات عبر بناء بنية تحتية أكثر مركزية للقدرات الأساسية، مما يتيح اعتماد مسارات وحوكمة موحّدة تشمل: المواصفات والتوثيق، وتحديد هوية المطور والتحكم في الوصول، وتطبيق سياسات برمجة التطبيقات، والتوجيه، والترقيم، ومعالجة الأخطاء.

وبفضل هذا التبسيط، يصبح تطوير الأدوات والروبوتات والمشاريع البحثية والميزات الداعمة لمهمة ويكيميديا أسرع وأكثر سهولة واستمتاعًا. كما يدعم هذا النهج مستقبل المهمة متعدد الأجيال من خلال تقليل تكاليف صيانة البنية التحتية، وتعزيز القدرة على مراقبة الوصول ومكافحة الجهات المسيئة، وبناء مجتمع مطورين أقوى وأكثر تماسكًا.

• • • النتائج الرئيسة لتجارب ويكي 3.5: بحلول نهاية الربع الرابع، نشر إطار عمل جديد للإسناد عبر الويب والتطبيقات والمساعدات الصوتية والنماذج اللغوية الكبيرة، وربطه بمواقع ويكيميديا، مع تقديم عرضين توضيحيين لإعادة الاستخدام يحققان تفاعلًا قابلًا للقياس، إضافة إلى اعتماد شريك خارجي واحد لممارسات الإسناد الأفضل.
      • لزيادة الإسناد المناسب لمحتوى ويكيميديا، يجري تقديم إرشادات واضحة لأفضل الممارسات التي تدعم إعادة الاستخدام بمسؤولية. ويشمل ذلك إعداد إطار عمل للإسناد عبر المنصات الرئيسة مثل الويب، والتطبيقات، والصوت، والوسائط المتعددة، إلى جانب تقديم مثالين عمليين على الأقل يبرزان كيفية تطبيق استخدامات نموذجية لمحتوى ويكيميديا. وتتضمن مخرجات هذا العمل تشجيع المؤسسات الإعلامية على الإشارة إلى صور ويكيميديا كومنز، وتحفيز محركات البحث على عرض بيانات ويكيميديا ذات الصلة بفاعلية أكبر، إضافة إلى دمج معرفة ويكيبيديا في المساعدات المعتمدة على الذكاء الاصطناعي بطرق شفافة ومسؤولة تعزّز الثقة في موثوقيتها. إن تحسين ممارسات الإسناد لا يرفع الوعي العام ويعيد التفاعل مباشرة إلى مشاريع ويكيميديا فحسب، بل يؤسس أيضًا لأساليب مسؤولة ومبتكرة لإعادة دمج المعرفة، ويسهم في الحد من سوء الاستخدام.
    • النتائج الرئيسة لتجارب ويكي 4.5: خفض حجم الزيارات الناتجة عن روبوتات التنقيب بنسبة 20 في المئة عند قياسها بمعدل الطلبات، وبنسبة 30 في المئة عند قياسها بعرض النطاق الترددي.
      • كان التنقيب في صفحات الويب جزءًا ثابتًا من بيئة الإنترنت منذ سنوات، إذ اعتمدت محركات البحث على ويكيبيديا لتزويد مستخدميها بالمعلومات لعقود طويلة. ومع ذلك، ظهر في الآونة الأخيرة دافع أقوى لتنقيب بيانات مشاريع ويكيميديا: فهي تمثل أكبر مجموعة معرفة منسّقة ومتعددة اللغات على الإنترنت، وتشكل مصدرًا أساسيًا لتدريب النماذج اللغوية الكبيرة. وينطبق هذا على محتوى ويكيبيديا الموسوعي وعلى مستودع الوسائط المتعددة، ويكيميديا كومنز، الذي يُعد موردًا بالغ الأهمية لنماذج تعلّم الآلة التي تولّد الصور.
      • ونتيجة لذلك، شهدنا خلال العام الماضي ارتفاعًا كبيرًا في حجم الزيارات القادمة من روبوتات التنقيب، إضافة إلى زيادة في حوادث استقرار الموقع المرتبطة بها. اضطر مهندسو موثوقية الموقع في العديد من الحالات إلى فرض قيود على معدل الزيارات أو حظر الروبوتات الزاحفة بشكل فردي بهدف حماية البنية التحتية. وقد أصبح التنقيب واسع الانتشار إلى درجة أن حجم النطاق الترددي الصادر ارتفع بنسبة خمسين في المئة في عام 2024. والأهم من ذلك، أظهر تحليل حديث أن ما لا يقل عن خمسة وستين في المئة من أكثر الطلبات تكلفة، وهي الطلبات التي لا يمكن خدمتها من خوادم التخزين المؤقت ويتم التعامل معها مباشرة من قواعد البيانات الرئيسية، تنفذها الروبوتات.
      • مواردنا الحاسوبية محدودة للغاية مقارنة بحجم الزيارات التي نستقبلها، ولذلك يصبح من الضروري تحديد أولويات الجهات التي نخدمها بهذه الموارد. ونهدف في هذا السياق إلى إعطاء الأفضلية للاستخدام البشري، مع التركيز على دعم مشاريع ويكيميديا والمساهمين فيها باستخدام مواردنا المحدودة.

---

تسريع المسار إلى نتائج المنتج (تجارب ويكي 6)

• الهدف: يتمكن مطورو ويكيميديا من نشر منتجاتهم للمستخدمين النهائيين بسرعة وثقة. ناقش
  • سياق الهدف: لكي يحقق مطورو ويكيميديا الركائز الاستراتيجية الأربعة بفعالية، ينبغي أن يتركز وقتهم وجهدهم في الأنشطة ذات التأثير العالي التي تسهم في تقديم منتجات عالية الجودة بأقصر وقت ممكن. إن مسارات العمل المعقدة بصورة مفرطة، وغياب الأدوات الموحدة، واعتماد مكوّنات نظام غير مستدامة، كلها عوامل تعيق الوصول إلى تلك النواتج.
  • يبني هذا العمل على الزخم الذي اكتسبناه خلال الخطتين السنويتين الأخيرتين في تطوير ميديا ويكي كمنصة وفي البرمجيات التي تدعم تطويرها ونشرها. سيركز العمل لهذا العام على توفير بيئات مطورين أكثر موثوقية، وتبسيط سير عمل ما قبل الإنتاج، وتقليل مخاطر المنصة والبنية التحتية.
    • النتائج الرئيسة لتجارب ويكي 6.1: بحلول نهاية الربع الرابع، يتم تقليل عدد الأخطاء التي تعيق عملية النشر وتتجاوز مشاريع الويكي الاختبارية بنسبة 10%.
      • ي عام 2024، اضطر المطورون إلى إعادة النظر في العمل في 144 مناسبة بسبب حالة طوارئ منعت نشر ميدياويكي. في العديد من تلك الحالات، تم اكتشاف الأخطاء بعد النشر على مشاريع الويكي الاختبارية، مما يعني أن المشكلة وصلت إلى جمهور محتمل يقدر بالمليارات من المستخدمين. لا يمكننا التحكم في وجود الأخطاء، لكن اكتشافها في وقت مبكر يعني أننا سنحتاج إلى "عمل بطولي" أقل. كما سيعزز ذلك ثقة المطورين في أن شيئًا ما عندما ينتقل إلى الإنتاج الفعلي، لن تحدث مشكلة.
      • سنتلقط هذه الأخطاء في وقت أبكر من خلال توفير البيئات التي يحتاجها المطورون لـ نشر واختبار الكود الخاص بهم بثقة على مدار دورة حياة التطوير والنشر بأكملها. كما يجب علينا ضمان ألا تأتي هذه التحسينات على حساب سرعة عمل المطورين.
    • النتائج الرئيسة لتجارب ويكي 2.6: بحلول نهاية الربع الرابع، يمكن تنفيذ 4 خطوات من قائمة مراجعة جاهزية الإنتاج دون تدخل من مهندسي موثوقية الموقع
      • يعتمد نشر خدمة أو ميزة جديدة في بيئة الإنتاج حاليًا على قائمة من 24 خطوة، والتي تتطلب كل خطوة منها عادةً دعمًا من مهندسي موثوقية الموقع. لقد أنشأنا برنامج سفراء مهندسي موثوقية الموقع للتدخل في وقت أبكر من دورة التطوير وبناء القدرات داخل فرق التطوير نفسها، ولكن العديد من المهام يجب أن تكون قابلة للخدمة الذاتية بالكامل. حاليًا، يرقى هذا الأمر إلى عمل يدوي، ومتكرر، وقابل للأتمتة، ويتوسع بشكل خطي مع عدد فرق التطوير. هذا غير مستدام لفريق مهندسي موثوقية الموقع على المدى الطويل.
      • في الماضي، تم تجرید الكثير من هذا العمل عن فرق التطوير من خلال الحفاظ على مجموعة من المكتبات المشتركة والممارسات الأفضل للتفاعل مع منصتنا. تم التخلي عن هذه المكونات عندما انتقلنا إلى بنيتنا التحتية الجديدة القائمة على ولم يكن لها بديل مباشر. من خلال توفير مكتبات مماثلة، وتوثيق، وتدريب ينطبق على الطريقة التي نُنشئ وننشر بها الأشياء اليوم، نعتقد أنه يمكننا تقليل حجم التدخل المطلوب من مهندسي موثوقية الموقع قبل نشر خدمة أو ميزة جديدة في بيئة الإنتاج.
    • النتائج الرئيسة لتجارب ويكي 3.6: بحلول نهاية الربع الرابع، يتم عرض 100% من مشاهدات صفحات ويكيبيديا عبر بارسويد (Parsoid).
      • يوفر بارسويد قدرات معززة لـ تطور نصوص الويكي وتحقيق الاستدامة المستقبلية للمنصة. إن الحفاظ على مُحللين نحويين متزامنين غير مستدام على المدى الطويل، لأنه يزيد من الديون التقنية والتعقيد. بالإضافة إلى ذلك، فإن نجاح بعض المشاريع الجديدة مثل ويكي دوال يعتمد على توفّر بارسويد على نطاق واسع.
      • لقد كنا نعمل على توسيع نطاق النشر للمشاريع الأصغر، وسنكون هذا العام جاهزين لمشاريع ويكيبيديا. إن خدمة جميع قراءات مشاهدات صفحات ويكيبيديا عبر بارسويد هي أهم إنجاز تالٍ لنا. وبالإضافة إلى عملية النشر نفسها، يشمل هذا العمل أيضًا حل مشكلات الأداء والتواصل بفعالية بشأن التأثير على القراء والمحررين.
    • النتائج الرئيسة لتجارب ويكي 4.6: بحلول نهاية الربع الثاني، يتم التخفيف من خطرين محددين على الأقل يهددان قدرتنا على الاستمرار في نشر أو توسيع نطاق مشاريع الويكي، أو تقليل هذين الخطرين إلى مستوى مقبول
      • من خلال مبادرات مستهدفة قليلة، سنعمل على تقليل أو التخفيف من العديد من مخاطر قابلية التوسع أو الموثوقية أو الأمن التي حددناها كتهديد محتمل لنمو واستدامة منصتنا ومشاريعنا العامة.
      • على سبيل المثال، سنقوم بإعادة هيكلة البنية الأساسية لقواعد بيانات ويكيميديا كومنز لضمان أن نموها لن يكون مقيدًا بقدرة الأجهزة الخادمة المتاحة خلال السنوات القليلة المقبلة. كما سنقوم بتحديث معالج النص التشعبي (PHP)، وهي لغة البرمجة التي تشغل ميدياويكي والخدمات ذات الصلة، إلى إصدار أكثر حداثة. من المرجح أن تتطلب المخاطر الأخرى المحددة تطبيق إجراءات أمنية إضافية لـ حماية وتقوية بنيتنا التحتية
    • Key result WE6.5: By the end of Q4, determine the feasibility of and next steps for scalable cross-wiki code collaboration and logged-in reader support.
      • One of the central features of wikis is collaborative content creation. In the context of the Wikimedia movement, the collaboration needs are very specific to the evolution of the projects and the challenges that arise at the scales that some of the larger projects operate in.
      • Code collaboration (cross-wiki or on-wiki) is a legitimate need and should be accommodated. This is less a single problem and more a problem space that includes several overlapping problems around code (templates & modules primarily) and solving problems in this space requires shared understanding around priorities that are most impactful.
      • With an experimentation mindset, we're exploring a leaner approach to test shared code libraries that could improve cross-wiki collaboration in a small and controlled environment. This means we will go through a phase of technical feasibility and scope exploration to approach the experiment roll-out in small iterations to collect insights that can help us decide how we want to tackle the aforementioned problem. Our intention is to demonstrate our learnings and progress in the Wikimedia Hackathon 2026.
      • Similarly, if we want to improve the experience of logged-in users, we need to know where the performance gains are, what product work will make demands, and what a sustainable approach will look like for this work next FY. Research in this area will set us up for starting platform work quickly next FY.
    • Key result WE6.6: By end of Q4, developers are able to get the results of MediaWiki Core CI in under 10 minutes.
      • Our current median CI cycle time baseline is over 24 minutes while a DevEx industry standard for high performing teams is 10 minutes or less.
      • To bridge this gap, we're planning to optimize the CI workflows, address main bottlenecks such us browser tests by optimizing how we run them, the underlying testing framework and its configuration.
      • By slashing median CI wait times from 24 to 10 minutes we ensure the rapid feedback loop needed to test and fix issues quickly, significantly accelerating iteration speed. Additionally, improving this metric speeds up merge times, shortening the time between a change being ready and being available for deployment, which directly contributes to the top-level OW5 metric of making it "easier and faster to build products".
    • Key result WE6.7: By end of Q1 of 2026-27 fiscal year, developers are able to test MediaWiki code in production within 1 day of it being merged.
      • Currently, on average developers can test their code on production ~4 days after merging. By shrinking this time, developers can test sooner, and by improving test environments they will have more confidence that their tests will result in fewer bugs reaching production.

---

خدمات البيانات والإشارات

البيانات المترية (خدمات البيانات والإشارات 1)

• الهدف (Objective): يستخدم صناع القرار بيانات مترية أكثر التي يمكن الوثوق بها وفي الوقت المناسب لـ توجيه قرارات المنتج والقرارات الاستراتيجية. ناقش
  • سياق الهدف: نستخدم البيانات المترية لتوجيه قرارات المؤسسة بشأن أين نركز جهودنا لخدمة الحركة على أفضل وجه. ومع ذلك، فإن بعض خطوط نقل البيانات لدينا عرضة للتوقف، مما يتسبب في تأخير التسليم. عندما تظهر مشكلات في البيانات، يكون وقت تحديدها وحلها طويلاً جدًا. بالإضافة إلى ذلك، فإن العديد من مجموعات بياناتنا ليست مُحسَّنة لـ الاستكشاف السهل للتوجهات وتفتقر إلى الأبعاد التي ظهرت كعناصر مهمة لـ تفسير البيانات. هذه المشكلات تبطئ وتحد من قدرتنا على تقييم البيانات المترية.
  • في السنة المالية 2025-2026، سنركز على حالات استخدام محددة من الخطة السنوية لـ سد فجوات جودة البيانات في خطوط النقل الحالية، وإعداد البنية التحتية والعمليات لـ مراقبة وحل مشكلات جودة البيانات، وتوفير الأدوات التي تُمكّن صانعي القرار من فهم التوجهات.
  • أحد حالات الاستخدام تتعلق بكيفية قياسنا لحجم زيارات البشر وروبوتات الإنترنت. لقد جعل صعود الزيارات المؤتمتة في العامين الماضيين من الصعب فهم مدى تفاعل البشر ومساهمتهم في مشاريع ويكيميديا. نهدف إلى تحسين قدرتنا على تقييم أنماط زيارات البشر والربوتات، والتي تُعد مدخلات حاسمة لقرارات التخطيط والمنتج.
    • النتائج الرئيسة لخدمات البيانات والإشارات 1.1: بحلول نهاية الربع الأول، يتمتع المحللون الذين يستخدمون البيانات المترية لمشاهدات الصفحات بإمكانية الوصول إلى مقاييس أساسية لجودة البيانات ومقاييس لأداء المنهجيات الاستدلالية للكشف عن الزيارات المؤتمتة.
      • من خلال الفرضيات التي يتم استكشافها في هذه النتيجة الرئيسة، نهدف إلى تحديد الفجوات في قواعد الاستدلال الحالية لدينا للكشف التلقائي عن حركة المرور وفهم الأماكن التي تفشل فيها في تصنيف حركة مرور مشاهدات الصفحات بشكل صحيح. ستوجه هذه الرؤى التحسينات في خطوط النقل التي تولّد وتصنّف البيانات المترية لمشاهدات الصفحات. بالإضافة إلى ذلك، سنقوم بتحديد البيانات المترية لجودة البيانات لـ مراقبة وقياس التحسينات في دقة البيانات.
      • ستمهد هذه النتيجة الرئيسة الأساس لـ نتيجة رئيسة تابعة تركز على تنفيذ تحسينات خط أنابيب البيانات الضرورية التي تم تحديدها هنا. وستكون مقاييس جودة البيانات التي تأسست في هذه المرحلة بمثابة معايير قياس لتقييم فعالية تلك التحسينات المستقبلية.
    • النتائج الرئيسة لخدمات البيانات والإشارات2.1: بحلول نهاية الربع الأول، سيتم إتاحة محتوى مجموعة بيانات سجل محتوى ميدياويكي عبر تصدير ملفي مع ضمانات تسليم أسبوعية (اتفاقيات مستوى الخدمة). الملف المُصدَّر ستكون بياناته مثل البيانات الموجودة في نظام التصدير القديم لملفات XML (الإصدار الأول).
      • كان هدف النتيجة الرئيسة رقم 4.1 للسنة المالية 2025/2024 هو إزالة الاعتماد على مجموعات البيانات mediawiki_wikitext_history و mediawiki_wikitext_history_current التي يتم تحديثها شهرياً لـ خطوط النقل الثلاثة الأكثر صلة في المراحل النهائية، وتوفير مجموعة بيانات بديلة ذات أهداف مستوى خدمة أسبوعية مضمونة.
      • على الرغم من أن النتيجة الرئيسة رقم 4.1 للسنة المالية 25/24 ساعدت في تخفيف مشكلات الموثوقية لـ خطوط معالجة البيانات الأكثر اعتمادًا،، إلا أنه لا تزال هناك خطوط نقل متبقية تستخدم مصدر الإدخال القديم غير الموثوق به. ينبغي ترحيل هذه الخطوط أيضًا، بالإضافة إلى ترحيل مصدر الإدخال المستند إلى الملفات إلى مجموعة بيانات سجل النص الويكي نفسها.
    • النتائج الرئيسة لخدمات البيانات والإشارات 1.3: بحلول نهاية الربع الثاني، سيقوم اكتشاف الروبوتات بـ دمج إشارة إضافية واحدة وتوليد تنبيهات آلية للحالات الشاذة
      • تعمل الفرق في المؤسسة بأكملها على اتخاذ قرارات بشأن المنتجات والتمويل بناءً على قدرتها على تحديد الفرق بين القراءة البشرية والزيارات المؤتمتة. وتُعد منصة البيانات هي المستودع المركزي لـ إشارات الكشف عن البوتات والتحليل الدفعي. من خلال الفرضيات التي حددناها نطاقها خلال الربعين الأول والثاني، نخطط للبدء في إدخال إشارات جديدة للكشف عن الروبوتات لـ صقل تحليلنا للزيارات المؤتمتة، والبدء في جعل عملية إدخال إشارات جديدة فعالة وقابلة للتكرار.
    • النتائج الرئيسة لخدمات البيانات والإشارات4.1: بحلول نهاية الربع الثاني، سيكون لدى صناع القرار فهم واضح للوضع الحالي للرؤى التي توفرها البيانات المترية التنظيمية لدينا. سنعرف أننا نجحنا إذا قمنا بتوفير عرض تقديمي جاهز لاجتماع مجلس الإدارة يضع تحليل بياناتنا المترية في سياق كل من بيئة ويكيميديا، وكذلك ضمن الاتجاهات والتحديات الأوسع نطاقًا على شبكة الإنترنت وفي السوق.
      • تُستخدم الرؤى المستخلصة من البيانات المترية التنظيمية لدينا لاتخاذ عدد لا يحصى من القرارات في المؤسسة، بما في ذلك القرارات المتعلقة بكيفية بناء منتجاتنا، وكيفية تخصيص موارد البنية التحتية، وكيفية جمع التبرعات. في الوقت نفسه، يتطور مشهد الإنترنت، مع تأثير الزيارات المؤتمتة بشكل خاص على بياناتنا المترية. الهدف هو أن يدخل قياديو المؤسسة اجتماع مجلس الإدارة في ديسمبر وهم يملكون سردًا واضحًا حول التهديدات والفرص داخل بيئة ويكيميديا، مدعومًا بـ تحليل واثق للبيانات المترية الداخلية والاتجاهات الخارجية. يمكننا سرد هذه القصة من خلال جمع الرؤى والبيانات المترية ونقاط البيانات التي تخبرنا بثقة حول:
        • الاتجاهات في مقاييسنا الداخلية للقراءة (مشاهدات الصفحات)
        • الاتجاهات في بيئة المساهمين الخاصة بنا
        • الاتجاهات المستخلصة من البيانات الخارجية ومعايير المنافسين
        • الرؤى المستخلصة من الدراسات الداخلية والخارجية والأبحاث الموثوقة
    • Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
      • In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
        • Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
        • Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).

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

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

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

---

منصة التجارب (خدمات البيانات والإشارات 2)

• الهدف: يتمكن مديرو المنتج من تقييم آثار التغييرات على ميزات المنتج في ويكيبيديا بسرعة وسهولة وثقة. ناقش
  • سياق الهدف: لـ تمكين وتسريع عملية صنع القرار المستندة إلى البيانات بشأن تطوير ميزات المنتج، يحتاج مديرو المنتجات إلى منصة تجارب يمكنهم من خلالها تحديد الميزات، واختيار جماهير المعالجة من المستخدمين، ورؤية قياسات الأثر. إن تسريع الوقت من الإطلاق إلى التحليل أمر بالغ الأهمية، حيث سيؤدي تقصير الجدول الزمني للتعلم إلى تسريع التجارب، وفي نهاية المطاف، الابتكار. تم تحديد المهام اليدوية والمقاربات المخصصة للقياس كعقبات أمام السرعة. السيناريو المثالي هو أن يتمكن مديرو المنتجات من الانتقال من إطلاق التجربة إلى الاكتشاف بتدخل يدوي قليل أو معدوم من المهندسين والمحللين.
  • نحن نركز على ويكيبيديا للسنة المالية القادمة؛ لأن هذا هو المجال الذي تهتم فيه الخبرات الأساسية بالتجارب (حيث تدعونا الاستراتيجية التنظيمية إلى مضاعفة الجهد على ويكيبيديا)، ولأنه يسمح لنا بالتركيز وتحديد الفرق والمشاريع التي نتعامل معها بشكل أوضح. لقد استخدمت فرق أخرى مكونات منصة التجارب وقد تستمر في ذلك، لكن هذا الاستخدام لن يكون محور تركيز هذا الهدف.
    • النتائج الرئيسة لخدمات البيانات والإشارات 2.1: بحلول نهاية الربع الثاني، يتم تمكين إكمال دورتين تجريبيتين كاملتين على الأقل باستخدام منصة التجارب.
      • نظرًا لأن المنظمة تُركز بشكل متزايد على القرارات المتعلقة بالمنتج المستنير بالبيانات، يجب علينا إتاحة التجارب لجميع فرق المنتجات، وليس فقط لتلك التي تمتلك مهارات متخصصة. تحتاج فرق المنتجات إلى معايير وأدوات وبنية تحتية مشتركة تمكنها من:
        • اختبار الأفكار بسرعة عبر قاعدة المستخدمين العالمية الخاصة بنا
        • قياس أثر التغييرات في المنتج باستخدام البيانات المترية المعيارية
        • مشاركة النتائج بشفافية مع الجهات المعنية في حركتنا
      • لماذا ننتقل من التركيز على عدد "الفرق المُمكنة" إلى "التجارب المُكتملة":
      1. التوافق الاستراتيجي: إنه المقياس الرئيسي لنجاح المنصة.
      2. المنهج القائم على البيانات: تشير أبحاث المستخدمين (قيد التنفيذ) إلى تباين في جاهزية الفرق عبر المنظمة، بينما نعلم أن فريق الويب قد أكد اهتمامه بإجراء تجربتين محددتين..
      3. تحسين الموارد: سيتطلب الإطلاق الأولي لمنصتنا إشرافًا مكثفًا في التهيئة، مما يجعل التركيز على فرص التجارب أكثر كفاءة على المدى القريب بدلاً من نشر شبكة واسعة عبر فرق متعددة. نحن نخطط للمضي قدمًا نحو إطلاق عام، ولا نرغب في إعادة الاستثمار في تدريب الفرق مرة أخرى، إذا أمكننا تجنب ذلك.
      4. التركيز على المستقبل: ستكون التغذية الراجعة من دورات التجارب المكتملة أكثر فعالية في توجيه تحسينات منصتنا مقارنة بالتعلم من الاعتماد الجزئي أو غير المكتمل. ومع تقدمنا نحو الإطلاق العام، فإن التركيز على إكمال التجارب يتجنب الاستثمار في المقاربات المؤقتة التي ستحتاج إلى إعادة تطوير.
      • لدينا أبحاث مستخدمين قيد التنفيذ لاستخلاص الاحتياجات والمتطلبات المشتركة بين الفرق: حيث يتم تحديد مواعيد لإجراء استبيانات ومقابلات لإضافة وضوح لاحتياجات فرق المنتجات في النصف الثاني من مايو 2025. بمجرد اكتمال هذا البحث، سنقوم بإعداد تقويم للتجارب يمكن استخدامه لـ تحديد أهدافنا وترتيب أولوياتنا للنتائج الرئيسة التالية.
    • Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
      • After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
      • Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
      • The architectural decisions we made during FY24/25 SDS2 and GrowthBook’s modularity allow us to replace parts of the Experimentation Lab out of order, i.e. WMF staff can define and deploy experiments with xLab UI while analyzing them with GrowthBook. Further, we can run the current experiment analytics pipeline and GrowthBook’s in parallel, which allows for side-by-side comparisons as well as User Acceptance Testing in real-world scenarios.
    • Key result SDS2.3: By the end of Q4, all new Test Kitchen experiments are configured in GrowthBook.
      • After having enabled WMF staff to use GrowthBook for analyzing experiment results, the Experiment Platform team held a design sprint to assess options for experiment configuration. The decision was to use GrowthBook as the source of truth for experiment configuration but keep Test Kitchen UI (TKUI) as the source of truth for instrument configuration.
        In making GrowthBook the source of truth for experiment configuration, we aim to:
        • Reduce coordination when running an experiment
        • Enable more frequent and repeatable experimentation
        • Clearly delineate between instruments and experiments
        • Move toward a mental model centered on metrics rather than instruments
    • Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
      • The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
      • KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
      • This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

---

جماهير المستقبل

جماهير المستقبل 1

• الهدف: تكون مؤسسة ويكيميديا مُجهَّزة بـ توصيات حول الاستثمارات الاستراتيجية التي يجب اتباعها لمساعدة حركتنا على خدمة جماهير جديدة في مشهد إنترنت متغير. ناقش
  • سياق الهدف: بسبب التغيرات المستمرة في التقنية وسلوك المستخدمين عبر الإنترنت (مثل: التفضيل المتزايد للحصول على المعلومات عبر تطبيقات التواصل الاجتماعي، انتشار مقاطع الفيديو القصيرة التعليمية الترفيهية، وصعود الذكاء الاصطناعي التوليدي)، تواجه حركة ويكيميديا تحديات في جذب القراء والمساهمين والاحتفاظ بهم. وتجلب هذه التغييرات أيضًا فرصًا لخدمة جماهير جديدة عبر إنشاء المعلومات وتقديمها بطرق جديدة. ومع ذلك، لا نمتلك كحركة صورة واضحة ومستنيرة بالبيانات لـ الفوائد والمفاضلات بين الاستراتيجيات المحتملة المختلفة التي يمكننا اتباعها للتغلب على التحديات أو اغتنام الفرص الجديدة. على سبيل المثال، هل ينبغي لنا أن......
    • الاستثمار في ميزات جديدة وكبيرة مثل روبوتات الدردشة؟
    • نقل معرفة ويكيميديا ومسارات المساهمة إلى منصات الطرف الثالث الشائعة؟
    • شيءٌ آخر؟
  • لضمان أن تصبح ويكيميديا مشروعاً متعدد الأجيال، سنقوم باختبار الفرضيات لـ فهم أفضل وتوصية بالاستراتيجيات الواعدة – لمؤسسة ويكيميديا وحركة ويكيميديا – التي يجب اتباعها لـ جذب جماهير المستقبل والاحتفاظ بها.
    • النتائج الرئيسة لجماهير المستقبل 1.1: كنتيجة لـ الرؤى والتوصيات التجريبية الخاصة بقسم جماهير المستقبل، بحلول نهاية الربع الثالث، يتم تضمين هدف واحد أو نتيجة رئيسة واحدة على الأقل تابعة لفريق غير تابع لجماهير المستقبل في مسودة الخطة السنوية للعام التالي.
      • منذ عام 2020، تعمل مؤسسة ويكيميديا على تتبُّع الاتجاهات الخارجية التي قد تؤثر على قدرتنا على خدمة أجيال المستقبل من مستهلكي المعرفة ومساهميها، والبقاء حركة معرفة حرة مزدهرة للأجيال القادمة. وسيقوم فريق جماهير المستقبل، وهو فريق صغير للبحث والتطوير، بما يلي:
        • إجراء تجارب سريعة ومحددة زمنياً (تهدف إلى 3 تجارب على الأقل لكل سنة مالية) لـ استكشاف سُبُل معالجة هذه الاتجاهات.
        • بناءً على الرؤى المستخلصة من التجارب، تقديم توصيات بالاستثمارات غير التجريبية الجديدة التي يجب على مؤسسة ويكيميديا اتباعها – أي المنتجات أو البرامج الجديدة التي تحتاج إلى أن يتولاها فريق أو فرق كاملة – خلال فترة التخطيط السنوي الاعتيادية لدينا.
      • يتم تحقيق هذه النتيجة الرئيسة إذا ظهر هدف واحد أو نتيجة رئيسة واحدة على الأقل، مملوكة لفريق خارج نطاق جماهير المستقبل ومدفوعة بتوصية من جماهير المستقبل، في مسودة الخطة السنوية للسنة المالية التالية.

---

الفيديو الاجتماعي (جماهير المستقبل 2)

• الهدف: أن يقوم الشباب (أقل من 25 عامًا) بالإعجاب بـ محتوى ويكيبيديا والتعلم منه والتفاعل معه ومشاركته على المنصات التي يفضلون قضاء الوقت فيها عبر الإنترنت. ناقش
  • سياق الهدف: أظهرت تجارب جماهير المستقبل في هذا العام المالي حول الفيديو القصير أنه يمكننا الوصول إلى الجماهير الأصغر سنًا على نطاق واسع على هذه المنصات، لكن بيانات صحة علامتنا التجارية تشير إلى أن استثمارنا الحالي ليس كافيًا لمواجهة تراجع الوعي والتقارب مع ويكيبيديا بين الجماهير الذين هم في عمر الجيل زد.
  • لضمان أننا نصل إلى هذا الجيل ونشركه بفعالية، نعتقد أننا سنحتاج إلى الانخراط في مجموعة متنوعة من التكتيكات، وزيادة مشاركتنا بشكل كبير في مجالات مثل التسويق المدفوع والمؤثرين، والحملات الإبداعية، والاستجابة للتوجهات الرائجة، ورفع مستوى تجاربنا على هذه القنوات.
  • نتوقع أن التحديات التي نواجهها ستتطلب استثمارًا أكثر جوهرية لمساعدتنا في التغلب عليها، لا سيما في جهود الاتصالات والتسويق لغرض إحداث التفاعل، بالإضافة إلى التعاون بين الأقسام لـ إنشاء منتجات وخبرات جديدة موجهة نحو زيادة حضور علامة ويكيبيديا التجارية ومحتواها على هذه المنصات.
    • النتائج الرئيسة لجماهير المستقبل 2.1: توليد 9,500,000 مشاهدة من محتوى الفيديو القصير عبر جميع القنوات المملوكة بحلول نهاية النصف الأول.
      • في هذا العام، حققنا وصولاً بلغ حوالي مليون مشاهدة في غضون ثلاثة أشهر من إطلاق مقاطع الفيديو القصيرة على قنوات @Wikipedia على منصات تيك توك وإنستغرام ويوتيوب. وبحلول بداية العام المالي المقبل، نتوقع زيادة عدد المتابعين على قنواتنا المملوكة، والحصول على رؤى معمقة إضافية حول المحتوى الفعال/الجذاب الذي يمكننا تطبيقه عمليًا للوصول إلى عدد أكبر من المشاهدين.
      • من خلال تحديد هدف طموح في النصف الأول من العام، نأمل في الدفع نحو تحقيق أثر أكبر بكثير، والسماح بـ إنشاء استراتيجيات/عمليات جديدة لتسهيل العمل، وأن نكون قادرين على المطالبة بموارد إضافية لتحقيق هذا الهدف.
    • النتائج الرئيسة لجماهير المستقبل 2.2: تنمية متابعينا خارج المنصة على تيك توك من الفئة المتوسطة(100 ألف – 250 ألف متابع) إلى الفئة الكبيرة (Macro tier) (250 ألف – 1 مليون متابع) بحلول نهاية السنة المالية 2025/2026 (يونيو 2026).
      • نحن حاليًا في الفئة المتوسطة من حيث عدد متابعينا على تيك توك (100 ألف – 250 ألف متابع)، وهدفنا هو الوصول إلى الفئة الكبيرة (250 ألف – 1 مليون متابع) بحلول نهاية السنة المالية 2025/2026 (يونيو 2026). تُعد هذه الفئات – المصغّرة، والمتوسطة، والكبيرة – معايير قياسية في الصناعة لحجم الجمهور ونطاق الوصول. ولتحقيق ذلك، سنعمل على صقل استراتيجية المحتوى الخاصة بنا لـ جذب متابعي الجيل زد بشكل أفضل وزيادة رؤيتنا الإجمالية من خلال إدارة المجتمع. سيتم الاعتماد على أداء النصف الأول في توجيه التعديلات التكتيكية في النصف الثاني لـ تسريع النمو والوصول إلى هذا الإنجاز.
    • النتائج الرئيسة لجماهير المستقبل3.2: إطلاق منتج خارج المنصة يستهدف أساليب جماهير المستقبل الجديدة للتعلم/استهلاك الوسائط، وطرحه في السوق من خلال حملة تسويق وعلامة تجارية للمنتج متعاون عليها.
      • يعمل فريق جماهير المستقبل عادة على تجارب صغيرة النطاق مع تسويق عضوي/بحد أدنى. وفي هذا العام، نود تخصيص وقت لـ منتج جديد مُوسَّع بالإضافة إلى حملة تسويق تستهدف الجماهير الأصغر سنًا خارج المنصة.

---

دعم المنتج والهندسة (PES)

دعم المنتج والهندسة (PES1)

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

الفرضيات

الربع الأول

يغطي الربع الأول من الخطة السنوية لمؤسسة ويكيميديا الفترة من يوليو إلى سبتمبر.

فرضيات تجارب الويكي (WE) [ النتائج الرئيسة لتجارب ويكي ] نقاش
الاسم المختصر للفرضية	نص الربع الأول	التفاصيل والنقاش
WE1.1.1	إذا قمنا بـ مطالبة المتطوعين الجدد (أو الأحدث) الذين يلصقون نصوصًا من موقع خارجي بـ تأكيد ما إذا كانوا هم من كتبوا المحتوى الذي يحاولون إضافته، فسنشهد انخفاضًا بنسبة 10% على الأقل (≥10%) في النسبة المئوية لتعديلات المحتوى الجديد التي ينشرها المتطوعون الجدد (أو الأحدث) والتي يتم التراجع عنها على أساس انتهاك حقوق النشر في ويكيبيديا (والسياسات ذات الصلة).
WE1.1.2	إذا قمنا بتسليم نسخة تجريبية أولية من "التعديل المقترح لتحسين النبرة"، فيمكننا أن نتعلم ما إذا كان هذا التنسيق الجديد للتعديلات المقترحة هو طريقة ذات مغزى لـ زيادة التعديلات البنّاءة للمساهمين الجدد دون زيادة عبء الإشراف على المُرَاقِبين/المُرَاجِعين.
WE1.1.3	إذا قمنا بتطبيق "وضع الاقتراحات الجديد" المُستهدف لـ المساهمين الأقدم ضمن المحرر المرئي (على الهاتف المحمول وسطح المكتب) كـ ميزة تجريبية تتضمن 3 اقتراحات تعديل جديدة على الأقل (≥ 3)، فسوف نكتشف ما هي التعديلات – إن وجدت – التي يجب إجراؤها قبل تقييم التجربة مع المتطوعين الجدد (أو الأحدث) من خلال تجربة مُنضبطة.
WE1.1.4	إذا قمنا بـ تطبيق "التحقق من المرجع" على ويكيبيديا الإنجليزية من خلال تجربة مُنضبطة، فسنشهد زيادة بنسبة 10% على الأقل (≥10%) في التعديلات البنّاءة التي ينشرها المتطوعون الجدد (أو الأحدث)، وسنتعلم ما إذا كان هناك دعم كافٍ بين المُرَاقِبين والمُشرفين لـ تمكين الميزة على نطاق أوسع.
WE1.1.5	إذا قمنا باختبار نظام تقدم عبر نماذج تصميم أولية مع الوافدين الجدد، فيمكننا تحديد أنواع الإنجازات، والتوجيه، والاعتراف التي يُنظر إليها على أنها الأكثر تحفيزًا، واستخدام هذه الرؤى لوضع تصميم نهائي لتجربة تجريبية مستقبلية على الويكي.
WE1.1.6	إذا قمنا بـ التحقيق في أهم الحواجز والمُمَكِّنات التقنية والاجتماعية والسلوكية للتعديل عبر الويب على الهاتف المحمول من خلال أبحاث المستخدمين وتحليل البيانات، فسوف نولّد ما لا يقل عن 3 رؤى قابلة للتنفيذ تعمل على سد الفجوات المعرفية الرئيسة وتعزيز قدرتنا على تحديد أولويات الاستثمارات في المنتجات بثقة للنصف الثاني من السنة المالية 26/25 وما بعدها.
WE1.2.1	إذا قمنا بإنشاء إثبات مفهوم لـ عرض بيانات المساهمة التعاونية على الويكيات، فيمكننا جمع تعليقات من 30 مساهمًا على الأقل، مع مشاركة 70% من المستجيبين بأن هذه الميزة مفيدة ويمكن أن تساعد في دفع النمو التعاوني.
WE1.3.1	إذا قمنا باستغلال الاحتياجات المحددة من الأبحاث والتصميمات السابقة ومشاركة النماذج الأولية المبكرة لـ أكثر X وحدات إشراف تأثيرًا، فيمكننا تعديل الصفحة الرئيسية لإجراءات الإشراف باستخدامها.
WE1.3.2	إذا قمنا بتعديل الصفحة الرئيسية للوافد الجديد لـ عرض وحدات الإشراف بشكل مشروط، فيمكننا إثبات جدوى استخدام الصفحة الرئيسية للمُشرفين.
WE1.4.1	إذا قمنا بإجراء عدد من التحسينات المشار إليها في Phab:T396489 (T396489)، فسوف نقلل من استعلامات "التغييرات الأخيرة" البطيئة بنسبة X في المئة على الويكيات الكبيرة. عندئذٍ، ستكون أدوات المُشرفين قادرة على تطبيق وحدات الصفحة الرئيسية على تلك الويكيات دون قلق خاص بشأن أداء قاعدة البيانات.	T400696
WE2.1.1	إذا دَعَيْنا مُتحدثين أصليين للغة للويكيات الصغيرة، عبر إعلان مركزي على ويكيبيديا ذات حركة مرور عالية في منطقتهم، لـ المساهمة في التعديلات المقترحة وميزات النمو الأخرى، فيمكننا تقييم ما إذا كان هذا النهج يجذب متحدثين أصليين جددًا، وما إذا كانوا يستخدمون أدوات التحرير هذه لـ تحسين المحتوى الحيوي.
WE2.1.2	إذا قمنا بتطوير وإصدار اقتراحات ترجمة مُصمَّمة خصيصًا للمحررين الجدد، فسنكون قادرين عندئذٍ على اختبار ما إذا كان هذا النهج ينتج نتائج ترجمة أفضل مقارنة بـ نهجنا الحالي. يتناول هذا الأمر التحديات المعروفة التي يواجهها المحررون الجدد، والذين لديهم احتمالية أعلى لحذف مقالاتهم. من خلال توجيههم نحو ترجمة محتوى يمكن إدارته بشكل أكبر، يهدف الهدف إلى توفير مقدمة لعملية الترجمة تكون أقل إرباكًا وأكثر سهولة في الوصول. يمكن أن تبدو الترشيحات الجيدة للمقالات والأقسام ذات تعقيد محدود من حيث التنسيق والطول الإجمالي.
WE2.1.3	إذا اطلعنا على تجربة المحرر عند إنشاء مقالات وأقسام جديدة (بما في ذلك الدوافع، ونقاط الألم، ورد فعلهم تجاه الأفكار الجديدة حول كيفية دعمهم بشكل أفضل)، فسوف نكشف عن احتياجات وسلوكيات المستخدمين التي توفر رؤى واستراتيجيات قابلة للتنفيذ لتوجيه أقسام المنتجات والتصميم والهندسة بشأن تحسين تجربة إنشاء المقالات.
WE2.1.4	إذا اكتشفنا من خلال ورش عمل أو مقابلات قائمة على المشاركة، كيف تتعامل ثلاث ويكيبيديات متوسطة الحجم مع فجوات المعرفة والأهمية، فسوف نكشف عن تعاريف عملية أو مفاهيم تأطيرية لـ "المعرفة الحيوية" تكون ذات صلة بكل مجتمع.
WE2.2.1	إذا اتبعنا خطة طرح بارسويد وأدمجنا الويكي دوال في معظم مشاريع ويكاموس وبعض مشاريع ويكيبيديا منخفضة الحركة، فسنحصل على الاختبارات التي نحتاجها لـ طرحها بثقة على الويكيات الأكبر.
WE2.2.2	إذا قمنا بتمكين ويكي دوال من إخراج جداول HTML، وتنسيقات، وروابط، فسوف نبرهن من خلال دالة تعرض جدول تصريف على قدرتها على توليد معرفة جديدة صافية في مشاريع ويكاموس بما يتجاوز التحويلات البسيطة.
WE2.2.3	إذا أضفنا دعمًا لكيانات ويكي بيانات في استدعاءات الدوال المضمنة، فسنُمكّن أكثر من 200 دالة جديدة يمكنها توليد جمل شاملة باستخدام كيانات ويكي بيانات، مما يُسهّل استخدام الدوال في مشاريع ويكيميديا.
WE2.2.4	إذا وضعنا خطة هندسيَّة لمكان تواجد المحتوى المجرد وكيفية تفاعله مع ويكيبيديا، فسنكون أكثر استعدادًا لتطبيق منصة ويكيبيديا المجردة لزيادة توفير محتوى موسوعي عالي الجودة.
WE2.2.5	إذا حددنا وتواصلنا مع فرق المنتجات والتقنية بشأن احتياجات المنتج للاستشهادات المطلوبة للمحتوى المجرد، فسنكون قادرين على قيادة العمل عبر ويكيميديا ​​لتقديم معلومات المنشأ المرتبطة بالمحتوى المجرد، وهو أمر بالغ الأهمية لنجاح الاستخدام عبر مواقع الويكي.
WE2.2.6	إذا جعلنا تنسيق الطلب الداخلي الخلفي أكثر تعبيرًا وإيجازًا، فيمكننا زيادة استقرار النظام، وبالتالي دعم طرح أوسع.
WE2.2.7	إذا وفّرنا نماذج أولية باستخدام استدعاءات ويكي بيانات وويكي دوال لتوليد مقتطفات من اللغة الطبيعية، فسنُظهر جاهزيتنا للمشروع، وسنكون مستعدين لاستخدامه لتدريب الذكاء الاصطناعي، مما يُغني البشر عن التفكير كثيرًا في الدوال.
WE2.2.8	إذا وفّرنا استيراد بيانات ويكي بيانات مع التصفيات، فسيكون من الممكن توليد حقائق متعددة الأوجه (حقائق تتطلب أكثر من مجرد فاعل/مسند/قيمة للتعبير عنها)، والتي تشمل ما يُقدّر بنحو 50% من المحتوى الموسوعي في ويكي بيانات.
WE2.2.9	إذا وفّرنا التخزين المؤقت للكيانات المستردة من ويكي بيانات، فسنقوم بتقليل متوسط ​​وقت تشغيل وظائف ويكي بيانات القائمة على المحتوى بنسبة 50% على الأقل، مما يقلل من فترات الانتظار وإحباط المستخدم.
WE2.2.10	إذا وفرنا مكون المعنى المعجمي في ويكي بيانات في واجهة مستخدم ويكي دوال، فسيكون المساهمون قادرين على تحديد المفردات ذات الصلة واختيارها دون مغادرة المنصة/ويكي دوال- مما يقلل من تبديل السياق وتمكين إنشاء دوال مرتبطة باللغة بشكلٍ أسرع وأكثر نجاحًا.
WE2.2.11	إذا تناولنا نتائج قابلية الاستخدام من مجتمع الدغبانية حول تكامل ويكي دوال على ويكيبيديا، فسنلاحظ أن المحررين يواجهون عددًا أقل أو لا يواجهون أي مشكلاتٍ حرجة في قابلية الاستخدام عند إدراج الدوال في مقال أثناء الاختبار.
WE3.1.1	إذا أجرينا اختبار A/B لإصدار مُحسّن من ميزة التصفح المُبوب، على تطبيق آي أو إس، فسنلاحظ زيادة بنسبة 5% في الاستخدام متعدد الأيام بين مستخدمي علامات التبويب.
WE3.1.3	إذا وفرنا طريقة جديدة للمستخدمين لتصفح محتوى الصور أو مقاطع الفيديو المرتبطة داخل صفحات المقالات، فسنلاحظ معدل نقر بنسبة 3% على الأقل بين المستخدمين الذين تُعرض عليهم هذه الميزة.
WE3.1.4	إذا عرضنا على القراء عدة مفاهيم لاجتياز شبكة المعرفة على الويكيات، فسنخرج بقائمة أولويات للمفاهيم لمزيد من التطوير.
WE3.1.5	إذا وفرنا لقراء الويب خيار عرض نسخة مترجمة آليًا من محتوى ويكيبيديا غير المتوفرة بلغتهم، فسنعرف ما إذا كان نشاط القراءة قد زاد، والذي يُقاس بزيادة بنسبة 3% في تفاعلات الصفحة، مما يجذب القراء إلى ويكي اللغة المحلية مع زيادة محتملة في نشاط التحرير المحلي. سيوفّر هذا كإعداد اختبار A/B مُتحكم به لمدة لا تزيد عن 6 أشهر، وفي 13 موقعًا من ويكيبيديا بموافقة مسبقة، باستخدام خدمات الترجمة الآلية المفتوحة المتاحة بالفعل لمحرري ويكيبيديا.
WE3.2.1	إذا تعاونّا مع فرق جمع التبرعات، فسنُطوّر شرائح متبرعين أكثر تفاعلًا وتكاملًا وتخصيصًا في مراجعة العام على نظام آي أو إس (iOS) كما قيّس من خلال اختبار المستخدم. وسيُتبع ذلك بفرضية في الربع الثاني لتقييم ما إذا كانت مراجعة العام قد شهدت زيادة في التبرعات بنسبة 5% مقارنةً بمراجعة العام لعام 2024.
WE3.2.2	إذا حثثنا قراء تطبيق أندرويد في المناطق غير المرتبطة بالحملات على إعداد تذكير اختياري وقابل للتخصيص (للمبلغ والتكرار) للتبرعات بناءً على استخدامهم لويكيبيديا، فسنشهد زيادة بنسبة 5% في التبرعات من خلال قوائم التطبيقات في تلك المناطق.
WE3.2.3	إذا أجرينا تجربة اختبار A/B على المستخدمين الذين سجلوا خروجهم لعرض متغيرات دقيقة لنقطة إدخال التبرعات لكل من الأجهزة المحمولة وأجهزة الحاسوب، فسنلاحظ زيادة بنسبة 2% في عدد التبرعات عبر مسارات المعالجة، مقارنةً بالمجموعة الضابطة.
WE3.3.1	إذا أضفنا عناصر مخصصة منخفضة إلى متوسطة الجهد طلبها مستخدمو آي أو إس (iOS) في عام 2024 إلى تقرير عام 2025، فسنشهد زيادة بنسبة 3% في الرضا مقارنةً بالعام الماضي، كما قيّست من خلال اختبار قابلية الاستخدام أو الاختبار التجريبي.
WE3.3.2	إذا وسّعنا علامة تبويب التحرير الحالية على نظام أندرويد إلى مركز أنشطة مخصص يتضمن رؤى حول المشاركة في القراءة والمشاركة غير التحريرية، فسنشهد زيادة بنسبة 5% في التفاعل متعدد الأيام مع علامة التبويب مقارنةً بالإصدار الأصلي.
WE3.3.3	إذا أضفنا صورة رمزية واحدة على الأقل قابلة للفتح في تطبيق أندرويد لأصحاب الحسابات - والتي يتم الحصول عليها من خلال إجراءات مفيدة للقراء مثل حفظ عدد معين من المقالات - فسنزيد التفاعل المتكرر مع الإجراءات المرتبطة بها من قبل المستخدمين المسجلين بنسبة 10% على مدار عدة أيام.
WE3.3.4	إذا منحنا القراء المسجلين إمكانية حفظ المقالات في قائمة قراءة خاصة، نتوقع زيادة التفاعل على الموقع، كما يُقاس بزيادة بنسبة 5% في حركة الإحالة الداخلية للقراء الذين يستخدمون هذه الميزة، وزيادة ذات دلالة إحصائية لجميع المستخدمين.
WE3.3.5	إذا أجرينا دراسة مستخدمين تسمح لقراء الويب بجمع/تنظيم المحتوى من ويكيبيديا، فسيحفظ 10% على الأقل من المشاركين نوعين أو أكثر من المحتوى (مثل المقالات والمقتطفات والوسائط) في مجموعة.
WE3.4.1	إذا عملنا على نشر هجين لنقطة تواجد/شبكة توصيل محتوى (PoP/CDN)، فسيسمح لنا ذلك بإنشاء نقاط تواجد كاملة ونقاط تواجد مصغّرة (مادية وسحابية) حسب الحاجة، مما يُرسي الأساس لنشر نموذج أولي لنقطة تواجد مصغّرة في المستقبل.
WE3.6.1	إذا أجرينا اختبار A/A على معدل الاحتفاظ للمستخدمين الذين لم يسجلوا دخولهم، فسنضع خط أساس لمعدل الاحتفاظ يمكننا استخدامه للأرباع المستقبلية.
WE3.6.2	إذا أنشأنا ونشرنا تعريفًا للقارئ الذي سجل دخوله، فسنتمكن من استخدام هذا التعريف في جميع الفرق والفرضيات المتعلقة بالنتيجة الرئيسية لتجارب الويكي 3.3 (WE 3.3 KR).
WE3.6.3	إذا أشركنا المجتمعات في محادثات حول الاحتياجات المتطورة للقراء، وحول الطبيعة المتغيرة للمعرفة على الإنترنت، يُمكننا بناء تركيزٍ مشترك على كيفية خدمة القراء والعمل معًا على ما إذا كان ينبغي اختبار أفكارنا المختلفة (بما في ذلك تلك المتعلقة بالوسائط المتعددة، والبحث والاستكشاف، والتعلم الآلي) وكيفية اختبارها.
WE3.6.4	إذا بحثنا عن الدوافع والسلوكيات والاحتياجات المميزة وراء متى ولماذا وكيف يستخدم القراء ويكيبيديا وغيرها من منصات المعرفة، فسوف نحصل على نتائج يمكننا استخدامها لإعلام وتطوير استراتيجية المستهلك الخاصة بنا.
WE4.1.1	إذا وضعنا نموذجًا أوليًا لتدفقٍ غير طارئ ذي جدوى محدودة، وحافظنا على حلقة تغذية راجعة متكررة أثناء تطويره مع مستخدمين يمتلكون صلاحياتٍ متقدمة، فستدعم هذه المجموعات النشر الموسع لهذا التدفق.	Project page
WE4.2.1	إذا كشفنا عن مستوى خطر الكابتشا (hCaptcha) المرتبط بإنشاء الحسابات لأصحاب الصلاحيات المتقدمة الموثوق بهم، فسنقلل الوقت اللازم لتحديد الجهات الفاعلة السيئة، ونزيد عدد عمليات اكتشاف حسابات الجهات الفاعلة السيئة التي أنشأت على المنصة. يمكننا قياس نجاح الفرضية من خلال النظر في معدل المنع المطبق على الحسابات، ومواءمة مستويات خطر الكابتشا (hCaptcha) ومنع الحسابات بشكل عام، والتغذية الراجعة النوعية من أصحاب الصلاحيات المتقدمة.
WE4.2.2	إذا أنشأنا تحقيقات مقترحة ليتابعها مدققو المستخدم، فسنلاحظ انخفاضًا في الوقت اللازم لتحديد حسابات الجهات الفاعلة السيئة وزيادة في عدد حسابات الجهات الفاعلة السيئة المحددة. سنتأكد من نجاحنا عندما نرى استخدامًا منتظمًا لميزة "التحقيقات المقترحة"، وزيادة في إجراءات التخفيف المطبقة على الحسابات المحددة من خلال التحقيقات المقترحة، ومن خلال ملاحظات الاستبيان النوعي.
WE4.2.3	إذا حللنا البيانات من تجربة إنشاء حساب الكابتشا (hCaptcha)، فسنفهم مسار إنشاء الحساب، وفعالية لغز الكابتشا (hCaptcha) ونتائجه، وسنحصل على البيانات اللازمة لإبلاغ المزيد من عمليات نشر الكابتشا (hCaptcha) على إنشاء الحسابات.
WE4.2.4	ذا نشرنا بطاقة معلومات المستخدم (UserInfoCard) في جميع مواقع الويكي، فسنمكّن أصحاب الصلاحيات المتقدمة والمراجعين من تحديد حسابات الجهات الفاعلة السيئة والحد منها بكفاءة أكبر.	Project page
WE4.2.5	إذا أجرينا أبحاثًا، واستشرنا المجتمعات، وبحثنا عن حلول تقنية، فسنتمكن من تحديد مجموعة من أسباب المنع المنظمة التي يمكن استخدامها في جميع ويكيات مؤسسة ويكيميديا.
WE4.2.6	إذا طورنا إمكانية نشر مجموعات بيانات قائمة على البحث المفتوح (OpenSearch) على منصة البيانات، فستمكن فرق هندسة ميزات المنتج من تطوير أنظمة تدمج هذه الإمكانية، مع قدر كبير من الاستقلالية والمرونة والعزلة عن أنظمة البحث الأخرى. وسيكون المستأجر الأول والرئيسي لهذا النظام هو خدمة IPoid.
WE4.2.7	إذا قمنا بتطبيق دمج نظام التحقق البشري hCaptcha – الإصدار المؤسسي. على العديد من مشاريع ويكيبيديا الإنتاجية كـ تجربة رائدة، فسوف نكون قادرين على جمع بيانات حول فعالية وقيمة نظام التحقق البشري hCaptcha – الإصدار المؤسسي. فيما يخص مكافحة إساءة الاستخدام، وكشف الروبوتات، وقابلية الاستخدام، وإمكانية الوصول.
WE4.3.1	إذا دمجنا دعم ملف تعريف الارتباط إيدج يونيكيز (Edge Uniques) الجديد في requestctl، وهو محرك قواعد إيدج الخاص بنا لمطوري خدمات الإنترنت (SREs) لمكافحة إساءة الاستخدام، فسنتمكن من الدفاع بشكل أفضل ضد هجمات الحرمان من الخدمات (DDoS) وإعادة استخدام المحتوى.
WE4.4.1	إذا تمكنا من إجراء تحسيناتٍ بناءً على ملاحظات المشاركين التجريبيين ونشر حسابات مؤقتة في جميع المشاريع، فسنتمكن من حماية معلومات التعريف الشخصية (عناوين بروتوكول الإنترنت) للمستخدمين غير المسجلين في جميع مشاريعنا من التعرض لأقل من 0.1% من إجمالي المستخدمين (المسجلين).	Project page
WE4.4.2	إذا تواصلنا مع الجهات المعنية بالحركة (بما في ذلك مجتمعات الويكي والمسؤولين العالميين) بوضوح وفي الوقت المحدد، فسنتمكن من النشر على جميع مواقع الويكي المتبقية، وتقليل عبء العمل الذي يُكتشف في اللحظة الأخيرة، وتجنب التراجع عن النشر.
WE4.4.3	إذا سهّلنا على القائمين على المراجعة تصفية الإجراءات وعرض نشاط الحسابات المؤقتة بناءً على عناوين بروتوكول الإنترنت الخاصة بها، فسنتمكن من نشر الحسابات المؤقتة بنجاح على جميع الويكيات.
WE4.4.4	إذا سمحنا بإلغاء إمكانية الكشف عن عناوين بروتوكول الإنترنت للحسابات المؤقتة وفقًا لسياسة الكشف عن هذه العناوين، وأضفنا الميزة في أماكن أكثر، فسنتمكن من نشر الحسابات المؤقتة بنجاحٍ على جميع الويكيات.
WE4.5.1	إذا أجرينا بحثًا نوعيًا لتحديد أمثلة على إساءة الاستخدام من جهات فاعلة سيئة بمساعدة الذكاء الاصطناعي التوليدي (مثل البريد العشوائي والمضايقات والمسيئين على المدى الطويل والتحرير المدفوع غير المعلن أو حملات التضليل)، فسنتمكن من تقييم المخاطر على نماذج مجتمعنا وتوليد أفكار للتخفيف من أنواع مختلفة من إساءة الاستخدام بمساعدة الذكاء الاصطناعي التوليدي.
WE4.6.1	إذا قمنا بأتمتة عملية مزامنة الحساب داخل زينديسك (Zendesk) لإعادة تعيين كلمة المرور، فسيخفف ذلك العبء على فريق الأمان والثقة ويسمح لهم بمعالجة المزيد من طلبات إعادة تعيين التوثيق ذو العاملين.
WE4.6.2	إذا دعمنا وشجعنا المستخدمين على تسجيل التوثيق ذو العاملين، فسيكون المستخدمون الذين فعّلوا هذا التوثيق أقل عرضة لإغلاق حساباتهم.
WE4.6.3	إذا سمحنا لجميع المستخدمين الذين لديهم عنوان بريد إلكتروني مؤكد بتفعيل التوثيق ذو العاملين لحساباتهم، ولكن لم نعلن عن هذا التغيير للمستخدمين بشكلٍ استباقي، فسيظل ضغط مكتب دعم الاسترداد لدينا عند مستوًى مستدام.
WE5.1.1	إذا استخدمنا واجهات تخزين خلفية مختلفة للجلسات المُصادق عليها والمجهولة، فسنتمكن من حماية مخزن الجلسات من هجمات الحرمان من الخدمة (DDoS) وبرامج استخراج البيانات عالية الحجم، وذلك بتجنّب إثقاله بالجلسات المجهولة المُنشأة لتوفير الحماية من هجمات تزوير الطلب عبر المواقع (CSRF) على صفحات المصادقة.	T398814
WE5.1.2	إذا غيّرنا ملفات تعريف ارتباط جلسة الميدياويكي إلى تنسيق مُهيكل ذي توقيع تشفيري، فسنتمكن من استخدام وجود الجلسة كعامل للحماية من برامج استخراج البيانات، وذلك من خلال تمكين التحقق الموثوق من الجلسات على الحافة بطريقة عالية الأداء وقابلة للتطوير بدرجة كبيرة.	T398815
WE5.1.3	إذا أنشأنا حلًا لتحديد معدل نقل البيانات لبوابة واجهة برمجة التطبيقات (API) باستخدام بيئة تطوير محلية قائمة على كوبرنيتس (Kubernetes)، فسنتمكن من تحديد الخيار الأمثل للاختبار مع حركة مرور الإنتاج، وذلك بمقارنة أداء ووظائف ثلاث خدمات مختلفة على الأقل لتحديد معدل نقل البيانات.	T398913
WE5.2.1	إذا أعدنا تصميم واجهة مستخدم ملعب واجهة برمجة التطبيقات (REST API Sandbox) لتلبية احتياجات المطورين المعلوماتية بشكلٍ أفضل، فسنحسّن وضوح التوثيق، كما هو مُثبت من خلال اختبارات قابلية الاستخدام.
WE5.2.2	إذا قمنا بتوجيه جميع واجهات برمجة التطبيقات ضمن ملف rest.php عبر بوابة مركزية، فسنُتيح إمكانية إدارة واجهات برمجة التطبيقات المركزية، وسنتمكن من البدء في قياس حركة مرور (REST API) وأنماط استخدامها باستمرار لاكتساب رؤى تُرشد القرارات والإجراءات المستقبلية.
WE5.2.3	إذا طبقنا لوحات معلومات وتنبيهات للمراقبة لواجهة برمجة تطبيقات (MediaWiki REST)، فقد نتمكن من إثبات طريقة مستدامة ومفيدة وقابلة للتكرار لتحسين رؤية سلوك أنظمتنا واكتشاف المشكلات بشكلٍ أسرع، خاصةً أثناء التعديلات الحرجة.
WE5.3.1	إذا قمنا بتوسيع وتبسيط إرشادات إسناد تجربة المستخدم مع تحديث أي إرشاداتٍ حالية، فسننشئ مجموعة أساسية من الإرشادات المُحسّنة الجاهزة للاختبار الداخلي والتحسين التكراري لتكون جاهزة للاستخدام العام على نطاقٍ أوسع.
WE5.3.2	إذا أنشأنا عرضًا تقديميًا يوضح فوائد إسناد محتوى ويكيبيديا إلى مُعيدي استخدام محتوى الجهات الخارجية ومستخدميهم النهائيين، فيمكننا دعم WME4.1 وWME4.2 من خلال تمكين شريك إعادة استخدام إضافي واحد على الأقل من الموافقة على الظهور في دراسة حالة أو عرض توضيحي للإسناد بحلول نهاية الربع الأول.
WE5.4.1	إذا ضمنا حصول غالبية طلبات الويب على ملف تعريف ارتباط فريد خاص بالطرف، فسيكون من الأسهل تحديد برامج الربوتات والطلبات المزيفة.
WE5.4.2	إذا أنشأنا طريقة قابلة للتطوير لتحديد العملاء المعروفين، يُمكننا السماح باستثناءات من حدود المعدلات العامة للبروتات ذات المصدر المُتحقق، والمضي قدمًا نحو تطبيق منهجي لقواعدنا.
WE5.4.3	إذا أعدنا تنظيم تصفية طلبات النصوص على شبكة توصيل المحتوى (CDN) حول نهج قائمة السماح/قائمة المنع، يُمكننا فرض حدود معدل عامة أكثر صرامة للبروتات وتبسيط تصفية حركة المرور.
WE5.4.4	إذا طورنا استراتيجية قياس موحدة، فسنُمكّن من تقييم الاستراتيجية متعددة السنوات "للاستخدام المسؤول للبنية التحتية"، ونحدد خارطة طريق لتوجيه تطوير المقاييس وقدرات إعداد التقارير.
WE6.1.1	إذا أعدنا بناء الصور اليومية إلى خادم النشر، وأضفنا تحديثات الصور الناتجة عن إجراءات نشر محددة، فسنكشف القيود ونحدد خط أساس للوقت اللازم لإجراء عمليات نشر أكثر استمرارية.
WE6.1.3	إذا أضفنا ويكي فارمز (wikifarms) إلى بيئة اختبار ما قبل الدمج، فسيمكّن ذلك فرق التطوير من البناء مقابل الإنتاج، والتي تتطلب من خوادم ويكي متعددة اختبار تصحيحاتها بشكل منفصل، مما يمنحها ثقة أكبر قبل الإنتاج، ويؤدي إلى تقليل حالات الهروب من العيوب.
WE6.2.1	إذا راجعنا ونشرنا قائمة التحقق من جاهزية الإنتاج التي تحدد بوضوح المتطلبات الأساسية لاعتبار الخدمة جاهزة للإنتاج، إلى جانب المهام ذاتية الخدمة، فسنوازن التوقعات بين مهندسي أمن البرمجيات وفرق التطوير، مما يُحسّن كفاءتنا التشغيلية وقابليتنا للتوسع بشكل عام.
WE6.2.2	إذا أعلنا عن إنشاء مكتبة Golang وnodejs تُلخص العديد من المهام الشاقة للمطورين، فسيستجيبون بتقديم الملاحظات والاهتمام.
WE6.2.3	إذا أنشأنا قائمة تحقق/ورقة عمل، يُمكن للمطورين الاستعداد الكامل مُسبقًا لمراجعة تصميم ثبات البيانات.
WE6.3.1	إذا أطلقنا ما لا يقل عن 70 موقع ويكيبيديا منخفض الزيارات في الربع الأول، باستثناء مواقع الويكي التي تدعم متغيرات اللغة، فسنزيد من ثقتنا في إمكانية إطلاقها في نهاية المطاف على أفضل 10 مواقع ويكي، مما سيكون له تأثير أكبر في مشاهدات الصفحات المُقدمة عبر بارسويد.
WE6.4.1	إذا نشرنا جدول روابط التقسيم الخاص بكومنز في مجموعته الخاصة، فسنزيد من فرص استدامة نمو قاعدة بيانات كومنز.	T398709
WE6.4.2	إذا قدمنا ​​هندسة موثوقية الموقع (SRE) المساعدة لفرق هندسة الميدياويكي- من خلال إنشاء الوثائق، وإعداد البنية التحتية اللازمة (مثل حزم بي إتش بي وصور الحاويات)، وتقديم التوجيه والمراجعة - فسيكونون قادرين على بدء ترقية بي إتش بي 8.3 الإنتاجية بثقة مع بداية الربع الثاني.	T360995
WE6.4.3	إذا طلبنا عامل أمان ثانوي مادي (مفتاح أمان الأجهزة) لتسجيلات دخول بروتوكول النقل الآمن (SSH) من قِبل المستخدمين ذوي امتيازات النظام المرتفعة، فسنقلل من خطر تسبب جهاز حاسوب محمول مُخترق في خرق أمني خطير.
WE6.4.4	إذا وحّدنا نطاقاتنا بعرض جميع مشاهدات الصفحات على مواقع ميدياويكي عبر نطاق أساسي، فسنُخفّض تعقيد المنصة ومخاطر تحسين محركات البحث (SEO) من خلال إزالة إعادة توجيه النطاقات الفرعية للأجهزة المحمولة. يُقاس الإنجاز بزيادة مشاهدات الصفحات على الأجهزة المحمولة على النطاقات الأساسية من 0% إلى 100%.	T214998
WE6.4.5	إذا راقب فريق هندسة ميدياويكي المشكلات المتعلقة بترقية بي إتش بي 8.3 ومعالجتها بشكل فعّال، فسيصبح فريق موثوقية الموقع قادرًا على المضي قدمًا في الترقية إلى بي إتش بي 8.3 مع بداية الربع الثاني.	T360995

فرضيات الإشارات وخدمات البيانات (SDS) [ النتائج الرئيسية للإشارات وخدمات البيانات ] نقاش
الاسم المختصر للفرضية	نص الربع الأول (Q1)	التفاصيل والنقاش
SDS1.1.1	إذا حللنا فعالية أساليب الكشف الآلي عن حركة المرور في مجموعات بيانات مشاهدات الصفحات، فسنتمكن من تطوير مقاييس جودة البيانات لوصف أدائها وتحديد الحاجة إلى مزيد من الاستثمار في هذه الأساليب.
SDS1.2.2	إذا نقلنا عملية XML Dumps من البنية التحتية الحالية "Dumps 1" إلى مسار معالجة بيانات يستفيد من أنابيب محتوى الميدياويكي، فسنتمكن من ضمان مستويات الخدمة (SLOs) وإيقاف تصدير XML المستند إلى "Dumps 1".
SDS1.2.3	إذا أجرينا جولة تعريفية وراجعنا مستويات الخدمة (SLOs) لسجل محتوى ميدياويكي ومنصة الأحداث/بوابة الأحداث، يمكننا التحقق من صحة العملاء والمقاييس والجهات المعنية التابعة، وتحديد التحسينات التي قد تكون ضرورية لمستويات الخدمة (SLOs)، مما سيساعدنا على توضيح أي ثغراتٍ في ضمانات التسليم الأسبوعية لدينا.
SDS2.1.1	إذا تعاونّا بشكلٍ وثيق مع الفرق التي تُجري التجارب، فسنتعلم كيفية جعل النظام أكثر ذاتية الخدمة في المستقبل، وما هي التحديات المفاهيمية أو التقنية التي قد تواجهها.
SDS2.1.2	إذا تمكنّا من تطبيق تصحيح أخطاء أفضل لتسجيل الأحداث، فستعرف فرق المنتجات أن تجربتهم تجمع بيانات الأحداث كما هو متوقع، مما يزيد من ثقة القائمين على التجربة.
SDS2.1.3	إذا حسّنّا التسجيل وإمكانية المراقبة لمكوّن نظام اختبار A/B (xLab) في منصة التجارب، ولأجزاء ميدياويكي المرتبطة به، فسنتمكن من وضع خطوط أساس لأداء النظام والاستجابة للأعطال المتعلقة بالتجارب.
SDS2.1.4	إذا شاركنا قصص التجارب ونتائجها على مستوى المؤسسة مرة واحدة شهريًا (من خلال اجتماعات عمليات المنتج، واجتماعات فريق التصميم، والعروض التقديمية المشتركة بين الفرق)، فسنُرسّخ استخدامًا عضويًا لمنصة التجارب.
SDS2.1.5	إذا أخبرنا المستخدمين أن أداتهم، إذا تم إنشاؤها في xLab، تحتوي على مجموعة من السمات التي تغير فئة المخاطر، فسنمنع مستخدمي الأدوات من جمع البيانات بشكلٍ مفرط ونزيد من الوضوح حول مجموعة السمات التي تتطلب مراجعة الخصوصية.

فرضيات الجمهور المستقبلي (FA) [ النتائج الرئيسية للجمهور المستقبلي ] نقاش
الاسم المختصر للفرضية	نص الربع الأول (Q1)	التفاصيل والنقاش
FA1.1.1	إذا قمنا 1) بتقديم طرق لجامعي الوسائط على منصات أخرى (مثل ليتربوكسد وغودريدز وريت ماي ميوزك) لتعزيز مجموعاتهم بمعرفة حصرية على ويكيبيديا، أو 2) تقديم مواد مثيرة للاهتمام لجامعي الوسائط على وسائل التواصل الاجتماعي، فسنكون قادرين على زيادة وصول ويكيبيديا خارج المنصة.
FA2.1.1	إذا قمنا ببناء قدرتنا الداخلية على إنشاء محتوى فيديو قصير (من خلال زيادة حجم فريقنا والتدقيق وتحديد الفرص لزيادة الكفاءة في عملية الإنتاج الحالية لدينا) في الربع الأول، فسنكون قادرين على العمل على الدروس المستفادة من المحتوى الذي تم إنشاؤه في السنة المالية 2024-2025 وتحقيق وصول أعلى على أساس سنوي للمحتوى المنتج في الربع الثاني من السنة المالية 2025-2026.

فرضيات دعم المنتج والهندسة (PES) [ النتائج الرئيسية لدعم المنتج والهندسة ] نقاش
الاسم المختصر للفرضية	نص الربع الأول (Q1)	التفاصيل والنقاش
PES1.1.1	إذا دعمنا xLab وCharts وToneCheck في تحديد المقاييس الخاصة بمؤشرات مستوى الخدمة (SLIs) في بروميثيوس، وقمنا بدمج أهداف مستوى الخدمة (SLOs) هذه في بيرا، فسوف نتعلم حدود وحالات الزاوية لأدواتنا في سيناريوهات معقدة متعددة، بالإضافة إلى توضيح التكرارات المطلوبة لقالب هدف مستوى الخدمة، مما سيساعدنا على دعم أهداف مستوى الخدمة الستة المخطط لها بشكل أفضل للنتائج الرئيسية.
PES1.1.2	إذا جرّبنا مجموعتين من لوحات معلومات تنبيهات هدف مستوى الخدمة (SLO)، فسنكتشف مدى صعوبة تطبيق أدوات مناسبة تُمكّن مالكي الخدمات من فهم التزاماتهم بوضوح، وسنكتشف أيضًا ما إذا كنا بحاجة إلى الانتقال إلى أداة مختلفة تُقدّم عرضًا واحدًا فقط لمستوى خدمة مُحدّد. ستكون إحدى لوحات المعلومات مُخصّصة للتقارير الفصلية (حيث تحدد اتفاقية مستوى الخدمة الفعلية لميزانية الأخطاء)، بينما ستكون لوحة معلومات ديناميكية أصغر (تُسمّى "متجددة") مُخصّصة للعمليات اليومية والتنبيهات.
PES1.1.3	إذا واصلنا دعم مجموعة ويكيبيديا المجردة في صياغة (أهداف مستوى الخدمة) لمشروع ويكي دوال، فسنتعلم كيفية تحديد قائمة بأهداف مُستوى الخدمة (مع مقاييس مستوى الخدمة الخاص بها) لميزة مُعقدة تُضاف حاليًا إلى سير عمل مُستخدم مُهم: عرض مقالات الويكي. سنتعلم أيضًا كيفية عرض ميزانيات الأخطاء ذات الصلة بشكلٍ صحيح والتنبيه إليها باستخدام لوحات المعلومات والشاشات التي تُوفرها هندسة موثوقية الموقع.
PES1.1.4	إذا دعمنا مجموعة منصة البيانات من خلال مراجعة وتكرار أهداف مستوى الخدمة لمشروع تاريخ محتوى الميديا ويكي، فسنتعلم كيفية الاستفادة من أهداف مستوى الخدم لدعم ملكية الخدمة عندما تُنسق مجموعة من خدمات المعالجة الدفعية والتدفقية معًا لتحديث مجموعة البيانات، والحفاظ عليها متسقة ومتاحة للمستخدمين النهائيين.
PES1.2.1	إذا أنشأنا 3 تحسينات مستهدفة لقائمة الأمنيات، فسنقوم بتشجيع زيادة عدد المشاركين الفريدين في قائمة الأمنيات بنسبة 30%
PES1.2.2	إذا فرزنا الأمنيات الواردة وتعيين مسؤول صيانة (مثل مديري المنتجات) في غضون 72 ساعة (بما في ذلك الرفض والتوضيح والإشارة إلى الخدمات غير الخاضعة للصيانة وغيرها)، من خلال الإشارة المتبادلة إلى الأمنيات الجديدة مقابل جدول مسؤولي الصيانة وتعيين "فئة مسؤول الصيانة" للفريق أو الفرد الأكثر صلة بالمنتج، فسيكون مسؤولو الصيانة (مثل مديري المنتجات) قادرين على تقييم الأمنيات والرد عليها في غضون 10 أيام أو أقل.
PES1.2.3	إذا جربنا العمل لتحديد إشارات المجتمع على نطاقٍ واسع، فسوف ندمج المزيد من صوت المتطوعين في جهودنا لتحديد الأولويات التي تأخذ في الاعتبار المجتمع.
PES1.2.4	إذا جربنا عملية مراجعة الأمنيات والإشارات المجتمعية ربع السنوية مع 3 فرق في الربع الأول، فسنقوم بإشراك مديري المشروعات لدمج إشارات المجتمع في عمليات التخطيط الفصلية والسنوية الخاصة بهم.
PES1.3.1	إذا قمنا، بحلول نهاية الربع الأول، بتنسيق 3 جلسات تخطيط وظيفية مع قسم الاتصالات وفرق المنتجات للتنسيق بشأن الرسائل والاحتياجات الإبداعية وجداول زمنية للحملات لمبادرات WP25، فسوف ننتهي من وضع الموجزات الإبداعية لجميع تجارب الحملات الثلاث (25YiR، Easter Eggs، WikiRun).
PES1.3.2	إذا أنشأنا لجنة توجيهية تضم ممثلين عن قسمي التصميم وهندسة الميزات، فسنتمكن من تحديد معايير أساسية للمساهمات في كوديكس: الوعي، والاستخدام، وجودة المساهمات، وكميتها. ستساعدنا الرؤى المستقاة من التقييم بناءً على هذه المعايير الأساسية في تحديد خارطة طريق لتوحيد نمو قاعدة مساهمي كوديكس وتنويعها.

الربع الثاني

يغطي الربع الثاني (Q2) من الخطة السنوية لمؤسسة ويكيميديا الفترة من أكتوبر إلى ديسمبر.

أبرز نتائج تجارب ويكي الفرضيات [ أبرز نتائج تجارب ويكي ] نقاش
الاسم المختصر للفرضية	نص الربع الثاني	التفاصيل والمناقشة
WE1.1.1	إذا حللنا مجموعة محددة مسبقًا من المؤشرات الرائدة بعد أسبوعين على الأقل (≥2 weeks) من بدء اختبار أ/ب (A/B test) لخاصية "التحقق من اللصق"، فسوف نكون قادرين على تحديد جوانب التجربة الشاملة التي تحتاج إلى تعديل أو تحقيق - إن وجدت - قبل أن نصبح واثقين من تقييم أثر الميزة.
WE1.1.4	إذا تطبقنا "التحقق من المرجع" على ويكيبيديا الإنجليزية من خلال تجربة مُنضبطة، فسنشهد زيادة بنسبة 4% على الأقل (≥4%) في التعديلات البنّاءة التي ينشرها المتطوعون الجدد (أو الأحدث)، وسنتعلم ما إذا كان هناك دعم كافٍ بين المُرَاقِبين والمُشرفين لـ تمكين الميزة على نطاق أوسع.
WE1.1.7	إذا حللنامجموعة محددة مسبقًا من المؤشرات القيادية بعد مرور أسبوعين أو أكثر على بدء اختبار أ/ب لميزة فحص النبرة، فسنتمكن من تحديد الجوانب –إن وُجدت– في التجربة الشاملة التي تحتاج إلى تعديل أو مزيد من التحقيق، قبل أن نصل إلى مستوى ثقة يسمح لنا بتقييم أثر الميزة.
WE1.1.8	إذا تطبقنا نموذج "التحقق من النبرة" على المقالات المنشورة، فسوف نتعلم ما إذا كان بإمكاننا تحديد 10,000 مشكلة نبرة أو أكثر (≥10,000 tone issues) (لكل منها درجة احتمالية 0.8 أو أعلى) اللازمة لـ بناء مجموعة اقتراحات عالية الجودة (بمعدل دقة 70% أو أعلى) للمساعدة في توجيه المحررين لتحسين نبرة المقالة.
WE1.1.10	إذا أجرينا مقابلات مع حوالي 10 متطوعين ذوي خبرة في ويكيبيديا الإنجليزية والفرنسية الذين يكتبون فلاتر إساءة الاستخدام (وغيرها من الأدوات/السكربتات/القوالب/إشعارات التعديل) لأتمتة سير عمل المراقبة/الإشراف، فسوف نحدد ≥3 أنماط/احتياجات ستساعد في تشكيل عرض القيمة لـ "تدقيقات التحرير" التي يضعها المجتمع.
WE1.1.11	إذا وزعنا استبيان على ≥ 500 من الوافدين الجدد الناجحين[i] وحصلنا على بيانات عالية الجودة تكون ممثلة لشريحة الوافدين الجدد الناجحين الأوسع، فسوف نكون قادرين على تحديد ≥4 رؤى قابلة للتنفيذ يمكننا استخدامها لتحديد أولويات جوانب تجربة الانضمام التي يجب تحسينها.
WE1.1.12	إذا قمنا بتمكين متطوعين من تقييم ≥30 تعديلاً عيّنة لكل متطوع، وذلك لكل لغة من اللغات العشر الجديدة التي نسعى إلى توسيع نطاق "التحقق من النبرة" إليها، فسوف نتعلم مدى تكرار اتفاق المتطوعين مع تنبؤات النموذج ونكون قادرين على تحديد الويكيات الجديدة التي يجب التواصل معها بشأن تطبيق "التحقق من النبرة" عليها.
WE1.1.13	ظرًا لأننا وسّعنا نطاق "إضافة رابط" ليصل إلى 100% من المتطوعين الأحدث في ويكيبيديا الإنجليزية، فسوف يتحسن تفعيل الوافدين الجدد بطريقة بنّاءة واستبقائهم، مما سيؤدي إلى زيادة التعديلات البنّاءة التي يجريها المتطوعون الأحدث بنسبة ≥4%.
WE1.2.3	إذا أزلنا الشرط الذي يقضي بضرورة حصول شخص ما على صلاحية "مُنظِّم فعالية" لاستخدام "تسجيل الفعاليات" في الويكيات الصغيرة والمتوسطة الحجم، فسوف نشهد إنشاء X فعالية إضافية على الأقل* في الويكيات الصغيرة والمتوسطة الحجم بحلول نهاية السنة المالية. في انتظار حساب خط الأساس/الهدف.
WE1.2.4	إذا قمنا بالتكرار على الحد الأدنى للمنتج القابل للتطبيق للمساهمات التعاونية بإدخال تحسينين اثنين على الأقل، فسوف يتم إنشاء المزيد من عمليات التعاون عبر تسجيل الفعاليات.
WE1.2.5	إذا وضعنا استراتيجية اعتماد واحدة لـ "تسجيل الفعاليات" على ويكيميديا كومنز في أوائل الربع الثاني (Q2)، فسوف نكون قادرين على اختبارها مع منظمي حملة كبيرة واحدة على الأقل، وتمكين 5 منظمين محليين من استخدام الميزة.
WE1.3.3	إذا أطلاقنا تجربة لعرض لوحة معلومات للمُشرفين على المحررين الأحدث، فإن 10% من المساهمين الذين يزورونها سيفعلون ذلك لأسبوعين متتاليين.
WE1.4.1	إذا قمنا بإجراء التحسينات المحددة في T396489، فسوف نقلل من استعلامات "التغييرات الأخيرة" البطيئة بنسبة 30% على الأقل على الويكيات الكبيرة، مما سيمكن فريق التقنية المجتمعية من تطبيق تصنيفات قائمة المراقبة دون إثقال كاهل قاعدة بيانات التغييرات الأخيرة.
WE1.4.3	إذا قمنا بتجهيز "التغييرات الأخيرة" و"قائمة المراقبة" بأدوات القياس، فسوف نتمكن من تعريف خط أساس لـ معدل النقر على الصفحات من قِبل الأشخاص.
WE1.5.1	إذا قمنا بتطبيق لوحة معلومات لاستكشاف 7 مقاييس للمساهمين وتوحيد طريقة حساب مقياس واحد على الأقل باستخدام أداة dbt، فسوف نتمكن من تمكين فرق منتجات المساهمين من الاستعلام الذاتي عن رؤى المقاييس وتطوير معيار لتخزين منطق حساب المقاييس.
WE1.5.2	إذا قمنا بتحديد الإجراءات الإشرافية التي سيتم تضمينها في تعريف "من هو المُشرف" في الربع الثاني (Q2)، فسيكون بإمكان فريق رؤى الحركة بناء مقياس "المُشرفون النشطون شهريًا" في الربع الثالث/الرابع (Q3/Q4).
WE2.1.3	إذا تعلمنا عن تجربة المُحرِّر عند إنشاء مقالات وأقسام جديدة (بما في ذلك الدوافع، ونقاط الألم، ورد فعلهم تجاه الأفكار الجديدة حول كيفية دعمهم بشكل أفضل)، فسوف نكشف عن احتياجات وسلوكيات المستخدمين التي توفر رؤى واستراتيجيات قابلة للتنفيذ لتوجيه أقسام المنتجات والتصميم والهندسة بشأن تحسين تجربة إنشاء المقالات.
WE2.2.12	إذا قمنا بطرح "ويكي دوال" على الويكيات التي تم تمكين بارسويد فيها، فسنكون قادرين على مواصلة الاختبار لمعرفة ما إذا كان النظام يظل فعال الأداء وقابلًا للاستخدام في عمليات الطرح الأوسع بشكل متزايد.
WE2.2.13	إذا قمنا بالتوعية بتوفر دالة جدول التصريف مع مجتمع ويكاموس ، فسوف نكتسب تعليقات قيّمة حول استخدام الدالة ورؤى حول شخصيات المستخدمين لدينا يمكننا تطبيقها على عمليات الطرح المستقبلية.
WE2.2.14	إذا نظرنا في عمل المجتمع المتعلق بـ "صندوق البيانات" بشأن استخدام ويكيداتا لصناديق المعلومات، والتحقيق فيما إذا كانت "ويكي دوال" قد تساعد في ذلك، فسوف نتمكن من تحديد تجربة أولى لـ "ويكي دوال" في صناديق المعلومات.
WE2.2.15	إذا قمنا بخلق وعي مجتمعي حول القدرة على إنشاء وترجمة رسائل الخطأ على "ويكي دوال"، فسوف نشهد زيادة في عدد رسائل الخطأ المفيدة.
WE2.2.16	إذا قمنا بعرض الدوال الدلالية المتاحة على المجتمع، فسوف نشهد زيادة في الدوال النحوية بنسبة 50%.
WE2.2.17	إذا قمنا بتوفير مكوّن مخصص لـ عرض بيانات ويكيداتا على "ويكي دوال"، فسيكون المستخدمون أكثر قدرة على فهم البيانات المستجلبة من ويكيداتا ويشعرون بوطأة أقل.
WE2.2.18	إذا تمكنا من منع ارتفاعات استهلاك الذاكرة بمقدار 10 أضعاف، فسيكون المُنسِّق أكثر قدرة على التعامل مع كائنات ويكيداتا، مما يدعم فائدة "ويكي دوال" كـ منصة لـ "ويكيبيديا التجريدية".
WE2.2.19	إذا قمنا بتمكين المستخدمين من مشاركة روابط مباشرة لاستدعاءات دوال محددة — بما في ذلك مدخلاتها — فسيكون بإمكان المساهمين إعادة إنتاج، والتحقق من، ومناقشة سلوك الدالة بسهولة أكبر، مما سيؤدي بدوره إلى تسريع عملية تصحيح الأخطاء، وتحسين سير عمل الاختبار، ودعم حل المشكلات التعاوني عبر مجتمع "ويكي دوال".
WE2.3.1	إذا قمنا بوضع اللمسات الأخيرة على قرار إنشاء ويكي جديد وقررنا اسمًا له مع المجتمع، فسوف نتمكن من التوعية بإنشاء هذا الويكي الجديد على نطاق أوسع مع أصحاب المصلحة لدينا والتحضير للخدمات اللوجستية الخاصة بـ تغيير محتمل لاسم المنتج.
WE2.3.2	إذا قمنا بتعريف الحد الأدنى للمنتج القابل للتطبيق لـ نموذج أولي لويكي تجريدي، يتضمن أقل تجربة ممكنة لاختبار قدراتنا الخلفية وتوليد اللغة الطبيعية، ويسمح لنا بالتصميم التكراري، فسوف نكون قادرين على التخطيط وإطلاق نموذج أولي مباشر في الربع الثالث.
WE2.3.3	إذا بدأنا التواصل مع المجتمع واستكشاف التصاميم المحتملة لتجربة المستخدم الخاصة «بويكي المجرّدة»، فسنكون قادرين على مواصلة سير العمل خلال الربع الثالث.
WE2.4.1	إذا قمنا بجمع حالات استخدام لـ ويكيداتا وخدمة استعلامات ويكيداتا من فرق ويكيميديا ألمانيا ومؤسسة ويكيميديا، فسوف نكون قادرين على تحديد متطلبات المنتج لـ تحسينات البنية التحتية.
WE2.4.2	إذا قمنا بإنشاء عرض تقارير مُجمّع لـ مؤشرات الأداء الرئيسة مع أهداف مستوى الخدمة الحالية لـ ويكيداتا وخدمة استعلامات ويكيداتا، فسوف نكون قادرين على تحديد وتتبع معايير النجاح للتحسينات التي تطرأ على البنية التحتية التقنية التي تدعم حالات الاستخدام الحيوية لويكيداتا.
WE2.4.3	إذا تمكنا من تقييم ومقارنة المخازن البديلة لـ Blazegraph باستخدام معايير واقعية للإنتاج خلال هذا الربع، فسوف نكون قادرين على اتخاذ قرار ترحيل يستند إلى البيانات وتحديد خارطة طريق ملموسة تتضمن الجدول الزمني ومتطلبات الموارد.
WE3.1.1	إذا قمنا بإجراء اختبار أ/ب لـ نسخة مُحسَّنة من ميزة "التصفح المبوب"، فسوف نشهد زيادة بنسبة 5% في الاستخدام متعدد الأيام بين مستخدمي الميزة.
WE3.1.3	إذا وفرنا طريقة جديدة للمستخدمين لـ تصفح محتوى الصور ذات الصلة ضمن صفحات المقالات، واختبرناها مع مجموعة فرعية من القراء غير المُسجَّلين عبر اختبار أ/ب عبر مجموعة من الويكيات، فسوف نشهد معدل نقر لا يقل عن 3% بين المستخدمين الذين تُعرَض عليهم هذه الميزة.
WE3.1.4	إذا قمنا بعرض عدة مفاهيم على القراء لـ استعراض شبكة المعرفة على الويكيات، فسوف نخرج بقائمة مفاهيم ذات أولوية لـ مواصلة التطوير.
WE3.1.5	إذا وفرنا خيار لقراء الويب لعرض نسخة مترجمة آليًا من محتوى ويكيبيديا غير المتاح بلغتهم، فسوف نتعلم ما إذا كان نشاط القراءة قد ازداد، ويُقاس ذلك بزيادة بنسبة 3% في تفاعلات الصفحة، مما يجذب القراء إلى الويكي باللغة المحلية مع زيادة محتملة في نشاط التحرير المحلي. سيتم توفير هذا الخيار كـ إعداد اختبار أ/ب مُنضبط لمدة لا تزيد عن 6 أشهر، وفي 13 ويكيبيديا بموافقة مسبقة، باستخدام خدمات الترجمة الآلية المفتوحة المتاحة بالفعل لمحرري ويكيبيديا.
WE3.1.6	إذا قمنا بإنتاج نموذج أولي لـ البحث الدلالي وأسئلة وأجوبة داخل المقالة، يتم تقديمه كـ واجهة عرض توضيحي تقارن بين النهج الحالي والنهج الاستكشافية الجديدة، فسيكون بإمكان فرق القراء تقييم نوعي لكيفية أداء كل نهج عبر مسارات مستخدمين مختلفة، والكشف عن الثغرات أو الفرص لمزيد من التكرار والتطوير.
WE3.1.7	إذا قمنا بمراجعة الأبحاث الحالية حول كيفية تفاعل القراء مع أدوات البحث والتنقل في ويكيبيديا، وكيفية استخدامهم للبحث الخارجي للعثور على المعرفة في ويكيبيديا، فسوف نتمكن من تزويد فرق القراء بـ ≥3 توصيات ونتائج قابلة للتنفيذ تساعدهم في تحديد نطاق الحد الأدنى للمنتج القابل للتطبيق للبحث والاستكشاف، لمعالجة الثغرات في توقعات واحتياجات القراء.
WE3.1.8	إذا قمنا بتقييم نموذجين أوليين للبحث الدلالي (البحث باللغة الطبيعية، والأسئلة والأجوبة) مع مشاركين خارجيين، فيمكننا معرفة ما إذا كان المستخدمون يرون قيمة في أدوات البحث المُحسَّنة، وتزويد فرق القراء بتوصية حول كيفية المضي قدمًا بالحد الأدنى للمنتج القابل للتطبيق للبحث والاستكشاف.
WE3.1.9	إذا عرضنا مفاهيم تصميم عالية الدقة لـ اكتشاف المحتوى من خلال البحث الدلالي على 10-20 من قراء ويكيبيديا العاديين في دراسة نوعية، فسوف نرى شعورًا إيجابيًا تجاه الميزة ونكتسب الثقة اللازمة للمضي قدمًا في الحد الأدنى للمنتج القابل للتطبيق (MVP) للبحث والاستكشاف والذي يعتمد على مقتطفات قصيرة مكتوبة بواسطة البشر لـ استعلامات البحث.
WE3.1.10	إذا عرضنا نموذج أولي مُباشر لتجربة تصفح الصور الجديدة على 10 قراء عاديين ضمن دراسة مستخدم غير مُراقَبة، فسوف نكشف عن تحسين واحد على الأقل في تجربة المستخدم للتكرارات المستقبلية للميزة.
WE3.1.11	إذا قمنا بتخفيف مطابقة الكلمات المفتاحية في البحث، فسوف ندعم بشكل أفضل استعلامات اللغة الطبيعية، ونمكّن فريق المنتج من تقييم هذه القدرة، وتضمينها في كيفية تصميمهم وتحديد أولوياتهم وإنجازهم للعمل في مجال البحث الدلالي.
WE3.1.14	If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3)	T409163
WE3.2.5	إذا قدمنا ميزة "حصاد العام" على نظام أندرويد، تسلط الضوء على أثر المستخدم وتتضمن رسائل تبرع مُدمجة، فسوف ندفع سلوكًا جديدًا للتبرع — وسنشهد زيادة بنسبة 5% في تفاعل قائمة التطبيق مقارنة بعام 2024.
WE3.2.6	إذا قمنا بجعل شرائح المُتبرّع في ميزة "حصاد العام" على نظام iOS أكثر اندماجًا وتخصيصًا، فسوف نشهد زيادة بنسبة 5% في التبرعات مقارنة بعام 2024.
WE3.3.3	إذا قمنا بتقديم صورة رمزية واحدة قابلة للفتح على الأقل في تطبيق أندرويد لأصحاب الحسابات — تُكتسَب من خلال إجراءات قراءة ذات مغزى مثل حفظ عدد معين من المقالات — فسوف نزيد من التفاعل المُتكرر مع الإجراء المرتبط من قِبل المستخدمين المُسجَّلين بنسبة 10% على مدى أيام متعددة.
WE3.3.4	إذا أتحنا للقراء المُسجَّلين الدخول القدرة على حفظ المقالات في "قائمة قراءة خاصة"، فإننا نتوقع أن يزداد التفاعل على الموقع، ويُقاس ذلك بزيادة بنسبة 5% في حركة الإحالة الداخلية للقراء الذين يستخدمون الميزة، وزيادة ذات دلالة إحصائية لجميع المستخدمين.
WE3.3.6	إذا قمنا بإتاحة بيانات استدلال موضوع المقالة عبر خدمة تُلبي متطلبات التوسع والتوافر المتفق عليها، بالإضافة إلى أي عمليات استرجاع ضرورية للبيانات، فسوف نكون قد أرسَيْنا الأساس التقني اللازم لدعم تجارب القارئ المُخصَّصة القادمة التي تعتمد على هذه البيانات.
WE3.3.7	إذا الاستفادنا من قدرات معالجة منصة البيانات لـ تجميع مقاييس المحررين وبيانات الأثر المُخصَّصة، وتقديم البيانات المُجمَّعة عبر خدمات مناسبة ذات أهداف مُحدَّدة لمستوى الخدمة، فيمكننا تعزيز التكرارات المستقبلية لكل من "حصاد العام"(الذي كان أبرز نتائج تجربة ويكي 1.3.3) و"علامة تبويب النشاط"(الذي كان أبرز نتائج تجربة ويكي 2.3.3)
WE3.3.9	إذا قمنا بإطلاق ميزة حصاد العام على نظام أندرويد واختبرنا أ/ب لـ تقديم مكافأة للمستخدمين المتفاعلين لحفظ "قائمة قراءة مُخصَّصة"، فسوف نشهد زيادة بنسبة 1% في معدل استبقاء التطبيق الإجمالي بين القراء الذين عُرضت عليهم المكافأة مقارنة بأولئك الذين لم تُعرض عليهم.
WE3.3.10	إذا قمنا بإجراء اختبار أ/ب يفرض ضرورة وجود حساب لعرض "رؤى القراءة المُخصَّصة" في ميزة "حصاد العام"، فسوف نشهد زيادة بنسبة 1% في معدل الاستبقاء الإجمالي للمستخدمين الذين اقتُضِي منهم امتلاك حساب، مقارنة بأولئك الذين لم يُطلب منهم ذلك.
WE3.3.11	إذا قمنا بإجراء اختبار أ/ب لـ نسخة مُحسَّنة من "علامة تبويب النشاط" على نظام iOS، تسلط الضوء على سلوكيات القراءة والتحرير والمشاركة الأخرى، فسوف نشهد زيادة بنسبة 5% في زيارات القراء المُسجَّلين الدخول للعلامة على مدى أيام متعددة مقارنة بالنسخة التجريبية
WE3.4.1	إذا عملنا على نشر "نقطة حضور هجينة" (PoP/CDN)، فسوف يتيح لنا ذلك تفعيل كل من نقاط الحضور الكاملة ونقاط الحضور المصغرة (مادية وسحابية) حسب الحاجة، مما يُرسي الأساس لـ نشر نموذج أولي لنقطة حضور مصغرة في المستقبل.
WE3.5.1	ذا قام فريقا المنتج والتقنية وجمع التبرعات بالتقييم والتوثيق التعاوني للنهج التقنية المتبعة لتحديد هُوية المتبرعين ضمن منصاتنا، فسوف نكون قادرين على التوصية بحل قصير وطويل الأمد يوازن بين الخصوصية والجَدوى والأثر. سيساعد هذا الفهم المشترك في مواءمة عملية اتخاذ القرار، وتمكين التعرف المستمر على المتبرعين عبر المنصات، بالإضافة إلى إجراء تجارب أكثر استهدافًا في الميزات المستقبلية المتعلقة بجمع التبرعات.
WE3.6.3	إذا قمنا بإشراك المجتمعات في محادثات حول الاحتياجات المتطورة للقراء، وحول الطبيعة المتغيرة للمعرفة على الإنترنت، فيمكننا بناء تركيز مشترك على كيفية خدمة القراء والعمل معًا بشأن ما إذا كان يجب علينا اختبار أفكارنا المختلفة وكيفية القيام بذلك (بما في ذلك تلك المتعلقة بـ الوسائط المتعددة، والبحث والاستكشاف، والتعلم الآلي).
WE3.6.4	إذا قمنا بدراسة الدوافع والسلوكيات والاحتياجات المختلفة التي تكمن وراء متى ولماذا وكيف يستخدم القرّاء ويكيبيديا وغيرها من منصات المعرفة، فسيمكننا عندئذٍ اقتراح مجالات أولوية ومبادرات محددة ضمن استراتيجية المستهلك.
WE3.6.5	إذا تعاون فريقا المنتج والتقنية وجمع التبرعات على وضع استراتيجية مشتركة تهدف إلى تنويع فرص التبرع داخل المنصة، ورعاية وتقدير القرّاء الذين يساهمون بالتبرع، فسنتمكن من وضع أهداف واضحة ومنسقة ومعايير قياس مرتبطة باستراتيجيتَي المستهلك وجمع التبرعات.
WE3.6.6	إذا قمنا بوضع استراتيجية موحّدة للقياس، فسنتمكن من تقييم استراتيجية المستهلكين متعددة السنوات، وتحديد خارطة طريق تساعد في توجيه تطوير المقاييس وتعزيز قدرات إعداد التقارير.
WE4.1.1	إذا قمنا بتصميم نموذج أولي لتدفق عمل مبدئي في الحالات غير الطارئة، وحافظنا على حلقة تغذية راجعة مستمرة أثناء تطويره بالتعاون مع المستخدمين ذوي الصلاحيات الموسّعة، فستدعم هذه المجموعات توسيع نطاق تطبيق هذا التدفق.
WE4.1.3	إذا قمنا بتحديث سبع نسخ من ويكيبيديا (الفرنسية، الألمانية، الإسبانية، الهنغارية، الإيطالية، البولندية، والبرتغالية) بحلول نهاية شهر أكتوبر، فسنكون بذلك قد أتممنا المرحلة الأولى من إطلاق التذييل القانوني الجديد استجابةً لمتطلبات قانون الخدمات الرقمية
WE4.1.4	إذا قمنا بنشر النسخة الأولية القابلة للاستخدام من نظام الإبلاغ عن الحوادث في ما لا يقل عن 15 موقع ويكي، مع التركيز على المجتمعات الأكبر والأكثر تعقيدًا، فسنلاحظ استخدام النظام بالطريقة التي يقصدها المجتمع، وبذلك نكون قد أثبتنا فعالية نموذجٍ عمليٍ للإبلاغ عن الحوادث غير الطارئة.
WE4.1.5	إذا قمنا بتصميم مخطط تدفقي للإبلاغ عن حوادث الإساءة في مواقع الويكي التي لا تمتلك بعد آليات معالجة إساءة معتمدة، فسيُسهم ذلك في تشجيع اعتماد نظام الإبلاغ عن الحوادث في تلك المواقع، كما سيمكن مستخدميها من اتباع مسار دعم واضح وفعّال.
WE4.2.3	إذا قمنا بتحليل البيانات الناتجة عن تجربة إنشاء الحسابات باستخدام اختبار التحقق من الإنسان (hCaptcha)، فسنتمكن من فهم مسار إنشاء الحسابات، وتقييم مدى فعالية اختبارات التحقق من الإنسان (hCaptcha) ونتائجها، والحصول على البيانات اللازمة لاتخاذ قرارات مستنيرة بشأن توسيع استخدام اختبار التحقق من الإنسان (hCaptcha) في عمليات إنشاء الحسابات.
WE4.2.5	إذا قمنا بإجراء البحوث، والتشاور مع المجتمعات المحلية، ودراسة الحلول التقنية المتاحة، فسنتمكن من تحديد مجموعة من أسباب الحظر المهيكلة التي يمكن استخدامها عبر جميع مواقع ويكي التابعة لمؤسسة ويكيميديا.
WE4.2.6	إذا قمنا بتطوير إمكانية نشر مجموعات تعتمد على OpenSearch ضمن منصة البيانات، فسيمكّن ذلك فرق هندسة ميزات المنتج من تطوير أنظمة تدمج هذه الإمكانية مع قدرٍ عالٍ من الاستقلالية والمرونة والعزل عن الأنظمة الأخرى المعتمدة على البحث. وسيكون خدمة IPoid أول وأهم مستفيد (tenant) من هذا النظام.
WE4.2.7	إذا قمنا بنشر تكامل نظام التحقق البشري hCaptcha – الإصدار المؤسسي. على عدد من نسخ ويكيبيديا التشغيلية كمرحلة تجريبية أولى، فسنتمكن من جمع بيانات حول فعالية وقيمة نظام التحقق البشري hCaptcha – الإصدار المؤسسي. في مجالات مكافحة الإساءة، واكتشاف الروبوتات، وسهولة الاستخدام، وإمكانية الوصول.
WE4.2.8	إذا قمنا بجعل الوكيل (البروكسي) الخاص بـ hCaptcha جاهزًا للإنتاج من خلال تحسين مستوى توفره وقابليته للمراقبة، فسنقدم بذلك خدمة أكثر استقرارًا وموثوقية لنسخ ويكيبيديا التشغيلية خلال الربع الأول من العام.
WE4.2.9	إذا قمنا بدمج حزمة تطوير البرمجيات الخاصة بـ اختبار التحقق من الإنسان (hCaptcha) في تطبيقات ويكيبيديا الأصلية للهواتف المحمولة، وقمنا بتقييم تجربة المستخدم في هذه التطبيقات، إلى جانب دراسة إمكانية تفعيل اختبارات التحقق من الإنسان (hCaptcha) ضمن واجهة برمجة تطبيقات إنشاء الحسابات، فسنحصل على فهم كافٍ يتيح لنا اتخاذ قرارات مدروسة بشأن التوسّع المستقبلي لاستخدام اختبار التحقق من الإنسان (hCaptcha) في واجهة إنشاء الحسابات.
WE4.2.11	إذا قمنا بتفعيل اختبار التحقق من الإنسان (hCaptcha) لاكتشاف الروبوتات في سيناريوهات التحرير عالية الخطورة، فسنلاحظ أن اختبار التحقق من الإنسان (hCaptcha) يسهم في الحد من الإساءة الآلية.
WE4.2.16	إذا قمنا بالتشاور مع الفرق المعنية في مؤسسة ويكيميديا (WMF)، فسنتمكن من وضع خطة متفق عليها لإدارة الوصول التفصيلي للمستخدمين إلى البيانات غير العامة، ودعم نشر قواعد برمجية دفاعية غير علنية.
WE4.2.17	إذا قمنا بتحليل أمثلة واقعية وأجرينا مقابلات مع مستخدمي صلاحية الفحص بهدف تحديد إشارتين على الأقل تدلان على سلوك مسيء محتمل بالاستناد إلى النموذج الأولي لتاريخ المحرّر، فسيتمكن فريق سلامة ونزاهة المنتج لاحقًا من دمج هذه الإشارات في ميزة “التحقيقات المقترحة” بدرجة أعلى من الثقة في أن تلك الإشارات ستضيف قيمة حقيقية.
WE4.3.2	إذا قمنا بنشر بصمات JA4H، وهي تقنيات تُستخدم لتلخيص سلوك عميل HTTP، فسنتمكن من تحسين قدرتنا على تحديد وتصنيف حركة مرور الروبوتات بشكل أدق.
WE4.4.1	إذا تمكنا من إجراء تحسينات استنادًا إلى ملاحظات التجارب الرائدة، ونشر نظام الحسابات المؤقتة في جميع المشاريع، فسنتمكن من حماية المعلومات الشخصية القابلة للتعرّف (مثل عناوين IP) الخاصة بالمستخدمين غير المسجلين، بحيث تصبح متاحة لأقل من 0.1٪ من إجمالي المستخدمين المسجلين عبر جميع مشاريعنا.
WE4.4.2	إذا تواصلنا بوضوح وفي الوقت المناسب مع أصحاب المصلحة المعنيين في الحركة، بما في ذلك مجتمعات الويكي والمسؤولون العالميون، فسنتمكن من نشر النظام في جميع مواقع الويكي المتبقية، وتقليل حجم العمل الطارئ في اللحظات الأخيرة، وتجنب الحاجة إلى التراجع عن عملية النشر.
WE4.4.5	إذا قمنا بتقليل الصعوبات التي تواجه المراقبين في تحديد المستخدمين المسيئين الذين يستغلون الحسابات المؤقتة لأعمال التخريب، فسنتمكن من منع زيادة معدلات التخريب، وهو ما سيتضح من خلال ثبات معدل الاسترجاع عبر جميع مواقع الويكي التي تستخدم الحسابات المؤقتة.
WE4.4.6	إذا قمنا بإيقاف امتداد نهائيًا، فسنتمكن من إزالة العقبات التي تعيق نشر نظام الحسابات المؤقتة في جميع المشاريع التي لا تزال تستخدم هذا الامتداد حاليًا.
WE4.6.1	إذا قمنا بأتمتة عملية مزامنة الحسابات في نظام زنديسك (Zendesk) لأغراض إعادة تعيين كلمات المرور، فسيسهم ذلك في تخفيف العبء عن فريق الثقة والأمان، مما يتيح لهم التعامل مع عدد أكبر من طلبات إعادة ضبط المصادقة الثنائية
WE4.6.3	إذا قمنا بتمكين جميع المستخدمين الذين لديهم عنوان بريد إلكتروني مؤكد من تفعيل ميزة المصادقة الثنائية (2FA) في حساباتهم، دون الإعلان عن هذا التغيير بشكل استباقي للمستخدمين، فسيظل عبء العمل على فريق دعم استعادة الحسابات ضمن مستوى مستدام يمكن التعامل معه.
WE4.6.4	إذا واصلنا تحديث تجربة المستخدم في نظام المصادقة الثنائية (2FA) وأضفنا دعم مفاتيح المرور، فسيقوم عدد أكبر من المستخدمين بتسجيل عوامل مصادقة متعددة، مما سيمنحهم حماية أفضل ضد فقدان إمكانية الوصول إلى حساباتهم.
WE4.6.5	إذا قمنا بتصميم وبناء إطار عام يُستخدم لتحديد المتطلبات التي يجب أن يستوفيها أعضاء المجموعات المحلية أو العالمية، فسنتمكن من استخدام هذا الإطار لضمان أن أعضاء مجموعة (temporary-account-ip-viewer) يلتزمون بمتطلبات السياسات القائمة.
WE4.6.6	إذا قمنا بدراسة كيفية اعتماد المستخدمين ذوي الصلاحيات الموسّعة (UWER) على السكربتات الشخصية، فسنتمكن من اقتراح خطة يمكن أن تحظى بدعم مجتمع UWER، تهدف إلى تنفيذ تدخلات تقنية جوهرية تُسهم في تعزيز أمان نظام السكربتات الشخصية بشكل فعّال.
WE4.6.7	إذا قمنا بتقييم تجربة المستخدم والتغييرات التقنية المطلوبة في تطبيقات الهواتف المحمولة الأصلية بهدف مواءمة تجربة تسجيل الدخول على الأجهزة المحمولة مع المنصة الويب، من خلال استكشاف آليات بديلة مثل OAuth، فسنتمكن من تحديد مدى جدوى التكامل، وذلك لضمان تجربة أكثر أمانًا واتساقًا للمستخدمين.
WE4.6.8	إذا قمنا بمراقبة أثر نماذج (Zendesk وMediaWiki) التي تم إنشاؤها خلال الربع الأول، فسنتمكن من اقتراح تدخلات تقنية مستقبلية في الأرباع القادمة، من شأنها تحسين أتمتة ما تبقّى من عملية استعادة الحسابات.
WE5.1.2b	إذا قمنا بدمج عدة أساليب لتعرّف المطورين والمصادقة عليهم ضمن بوابة واجهة برمجة التطبيقات، فسنتمكن من تعيين حدود معدل مناسبة لكل طلب، من خلال التعرّف الدقيق على الطلبات الصادرة من فئات المستخدمين المختلفة.
WE5.1.3b	إذا قمنا بتنفيذ تجربة تجريبية (dry run) لتطبيق حدود المعدل على ما لا يقل عن ثلاث مسارات في بوابة REST، فسيتيح لنا ذلك التحقق من جدوى تطبيق حدود المعدل من حيث استهلاك الموارد، وتحديد مجموعة أولية من الحدود التي يمكن تطبيقها دون تأثير يُذكر على تجربة المستخدم.
WE5.1.4b	إذا قمنا بالتحقق من صحة آليات تقسيم مستخدمي واجهة برمجة التطبيقات المقترحة باستخدام مجموعات بيانات أوسع ومراجعات يدوية للفئات المحددة، فسنتمكن من إقرار الفئات النهائية للمستخدمين، وتحسين المنهجيات المستخدمة في حسابها، وفهم مدى فعاليتها بشكل أدق.
WE5.1.5	إذا تعاونّا مع فريق منصة ميديا ويكي في مجال تحديد حركة المرور وتطبيق حدود المعدل، فسنتمكن من نشر ميزة تحديد المعدل لإجراء اختبار تجريبي (dry run) في بيئة الإنتاج، وذلك من خلال دعم فريق المنصة في تطوير هذه الإمكانية وتنفيذها.
WE5.2.1b	إذا تفاعلنا مع المستخدمين المحتملين لأداة استكشاف واجهة REST الجديدة، فسيساعدنا ذلك على تحديد أبرز الملاحظات المتعلقة بقابلية الاستخدام، والتي تُظهر ما إذا كان التصميم الجديد سهل الاستخدام ويتماشى مع النموذج الذهني للمطورين.
WE5.2.2b	إذا قمنا بتوجيه واجهة (Action API) عبر بوابة واجهة برمجة التطبيقات المركزية، فسنتمكن من قياس حركة المرور وأنماط الاستخدام بشكل منتظم، مما سيوفر رؤى ومعطيات تساعد في توجيه القرارات والإجراءات المستقبلية.
WE5.2.4	إذا قمنا بتطبيق أنماط توثيق معيارية على واجهتَي برمجة تطبيقات، فسنتمكن من تحسين إرشادات المحتوى، وفهم احتياجات مالكي واجهات البرمجة لتبنّي تلك الإرشادات، وتقدير حجم الجهد المطلوب لتطبيقها على بقية وثائق واجهات برمجة التطبيقات التابعة لويكيميديا.
WE5.2.5	إذا قمنا بتجربة وضع وتطبيق قواعد فحص تلقائي لمواصفات OpenAPI على واجهات REST الخاصة بميدياويكي (MediaWiki REST APIs)، فسنتمكن من إثبات إمكانية فرض أدلة أسلوب واجهات البرمجة (API style guides) برمجيًا، بما يسهم في رفع مستوى الجودة والاتساق في واجهات البرمجة المنشورة عبر مشاريع ويكيميديا ومجتمعاتها.
WE5.2.6	If we introduce access controls to the sitemap API to only allow trusted bots, we can improve strategic alignment and reduce the risk of abusive scraping.	phab:T406921
WE5.3.1	إذا قمنا بتوسيع وتبسيط إرشادات إسناد تجربة المستخدم مع تحديث أي إرشادات قائمة، فسوف نؤسس مجموعة أساسية من الإرشادات المُحسَّنة تكون جاهزة لـ الاختبار الداخلي والتنقيح التكراري، استعدادًا لـ استخدام عام أوسع.
WE5.3.1b	إذا قمنا بنشر إرشادات وتجارب المستخدم المسودة والتكرار عليها، فسوف نؤسس إطارًا أساسيًا جاهزًا لـ الاختبار الداخلي والتنقيح التكراري، استعدادًا لـ استخدام عام أوسع.
WE5.3.2	إذا قمنا بإنشاء عرض تقديمي يوضح فوائد إسناد ويكيبيديا لـ مُعيدِي استخدام محتوى الطرف الثالث ومستخدميهم النهائيين، فيمكننا دعم "أبرز نتائج تجارب ويكي 1.4" و"أبرز نتائج تجارب ويكي2.4" من خلال تمكين شريك إعادة استخدام إضافي واحد على الأقل من الموافقة على الظهور في دراسة حالة أو عرض توضيحي للإسناد بنهاية الربع الأول.
WE5.4.2b	إذا قمنا ببناء طريقة قابلة للتطوير لتحديد هُوية العملاء المعروفين، فيمكننا السماح باستثناءات لحدود المعدل العامة لـ الربوتات ذات المصدر المُوثَّق، والتحرك نحو التطبيق المنهجي لقواعدنا.
WE5.4.5	إذا بدأنا تطبيق حدود المعدل المخصصة لـ فئات مختلفة من العملاء الأفراد، فسوف نقلل من عبء الزحف على البنية التحتية الخاصة بنا.
WE5.4.6	إذا قمنا بتصنيف (classified) أفضل (top) عدد N من برامج الزحف (spiders) كـ روبوتات معروفة بحلول نهاية الربع الثاني، فيمكننا تقييد كمية الموارد التي تستخدمها.
WE5.4.7	إذا استقررنا على مجموعات موحدة لـ أحجام الصور المُصغَّرة المسموح بها على البنية التحتية للوسائط لدينا، وقمنا بتوليد الأحجام الأكثر تكلفة مُسبقًا بينما نُطبِّق حدودًا على معدل توليد أحجام الصور المختلفة، فسوف نقلل العبء على البنية التحتية لخدمة الوسائط.
WE6.1.2	إذا قمنا بإضافة "مزارع الويكي" إلى بيئة اختبار ما قبل الدمج، فسوف يُمكِّن هذا فرق التطوير التي تعمل بناءً على بيئة الإنتاج وتتطلب ويكيات متعددة لاختبار تصحيحاتها بمعزل عن غيرها، مما يمنحهم ثقة أكبر قبل الإنتاج ويؤدي إلى عدد أقل من عيوب التسرب.
WE6.2.1	إذا قمنا بمراجعة ونشر قائمة التحقق من جاهزية الإنتاج الخاصة بنا، والتي تُعرِّف بوضوح المتطلبات الأساسية لاعتبار أي خدمة جاهزة للإنتاج، بالإضافة إلى المهام التي يمكن إنجازها ذاتيًا، فسوف نُوائم التوقعات بين مهندسي موثوقية المواقع (SREs) وفرق التطوير، مما يُحسِّن من كفاءتنا التشغيلية الإجمالية وقابليتنا للتوسع
WE6.2.2	إذا قمنا بالإعلان عن إنشاء مكتبة بلغة جو ولغة تعمل على تجريد الكثير من المهام المُجهدة للمطورين، فسوف يستجيبون بتقديم التعليقات وإظهار الاهتمام.
WE6.2.4	إذا قمنا بتطبيق ودعم مراجعة تصميم "ثبات البيانات" بنشاط، فقد نتمكن من تحديد مسارات مُعبّدة تؤدي إلى الإنتاج.
WE6.3.2	إذا قمنا بتطوير مقاييس جديدة، وتحسين البنية التحتية لذاكرة التخزين المؤقت لـ "بارسويد"، ونشرها على اثنتين من ويكيبيديات "المراتب العشرة الأولى"، فسوف نطور معايير أداء لإطار الثقة، مما سيساعد في التحقق من جاهزيتنا للنشر على الويكيات الكبيرة الأخرى وإثبات قدرتنا على التعامل مع أحجام حركة المرور العالية على نطاق واسع
WE6.3.3	إذا قمنا بتطبيق تحسينات دعم متغيرات اللغة الحاسمة ونشرنا "بارسويد" بنجاح على ما لا يقل عن 3 ويكيات ذات متغيرات لغوية في الربع الثاني، فسوف نحدد ونحل التحديات التقنية الرئيسة اللازمة لـ النشر بثقة على جميع الويكيات المتبقية ذات المتغيرات اللغوية.
WE6.4.6	إذا قام فريق هندسة موثوقية المواقع (SRE) بتقديم المساعدة لفرق هندسة "ميدياويكي" من خلال إدارة السعة وحركة المرور، وإعداد ومراجعة تغييرات التهيئة، والتعاون للتحقيق في المشكلات واستكشاف أخطائها فسوف نُكمل معًا ترقية بيئة الإنتاج إلى PHP 8.3 في الربع الثاني ونوثق مجموعة من التوصيات لـ تقليل التبعيات الحرجة للمسار على فريق SRE في الترقيات المستقبلية.	T360995
WE6.4.7	إذا قمنا بترحيل 90% على الأقل من جميع المستخدمين الذين لديهم صلاحية وصول جذر عالمية لاستخدام مفتاح SSH مدعوم بالعتاد للوصول إلى خوادم إنتاج ويكيميديا، فسوف نقلل من خطر أن يتسبب جهاز كمبيوتر محمول مُخترَق في انتهاك أمني خطير
WE6.4.8	إذا قام فريق هندسة "ميدياويكي" بمراقبة وحل المشكلات بنشاط في "ميديا ويكي" المتعلقة بـ ترقية PHP، فسوف يُمكِّن ذلك فريق SRE من إكمال ترقية بيئة الإنتاج إلى PHP 8.3 بحلول نوفمبر 2025.	T360995

فرضيات خدمات الإشارات والبيانات [ النتائج الرئيسة لخدمات الإشارات والبيانات ] نقاش
الاسم المختصر للفرضية	نَص الربع الثاني	التفاصيل والمناقشة
SDS1.2.1	إذا قمنا بترحيل عملية تفريغ ملفات XML (XML Dumps process) من البنية التحتية الحالية 'Dumps 1' إلى مسار معالجة البيانات يستفيد من "مسار معالجة البيانات لمحتوى ميدياويكي" ، فسوف نتمكن من ضمان أهداف مستوى الخدمة (SLOs) وإيقاف تشغيل تصدير XML المعتمد على البنية 'Dumps 1'.
SDS1.2.2	إذا قمنا بجولة استعراض ومراجعة لأهداف مستوى الخدمة (SLOs) الخاصة بـ "سجل محتوى ميدياويكي" و"منصة الأحداث / بوابة الأحداث"، فيمكننا التحقق من صحة العملاء والمقاييس وأصحاب المصلحة التابعين، وتحديد التحسينات التي قد تكون ضرورية لأهداف مستوى الخدمة (SLOs)، مما سيساعدنا في توضيح أي ثغرات في ضمانات التسليم الأسبوعية لدينا.
SDS1.3.1	إذا قمنا بتقديم إشارات من جانب العميل وتدقيقها ومقارنتها بسجلات طلبات الويب من جانب الخادم، فسوف نعثر على أنماط إضافية للبوتات يمكن توصيفها وتحديد خصائصها.
SDS1.3.2	إذا افترضنا التوزيع الحالي للبشر مقابل الروبوتات كخط أساس وأنشأنا تنبيهات آلية لأي تحولات في هذا التوزيع، فسوف نُقلل وقت اكتشاف النمط غير المتوقع التالي لحركة المرور الآلية من أسابيع إلى دقائق.
SDS1.3.3	إذا قمنا بأتمتة آلية التغذية الرجعية لـ طلبات الويب واستخدمناها على سجلات شهر مايو، فسوف نقلل وقت المعالجة للحوادث المستقبلية من أشهر إلى أيام، ونحل حادثة "الارتفاع في مشاهدات صفحة مايو"
SDS1.3.4	إذا قمنا بإنشاء عملية تدقيق داخلي مُنظَّمة وعادية لمخرجات تصنيف الروبوتات، فسوف نبني الثقة في حلولنا ونتوقع التغييرات في أنماط حركة المرور التي لا يتم اكتشافها تلقائيًا.
SDS1.3.5	إذا قمنا بتحليل الإشارة الأساسية من جانب العميل وأدمجناها في استدلالاتنا، فسوف نكتشف أنماط بوتات إضافية في منصة البيانات
SDS1.3.6	إذا قمنا باستيراد وتحليل ودمج سمعة عنوان بروتوكول الإنترنت الخاصة بـ في استدلالاتنا، فسوف نكتشف أنماط بوتات إضافية في منصة البيانات
SDS1.3.7	إذا قمنا باستيراد وتحليل ودمج إشارة واحدة من الحافة في استدلالاتنا، فسوف نكتشف أنماط بوتات إضافية في منصة البيانات
SDS1.4.1	ذا قمنا بإعادة تأكيد التحليل الحالي للاتجاهات ضمن بيئة ويكيميديا — مثل مشاهدات الصفحة، ومقاييس المساهمين والقراء، وحركة المرور، وما إلى ذلك — فسوف نتمكن من دعم النقاط الرئيسية البارزة بثقة لأهم رؤى الحركة لدينا.
SDS1.4.2	إذا قمنا بإعادة تأكيد التحليل الحالي للاتجاهات ضمن بيئة ويكيميديا — مثل مشاهدات الصفحة، ومقاييس المساهمين والقراء، وحركة المرور، وما إلى ذلك — فسوف نتمكن من دعم النقاط الرئيسية البارزة بثقة لأهم رؤى الحركة لدينا.
SDS2.1.1	ذا قمنا بالمزاوجة/العمل عن كثب مع الفرق التي تُجري التجارب، فسوف نتعلم كيفية جعل النظام "ذاتي الخدمة" بشكل أكبر في المستقبل، وما هي التحديات المفاهيمية أو التقنية التي قد يواجهونها.
SDS2.1.2	إذا تمكنا من تطبيق أدوات أفضل لتصحيح الأخطاء الخاصة بـ "تسجيل الأحداث"، فسوف تتأكد فرق المنتج من أن تجربتها تجمع بيانات الأحداث كما هو متوقع، مما يزيد من ثقة مالكي التجربة
SDS2.1.3	إذا قمنا بتحسين عملية التسجيل والمراقبة لمكوِّن نظام اختبار أ/ب الخاص بمنصة التجارب، ولأجزاء ميدياويكي المرتبطة به، فسوف نتمكن من إرساء خطوط أساس لأداء النظام والاستجابة لحالات الفشل المتعلقة بالتجارب.
SDS2.1.4	إذا قمنا بمشاركة قصص ونتائج التجارب عبر المنظمة مرة واحدة شهريًا (من خلال اجتماعات عمليات المنتج، واجتماعات فريق التصميم، والعروض التقديمية بين الفرق)، فسوف نُنشئ تبنيًا عضويًا لمنصة التجارب.
SDS2.1.5	إذا أخبرنا المستخدمين أن الأداة الخاصة بهم، في حال إنشائها في نظام xLab، تحتوي على مجموعة من السمات التي تُغيّر فئة المخاطر، فسوف نردع مستخدمي الأدوات عن الإفراط في جمع البيانات ونزيد من الوضوح حول مزيج السمات المطلوب لمراجعة الخصوصية
SDS2.1.6	إذا عمل فريق النمو على تجهيز أُدوات حالتي استخدام (إحداهما تتضمن اختبار أ/ب) لاكتساب رؤية حول قدرات التجميع/التقسيم، والأخرى تتضمن تجهيز أدوات طويل الأمد للتعرف على دعم المقاييس الشبيهة بمؤشرات الأداء الرئيسية باستخدام "مختبر التجارب"، فسوف نتمكن من تقييم ما إذا كان يلبي المتطلبات بالقدر الكافي لـ الحل محل إعداد التجارب المخصص لدينا في "تجارب النمو"

فرضيات الجمهور المستقبلي [ النتائج الرئيسة للجمهور المستقبلي ] نقاش
الاسم المختصر للفرضية	نَص الربع الثاني	التفاصيل والمناقشة
FA1.1.4	[متابعة من السنة المالية الماضية] إذا قمنا ببناء تجربة جديدة لويكيبيديا على منصة Roblox، فسوف نتعلم ما إذا كان يمكن أن تكون هذه طريقة فعالة لتقديم علامتنا التجارية إلى الجمهور الأصغر سنًا (الجيل ألفا).
FA1.1.2	إذا قمنا ببناء محور مركزي (central hub) لـ تجارب ويكيبيديا الجديدة على منصة itch.io، فسوف نتمكن من تنمية جمهور يضم أكثر من 50 من غير الويكيبيديين المهتمين الذين يقدمون لنا الملاحظات/التعليقات، مما سيساعدنا على معرفة ما ينجح وما لا ينجح في الألعاب.
FA2.2.1	إذا استثمرنا في إدارة المجتمع عبر منصات الفيديو القصير، فسوف نشهد بحلول نهاية الربع الثاني (ديسمبر 2025) زيادة ربع سنوية قدرها 30% في نسبة المشاهدات من المشاهدين الجدد على منصة تيك توك — وعبر جميع منصات الفيديو القصير (SFV platforms)، سنحقق ما مجموعه 50,000 تفاعل (إعجاب وتعليقات رد) على تعليقات العلامة التجارية المتروكة على محتوى خارجي، مما سيساعدنا على زيادة الظهور ودفع التفاعل مع الجماهير التي لا نصل إليها حاليًا.
FA2.2.2	إذا قمنا بتطوير والحصول على موافقة على استراتيجية داخلية ومواد قابلة للمشاركة خارجيًا لـ "برنامج شراكات صنّاع محتوى ويكيبيديا" (بما في ذلك مُخطط لقيمتنا بالنسبة للصنّاع، ومعايير الشراكة، وعملية التعاقد، وكيف سيظهر محتوى الصانع عبر القنوات المملوكة وقنوات الصانع)، فسوف نتمكن من إرساء استراتيجية قوية للصنّاع ستساعدنا في الوصول إلى جماهير جديدة عبر وسائل التواصل الاجتماعي من خلال المحتوى المعرفي الخاص بنا.

فرضيات دعم المنتج والهندسة [ النتائج الرئيسة لدعم المنتج والهندسة ] نقاش
الاسم المختصر للفرضية	نَص الربع الثاني	التفاصيل والمناقشة
PES1.1.5	إذا قمنا بإدخال أهداف مستوى الخدمة الخاصة بـ "سجل محتوى ميدياويكي" و"ويكي دوال" إلى نظامي Sloth/Pyrra، فسوف ندخل هدفين إضافيين لمستوى الخدمة إلى بيئة الإنتاج.
PES1.1.6	إذا قمنا بتجريب نظام Sloth باستخدام البيانات بأثر رجعي من أهداف مستوى الخدمة الحالية، فسوف ندرك ما إذا كان Pyrra أو Sloth (أو أداة أخرى) هو الأداة المناسبة لنهج النافذة الثابتة الخاص بنا لنوافذ ميزانية الأخطاء. وسوف نتعلم كيفية دعم مالكي الخدمات من خلال نهج "الخدمة الذاتية" لمقاييس أهداف مستوى الخدمة واستخدامها في اتخاذ القرار.
PES1.2.4	إذا قمنا بتجريب عملية ربع سنوية لمراجعة رغبات وإشارات المجتمع مع 3 فرق في الربع الأول، فسوف نُشرك مديري المنتجات لـ دمج إشارات المجتمع في عمليات التخطيط ربع السنوية والسنوية الخاصة بهم.
PES1.2.5	إذا قمنا بإضافة القدرة على تصفية وفرز الرغبات في إضافة قائمة الأمنيات، إلى التحسينات التي تسمح بـ التصنيف باستخدام الوسوم والتصويت، فإن هذه التحسينات الثلاثة سوف تزيد من عدد المشاركين الفريدين في قائمة الرغبات بنسبة لا تقل عن 30%.
PES1.3.3	إذا قمنا بإنشاء ما لا يقل عن 5 تدخلات مبهجة على المنصة تحدث بناءً على تفاعلات المستخدمين، فسوف نحدد ما هي المُحفّزات اللازمة لصفحة البوابة وأداة "وضع عيد الميلاد". وسيُخبرنا اختبار قابلية الاستخدام أي من هذه التدخلات يُنشئ ارتباطات إيجابية بعلامتنا التجارية. هذه الفرضية مُحددة زمنيًا لتنتهي بحلول مؤتمر "ويكي كون أمريكا الشمالية" في نهاية أكتوبر.
PES1.3.4	إذا قمنا بإنشاء موقع ويب غامر يستكشف تاريخ ويكيبيديا وحاضرها ومستقبلها، بالتعاون مع أعضاء قسم الاتصالات، ويهدف إلى إشراك الجماهير عبر الإنترنت التي تتراوح أعمارها بين 18-34 عامًا في المناطق المستهدفة للحملة، فسوف يُحاكي/يُنشئ اتصالاً أكبر بويكيبيديا عبر المشاركات الاجتماعية وغيرها من الأنشطة عبر الإنترنت. سيساهم هذا في تحقيق النتيجة الرئيسة لقسم الاتصالات والمتمثلة في زيادة الحضور العلامة التجارية بنسبة 10 نقاط مئوية، بينما يُخبرنا ما إذا كانت الأساليب الديناميكية للمحتوى تُحسِّن من جاذبية العلامة التجارية

Q3

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

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

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

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

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

Q4

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

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

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

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

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

التخطيط معًا

تحديث يناير 2025.

الخطة السنوية هي وصفُ مؤسسةِ ويكيميديا لما نأمل تحقيقه في العام المقبل. لذا نعمل جاهدين لجعل الخطة تشاركية وطموحة وقابلة للتحقيق. ونطلب سنويًا من المساهمين مشاركة وجهات نظرهم وآمالهم وطلباتهم المحددة أثناء تشكيل الخطة. نحصل على هذه المدخلات بعدة طرق منها: محادثات فرق المنتجات مع المجتمعات، وقائمة أمنيات المجتمع، والمحادثات المجتمعية مثل سلسلة محادثات كومنز، والمؤتمرات وصفحات مشاريع ويكيميديا كهذه.

لخطتنا السنوية القادمة، من يوليو 2025 إلى يونيو 2026، نفكر في أفضل السبل لخدمة رؤية متعددة الأجيال، في ظل التغيرات السريعة التي يشهدها العالم والإنترنت، وتأثير ذلك على مهمتنا في توفير المعرفة الحرة.

كما ذكرتُ العام الماضي، علينا التركيز على ما يميزنا: قدرتنا على توفير محتوى موثوق في ظل انتشار المعلومات المضللة والخاطئة عبر الإنترنت وعلى المنصات التي تتنافس على جذب انتباه الأجيال الجديدة. يشمل ذلك ضمان تحقيق مهمتنا في جمع مجموع المعرفة البشرية للعالم وتقديمه من خلال توسيع نطاق تغطيتنا للمعلومات المفقودة الناتجة عن عدم المساواة والتمييز والتحيز. يجب أن يظل محتوانا حيويًا وملائمًا في سياق إنترنت متغير يقوده الذكاء الاصطناعي والتجارب الغنية. وأخيرًا، يجب أن نجد طرقًا لتمويل حركتنا بشكلٍ مستدامٍ من خلال بناء استراتيجية مشتركة لمنتجاتنا وجهودنا في جمع التبرعات؛ لضمان دعم هذا العمل على المدى الطويل.

لاتخاذ قرارات وتحديد الأولويات بشأن المجالات التي سنركز جهودنا عليها في العام المقبل، أعددنا مجموعة من الأسئلة وفكرنا في كيفية تخصيص مواردنا المحدودة لتحقيق أكبر تأثير ممكن.

إذا كنتُم مهتمين بالميزات أو الخدمات التي سيطورها قسم المنتجات والتقنية بناءً على الأولويات المحددة هنا، فشهر مارس متاحٌ للتعليق على أهداف ونتائج رئيسة محددة. (إليكم الأهداف والنتائج الرئيسة للخطة السنوية الحالية للاطلاع عليها).

في حال فكرتُم في التحديات والفرص في البنية التقنية والاتجاه الذي يجب أن نتخذه في الخطة السنوية القادمة، برجاء التفكر معنا في الأسئلة أدناه.

نستمر في جمع المعلومات حول هذه الأسئلة بطرق متعددة، من خلال محادثات المجتمع، والبيانات التي نجمعها، والمقابلات البحثية التي نجريها، وغير ذلك. هذه ليست المرة الأولى التي نسأل ونتعلم فيها عن هذه المسائل، وقد بدأنا بالفعل العمل على العديد منها ونريد أن نطرحها مرة أخرى الآن ونستمر في التعلم؛ لأنها تمثل أولوية بالنسبة لنا في هذه المرحلة من التخطيط.

الأسئلة:

• المقاييس والبيانات
  • ما هي الطرق التي يمكن أن تدعم بها البيانات والمقاييس مساهماتكم التحريرية بشكلٍ أفضل؟ هل يمكنكم التفكير في بيانات متصلة بالتحرير أو القراءة أو التنظيم قد تساعدكم في تحديد كيفية استثمار وقتكم أو معرفة متى يحتاج شيءٌ ما إلى الاهتمام؟ يمكن أن تكون هذه البيانات متعلقة بنشاطكم الشخصي أو نشاط الآخرين.
• التحرير
  • متى يكون التحرير أكثر تحفيزًا ومتعةً بالنسبة لكم؟ ومتى يكون أكثر إحباطًا وصعوبة؟
  • نريد أن يتلقى المساهمون المزيد من الملاحظات والتقدير لعملهم، حتى لا يشعروا بأن جهودهم المبذولة في ويكيبيديا تمر مرور الكرام. ما نوع الملاحظات والتقدير الذي يحفزكم؟ وما الذي يشجعكم على الاستمرار في التحرير؟
  • نظراً لكبر حجم مشاريع الويكي، قد يكون من الصعب على المحررين تحديد أهم أعمال الويكي بالنسبة لهم لتخصيص وقتهم لها يوميًا. ما هي المعلومات أو الأدوات التي يمكن أن تساعدكم في اختيار كيفية قضاء وقتكم؟ هل سيكون مفيدًا وجود مكان مركزي ومخصص يسمح لكم بالعثور على فرص جديدة، وإدارة مهامكم، وفهم تأثيركم؟
  • نريد تحسين تجربة التعاون في مشاريع الويكي، بحيث يسهل على المساهمين العثور على بعضهم البعض والعمل معًا في المشاريع، سواء من خلال حملات إزالة الأعمال المتراكمة، أو المبادرات التحريرية، أو مشاريع ويكيميديا، أو حتى اثنين من المحررين يعملان معًا. كيف تعتقد أنه يمكننا مساعدة المزيد من المساهمين في العثور على بعضهم البعض والتواصل والعمل معًا؟
• القراءة والتعلُّم
  • نظرًا لاختلاف سرعة تحميل مواقع مشاريع الويكي حسب موقع إقامة الأفراد، ما هي المناطق التي ترى أنه من الضروري تحسين الأداء فيها؟
  • كيف يمكننا إثارة اهتمام الأجيال الجديدة من القراء بمحتوى ويكيبيديا؟ لقد ناقشنا سابقًا أفكارًا حول المحتوى التفاعلي والفيديو، وفي العام الحالي ركزنا على الرسوم البيانية وتجربة طرق جديدة لعرض محتوى ويكيبيديا الحالي. كيف يمكننا مواصلة هذا المسار لاستخدام محتوانا الحالي بطرق جديدة فريدة من نوعها في ويكيميديا؟
• المشرفون
  • ما هي التغييرات التي يجب أن تطرأ على ويكيبيديا لزيادة رغبة المتطوعين بالمشاركة بصلاحيات متقدمة مثل الإداريين والمراجعين؟
  • ما هي المعلومات أو السياق المتعلق بالمحررين أو تعديلاتهم التي يمكن أن تساعد في تسريع أو تسهيل عمليات اتخاذ القرارات الإدارية أو المراجعة؟
• التوجهات الخارجية
  • ما هي أهم التغيرات التي تلاحظها في العالم خارج ويكيميديا؟ قد تكون هذه التغيرات ذات علاقة بتوجهات تقنية أو تعليمية أو كيفية تعلُّم الناس.
  • بخلاف حركة ويكيميديا، في أي مجتمعات رقمية تشاركون؟ وما الدروس التي يمكن أن نستفيد منها من الأدوات والعمليات في منصات المجتمعات الأخرى؟
  • كيف تستخدمون أدوات الذكاء الاصطناعي داخل وخارج عملكم في ويكيميديا؟ وما هي الأشياء التي تجدون أن الذكاء الاصطناعي مفيد فيها؟
• ويكيميديا كومنز
  • ما هي القرارات التي يمكن اتخاذها في كومنز لجعله مشروعًا مستدامًا يدعم إنشاء المعرفة الموسوعية؟
• ويكي بيانات
  • كيف ترون تطور ويكي بيانات في المستقبل؟ كيف يمكن أن يكون أكثر فائدة لبناء محتوى موسوعي موثوق؟

نقاش

–– Selena Deckelmann