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