התוכנית השנתית של קרן ויקימדיה/2025-2026/יעדים ותוצאות מפתח של מוצר וטכנולוגיה

קרן ויקימדיה
Annual Plan 2025–2026

Wikimedia Foundation Annual Plan 2025–2026

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

השנה שלפנינו

גם כשהעולם משתנה, קרן ויקימדיה עדיין איתנה בשאיפתה שהחזון שלה - להבטיח זמינות מתמדת של מידע שימושי ממיזמי ויקימדיה באינטרנט חינם - צריך להיות מפעל לדוֹרוֹת: שאיפתנו היא שידע חופשי ימשיך להיות זמין לדורות רבים בעתיד.

האינטרנט משתנה במהירות. דורות צעירים מקבלים מידע באמצעות חוויות חברתיות מבוססות וידיאו ובינה מלאכותית, ובהשוואה לדורות ותיקים יותר, פחות מודעים לקיומה של ויקיפדיה. בהקשר זה, אנחנו רואים התמעטות במספר האנשים שמגיעים לאתרים שלנו ובמספר האנשים שעורכים. בה בעת, פלטפורמות בכל רחבי האינטרנט נשענות על תוכן ויקימדיה כבסיס למערכות הבינה המלאכותית והחיפוש שהן מציעות. הדינמיקות האלה הן אתגרים גדולים, אבל הן גם מבהירות את חשיבותו הרבה של הידע החופשי והמהימן שאנחנו יוצרים יחד. העולם זקוק, יותר מאי־פעם בעבר, למקור ידע אמין שנבדק על־ידי בני אדם, ומיזמי ויקימדיה ממשיכים להראות שהם יכולים לספק אותו.

כדי לעמוד באתגרים האלה בשנה הקרובה, ניצור דרכים שיאפשרו להסתמך על תוכן של ויקימדיה באופן בר־קיימה, ונביא תוכן של ויקימדיה למרחבים חברתיים מקוּונים שהדורות הצעירים מבלים בהם. נשפר את האתרים שלנו, כדי שקוראות וקוראים ירצו לחזור אליהם, להיות מעורבים באופן עמוק ולתרום בדרכים שיש בהן משמעות מבחינתם. גם נשקיע ביכולתנו להתנסות במהירות בטכנולוגיה חדשה, כך שקצב ההתפתחות שלנו יתאים לקצב ההשתנות של העולם.

המטרה הנוגעת לתשתית עוסקת באופן שבו הפלטפורמה וחוויית המשתמש יתמכו בהתמודדות עם האתגרים האלה וביצירת קשר עם רוב המשתתפות והמשתתפים בתנועה. אין מדובר ברשימה של פרויקטים, אלא בסדרה של כיוונים שימריצו את הגידול במספר המתנדבות והמתנדבים, יאפשרו להם לבנות תוכן אנציקלופדי מהימן, יבטיחו מימון למשימתנו ויפתחו את תרומתנו לעיצוב האינטרנט המשתנה. מידע נוסף על ארבעת היסודות האסטרטגיים האלה אפשר לקרוא בקישור.

להמריץ את הגידול במספר המתנדבות והמתנדבים

קהילת המתנדבות והמתנדבים היא המנוע הייחודי מאחורי הצלחת מיזמי ויקימדיה, ואנחנו צריכים לשמור עליה בריאה וצומחת. אלא שבשנה האחרונה ראינו ירידה מתמשכת במספר העורכות והעורכים החדשים והחוזרים אל המיזמים. כדי להבין טוב יותר את צורכי המתנדבות והמתנדבים הנוכחיים, וכדי לתת להם מענה יותר אפקטיבי, קרן ויקימדיה שדרגה את רשימת המשאלות הקהילתית, והפכה אותה מסקר שנערך פעם בשנה לתהליך קליטת מידע בלתי פוסק, שבו צורכי המשתמשים ורעיונות המיזמים יכולים להזין את עבודתם של צוותים רבים בקרן. קיבצנו משאלות ל"אזורי מיקוד" ושילבנו שלושה מאזורי המיקוד האלה בפרק תוצאות המפתח של התוכנית השנתית. גם התחלנו פיילוט: ועדה מייעצת למוצר וטכנולוגיה כדי להוסיף חברי קהילה לשיחות הרבות שצוותי הקרן מנהלים במערכות הוויקי ומחוץ להן לאורך השנה. נוסף על כך, זיהינו הזדמנויות להבאת דורות צעירים אל המיזמים שלנו, למשל העובדה שאנשים צעירים משתתפים בהתלהבות במרחבים חברתיים מקוונים אחרים, שבהם יש להם דרכים קלות, ידידותיות למכשירים ניידים, ליצור קשר בנושאי עניין משותף.

בשנה הקרובה נמריץ את הגידול במספר המתנדבות והמתנדבים בכך שנהפוך את תרומות התוכן לקלות ומזמינות יותר לדורות צעירים באמצעות הרחבת זכות קדימה לניידים, דרכים חדשות לערוך ("משימות מובְנות") והוספת תרשימי עבודה חכמים שמקילים על תורמות ותורמים חדשים לבצע עריכות קונסטרוקטיביות במכשיר נייד ("בדיקת עריכות"). כדי לעודד מעורבות עמוקה יותר וכדי לשמר מתנדבות ומתנדבים קיימים, נציע המלצות לפעולות ולמשימות ונציף אותן במקום מרכזי שיקל על ארגון פעילות בתוך מערכות הוויקי. נשתמש באופן מושכל בבינה מלאכותית כדי לחזק את מתנדבות ומתנדבים בעבודתם. תמיד נשאיר בני־אדם במסגרת וניתן קדימות לשקיפות. למתנדבות ומתנדבים חדשים ובעלי ניסיון כאחד, נסלול שבילים ליצירת קשר לעבודה משותפת באתרים שלנו - בהשראת קמפיינים מוצלחים וּויקי־פרויקטים - נאפשר להם למצוא עורכות ועורכים בעלי עניין משותף ולשפר תוכן הקשור לתחומי העניין שלהם (בתיאום עם אזורי המיקוד האלה של רשימת המשאלות).

לספק תוכן אנציקלופדי אמין

בשעה שתוצרים של בינה מלאכותית מתרבים באינטרנט, העולם צריך תוכן אנציקלופדי אמין יותר מאי־פעם. שאיפתנו היא להגדיל את יכולותיהם של מתנדבים ומתנדבות כדי ליצור תוכן חדש ולהבטיח שהתוכן הקיים ימשיך להיות אמין, כמו גם לספק תוכן אמין לדור צעיר של קוראות וקוראים עם העדפות וצרכים חדשים.

כדי לעזור למתנדבות ומתנדבים ליצור תוכן חדש, נתבסס על כלי הדרכה ותכנון עבודה קיימים (כמו כלי תרגום התוכן), כך שקהילות גדולות וקטנות כאחד יוכלו לעסוק בתוכן חיוני. כדי להבטיח שתוכן קיים יישאר אמין, נעזור למתנדבות ומתנדבים מנוסים לנהל טוב יותר את נטל העבודה המתגבר באמצעות הרחבת הכלים המשמשים אותם למציאת משימות הזקוקות לטיפול. בכך נקל עליהם לעדכן ערכים ולשחזר עריכות לא־רצויות (בהתאם לאזור המיקוד הזה ברשימת המשאלות).

כמו כן, נעזור לבעלי תפקידים להגן על התוכן שלנו באמצעות חשיפה של סימנים חדשים (מלבד כתובות איי־פי) המזהים בעלי כוונות רעות, כך שנאפשר חסימה של משתמשים בדרכים שיצמצמו חסימות מוטעות של עורכות ועורכים בעלי כוונות טובות.

כדי לספק תוכן אנציקלופדי לדור חדש, נבנה תכונות שיסייעו לסוגים חדשים של קוראות וקוראים להבין ערכים בקלות, למצוא מידע שמעניין אותם ולאפשר להם להשתתף באופן פעיל תוך כדי קריאה. השינויים האלה נועדו לעודד קוראות וקוראים חדשים של ויקיפדיה להפוך לקוראים מסורים ובחלק מהמקרים אף להפוך לתורמים (בהתאם לאזור המיקוד הזה ברשימת המשאלות).

לספק תוכן אמין פירושו גם לתמוך במודל של "ידע הוא שירות", שבמסגרתו האינטרנט כולו מסתמך על תוכן ויקימדיה. במודל הזה, התשתיות שלנו אינן רק מקור רב־ערך לבני אדם המבקרים באתר שלנו, אלא גם לחברות חיפוש ובינה מלאכותית הניגשות לתוכן שלנו באופן אוטומטי כקלט יסודי להפקת פלט מהמוצרים שלהם. חברות כאלה מייצגות רק שימוש אחד מני רבים שמטילים נטל גובר שאינו בר־קיימה על התשתיות שלנו. בשנה האחרונה, גידול משמעותי בנפח הבקשות שמגיעות מכלים ומבוטים לסריקת אתרים (סקרייפרים), העלה את הדחיפות לתיקון ניתוב המגמה הזאת. אנחנו צריכים להקים נתיבים בני־קיימה למפתחים ולממחזרי תוכן שיתעדפו בני אדם בגישה לתוכן ידע על פני בוטים.

לממן את העתיד של ה'חופשי'

מחלקת המוצר והטכנולוגיה ממלאת תפקיד חשוב בהבטחת הקיימות של התנועה שלנו. בשנה הקרובה נקיים שיתוף פעולה הדוק עם צוות גיוס התרומות כדי שלתורמי הכספים שלנו תהיה חוויה ברורה ומתגמלת יותר. באתרים וביישומוני הניידים שלנו ניצור הזדמנויות לקוראות ולקוראים להביע את הוקרתם לוויקיפדיה באמצעות תרומת כסף, וניצור דרכים חדשות שיתנו לתורמי הכספים תחושה של הכרה ורצון להמשיך לתרום שנה אחר שנה.

לעצב אינטרנט משתנה

כדי להביא ידע חופשי לכל בני האדם בעולם, אנחנו צריכים לפגוש אותם במקומות שבהם הם נמצאים, עם החוויות שעוזרות להם ללמוד. לאנשים בני 18 עד 24 יש מודעות נמוכה יותר לוויקיפדיה והם עושים בה שימוש מועט יותר מאשר הדורות שקדמו להם. הם לומדים בעיקר מפלטפורמות וידיאו בפורמט קצר, מאנשי רשת שהם סומכים עליהם, מחוויות 'גיימינג' חברתיות ובמידה הולכת וגוברת גם מיישומוני בינה מלאכותית. בשנה הזאת נדאג להנגיש את ויקיפדיה לקהלים האלה במקומות המקוונים שבהם הם מבלים את זמנם, כדי שיכירו את ויקיפדיה כמקור של ידע אמין שנוצר בידי אדם. נגדיל את נוכחותנו בפלטפורמות וידיאו פופולריות, נפיץ את תוכן ויקיפדיה וניצור קהילה במרחבים האלה. גם נבחן רעיונות להבאת הידע של ויקיפדיה לפלטפורמות 'גיימינג' ולפלטפורמות חברתיות.

בתוך 'תשתיות', נושא זה מחולק לשלוש תיקיות עבודה (המכונות 'דליים'): 'חוויות ויקי', 'שירותי אותות ונתונים' ו'קהלים עתידיים'. הדליים האלה זהים לאלה של השנה שעברה ושל השנה שקדמה לה.

לאור כל זאת, דעתנו היא שהתוכנית הזאת פועלת ברגע קריטי בהיסטוריה של האינטרנט, והיא דורשת מאיתנו להבטיח שתוכן של ידע חופשי ימשיך להיות נגיש לכל הדורות וימשיך להיות מעוצב על־ידיהם. היעדים ותוצאות המפתח שלנו מראים את המבנה ואת התכנים של התוכנית בפירוט רב יותר, ואנחנו מחכים לשמוע שאלות ורעיונות מהקהילה הרחבה.

בנייה, שיפור ושימור התשתית, למען מיזמי ויקימדיה והמתנדבים, נטועים בערכים שלנו

"הקרן תנגיש מידע שימושי מהמיזמים שלה באינטרנט, חינם, לדורות."

צוותי המוצר והטכנולוגיה קבעו עדיפות קבועה, לכל אורך השנה, לבנייה, שיפור ושימור התשתית המשרתת את מיזמי ויקימדיה. אנחנו משקיעים באירוח מיזמי ויקימדיה, בפיתוח תוכנות ומערכות עיצוב בקוד פתוח, ובתחזוקה ושיפור של התשתית לטובת מוצרי נתונים ומודלים של בינה מלאכותית.

חלק חשוב מעבודתנו ממוקד בעקרונות הבסיסיים של פיתוח ואירוח של אתר אינטרנט גדול ופופולרי. אנחנו מארחים את מיזמי ויקימדיה במרכזי נתונים, בשרתים ובחומרה שאנחנו קונים, מתקינים ומתחזקים, מקושרים זה לזה ולשאר האינטרנט באמצעות רשת מהירה. אנחנו מנטרים ומוסיפים קיבולת במקומות שבהם מתעורר צורך, ומחדשים את הציוד כשהוא מתיישן. לדוגמה, השנה אנחנו מתכננים להגדיל את הקיבולת ולחדש את התוכנה שלנו במרכזי הנתונים שלנו באשבורן שבווירג׳יניה ובקרולטון שבטקסס.

אנחנו מעצבים ומפתחים תוכנות קוד פתוח (בראשן מדיה־ויקי). אנחנו גם משתמשים ביישומים, בספריות ובמסגרות קיימים רבים של צדדים שלישיים ומפיצים אותם. באגים חשובים בתוכנה שלנו מתועדפים ומתוקנים. תחזוקת תוכנה בקוד פתוח דורשת עבודה במיומנות גבוהה של אנשים עם מומחיות מיוחדת בפיתוח תוכנות קוד פתוח, בהנדסת אמינות אתרים (SRE), בניהול מוצר, בניהול תוכניות, בעיצוב ועוד. הסגל שלנו עובד כדי להבטיח שהתוכנות והמערכות שלנו מעודכנות ומותאמות לסביבה המשתנה תמיד. מדובר, בין היתר, בעדכון הקוד, כדי שנוכל להמשיך ליהנות מתיקוני אבטחה וכדי שנוכל לעבוד היטב עם תוכנות חדשות של צדדים שלישיים. לדוגמה, מדיה־ויקי כתובה ב־PHP. בשנה החולפת עברנו מ־PHP 7.4 ל־8.1, דבר שדרש שינויים הן בקוד והן בתשתית שבה אנחנו מארחים את האתרים ואת השירותים שלנו. השנה נצעד עוד צעד קדימה ונעבור ל־8.3, תוך שימוש בלקחים שנלמדו ובכלים שפותחו בשדרוג ל־8.1. העדכון יגביר את המהירות של המערכות שלנו לטובת הקוראות והקוראים, יקל על השימוש בהן לטובת הסגל, המתנדבות והמתנדבים, ויגביר את האבטחה שלהן לטובת כולם. הוא גם יחסוך זמן פיתוח בעתיד הודות לשיפור בביטחון, בביצועים ובתמיכה הנלווה לעדכוני שפה.

כדי להבטיח שהמיזמים והתוכן שלנו יישארו זמינים באינטרנט, היום ולדורות קדימה, הצוותים שלנו מקדישים מידה ניכרת של מאמץ כדי להבטיח זמינות גבוהה של האתרים והשירותים שלנו. היבט אחד של העבודה הזאת ממוקד בהתאוששות מאסונות ומפעולות זדוניות. לדוגמה, אנחנו דואגים לגיבויים של נתונים חשובים ויכולים לשחזר אותם. כמו כן, פעמיים בשנה אנחנו בוחנים את יכולתנו להעביר את האתרים שלנו בין מרכזי הנתונים שלנו באופן אוטומטי, ולתקן כל דבר שמצאנו ודורש תיקון. היבט נוסף של העבודה הזאת ממוקד בזיהוי מגמות מתפתחות בסוגים ובנפחים של התעבורה שאנחנו מקבלים, ובהסתגלות אליהן. לדוגמה, לאור גידול חסר תקדים בסקרייפרים אוטומטיים, אנחנו מתעדפים עבודה שנועדה להבטיח שהאתרים והשירותים שלנו יישארו נגישים למשתמשים אנושיים, בגישה מערכתית שמבססת נורמות סביב שימוש אחראי בתשתית שלנו.

לא כל עבודה מתוכננת זמן רב מראש. אנחנו גם מגיבים לאירועים ותקריות שצצים בהפתעה, כגון קריסת אתר, דוחות אבטחה או תקריות אבטחה, או מתקפת השחתה רחבת־היקף על המיזמים שלנו. אנחנו מנטרים את הביצועים שלנו ואת המחסומים העומדים בפני יכולתנו להגיע לכל מקום בעולם (כולל בעיות בקישוריות האינטרנט או חסימות צנזורה), ואנחנו חוקרים כל חריגה שאנחנו מוצאים. חלק מהאירועים הבלתי צפויים האלה, או דפוסי הבעיות החוזרים, גורמים לכך שהסגל מתעדף פרויקטי המשך קצרי־טווח שמטרתם לצמצם או למנוע לחלוטין השפעה שלילית נוספת. לדוגמה, מאמצים מסוג זה היו קריטיים להקניית יכולת למיזמי ויקימדיה שלנו לעמוד בעליות חדות בתעבורה העולמית עקב אירועים חדשותיים גדולים (לדוגמה, מותם של ידוענים מוכּרים מאוד), באמצעות שילוב של אופטימיזציית ביצועים, עיצוב ארכיטקטוני מחדש של אזורי צווארי בקבוק והגדלות של הקיבולת. כמו כן, שיפורים אחרונים בשימושיות של הכלים והמערכות שלנו לניהול התעבורה שאנחנו מקבלים אפשרו לנו להגיב מהר יותר ובאופן אפקטיבי יותר לתנאים משתנים. עבודת הסתגלות מהסוג הזה היא חלק בלתי נפרד מהיכולת שלנו להגיב לאירועים שצצים, לעיתים קרובות בתוך זמן קצר, ולהבטיח שהמיזמים והתוכן שלנו יישארו זמינים.

יעדי מוצר וטכנולוגיה

היעדים המוצגים כאן הם בבחינת טיוטה והם פתוחים להערות ולדיון.

• היעדים מייצגים כיוון בדרגה גבוהה.
• "תוצאות המפתח" (KRs) מייצגות דרך מדידה למעקב אחר הצלחת היעדים הקשורים אליהן.
• ה'השערות' המונחות בבסיס כל תוצאת מפתח מייצגות את העבודה שאנחנו מבצעים הלכה למעשה כדי לנסות להשיג את תוצאות המפתח הקשורות אליהן. הן יעודכנו במסמך הזה ובדפי הפרויקט או דפי הצוות ככל שיעלו תובנות במהלך השנה.
• הסימן מופיע בצד עבודה שהקרן מתעדפת לפי רשימת המשאלות של הקהילה.

חוויות ויקי (WE)

חוויות תורמי התוכן (WE1)

• יעד: גידול בתרומות התוכן כיוון שהמתנדבות והמתנדבים מקבלים הזדמנויות משכנעות ומבינים את השפעתם. דיון
  • הֶקשר: היעד הזה יהיה הבסיס לביצוע אסטרטגיית תורמי התוכן החדשה, שיש לה שלושה יסודות: (1) הצעת דרך ריכוזית למתנדבות ולמתנדבים לארגון פעילותם במערכות הוויקי, (2) הצעת משימות קטנות ומובחנות יותר כדי ליצור יותר בהירות וכדי לעזור למתנדבות ולמתנדבים לממש את הפוטנציאל שלהם, (3) הפיכת תרומות התוכן ליותר משמעותיות. בשנת הכספים 2025-26, אנחנו מתכננים לספק את התשתית הבסיסית כדי לעזור למתנדבות ולמתנדבים לארגן את פעילותם במערכות הוויקי בצורה ריכוזית, תחילה בהתערבויות ממוקדות באופן ספציפי בבעלי הרשאות ובעורכים מנוסים. בשנים שלאחר מכן נוסיף התערבויות בכל תפקידי תרומות התוכן ונכלול יותר מרחבי בעיות. נוסף על כך, נמשיך להשקיע בבדיקת עריכות (Edit Check) ובמשימות מוּבנות (Structured Tasks), ונבנה בסיס לצורת השימוש בבינה מלאכותית באופן שיאפשר את הרחבת השימוש, הן כהדרכה במהלך תהליך העריכה והן כדרך לכוון מתנדבות ומתנדבים לעבר הזדמנויות משכנעות. לבסוף, נשקיע בנראוּת טובה יותר של השפעת המתנדבות והמתנדבים כדי שתהיה להם חוויה משמעותית יותר.
    • תוצאת מפתח WE1.1: הגדלת השיעור שבו עורכות ועורכים עם לא יותר מ־100 עריכות מצטברות מפרסמים עריכות קונסטרוקטיביות במובייל־ווב [i] ב־4% [ii], כפי שיימדד בניסויים מבוקרים (עד סוף הרבעון השני).
      • i. 'עריכות קונסטרוקטיביות' - עריכות בכל מרחב שם של ויקיפדיה שאינן משוחזרות בתוך 48 שעות מרגע פרסומן.
      • ii. T389403#10960480
      • עורכות ועורכים חדשים וחדשים יחסית נאבקים כדי להתחיל לערוך בהצלחה. בפרט אנשים שמשתמשים במכשירים ניידים שמרחב המסך שלהם מוגבל והקשב לעיתים קרובות מקוטע.
      • יש כאלה שמתייאשים מההֶקשר, מהסבלנות ומהניסוי והטעייה הדרושים לתרומת תוכן קונסטרוקטיבית. אחרים עוד לא נתקלו בהזדמנות משכנעת כדי להתחיל לנסות.
      • חוויית ויקי WE 1.1 תטפל בעניינים האלה באמצעות:
        • הצפת הצעות עריכה
        • מתן הדרכה מעשית בזמן העריכה
        • בניית תוכניות עריכה ממוקדות יותר במשימות
      • בליבת המאמצים האלה נמצא הצורך בדרכים שניתנות להרחבה לשם זיהוי איך אפשר לשפר עריכות בהתהווּת ותוכן קיים. כדי להגדיל את היכולת הזאת, נמשיך להתנסות בלמידת מכונה כדי ללמוד איך היא יכולה לשרת עורכות ועורכים באופן הטוב ביותר, בכל התפקידים ובכל רמות הניסיון.
      • הצעת מתודולוגיה למדידת תוצאת המפתח: בכל פלטפורמה בנפרד, נחשב את פרופורציית ההתערבויות שהצענו והערכנו באמצעות ניסויים מבוקרים שעמדו במטרת העריכה הקונסטרוקטיבית שקבענו בתחילת השנה או עלו עליה. ראו phab:T379285#10782051 למחשבה.
        • הערה: נכון ל־30 ביוני 2025, יש שני ניסויים מבוקרים מתוכננים ל־WE 1.1.

• תוצאת מפתח WE1.2: גידול במספר שיתופי הפעולה במערכות הוויקי ב־55% לעומת השנה שעברה עד סוף הרבעון הרביעי.
  • תורמי תוכן נאבקים לעיתים קרובות כדי למצוא הזדמנויות לשיתוף פעולה אלה עם אלה, במיוחד סביב הנושאים והמשימות הקרובים לליבם. זה יכול להוביל לתחושת בדידות של מצטרפות ומצטרפים חדשים למערכות הוויקי, או לשחיקה של עורכות ועורכים מנוסים. נוסף על כך, השפעת שיתופי הפעולה היא לעיתים קרובות בלתי ברורה, וזה יכול להוביל להתמעטות האנשים המעוניינים להצטרף לשיתופי פעולה במערכות הוויקי, לארגן אותם או לתמוך בהם.
  • אנחנו רוצים שהערך של שיתוף הפעולה יהיה ברור יותר, ונפעל לשם כך בדרכים הבאות:
    1. יצירת דרכים חדשות לשיתוף ההשפעה שיש לשיתופי פעולה במערכות הוויקי
    2. התחלת איסוף נתונים מכל רחבי התנועה על ההשפעה של שיתופי פעולה
    3. הקמת התשתית הבסיסית למעקב אחר תרומות תוכן שנוצרו בשיתוף פעולה, כדי שנוכל להציע דרכים חדשניות להוקרת תרומות התוכן האלה בעתיד.
  • שיתופי הפעולה יימדדו כפעילויות חדשות שנוצרו דרך 'רישום אירועים' (Event Registration) בתוסף CampaignEvents. המטרה בסוף תוצאת המפתח הזאת היא גידול במספר המשתמשים בתוספים, ודרכים חדשות להצפת השפעת שיתופי הפעולה. כך נהיה בעמדה נוחה יותר לחיבור התשתית הקיימת שלנו לדרכים אחרות להוקרת עבודה במערכות הוויקי (כגון מודול האימפקט, התודות וכו׳).
  • אזור מיקוד ברשימת המשאלות: חיבור תורמי התוכן
• תוצאת מפתח WE1.3: עד סוף הרבעון השלישי, 10% מתורמי התוכן שנחשפו לדף בית שנועד לבעלי תפקידים חדשים, ביקרו בו שבועיים ברצף.
  • אפשר לדעתנו לפעול טוב יותר כדי להציף למתנדבות ולמתנדבים הזדמנויות לתרומות תוכן. בטווח הארוך, דף בית יכול לדעתנו להועיל לכל עורכת או עורך לארגן את עבודתם, למצוא הזדמנויות חדשות ולהבין את ההשפעה שלהם. מטרתנו בשנת הכספים 2025-26 היא להציף הזדמנויות חדשות לעורכות ולעורכים מנוסים לקחת על עצמם משימות ותפקידים שכנראה לא היו נחשפים אליהם אחרת.
    • נבחן את התאוריה הזאת תחילה בבדיקה כמה עורכות ועורכים מנוסים עשויים להשתמש בדף בית דומה לזה שמצטרפים חדשים מגיעים אליו.
    • אז נציף פעילויות ותפקידים ספציפיים (פרטים ייקבעו בהמשך) לתורמי תוכן שלא התנסו בסוג כזה של תפקידים, במטרה לעזור להפחית את הנטל המוטל על עורכות ועורכים מנוסים באמצעות צמצום רשימות המטלות (backlogs, במסגרת תוצאת מפתח חדשה).
    • אם רעיון דף הבית יצליח, אנחנו מתכננים להפוך אותו למודולרי כדי לענות על צורכי הקהילות. היחידות האלה יכולות לכלול דברים כגון: להקל על עורכות ועורכים להבין את ההשפעה שלהם.
  • הערות לגבי המתודולוגיה:
    • תהיה לנו 'השערה' שתגדיר את הקהל שלנו. היא תהיה חלק מ־WE1.3.1.
    • הגדרת 'בעלי תפקידים' ('מודרטורים') תהיה על־פי ההגדרה שהתחילה ב־Research:Develop a working definition for moderation activity and moderators, אם כי תידרש עבודת המשך כדי לצמצם את ההגדרה הכמותית.
    • 'שבוע שני' יוגדר ביחס לזמן הביקור הראשון של כל משתמשת או משתמש. במקרה הזה, נסקור את כל בעלי התפקידים החדשים שביקרו בדף הבית במהלך מסגרת זמן תחומה, ולאחר מכן חזרו לבקר פעם אחת נוספת או יותר (7 עד 14 ימים) מאוחר יותר.
  • אזור מיקוד ברשימת המשאלות: תעדוף משימות
• תוצאת מפתח WE1.4: שיפור באחוז המבקרים הייחודיים ב'רשימת המעקב' ו/או 'שינויים אחרונים' שלחצו כדי לבדוק עריכה.
  • מטרתנו היא לעזור לעורכות ולעורכים עם 100 עריכות לפחות למצוא ולפתוח עריכות שקשורות בתחומי העניין שלהם ביעילות רבה יותר. נבדוק את אזור המיקוד תעדוף משימות, נממש משאלות באזור הזה ונבקש משוב נוסף ממתנדבות וממתנדבים לגבי שיפור השטחים האלה. נוכל למדוד הצלחה באמצעות שיפור היעילות של כל דף ב'מציאת עבודה', שיוגדר באמצעות מטריקת אינדיקטורים של שיעורי הקלקות.
• תוצאת מפתח WE1.5: הגדרה והתוויה של שבע מטריקות בעדיפות גבוהה [1] הנחוצות למעקב אחר ההתקדמות להשגת המטרות המתוארות באסטרטגיית תורמי התוכן עד סוף הרבעון הרביעי, באמצעות יצירת דשבורד והתוויית מטריקה ל'מודרטור פעיל חודשי.
  [1] עורכים ממשיכים, הפעלה קונסטרוקטיבית, עריכות קונסטרוקטיביות, מצטרפים חדשים ממשיכים שנרשמו לחשבון, עורכים פעילים לפי ותק, עורכים פעילים לפי רמת ניסיון.
  • אסטרטגיית חוויית תורמי התוכן מנבאת מאמץ בן 3 עד 5 שנים ל"המרצת הגידול במספר המתנדבים" ול"הגדלת מספר הממשיכים והפעילים" מבין תורמי התוכן החדשים והקיימים כאחד באמצעות שלושה אזורים עיקריים של פעילות:
  1. פישוט הדרך שבה מתנדבות ומתנדבים יכולים לקבל המלצות, לנהל את משימותיהם ותחומי העניין שלהם, לראות מה קורה במערכות הוויקי ולהבין את ההשפעה שלהם
  2. הצעת משימות מוּבְנות כראוי כדי להגביר את הבהירות ולעזור למתנדבות ולמתנדבים לממש את הפוטנציאל שלהם באמצעות טיוב תוכניות העבודה שהם נשלחים אליהן, בכלל זה, השקעה נמשכת במתן הדרכה מובנית ואוטומציה של משימות חזרתיות, תוך התמקדות מיוחדת בחווית המובייל־ווב.
  3. הדגשת המשמעות של תרומות התוכן באמצעות הצגה למתנדבות ולמתנדבים של ההשפעה שלהן ובאמצעות השקעה בערוצים לקשר אנושי ובסביבה מבוססת על משוב חיובי.
  • אז התווה פרויקט אסטרטגיית מדידה רשת מטריקות רחבה למעקב אחר תיאוריית השינוי הזאת. הוא קבע שמדידת ההצלחה העיקרית ("מטריקת הליבה") תהיה ספירה של עורכות ועורכים ממשיכים בתוספת מטריקות של אינדיקטורים מצומצמים יותר כמו ההפעלה הקונסטרוקטיבית וכוונת תורמי התוכן לחזור, ומטריקות תוצאתיות רחבות יותר, כמו עורכות ועורכים פעילים ותוכן איכותי. אנחנו צריכים להבטיח שהמטריקות האלה יוגדרו בצורה מעשית ויוצגו בדשבורד, כדי שנוכל לעקוב אחר ההתקדמות אל עבר מימוש האסטרטגיה.
• Key result WE1.6: By the end of Q3, watchlist users can more easily organize their work and act more effectively on taking patrolling or editing action, as measured by qualitative feedback.
  • Our goal is to help editors with 100+ edits to more efficiently find edits that relate to their interests. We will explore the Task Prioritization Focus Area, deliver wishes in this area, and solicit additional feedback from volunteers on how to improve these surfaces.

---

ידע חיוני (WE2)

• יעד: יותר מידע חיוני יהיה זמין ומוסבר היטב בכל שפה ונושא. דיון
  • הֶקשר היעד: היעד הזה יניע גידול בתוכן שמתכתב הן עם תחומי העניין של תורמי התוכן בשפות ובנושאים מסוימים והן עם דרישת הקוראות והקוראים לקבל מידע חיוני מוסבר היטב. ידע חיוני הוא סדרה של ערכים המציגים את רוחב היריעה והעומק של נושאים הנחוצים למיזם שפה שימושי של ויקיפדיה. הוא מוגדר על־ידי הקהילות בזיקה לחשיבות, רלוונטיות, צפי למספר קוראים וקשרים בין הערכים.
  • אנחנו ננקוט גישה חברתית־טכנית, נשפר את האפקטיביות של תכונות, כלים ותהליכים חברתיים. נסתמך על תכונות מוצר בעלות השפעה גבוהה, כמו הצעת משימות, חיפוש מדיה ותרגום תוכן, אבל גם נקל על ההטמעה והפיתוח של ויקיפדיות בשפות קטנות יחסית. נתמוך במארגנים של ויקימדיה שמגייסים תורמי תוכן, מכשירים אותם ותומכים בהם, כדי שיעבדו על מטרות תוכן משותפות באמצעים שיתופיים כמו WikiProjects וקמפיינים. (להערכתנו, לפחות 300 מארגנות ומארגנים פעילים מדי רבעון.) גם נפתח קשרים עם המו״לים הרלוונטיים ביותר כדי להסיר חסמים על מקורות. (יש לנו כעת שותפויות עם יותר מ־100 מסדי נתונים למנויים בלבד מהחשובים בעולם.)
  • כדי להבטיח שלהתערבויות שלנו תהיה השפעה חיובית על ידע חיוני, נמדוד גם את הגידול בתוכן שהקהילה תעדפה וגם את איכות התוכן הזה. נסתכל על גורמים כגון קצב השחזורים ומספר הציטוטים והתמונות.
    • תוצאת מפתח WE2.1: עד סוף הרבעון השני, ניסוי והערכה של שלוש התערבויות שעוזרות לתורמי תוכן לשפר את מצב התוכן החיוני בוויקיפדיה שלהם.
      • תוצאת המפתח הזאת תדגיש פערי תוכן בתוך מנגנוני עריכה, כגון מציאת תמונות בוויקיפדיה, תרגום תוכן ויצירה מודרכת של ערכים חדשים. גם ניישם ונבחן התערבות חברתית־טכנית לתמיכה בפעילות יצירת תוכן בקהילות שפה קטנות. הצלחה תימדד במסגרת כל אחת מה'השערות'.
    • תוצאת מפתח WE2.2: עד סוף הרבעון הרביעי ייבנו יכולות הפלטפורמה הנחוצות כדי לוודא שאנחנו יכולים לתמוך בחזון 'ויקיפדיה האבסטרקטית' בקנה מידה גדול. נדע שהצלחנו אם נראה שקהילת ויקימדיה שולטת בתוצרי המערכת הכוללים תוכן עשיר, רב־לשוני ואנציקלופדי באמצעות ויקינתונים ויצירת שפה טבעית, ואם הביצועים שלהם נשארים טובים בחשיפה רחבה לציבור.
      • כעת, כשאנחנו יכולים להשתמש בוויקינתונים כדי להפיק תוכן טקסטואלי פשוט ובסיסי בוויקיפדיות, הצעד הבא הוא להמשיך לבנות לפלטפורמה יכולות שיתמכו בתוכן עשיר ורב־לשוני שהקהילה יכולה לשלוט בו, ושהביצועים שלהן נשארים טובים בקנה מידה גדול. תוצאת המפתח הזאת היא אבן דרך כשאנחנו מתקדמים מ־0-1.
    • תוצאת מפתח WE2.3: עד סוף הרבעון הרביעי, הפצה של הצורה הראשונית של הוויקי החדש להתחלת יצירת ערכים 'אבסטרקטיים' על־ידי הקהילה.
      • תוצאת המפתח הזאת מכינה אותנו לבדיקת יכולות הפלטפורמה של מערכת ויקי 'אבסטרקטית' בשנה הבאה. מערכת הוויקי החדשה העצמאית תארח את ספריית הערכים האבסטרקטיים שתתבסס על ויקיפונקציות (Wikifunctions) ותספק את יכולות הפלטפורמה ההכרחיות לשילוב עתידי של ערכים אבסטרקטיים אל תוך ויקיפדיה.
    • תוצאת מפתח WE2.4: תיאום בין קרן ויקימדיה לוויקימדיה גרמניה לגבי הגדרת הצלחה בכל הקשור לשיפורים בתשתית הטכנית התומכת בתרחישי שימוש קריטיים של ויקינתונים עד סוף הרבעון השני, כולל מטריקות ומטרות לאורך שנת הכספים 2025-26.
      • צוות פלטפורמת ויקינתונים (WDP) של קרן ויקימדיה הוקם ואויש - ממונה מוצר וממונה טכנולוגיה - באוגוסט 2025. כתוספת חדשה לתוכנית שעברה שנים של פיתוח על־ידי ממונים על טכנולוגיה ומוצר בקרן ויקימדיה ובוויקימדיה גרמניה בהתאמה, המטרה הזאת משקפת את כוונתנו להעביר את האחריות באמצעות תיאום תרחישי השימוש, גורמים תלויים וקריטריונים עיקריים להצלחה. תוצאת המפתח הזאת תבנה בסיס להבנה הדדית של מרחב הבעיות שעליו נתבסס במהלך שאר שנת הכספים (מאי 2026).
    • Key result WE2.5: By the end of Q4, our backend replacement has been stood up in parallel to Blazegraph and is capable of supporting the cutover of select users. We define “migration ready” for this KR as capable of supporting the pilot phase of our migration in Q1 of FY26-27.
      • Following the progress made towards defining the success criteria as a part of WE2.4, we are now shifting into execution mode. In the next two quarters, we will outline all of the variables associated with the Blazegraph cutover in a migration plan, determine which are critical for pilot launch, implement them in a new RDF database, and define the migration timeline for all requirements beyond our pilot personas. Our work between now and our target launch of a new WDQS backend (est. July 2026) will be guided by the requirements laid out in this plan.

---

חוויות צרכנים (WE1)

• יעד: קוראות וקוראים מדורות שונים יהיו ויישארו מעורבים בוויקיפדיה, ויביאו לעלייה מדידה בשימור הקהל ובפעילות תרומות הכספים. דיון
  • הֶקשר היעד: היעד הזה יתמקד בשימור קוראות וקוראים חדשים באמצעות פורמטים חדשניים של תוכן, וקהלים ותיקים באמצעות חיזוק חוויות קריאה מוּכּרות, ויבטיח קיימות ארוכת טווח באמצעות העמקת קשרי הקוראים וגיוון תרומות הכספים. הוא יכלול המשך של עבודתנו להקל על מציאת תוכן באמצעות תכונות ניסיוניות נוספות חדשות, כגון סיכומי בינה מלאכותית או 'מחילות ארנב' מותאמות אישית. הוא גם יכלול עבודה על שימור ושיפור האיכות של חוויית הקריאה לעומק משפך הקריאה ועל גילוי מאגרי קריאה באמצעות רשימות קריאה וצורות השתתפות אחרות שאינן עריכה. לתורמי כספים, העבודה הזאת תמשיך להתמקד בגיוון מקורות ההכנסה מתוך הפלטפורמה.
    • תוצאת מפתח WE3.1: עד סוף הרבעון השני נראה עלייה משמעותית באופן מעשי בשימור קוראות וקוראים שאינם רשומים, כפי שיימדד באמצעות בדיקת A/B של תכונה אחת בכל פלטפורמה
      • תוצאת המפתח הזאת תתמקד בהמשך ההשקעה בחוויות שיטייבו דרכים חדשות של גלישה ולמידת תוכן, לעיתים קרובות באמצעות שימוש בטכנולוגיות ובפורמטים חדשים - הצגת תוכן קיים בדרכים חדשות שמעודדות מעורבות. בשנת הכספים הזאת, נרצה להמשיך לערוך ניסויים בתכונות חדשות, תוך התמקדות בהרחבת ניסויים מוצלחים אל מערכות ופלטפורמות ויקי נוספות. העבודה בתוצאת המפתח תכלול את האתרים המיועדים למכשירים ניידים ולמחשבים שולחניים, וגם יישומונים ל־iOS ול'אנדרואיד', ותתמקד בגילוי תוכן (נקודות כניסה לגלישה ולהמלצות) ובפורמטים ללמידה הניתנים להתאמה (סיכומים בעזרת תוכנה, עריכה מחדש של תוכן).
      • אזור מיקוד ברשימת המשאלות: חוויות צריכה חדשות
    • תוצאת מפתח WE3.2: נגדיל את מספר תרומות הכספים, בדרכים שאינן כוללות באנרים או דוא״ל, ב־5% לעומת השנה שעברה, לכל פלטפורמה, באמצעות התערבויות מוצר שמטפחות קשרים עמוקים יותר ומפחיתות את החיכוך לתורמי הכספים, עד סוף הרבעון השני
      • תוצאת המפתח הזאת תביא אותנו להמשיך לבדוק נקודות כניסה חדשות לתורמי כספים והזדמנויות אחרות להפיכת קוראות וקוראים לתורמות ולתורמי כספים, ולשמר אותם באמצעות העמקת הקשרים שלהם למערכות הוויקי, כולל תוכן מותאם יותר אישית. תוצאת המפתח תתמקד בהנהגת נקודות כניסה חדשות ובשיפור מתמיד של נקודות הכניסה הקיימות ביישומונים ובווב, בשיתוף פעולה עם צוות גיוס התרומות
    • תוצאת מפתח WE3.3: עד סוף הרבעון השני, נראה עלייה משמעותית באופן מעשי בשימור קוראות וקוראים רשומים, כפי שיימדד באמצעות בדיקת A/B של תכונה אחת בכל פלטפורמה
      • תוצאת המפתח הזאת מתמקדת בשיפור חוויית הקריאה והלמידה לקוראות ולקוראים ותיקים ומנוסים, במטרה לשמר את הקהל הנוכחי שלנו ולהעמיק את קשריו לאתר, כך שיוכלו ללמוד יותר וגם להיות מוכנים ופתוחים ללכת בנתיבים שיובילו אותם לתרומת כסף ולעריכה. העבודה כאן תתמקד בשיפור חוויית הקריאה בווב וביישומונים (שיפור הקריאוּת, גלישה וגילוי טובים יותר), וגם להרחיב ולשפר בהתמדה את המאגרים ואת ההתאמה האישית שאנחנו מציעים (רשימות קריאה, הצעות מותאמות אישית, היסטוריית משתמש, היסטוריית ערכים וכולי).
    • תוצאת מפתח WE3.4: עד סוף הרבעון הרביעי נסיר את כל החסמים שאיתרנו לפריסת אתרי מטמון בקנה מידה קטן (PoPs) המתאימים לסטנדרטים הנוכחיים שלנו לגבי איכות השירות והאבטחה בפריסת אתרי המטמון הנוכחית שלנו
      • תוצאת המפתח הזאת תתמקד בהוכחת הרעיון שאנחנו יכולים לשפר את ביצועי האתרים ולצמצם את זמן ההמתנה של הקוראות והקוראים שלנו בכך שנפשט את תשתית אגירת המטמון (caching) שלנו ושיפור התהליכים לפריסת אתרי מטמון באמצעות הפחתת זמן הבסיס לפריסה משנה אחת בערך בממוצע לרבע מזה לכל היותר. המוקד כאן יהיה בהשלמת הפישוט, פריסת PoC, עריכת בקרת אבטחה, והשלמת סקירה לפני החלטה על התקדמות בפריסת מטמוני הקצה שלנו בעננים ציבוריים. צמצום זמן ההמתנה יכול להוביל לעלייה מוכחת בצפיות בדפים ובקהל בסיס מגוון יותר מבחינה גיאוגרפית של קוראות וקוראים.
    • תוצאת מפתח WE3.5: שיפור זיהוי תורמי הכספים - להבטיח שכל הקוראות והקוראים הרשומים שנתנו את הסכמתם יוכלו להזדהות בסטטוס של תורמי כספים לקבלת חוויה מותאמת אישית - עד סוף הרבעון הרביעי.
      • ניישם אסטרטגיות לזיהוי תורמי כספים כדי להבטיח שכל הקוראות והקוראים הרשומים שנתנו את הסכמתם יוכלו להזדהות בסטטוס תורמי כספים, ובכך לאפשר חוויה יותר אישית ומערבת. העבודה על זיהוי תורמי כספים תקבל עדיפות במהלך הרבעון הרביעי כדי לתמוך ביוזמות עתידיות להפעלה ולהתאמה אישית יותר אפקטיביות.
    • תוצאת מפתח WE3.6: השלמה, ליטוש ופרסום של אסטרטגיה לחוויית קריאה וצריכה של ויקיפדיה בכל הפלטפורמות עד סוף הרבעון הרביעי עם מטרות מוגדרות ומטריקות בסיסיות, שתפותח בשיתוף פעולה עם בעלי עניין ועם הקהילה, כדי שתנחה את עבודתנו עד 2030.
      • העבודה על אסטרטגיית הצריכה תמשיך תוך התמקדות על בניית האסטרטגיה ופרסום שלה באופן פנימי, וגם עם הקהילה, והגדרה וביסוס של מטריקות ליבה לצרכנים ולקווי הבסיס המתאימים להם.
    • Key result WE3.7: Increase the number of donations through non-banner or email methods by 10% YoY per platform through product interventions that foster deeper connections and reduce friction for donors by the end of Q3.
      • This KR will see us continue to explore new entry points for donation and other opportunities to convert readers into donors and retain them by deepening their connections to the wikis, including more personalized content. The KR will focus on introducing new entry points and iterating on existing entry points on apps and web, in collaboration with the fundraising team.
    • Key result WE3.8: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for active readers in a test environment, monitoring a guardrail appropriate for the feature.
      • This KR will focus on scaling features that showed promise in improving engaged reader retention (or related indicator metric) across web and apps, based on experiment results from Q1/Q2. This includes scaling of the reading list on web (to drive account creation and internal referral rate), activity tab on iOS (for account creation and retention), and a potential longer production analysis of activity tab on Android (already released) to validate feature retention improvements.
    • Key result WE3.9: By the end of Q4, scale at least one experiment per platform (web and apps) that displayed improvement to retention or an indicator metric for logged-out casual readers in a test environment, monitoring a guardrail appropriate for the feature.
      • In this KR, we will scale successful experiments that have proven to provide a high value to readers, new and lapsed, who do not currently engage with wiki projects. We will scale improvements focused on logged-out reader experiences that support knowledge seeking- content discovery experiences, visual presentations and modalities for sharing (knowledge, content, topics of interest). This KR spans across mobile web and apps platforms (iOS and Android).
    • Key result WE3.10: By the end of Q4, perform at least one experiment per platform (web and apps) that shows a practically significant improvement in logged-out casual reader retention or another indicator metric over control (with casual reader retention defined as 21-day cumulative retention for web, and 14-day cumulative retention for apps).
      • We are continuing our investment in experiments that convey Wikipedia's value to readers, new and lapsed, who do not currently engage with wiki projects. We will look to test improvements to the logged-out reader experience focusing on content discovery (e.g., Minerva TOC, semantic search, Q&A), visual presentations (e.g., visually engaging link cards), and modalities for sharing (e.g., share action). This KR spans web (mobile and desktop, though with an emphasis on mobile due to the audience) and apps (iOS and Android).

---

בטיחות ואבטחה (WE4)

• יעד: המערכות שלנו יגנו טוב יותר על חשבונות העורכות והעורכים שלנו ועל המידע האישי שלהם כברירת מחדל, והצעת עוד מסלולים לעורכים ולמשתמשים עם הרשאות מורחבות למניעת פעילות השחתה ולתגובה עליה. דיון
• תוצאת מפתח WE4.1: פריסת מערכת בת־יישום ופעילה לדיווח על תקריות בכל מערכות הוויקי שלנו, בהסכמה ובשימוש של הקהילות שלהן, עד סוף הרבעון השני.
  • הבטיחות והרווחה של המשתמשות והמשתמשים הן אחריות בסיסית של הפלטפורמה שלנו. למדינות ולמחוזות רבים יש תקנות המחייבים פלטפורמות מקוונות כמו שלנו לנטר הטרדות, בריונות רשת ותוכן מזיק אחר, ולפעול נגדם בפלטפורמות עצמן. אי־קיום התקנות עלול לחשוף את הפלטפורמות לאחריות משפטית ולעיצומים מצד הרשויות המפקחות.
  • אנחנו רוצים להעצים את המשתמשות ואת המשתמשים שלנו כדי שיוכלו לדווח על איומים מיידים בנזק באמצעות מנגנון דיווח קל למציאה ואינטואיטיבי, כדי להבטיח שאנחנו יכולים לדעת על תקריות כאלה ולנקוט פעולה מיידית בעת הצורך. זהו צעד שיביא את המשתמשות והמשתמשים שלנו להרגיש בטוחים כשהם תורמים תוכן לפלטפורמה שלנו. נעשה זאת בהנהגת 'מערכת דיווח על תקריות' במערכות הוויקי שלנו.
• תוצאת מפתח WE4.2: לחזק את הדיוק ואת היעילות של כלים נגד ניצול לרעה באמצעות הכנסת 2 שיפורים עד סוף הרבעון השני.
  • אנחנו והקהילה שלנו צריכים לזהות ולמנוע טוב יותר פעילות חריגה וזדונית במערכות הוויקי. נעשה זאת באמצעות הגדלת מספרם ואיכותם של האותות הזמינים לפלטפורמה, שילוב האותות האלה ליצירת כלים שיהיו זמינים למשתמשות ולמשתמשים עם הרשאות מורחבות, וזיהוי מצבים שבהם אנחנו יכולים בביטחון להפעיל הגבלות אוטומטיות על פעילות חשודה.
  • אנחנו גם רואים הזדמנויות לשיפור הנגישות של ויקיפדיה ושל המיזמים האחרים שלנו בו־בזמן. לדוגמה, יש פרויקט להחלפת ה־CAPTCHA הקונבנציונלי מאוד, המנהל את עצמו, שמונע ממשתמשים להיכנס כרשומים עד שהם פותרים חידה, עם שירות ציון בנקודות לרמת הסיכון, שרק לעיתים רחוקות מאתגר את המשתמשים. במקומו הוא יתייג בשקט חשבונות ברמת חשד כלשהי שנוכל להשתמש בה כדי לבטל אפשרויות מסוימות, ולהציג אותה בפני בעלי הרשאות גבוהות במיוחד כדי לסייע להם בעבודתם.
  • באופן יותר כללי, מיזמי ויקימדיה נסמכים הרבה על חסימת כתובות איי־פי כדי למנוע השחתות מצד גורמים שליליים. השיטה הזאת נעשית פחות ופחות אפקטיבית במניעת השחתות, והיא משפיעה באופן שלישי על משתמשות ומשתמשים בעלי כוונות טובות שמושפעים מאיי־פי ומחסימת טווחים של איי־פי. בתוצאת המפתח הזאת אנחנו חותרים לשיפור יכולות קיימות ולמתן כלים חדשים שמאפשרים חסימה מדויקת ואפקטיבית יותר של גורמים שליליים, וגם להפחתת הנזק האגבי שנגרם מאיי־פי ומחסימת טווחים של איי־פי.
  • כדי לכוונן את האפקטיביות שלנו, נבדוק משוב איכותני ממתנדבות וממתנדבים העוסקים בפעילות נגד השחתה, ומדדים כמותיים כגון תדירות השימוש בחסימות איי־פי, התחשבות במוניטין של כתובת איי־פי והקלות המבוססות על אותות מהדפדפן. נבדוק את תדירות האינטראקציות האנושיות לכאורה כשמשתמש נחסם ונאמץ אותות חדשים בכלים נגד השחתה.
  • העבודה בתוצאת המפתח הזאת כוללת את שיפור הזיהוי והסיכול של שימוש ב'בובות גרב' ושל התחמקות מחסימה, הצפת מידע על הפוטנציאל לנזק אגבי, חיזוק זיהוי בוטים, הצפת אותות למתנדבות ולמתנדבים הפועלים נגד השחתה, שיפור היעילות בממשקי כלים נגד השחתה, שיפור מטריקות הקשורות להשחתה, והעברה ל־CheckUsers של הצעות לחקירת פעילות חשודה בחשבון.
• תוצאת מפתח WE4.3: צמצום מספר התקיפות בקנה מידה גדול שמחייבות התערבות אנושית של הנדסת אמינות אתרים ב־50% (לעומת שנת הכספים שעברה) עד סוף הרבעון הרביעי.
  • התפתחות הנוף של האינטרנט, כולל הופעת רשתות בוטים רחבות ותקיפות תדירוֹת יותר, ביטלה את היעילות של השיטות המסורתיות שלנו לצמצום השחתה בקנה מידה גדול. תקיפות כאלה יכולות לפגוע בזמינות האתרים שלנו באמצעות הצפת התשתית שלנו בבקשות, או לשתק את יכולת הקהילה שלנו להילחם בוונדליזם בקנה מידה גדול. זהו גם לחץ בלתי סביר על העורכות והעורכים בעלי ההרשאות הגבוהות ועל קהילת הטכנולוגיה שלנו.
  • אנחנו צריכים בדחיפות לשפר את יכולתנו לזהות, לבלום, ולמזער או לעצור תקיפות כאלה, באופן אוטומטי.
  • השנה הזאת נתמקד בעיקר בזיהוי אוטומטי של כתובות איי־פי ורשתות שמנהלות באופן קבוע התקפות נגדנו, ובהפחתת מידת העומס שגורמים המזיקים בהתמדה יכולים להטיל על המערכות שלנו.
• תוצאת מפתח WE4.4: פריסת חשבונות זמניים ב־100% מהמיזמים שלנו, כך שחשיפת מידע אישי מזהה של העורכות והעורכים הלא־רשומים שלנו תהיה זמינה ללא יותר מ־0.1% מהמשתמשות והמשתמשים שלנו עד סוף הרבעון השני.
  • מטרתם של החשבונות הזמניים היא לשפר את הפרטיות, וכתוצאה מכך גם את הבטיחות, של העורכות והעורכים הלא־רשומים שלנו באמצעות הסתרת המידע האישי המזהה שלהם (כתובת איי־פי) מהעין הציבורית והגבלת הגישה אליו לאלה הזקוקים לו לצורך ניטור ולהם בלבד. מלבד השיפור הגדול לבטיחות המשתמשים, הפרויקט הזה חשוב גם כדי לקיים הוראות רגולטוריות שונות.
• תוצאת מפתח WE4.5: הערכת ההשפעה של בינה מלאכותית יוצרת על האמון והבטיחות, וקביעת התערבויות במוצר כדי למנף הזדמנויות ולמנוע איומים על מיזמי ויקימדיה, עד סוף הרבעון השלישי.
  • שימוש בבינה מלאכותית, בפרט בבינה מלאכותית יוצרת, גובר במהירות בכל רחבי האינטרנט. יש בכך הזדמנויות לאמון ולבטיחות, כמו גם איומים העולים מהתפוצה הרחבה שהבינה המלאכותית זוכה לה. לדוגמה, קל וזול ליצור תוכן, אבל ניטור התוכן הוא עול יותר כבד. באופן דומה, אפשר לערוך מחקר בהרבה פחות מאמץ, אבל הזיות בינה מלאכותית קשות יותר לזיהוי.
  • הפרויקט הזה שואף להתבסס על 'הערכת ההשפעה של למידת מכונה ושל בינה מלאכותית על זכויות האדם' (Human Rights Impact Assessment of ML/AI) כדי להעריך את ההשפעה של הבינה המלאכותית על היבטי אמון ובטיחות של המערכת האקולוגית (אקוסיסטם) של ויקימדיה. בכלל זה:
    • היוועצות במשתמשות ובמשתמשים עם הרשאות מורחבות
    • זיהוי דוגמאות של השחתה בסיוע בינה מלאכותית יוצרת ואפשרויות למניעתה.
    • זיהוי הזדמנויות של למידת מכונה להפחתת העול על משתמשות ומשתמשים עם הרשאות מורחבות.
    • הרצת ניסויים כדי להבין על מה אנחנו צריכים להתמקד כדי להשיג את ההשפעה הגדולה ביותר.
• תוצאת מפתח WE4.6: לאכוף באמצעים טכניים מצב שבו 100% מההרשאות המאפשרות למשתמשות ולמשתמשים לנקוט פעולות רגישות הקשורות בבטיחות או בפרטיות יוכלו להתבצע רק דרך חשבונות שיש בהם אימות דו־שלבי, עד סוף הרבעון הרביעי.
  • עלינו לחזק את האבטחה של חשבונות המשתמש במערכות הוויקי שלנו, בפרט אלה שיש להם הרשאות רגישות. המוקד העיקרי הוא דרישה שכל פעולה רגישה תוכל להתבצע אך ורק על־ידי משתמשות ומשתמשים שהפעילו אימות דו־שלבי (2FA). נבנה מערכת שניתנת להרחבה לאכיפת הרשאות שתעקוף את הצורך בבקרה ובאכיפה ידנית של האימות הדו־שלבי ותקבע את היקף ההרשאות המחייבות הפעלת אימות דו־שלבי בפלטפורמה.
  • כחלק מזה, נשפר את מערכות האימות והשחזור שלנו, כך שאנחנו בקרן ויקימדיה והמשתמשות והמשתמשים שלנו נוכל לתמוך בקלות רבה יותר בגישה מחמירה יותר לגבי אימות דו־שלבי. נרחיב את הזמינות הכללית של האימות הדו־שלבי בכל הפלטפורמה, כך שכל משתמשת ומשתמש יוכלו להפעיל אותו כפי רצונם וכדי להבטיח שהוא מופעל לפני הענקת הרשאות רגישות. גם נמקד את תשומת ליבנו בהפחתת העומס התפקודי המוטל על מערכות שחזור החשבונות והתמיכה, כדי לסייע בהזרמת תהליכי האיפוס והשחזור סביב כניסה רשומה לחשבון. עוד אנחנו מתכוונים לשפר את השימושיות של יישום האימות הדו־שלבי שלנו, בכך שנציע למשתמשות ולמשתמשים אפשרויות נוספות לאבטח את החשבונות שלהם ולהימנע מאיבוד בטעות של היכולת להיכנס אליהם.

---

שימוש אחראי בתשתית (WE5)

• יעד: מפתחים וממחזרים ייגשו לתוכן הידע במסלולים מודרכים שיבטיחו את יציבות התשתית שלנו ושימוש חוזר אחראי בתוכן. דיון
  • הֶקשר היעד: היעד הזה יתמקד בהקמת מסלולים לשימוש חוזר אחראי בתוכן.
  • ויקיפדיה מארחת את האוסף הגדול ביותר של ידע ערוך בידי אדם ברשת. כיוון שכך, תשתית הידע שלנו הפכה למקור שלא יסולא בפז לא רק לבני אדם, אלא גם לצרכני נתונים אוטומטיים. התוכן שלנו מוזן לתוך מנועי חיפוש, פלטפורמות של מדיה חברתית, מסחר אלקטרוני, ומאז הופעת הבינה המלאכותית, הוא משמש לאימון מודלים גדולים ללמידת מכונה. הצרכנים שואבים נתונים באמצעות גרידת דפים (scraping), שימוש ב־APIs והורדת תוכן - בדרך כלל בלי ייחוס (קרדיט).

בעולם של תעבורה בלתי ניתנת לאימות, איננו יכולים להבדיל בצורה אמינה בין משתמשים, ולכן יכולתנו לאפשר ולאכוף שימוש אחראי בתשתית שלנו, מוגבלת. איך אנחנו יכולים להמשיך לאפשר גישה לקהילה שלנו ובאותה שעה גם למתוח גבולות סביב צריכת תוכן אוטומטית? איך אנחנו יכולים לכוון משתמשים אל הערוצים המועדפים שיש בהם תמיכה? איזו הדרכה אנחנו צריכים כדי לתמרץ שימוש חוזר אחראי בתוכן? איך אנחנו יכולים לחתור אל עבר חוויית פיתוח מגובשת, ולבנות מוצרים שעונים על הצרכים של מפתחים מתנדבים, הסגל וממחזרי תוכן במידה שווה? אומנם לא כל השאלות האלה חדשות, הדחיפות לטפל בהן גדלה באופן אקספוננציאלי: מאז 2024, אנחנו רואים עלייה דרמטית בנפח הבקשות, ורוב העלייה מגיעה מבוטים לגרידת נתונים שאוספים נתונים לאימון לתוכניות עבודה ולמוצרים המבוססים של בינה מלאכותית. הנטל על התשתית שלנו אינו בר־קיימה ומסכן את הגישה של בני אדם לידע. אנחנו צריכים לפעול עכשיו כדי להקים מחדש איזון בריא, כך שנוכל לתמוך בצורה אפקטיבית במיזמי ויקימדיה ולאפשר הצלחה בת־קיימה של החזון שלנו.

• • • תוצאת מפתח WE5.1: עד סוף הרבעון הרביעי, 50% מהבקשות לערוצי גישה תכנותיים יהיה אפשר לייחס למפתחים או ליישומים ידועים.
      • יש לנו כרגע דרכים מוגבלות לזיהוי האחראים לתעבורה אוטומטית, ובניגוד למצב בתוך מערכות הוויקי, דרכים מוגבלות ליצירת קשר עם משתמשים או להסדיר את הגישה שלהם. ראינו עלייה משמעותית בנפח התעבורה האוטומטית החיצונית, מצב שאינו בר־קיימה מבחינתנו ומסכן את הגישה של בני אדם לידע. אנחנו שואפים להגדלת שיעור התעבורה האוטומטית שאפשר לייחס לחשבון ידוע באמצעות בקשת אימות ורישוי המבוססים על רמות שונות של גישה לגרידת נתונים בנפח גבוה ולשימוש ב־API. זה יסייע לנו לזהות מי עושה שימוש חוזר בתוכן בקנה מידה גדול, ובכך יאפשר לנו להגן על התשתית שלנו ולשפר את השליטה סביב עקרון השימוש ההוגן, ובאותו הזמן יענה על הצרכים שלנו באופן יותר אפקטיבי. עוד נבחן איך לתמוך טוב יותר בקהילת הטכנולוגיה עם ניסיון פיתוח מגובש יותר שמגן על זכות קדימה לחברי קהילה ומאפשר פונקציונליות חדשה למפַתחות ולמפתחים.
    • תוצאת מפתח WE5.2: עד סוף הרבעון הרביעי, 70% מנקודות הקצה של ה־API הוובי של ויקימדיה ייתמכו בתשתית פשוטה.
      • אנחנו שואפים לשיפור החוויה והקיימות של מסלולי המפתחים שלנו באמצעות APIs ווביים עקביים יותר, יציבים יותר וגלויים יותר לכל המפַתחות והמפתחים של ויקימדיה. נפשט את ה־APIs שאנחנו מציעים באמצעות הכנסת תשתית ריכוזית יותר ליכולות הליבה של ה־API שיאפשרו לנו לקיים מסלולים עקביים ושליטה עקבית בכל אלה: מאפיינים ותיעוד של OpenAPI, זיהוי מפתחים ובקרי גישה, אכיפת מדיניות API, ניתוב, ניהול גרסאות וטיפול בשגיאות. הזרמת הצעות ה־API שלנו תאפשר לנו להפוך את בניית הכלים, הבוטים, פרויקטי המחקר והתכונות שמשרתות את חזון ויקימדיה למהירה יותר, קלה יותר ונעימה יותר. הגישה הזאת תומכת בחזון העתיד הרב־דורי באמצעות הפחתת עלויות תחזוקת תשתית ה־API, הגברת הנראות ובקרת הגישה של גורמים עוינים, וטיפוח קהילת מפַתחות ומפתחים חזקה יותר.
    • תוצאת מפתח WE5.3: עד סוף הרבעון הרביעי תתפרסם מסגרת ייחוס חדשה לווב, ליישומונים, לעזרי קול ולמודלים גדולים של שפה, עם קישורים אליה בכל אתרי ויקימדיה, עם הפצת שתי הדגמות לשימוש חוזר שיעודדו מעורבות מדידה, ושותף שימוש חוזר חיצוני אחד שיטמיע יישום מיטבי של ייחוס.
      • כדי להגביר ייחוס (קרדיט) נאות לתוכן ויקיפדיה, נספק הדרכה ברורה ליישום מיטבי שתקדם שימוש חוזר אחראי. בכלל זה, יצירת מסגרת ייחוס לפלטפורמות מרכזיות (ווב, יישומונים, קול, מולטימדיה) והצגת שתי דוגמאות מעשיות לפחות שידגישו יישומים רצויים של תוכן ויקימדיה. דוגמאות כוללות עידוד ארגוני מדיה לתת קרדיט לתמונות מוויקישיתוף, מנועי חיפוש להצפת נתוני ויקימדיה רלוונטיים בצורה אפקטיבית יותר, או עזרי בינה מלאכותי לשילוב ידע של ויקימדיה בדרכים שקופות ואחראיות שיגבירו את הביטחון באמינות שלהם. חיזוק פרקטיקת הייחוס תגביר את המודעוּת הציבורית ותעודד מחדש מעורבות במיזמי ויקימדיה, ויותר מכך, תעזור לבסס דרכים חדשניות ואחראיות לעריכה מחדש של ידע ולהרתיע מפני שימוש לרעה.
    • תוצאת מפתח WE5.4: הפחתת כמות התעבורה שיוצרים מנגנונים לגרידת נתונים ('סקרייפרים') ב־20% במדידה לפי היקף הבקשות, וב־30% במדידה לפי רוחב פס
      • גרידת נתונים (קציר מידע) התקיימה תמיד: מנועי החיפוש מסתמכים על ויקיפדיה כדי לספק מידע למשתמשים שלהם זה עשורים. עם זאת, בזמן האחרון, יש מניע גדול אחר לקצירת המידע שלנו: זהו תוכן הידע הערוך היטב והרב־לשוני הגדול ביותר שאפשר למצוא באינטרנט, והוא כלי בסיסי לאימון מודלים גדולים של שפה. כל זה נכון הן לגבי התוכן האנציקלופדי והן לגבי מאגר המולטימדיה שלנו, ויקישיתוף, שהוא בעל ערך רב למודלים של למידת שפה שיוצרים תמונות.
      • כתוצאה מכך, במהלך השנה האחרונה, ראינו עלייה משמעותית בכמות תעבורת גרידת הנתונים, וגם במספר תקריות יציבות האתר הקשורות לכך: מהנדסי אמינות האתר נאלצו לאכוף, בכל מקרה לגופו, הגבלות על היקף הפעילות או חסימה חוזרת ונשנית של זחלנים, כדי להגן על התשתית שלנו. גרידת נתונים נעשתה נרחבת כל כך, עד שרוחב הפס שלנו לתקשורת יוצאת עלה ב־50% ב־2024. יותר מכך, ניתוח מהזמן האחרון הראה ש־65% לפחות מהבקשות היקרות ביותר שלנו (אלה שאיננו יכולים לטפל בהן משרתי המטמון שלנו, ובמקום זאת מטופלות ממסד הנתונים הראשי) מבוצעות על־ידי בוטים.
      • משאבי המחשוב שלנו מוגבלים מאוד בהשוואה לכמות התעבורה שאנחנו יוצרים, לכן עלינו לתעדף את הגורמים שאנחנו משרתים באמצעות המשאבים האלה, ואנחנו רוצים להעדיף צריכה אנושית ולתת זכות קדימה לתמיכה במיזמי ויקימדיה ובתורמי התוכן באמצעות משאבינו הדלים.

---

האצת המסלול לתוצרי מוצר (WE6)

• יעד: מפַתחות ומפתחים של ויקימדיה מציעים את המוצרים שלהם במהירות ובלא חשש למשתמשי קצה. דיון
  • הֶקשר יעד: כדי להיות אפקטיביים בהשגת 4 היסודות האסטרטגיים, מפַתחות ומפתחים של ויקימדיה צריכים להקדיש את זמנם ואת מרצם לפעילויות במינוף גבוה שמסתיימות באספקת מוצרים איכותיים במהירות האפשרית. תוכניות עבודה מסובכות מדי, מחסור בכלים סטנדרטיים ורכיבי מערכת שאינם בני־קיימה, מפריעים להשגת התוצרים האלה.
  • העבודה הזאת בנויה על המומנטום שתפסנו בשתי התוכניות השנתיות האחרונות ששדרגו את מדיה־ויקי כפלטפורמה ואת התוכנה שתומכת בהתפתחות ובהפצה שלה. העבודה בשנה הזאת תתמקד ביצירת סביבות פיתוח אמינות יותר, פישוט תוכניות עבודה של לפני־הפקה והפחתת סיכונים לפלטפורמה ולתשתית.
    • תוצאת מפתח WE6.1: עד סוף הרבעון הרביעי, מספר הבאגים החמורים שמתגלים מחוץ למערכות הוויקי הניסיוניות יפחת ב־10%
      • ב־2024 היו 144 פעמים שבהן מפַתחות ומפתחים נאלצו לפתוח מחדש עבודה בגלל מצב חירום שמנע את ההפצה של מדיה־ויקי. ברבים מהמקרים האלה התגלו הבאגים אחרי ההפצה למערכות הוויקי הניסיוניות (testwikis), כלומר, התקלה הגיעה לקהל פוטנציאלי של מיליארדי משתמשות ומשתמשים. קיומם של באגים הוא מחוץ לשליטתנו, אבל אם נגלה אותם מוקדם יותר יידרשו מאיתנו פחות 'מבצעי גבורה', ונגביר את האמון במפַתחות ובמפתחים, שאם משהו מגיע להפקה אמיתית, לא יקרה אסון.
      • נגלה את הבאגים האלה מוקדם יותר באמצעות סביבות הנחוצות למפַתחות ולמפתחים כדי לספק ולבדוק את הקוד שלהם בכל שלבי מחזור הפיתוח וההפצה. עלינו גם להבטיח שהשיפורים האלה לא יבואו על חשבון מהירות הפיתוח.
    • תוצאת מפתח WE6.2: עד סוף הרבעון הרביעי, 4 שלבים מרשימת הבדיקה למוכנות ההפקה יוכלו להתבצע בלי התערבות הנדסת אמינות אתר
      • פריסת תכונה חדשה או שירות חדש בהפקה תלויה כרגע ברשימה של 24 צעדים, כשכל צעד דורש בדרך כלל תמיכה של מהנדסי אמינות אתר. הקמנו את תוכנית שגרירי הנדסת אמינות תוכנה כדי להתערב בשלב מוקדם יותר של מחזור הפיתוח וכדי לבנות יכולת בקרב צוותי הפיתוח עצמם, אבל רבות מהמשימות צריכות להתאפשר לגמרי בשירות עצמי. כרגע, הדברים מגיעים לכדי עבודה ידנית, חזרתית, שאפשר להפוך אותה לאוטומטית, וקנה המידה גדל באופן ליניארי עם הגידול במספר צוותי הפיתוח. המצב הזה אינו בר־קיימה מבחינת צוות הנדסת אמינות האתר לטווח הארוך.
      • בעבר, חלק גדול מהעבודה הזאת הוצא מידי צוותי הפיתוח על־ידי החזקת שורה של ספריות משותפות ושיטות להתקשרות עם הפלטפורמה שלנו. זנחנו אותן כשעברנו לתשתית Kubernetes החדשה שלנו, ואין להן תחליף ישיר. באמצעות מתן גישה לספריות דומות, לתיעוד ולהכשרה, שמתאימים לאופן שבו אנחנו בונים ומפיצים דברים כיום, אנחנו מאמיני שנוכל להפחית את מידת המעורבות הנדרשת ממהנדסי אמינות אתר לפני פריסת שירות חדש או תכונה חדשה בהפקה.
    • תוצאת מפתח WE6.3: עד סוף הרבעון הרביעי, 100% מהצפיות בדפי ויקיפדיה יטופלו דרך Parsoid
      • פרסויד (Parsoid) מציעה יכולות משודרגות להתפתחות טקסט ויקי ולחיזוק עתידי של הפלטפורמה. שימוש בשני מנתחים תחביריים בו־זמנית אינו בר־קיימה בטווח הארוך, כיוון שהוא מגדיל את החוב הטכני ואת המורכבות. נוסף על כך, הצלחתם של כמה פרויקטים חדשים, כמו ויקיפונקציות, תלוי בזמינות הרחבה של Parsoid.
      • הרחבנו את חשיפת השירותים למיזמים קטנים יחסית, והשנה נהיה מוכנים לוויקיפדיות. טיפול בכל קריאת דפי ויקיפדיה המוצגים באמצעות Parsoid הוא אבן הדרך הבאה החשובה ביותר. נוסף על חשיפת השירות עצמה, העבודה הזאת כוללת גם פתרון בעיות ביצועים ודיווח אפקטיבי על ההשפעה לקוראים ולעורכים.
    • תוצאת מפתח WE6.4: עד סוף הרבעון השני, לפחות שני סיכונים מזוהים המאיימים על יכולתנו להמשיך לפרוס או להרחיב את מערכות הוויקי הוסרו או פחתו לרמה נסבלת
      • באמצעות כמה יוזמות ממוקדות, נפחית או נסיר כמה סיכונים לביטחון, לאמינות או ליכולתנו לגדול, שזיהינו כאיומים פוטנציאלים מתקבלים על הדעת לצמיחה ולקיימות של הפלטפורמה והמיזמים הציבוריים שלנו.
      • לדוגמה, אנחנו נשפר את מבנה מסדי הנתונים הבסיסיים של ויקישיתוף כדי להבטיח שהגידול שלו לא יוגבל על־ידי קיבולת חומרת השרתים הזמינים במהלך השנים הקרובות. אנחנו גם נשדרג את PHP, שפת התכנות שמשמשת את מדיה־ויקי ושירותים הקשורים אליה, לגרסה מודרנית יותר. סיכונים מזוהים אחרים ידרשו ככל הנראה יישום של אמצעים ביטחוניים נוספים כדי להגן ולהקשיח את התשתית שלנו.

---

אותות ושירותי נתונים (SDS)

מטריקות (SDS1)

• יעד: מקבלי החלטות ישתמשו במטריקות יותר מהימנות ומעודכנות כדי לבסס עליהן החלטות הנוגעות למוצר ולאסטרטגיה. דיון
  • הֶקשר היעד: אנחנו משתמשים במטריקות כדי לבסס את החלטות הקרן לגבי מוקד המאמצים שלנו, במטרה לשרת בצורה הטובה ביותר את התנועה. עם זאת, כמה מצינורות הנתונים שלנו עלולים להתקלקל ולגרום לעיכובים בהשלמת הפיתוח. כשמתעוררות בעיות נתונים, הזמן שלוקח לנו לזהות ולפתור אותן ארוך מדי. נוסף על כך, רבים ממערכי המידע שלנו אינם מטוּיבים לבדיקת מגמות, וחסרים להם ממדים שהתגלו כבעלי חשיבות לפירוש הנתונים. הבעיות האלה מאיטות ומגבילות את יכולתנו להעריך מטריקות.
  • בשנת הכספים 2025-26 נתמקד בתרחישי שימוש ספציפיים של התוכנית השנתית כדי לגשר על פערי איכות הנתונים בצינורות הקיימים שיש לנו, נקים תשתית ותהליכים לניטור ולפתרון בעיות איכות נתונים, ונספק כלים שיאפשרו למקבלי החלטות להבין מגמות.
  • תרחיש שימוש אחד נוגע לשאלה איך אנחנו מודדים תעבורת בני אדם ובוטים. העלייה בתעבורה האוטומטית בשנים האחרונות מקשה על הבנת היקף האינטראקציה של בני אדם עם מיזמי ויקיפדיה ועל היקף תרומות התוכן שלהם. אנחנו שואפים לשפר את יכולתנו להעריך דפוסי תעבורה של בני אדם ושל בוטים, שהם מידע קריטי להחלטות לגבי תכנון ומוצרים.
    • תוצאת מפתח SDS1.1: עד סוף הרבעון הראשון, לאנליסטים שמשתמשים במטריקות של צפייה בדפים תהיה גישה למדידות בסיסיות של איכות נתונים ולמדידות של ביצועי היוריסטיקות לאיתור תעבורה אוטומטית.
      • באמצעות ההשערות הנבחנות בתוצאת המפתח הזאת, אנחנו שואפים לזהות פערים בהיוריסטיקות הקיימות לאיתור תעבורה אוטומטית, ולהבין איפה הן כשלו בסיווג הנכון של תעבורת צפייה בדפים. התובנות האלה יבססו שיפורים בצינורות המייצרים ומסווגים מטריקות של צפייה בדפים. נוסף על כך, נגדיר מטריקות איכות נתונים כדי לנטר ולמדוד שיפורים בדיוק הנתונים.
      • תוצאת המפתח הזאת תניח את היסודות לתוצאת מפתח שתבוא בעקבותיה ותתמקד ביישום של השיפורים ההכרחיים בצינורות שזוהו כאן. מטריקות איכות הנתונים שנקבעו בשלב הזה ישמשו כמדדים להערכת האפקטיביות של השיפורים העתידיים האלה.
    • תוצאת מפתח SDS1.2: עד סוף הרבעון הראשון, תוכן מערך הנתונים של היסטוריית התוכן של מדיה־ויקי יהיה זמין באמצעות יצוא קובץ עם ערבויות ביצוע שבועיות (יעדי רמת שירות). נתוני קובץ היצוא יהיו בני השוואה לצינור היצוא הישן של XML Dumps 1.
      • מטרת תוצאת המפתח 1.4 לשנת הכספים 2024-25 הייתה לבטל את התלות בעדכון החודשי של מערכי המידע של updated mediawiki_wikitext_history ושל mediawiki_wikitext_history_current ל־3 צינורות ההמשך הרלוונטיים ביותר, ולספק מערכי נתונים חלופיים עם יעדי רמת שירות שבועיים מובטחים.
      • אומנם תוצאת המפתח 1.4 לשנת הכספים 2024-25 עזרה לפתור את בעיית המהימנות לצינורות התלויים הרלוונטיים ביותר, אך יש עדיין צינורות שנשארו עם מקור קלט ישן ובלתי מהימן. גם את אלה צריך להעביר, כמו גם את מקור הקלט המבוסס על קבצים של מערך הנתונים עצמו של היסטוריית טקסט ויקי.
    • תוצאת מפתח SDS1.3: עד סוף הרבעון השני יכלול איתור הבוטים אות נוסף אחד ויפיק אזהרות אוטומטיות מפני אנומליות.
      • בכל רחבי הקרן, צוותים מקבלים החלטות הנוגעות למוצרים ולמימון בהתבסס על יכולתם לקבוע את ההבדל שבין קוראות וקוראים אנושיים לבין תעבורה אוטומטית. פלטפורמת הנתונים היא המאגר המרכזי לאיתור אותות בוטים וניתוח אַצווֹת. באמצעות ההשערות שבדקנו במהלך הרבעונים הראשון והשני, אנחנו מתכננים להתחיל הכנסת אותות חדשים לאיתור בוטים כדי לחדד את הניתוח שלנו של תעבורה אוטומטית, ולהתחיל להפוך את תהליך הכנסת אותות חדשים ליעיל וגם ניתן לחזרה.
    • תוצאת מפתח SDS1.4: עד סוף הרבעון השני תהיה למקבלי החלטות הבנה ברורה של מצבן הנוכחי של תובנות שנובעות מהמטריקות הארגוניות שלנו. נדע שהצלחנו אם נספק לישיבה של חבר הנאמנים סדרת מצגות שממקמות את ניתוח המטריקות שלנו בתוך הסביבה האקולוגית של ויקימדיה, כמו גם בתוך מרחב המגמות והאתגרים האינטרנטיים בשוק.
      • תובנות מהמטריקות הארגוניות שלנו משמשות לקבלת שפע של החלטות בכל רחבי הקרן, כולל החלטות הנוגעות לאופן בניית המוצר שלנו, להקצאת משאבי תשתית ולגיוס התרומות. בו־בזמן, נוף האינטרנט מתפתח, ובעיקר התעבורה האוטומטית שמשפיעה על המטריקות שלנו. המטרה היא שהנהגת הקרן תגיע אל ישיבת חבר הנאמנים בדצמבר עם נרטיב ברור לגבי איומים על הסביבה האקולוגית של ויקימדיה ולגבי הזדמנויות המצויות בתוכה, שנתמך בניתוח איתן של מטריקות פנימיות ומגמות חיצוניות. אנחנו יכולים לספר את הסיפור באמצעות איסוף תובנות, מטריקות ונקודות נתונים, המספרים לנו בביטחון על כל אלה:
        • מגמות במדידות הקריאה הפנימיות שלנו (צפיות בדפים)
        • מגמות בסביבה האקולוגית של תורמי התוכן שלנו
        • מגמות מנתונים חיצוניים ומדדים של מתחרים
        • תובנות ממחקרים אמינים פנימיים וחיצוניים
    • Key result SDS1.5: By the end of FY25-26 Q4, analytics bot detection will incorporate 2 signals calibrated against 1 trusted classification.
      • In Q1/Q2, SDS1.3 addressed the big gap in incident detection time and analyzed additional signals for bot detection. We learned that:
        • Modern and feasible signals come with a number of caveats and uncertainties that need to be expressed in our metrics.
        • Evaluating the quality of our model, as well as doing robust analysis of signals to enable future iteration, will require labeled data, trusted by definition and preferably sourced from independent systems (formerly called “ground truths”).
        • We will need knowledge and calibration from third-parties that specialize in this domain to be able to quantify our current state and prioritize future improvements.
      • In Q3/Q4, we will follow that with three main deliverables:
        • Extend our pageview metric to incorporate a numerical confidence score in addition to the existing labels, computed from at least 2 new signals, which will allow analysts to quantify and convey the nuances of those signals.
        • Curate trusted labels, preferably sourced from a third-party that specializes in this domain, and use it to evaluate our current performance and better understand the new signals.
        • Operationalize a client-side signal, which remains the most promising internally developed detection method.
    • Key result SDS1.6: Deliver a Movement Insights report on a regular basis, with consistent coverage across readership, contributors, and content thematic areas. We’ll know we’re successful when we’ve established the following by the end of Q4:
      • A consistent delivery cadence
      • Most valuable content for our stakeholders
      • Areas for future automation
      • Today, critical signals about the health of the Wikimedia Movement are fragmented across systems and teams. Readership trends, contributor health, brand perception, SEO/AEO, and competitor intelligence are monitored independently, without a consistent process or systems to aid in interpreting them together. We have existing monthly metric monitoring processes but they don’t address the scope and focus that is needed by executive decision-makers. The Movement Trends Brief is a concise, recurring intelligence brief that provides leadership and product teams with a shared understanding of how the Wikimedia movement is evolving week over week. Rather than describing everything that happened, this communication answers the following questions consistently:
        • What meaningfully changed in the past week/2 weeks?
        • Have we learned anything new about existing trends that we’re questioning?
        • Why does it matter now?
        • What requires attention or action?
      • The brief is designed to support situational awareness and provide a forum to present deeper analysis. It surfaces early signals, connects related trends across various data sources, and creates an entry point to inform decision-making.

---

פלטפורמת ניסויים (SDS2)

• יעד: מנהלי מוצר יוכלו להעריך בביטחון, באופן מהיר וקל, את ההשפעות של שינויים בתכונות מוצר בוויקיפדיה. דיון
  • הֶקשר יעד: לאפשר ולהאיץ קבלת החלטות מבוססת על נתונים בנוגע לפיתוח תכונות מוצרים. מנהלי מוצר זקוקים לפלטפורמת ניסויים שבה יוכלו להגדיר תכונות, לבחור קהלי יעד של משתמשות ומשתמשים ולראות מדידות השפעה. האצת הזמן מתחילת הניסוי ועד לניתוח היא קריטית, כיוון שקיצור ציר זמן הלמידה יאיץ את הניסויים, ובסופו של דבר את החדשנות. משימות ידניות וגישות ייחודיות למדידה זוהו כמכשולים בפני המהירות. התרחיש האידיאלי הוא שמנהלי מוצר יוכלו להגיע מתחילת הניסוי לגילוי בלי התערבות ידנית או בהתערבות ידנית מעטה מצד מהנדסים ואנליסטים.
  • אנחנו ממוקדים בוויקיפדיה בשנת הכספים הבאה, כי שם 'חוויות הליבה' מעוניינים בעריכת ניסויים (האסטרטגיה הארגונית מביאה אותנו לשים דגש על ויקיפדיה), ומכיוון שכך מתאפשר לנו להתמקד ולסמן באופן ברור יותר עם אילו צוותים ובאילו פרויקטים אנחנו מעורבים. צוותים אחרים השתמשו ברכיב פלטפורמת הניסויים, וייתכן שימשיכו כך, אבל שימוש כזה לא יהיה במוקד היעד הזה.
    • תוצאת מפתח SDS2.1: עד סוף הרבעון השני נאפשר השלמת שני מחזורים מלאים של ניסויים באמצעות פלטפורמת הניסויים.
      • כיוון שהארגון מדגיש יותר ויותר את קבלת החלטות מבוססות על נתונים, אנחנו חייבים להנגיש עריכת ניסויים לכל צוותי המוצר, ולא רק לאלה עם מיומנויות מיוחדות. צוותי המוצר צריכים סטנדרטים, כלים ותשתית משותפים שיאפשרו להם את אלה:
        • בחינת רעיונות במהירות בכל בסיס המשתמשים הגלובלי שלנו
        • מדידת השפעת שינויים במוצר באמצעות מטריקות סטנדרטיות
        • שיתוף תוצאות עם בעלי עניין בתנועה באופן שקוף
      • למה אנחנו מעבירים את המוקד ממספר "הצוותים בעלי היכולת" ל"ניסויים שהושלמו":
      1. יישור קו אסטרטגי: זוהי מטריקת ההצלחה העיקרית של הפלטפורמה
      2. גישה מבוססת על נתונים: מחקר המשתמשים שלנו (טרם הושלם) מעלה רמות שונות של מוכנות צוותים ברחבי הארגון, בעוד אנחנו יודעים שצוות הווב אישר עניין בשני ניסויים ספציפיים.
      3. אופטימיזציה של משאבים: חשיפת פלטפורמות המוצר המינימלי (MVP) שלנו תדרוש הנחיה צמודה. לפיכך, בטווח הקרוב, יהיה יעיל יותר להתמקד בהזדמנויות ניסוי ולא בניסיון להגיע לצוותים רבים בבת אחת. אנחנו מתכננים להתקדם לעבר שחרור כללי של המוצר ואיננו רוצים להשקיע מחדש בהכשרת צוותים, אם אפשר להימנע מכך.
      4. התמקדות עתידית: משוב ממחזורי הניסוי שהושלמו יספק נתונים לשיפור הפלטפורמה שלנו בצורה יותר אפקטיבית מאשר הפקת לקחים מהטמעה חלקית או בלתי שלמה. ככל שאנחנו מתקדמים לעבר שחרור כללי של המוצר, התמקדות בהשלמת הניסויים מונעת השקעה בגישות זמניות שיצטרכו פיתוח חוזר.
      • אנחנו עובדים כרגע על מחקר משתמשים שנועד לגלות את הצרכים ואת הדרישות הנוגעות לכל הצוותים: נקבעו סקרים וראיונות כדי להוסיף בהירות לצורכי צוות המוצר במחצית השנייה של מאי 2025. לכשיסתיים המחקר, נכין יומן ניסויים שנוכל להשתמש בו כדי לקבוע את היעדים וסדרי העדיפויות של תוצאות המפתח הבאות.
    • Key result SDS2.2: Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
      • After a long and arduous process, we finally made a decision to integrate GrowthBook as a third-party experimentation solution that offers experiment flagging, automated analysis, and dashboarding, with support for guardrail metrics. Experiment Platform intends to replace the UI to define and deploy experiments (1) and the experiment analytics pipeline (5) with GrowthBook.
      • Because of the risks associated with this integration, the Experiment Platform Team believes that GrowthBook should be integrated as an experiment analytics pipeline first because it's non-disruptive and because it's the greatest source of risk.
      • The architectural decisions we made during FY24/25 SDS2 and GrowthBook’s modularity allow us to replace parts of the Experimentation Lab out of order, i.e. WMF staff can define and deploy experiments with xLab UI while analyzing them with GrowthBook. Further, we can run the current experiment analytics pipeline and GrowthBook’s in parallel, which allows for side-by-side comparisons as well as User Acceptance Testing in real-world scenarios.
    • Key result SDS2.4: At least 14 out of 20 product teams have used Test Kitchen to inform a strategic decision for an OKR initiative, by the end of Q4.
      • The work done under SDS2.1 revealed a critical insight: building an experiment platform is not enough — Product & Tech teams face some barriers to adoption. Even though teams see value, they often lack time, infrastructure, instrumentation, or confidence to begin. In addition to this, they may encounter technical blockers that will need to be addressed by thoughtful partnership.
      • KR SDS2.4 shifts our focus from building to scaling adoption. By continuing to partner with teams as they onboard onto the platform, overcoming technical barriers and providing hands-on migration support, we aim to consolidate experimentation onto Test Kitchen as the unified platform for product teams, enabling fast, self-service testing cycles that reduce dependence on engineering and analytics support.
      • This KR was planned after we decided to split SDS2.2 in two pieces of work, which is why the numbering was affected. SDS2.3 is an upcoming KR that is sequential to GrowthBook for Experiment Analytics.

---

קהלים עתידיים (FA)

קהלים עתידיים (FA1)

• יעד: לקרן ויקימדיה יהיו המלצות בנות־ביצוע על השקעות אסטרטגיות שיעזרו לתנועה שלנו לשרת קהלים חדשים באינטרנט משתנה. דיון
  • הֶקשר היעד: בשל השינוי המתמשך בטכנולוגיה ובהתנהגות המקוונת של משתמשים (לדוגמה, העדפה גוברת להשגת מידע באמצעות יישומונים חברתיים, הפופולריות של סרטוני חינוך־בידור קצרים, הופעת הבינה המלאכותית היוצרת), קרן ויקימדיה עומדת בפני אתגרים הנוגעים למשיכה ולשימור של קוראים ותורמי תוכן. השינויים האלה מביאים גם הזדמנויות לשירות קהלים חדשים באמצעות יצירה והגשה של מידע בדרכים חדשות. עם זאת, אין לנו כתנועה תמונה ברורה מבוססת על נתונים של התועלת והטרייד־אוף של אסטרטגיות פוטנציאליות שונות שאנחנו יכולים לאמץ כדי להתגבר על האתגרים או כדי לנצל הזדמנויות חדשות. לדוגמה, האם עלינו...
    • להשקיע בתכונות גדולות חדשות כמו צ׳טבוטים?
    • להביא את הידע של ויקימדיה ואת המסלולים שלה לתרומת תוכן לפלטפורמות צד־שלישי פופולריות?
    • עוד משהו?
  • כדי להבטיח שוויקימדיה תהפוך למיזם רב־דורי, נבחן השערות כדי להבין טוב יותר ולהמליץ על אסטרטגיות מבטיחות - לקרן ויקימדיה ולתנועת ויקימדיה - במטרה למשוך קהלים עתידיים ולשמר אותם.
    • תוצאת מפתח FA1.1: כתוצאה מתובנות והמלצות מניסויים בתחום קהלים עתידיים, עד סוף הרבעון השלישי, לפחות יעד אחד או תוצאת מפתח אחת השייכים לצוות שאינו עוסק בקהלים עתידיים ייכללו בטיוטת התוכנית השנתית של השנה הבאה.
      • מאז 2020, קרן ויקימדיה עוקבת אחר מגמות חיצוניות שעשויות להשפיע על יכולתנו לשרת דורות עתידיים של צרכני ידע ושל תורמי ידע ולהישאר תנועה משגשגת של ידע חופשי לדורות הבאים. צוות הקהלים העתידיים, צוות מו״פ קטן יפעל -
        • לבצע ניסויים מהירים, מוגבלים בזמן (בשאיפה לשלושה ניסויים לפחות בכל שנת כספים) כדי לבחון דרכים להתמודדות עם המגמות האלה
        • על יסוד תובנות מהניסויים, יציע המלצות להשקעות חדשות לא־ניסיוניות שהקרן צריכה לשאוף אליהן, כלומר, תוכניות או מוצרים חדשים שיש לעבוד עליהם באמצעות צוות או צוותים מלאים, במהלך תקופת התכנון השנתי הרגיל שלנו.
      • תוצאת המפתח הזאת תושג אם יעד אחד או תוצאת מפתח אחת לפחות השייכים לצוות מחוץ ל'קהלים עתידיים', שפועל לפי המלצה של 'קהלים עתידיים', יופיעו בטיוטת התוכנית השנתית לשנת הכספים הבאה.

---

וידיאו חברתי (FA2)

• יעד: צעירות וצעירים (בני פחות מ־25) יאהבו את ויקיפדיה, ילמדו ממנה, יהיו מעורבים בה וישתפו תוכן שלה בפלטפורמות שהם אוהבים לבלות בהן זמן גלישה. דיון
  • הֶקשר יעד: ההתנסות של קהלים עתידיים בסרטוני וידיאו קצרים בשנת הכספים הזאת הראתה שאנחנו יכולים להגיע אל קהלים צעירים יותר בקנה מידה גדול בפלטפורמות האלה, אבל נתוני בריאות המותג שלנו מראים שההשקעה הנוכחית שלנו אינה מספיקה כדי לשנות את מגמת השפל במודעוּת לוויקיפדיה ובזיקה אליה בקרב קהלים מדור Z.
  • כדי להבטיח שאנחנו מגיעים באופן אפקטיבי לדור הזה ומערבים אותו, אנחנו מאמינים שעלינו לפעול במגוון טקטיקות, ולהגדיל באופן משמעותי את המעורבות שלנו בתחומים כגון שיווק בתשלום ושיווק משפיענים, קמפיינים יצירתיים, היענות לטרנדים והעלאת רמת ההתנסות שלנו בערוצים האלה.
  • אנחנו צופים שהאתגרים העומדים בפנינו ידרשו השקעה משמעותית יותר כדי לסייע לנו להתגבר עליהם, בפרט במאמצי התקשורת והשיווק ליצירת מעורבות, כמו גם שיתוף פעולה בין־מחלקתי ליצירת מוצרים חדשים וחוויות המיועדות להגברת הנוכחות של מותג ויקיפדיה ותוכן ויקיפדיה בפלטפורמות האלה.
    • תוצאת מפתח FA2.1: לחולל 9,500,000 צפיות מתוכן וידיאו בפורמט קצר בכל הערוצים בבעלותנו עד סוף המחצית הראשונה.
      • השנה הצלחנו להגיע לכמיליון צפיות בתוך 3 חודשים מפרסום סרטונים קצרים בערוצי Wikipedia@ בטיקטוק, באינסטגרם וביוטיוב. עד תחילת שנת הכספים הבאה, אנחנו צופים יותר עוקבים בערוצים בבעלותנו ויותר תובנות לגבי תוכן אפקטיבי ומעודד מעורבות שאנחנו יכולים ליישם כדי להגיע אף ליותר צפיות.
      • באמצעות קביעת מטרה שאפתנית במחצית הראשונה של השנה, אנחנו מקווים להשיג עוד השפעה משמעותית, לאפשר יצירה של אסטרטגיות ותהליכים שיקלו על העבודה, ולהיות מסוגלים לשכנע לתרום משאבים נוספים כדי להשיג את המטרה הזאת.
    • תוצאת מפתח FA2.2: להגדיל את מספר העוקבות והעוקבים שלנו מחוץ לפלטפורמה, בטיקטוק, מהיקף בינוני (Mid tier - בין 100 אלף ל־250 אלף עוקבים) להיקף גדול (Macro tier - בין 250 אלף למיליון עוקבים) עד סוף שנת הכספים 2025-26 (יוני 2026).
      • אנחנו כרגע בהיקף בינוני של עוקבי טיקטוק (Mid tier - בין 100 אלף ל־250 אלף עוקבות ועוקבים), והמטרה שלנו היא להגיע להיקף גדול (Macro tier - בין 250 אלף למיליון עוקבות ועוקבים) עד סוף שנת הכספים 2025-26 (יוני 2026). ההיקפים האלה: קטן (Micro), בינוני (Mid) וגדול (Macro) הם מדדים סטנדרטיים בתעשייה לגודל הקהל והתפוצה. כדי להגיע לשם, נלטש את אסטרטגיית התוכן שלנו, כדי למשוך טוב יותר עוקבות ועוקבים מדור Z, וכדי להגביר את הנראות הכוללת שלנו באמצעות ניהול קהילה. הביצועים במחצית הראשונה יספקו נתונים להתאמות טקטיות במחצית השנייה, כדי להאיץ צמיחה ולהגיע אל השלב הזה.
    • תוצאת מפתח FA2.3: להוציא לדרך מוצר מחוץ לפלטפורמה שמיועד לשיטות החדשות של למידה וצריכת מדיה של קהלים עתידיים, ולהביא אותה לשוק באמצעות מיתוג מוצר וקמפיין שיווק בשיתוף פעולה.
      • קהלים עתידיים עובדים בדרך כלל על ניסויים בקנה מידה קטן עם שיווק מינימלי/אורגני. בשנה הזאת, אנחנו רוצים להשאיר זמן לקמפיין בקנה מידה גדול יותר להצגת המוצר החדש ולשיווקו, ולהתמקד בקהלים צעירים יחסית מחוץ לפלטפורמה שלנו.

---

תמיכת מוצר והנדסה (PES)

תמיכת מוצר והנדסה (PES1)

• יעד: צוותי מוצר והנדסה של קרן ויקימדיה יותר אפקטיביים עקב תהליכים משופרים, והם מטפחים שינוי חיובי בתרבות שלנו. דיון
  • הֶקשר היעד: היעד הזה עוסק בהפיכת דרכי העבודה של קרן ויקימדיה למהירים יותר, חכמים יותר וטובים יותר. אופן העבודה הוא העניין המרכזי. פירוש הדבר, פחות חיכוך ומכשולים (חוסר יעילות וטעויות) בתהליכים והשגת תוצאות מהר יותר. היעד הזה עוסק גם בלמידת דרכי עבודה שאפשר לאמץ אותן בכל המחלקות והארגונים.
    • תוצאת מפתח PES1.1: עד סוף הרבעון השני נגדיר יעד רמת שירות ל־6 שירותי הפקה, בהתבסס על לוח תעדוף שמטרתו למקסם את הלמידה שלנו לגבי אופן ההגדרה של יעד רמת שירות והשימוש בו כדי לקבל החלטות מושכלות על תעדוף עבודה הקשורה לאמינות שנעשית בידי צוותי בעלי עניין.
      • יעד רמת שירות (SLO) הוא הסכם בין צוותי בעלי עניין על רמת מטרה של שירות (אמינות/ביצועים) שהצוותים משתפים פעולה כדי לעמוד בה (ולא לעלות עליה יותר מדי). לדוגמה, הוא עוזר לקבוע מתי צוות פיתוח צריך לתעדף או להוריד בסולם העדיפויות עבודה על אמינות או על ביצועים, או מה נחשב לבעיה. צוותים צריכים לדאוג לזהות מה דורש טיפול מיידי (התרעה/תגובה על תקרית/באגים קריטיים) ומה לא. המטרה היא להפחית חיכוך בכל הפונקציות באמצעות משא ומתן על יעדים ואספקת מידע למען תעדוף ברור ומשותף.
    • תוצאת מפתח PES1.2: עד סוף הרבעון השני ישפיעו האותות הקהילתיים (כולל רשימת המשאלות) על קרן ויקימדיה לתעדוף לפחות 5 תוכניות עבודה למוצרים לרבעונים השלישי והרביעי.
      • מטרתנו היא לזהות ולקדם בברכה תעדוף עבודה על־ידי צוות, שמתבסס על בקשה מגובה בראיות מהקהילה.
      • שתי השערות מתוכננות מתמקדות ברשימת המשאלות בלבד. הן נועדו לשפר אמון, להזרים תהליכים ולהגביר השתתפות בקרב הסגל והמתנדבים. השערה נוספת היא ניסוי שנועד לראות אם יש די אותות בעלי ערך מ'המזנון' וכולי, ואם בינה מלאכותית יכולה לתמוך ביכולת איסוף האותות שלנו.
    • תוצאת מפתח PES1.3: שני ניסויים בין־מחלקתיים בשלביהם המוקדמים, מתוּקפים על־ידי קהלים חיצוניים של צרכנים, תורמי כספים ותורמי תוכן שלנו, ישולבו בתוכנית השנתית על־ידי הקרן.
      • העבודה הזאת נועדה ליצור ניסויים ותהליכי ניסוי להטמעה בכל רחבי הארגון.
      • הקרן מחזקת תרבות של ניסויים בין־מחלקתיים באמצעות שילוב שני ניסויים מתוּקפים, בשלביהם המוקדמים, בתוך התכנון השנתי שלה. היוזמה הזאת מטפחת שיתוף פעולה מעבר לצוותי התכונות של מחלקת המוצר והטכנולוגיה ומעודדת עוד חדשנות עם מחלקות אחרות בארגון (כגון 'תקשורת והתקדמות'). באמצעות זריעת רעיונות חדשים שלא נבדקו והזרמת תהליכים לניסוי, הצוותים מגבירים יצרנות ומגדילים השפעה. ההצלחה נמדדת לפי השלמת שני ניסויים בין־מחלקתיים לשנה, שילובם בעבודת יעדים ותוצאות מפתח (OKR) עתידית, והגברת ההטמעה של פרקטיקות ניסוי. דוגמאות לתוצרים הן אבטיפוסים חדשים להגדלת מספר העורכים החדשים והיצרנות שלהם ומוּדעוּתם לתכונות ניסיוניות שמעמיקות את הקשר של קוראים ושל תורמי כספים לוויקיפדיה. הזדמנות ספציפית אחת שזוהתה היא לקשר בין גילוי תכונות קטנות לחגיגות יום־הולדתה ה־25 של ויקיפדיה.
    • Key result PES1.4: By the end of Q4, we'll see a 10% adoption rate increase for Codex among P&T teams.
      • As a standardized UI library, Codex vastly reduces both the maintenance burden of creating custom UI components, as well as the time needed for implementing product UIs. Codex also provides a shared vocabulary for talking about design and implementation, which increases efficiency between Design & Engineering.
      • Codex will lose utility if adoption doesn’t increase and Codex isn’t widely used, and currently it is not being adopted or widely used in some places because the tooling isn't ready for some use cases. It may also need more prominent advertising/awareness. This work is a priority because teams must be able to adopt Codex organically, and currently not all can without blockers to adoption being addressed first.
      • We're anticipating that this will mean:
        • Discovery - What do different teams show us is blocking them? What are the use cases and blockers about which we are not yet aware?
        • Improvement - Example: We know that Codex PHP 1.0 will unblock server-side adoption.
        • Metrics deep dive - Example: What do the baseline metrics established in Q1 tell us about where organic adoption is not working (and are there lessons from OOUI adoption in years past)?
      • The KR will focus on tracking “official” usage (i.e. adoption that follows the documented guidance) separately from partial or piecemeal usage, e.g. when teams use only part of a component or just the CSS. The latter type of adoption incurs a higher maintenance cost than out-of-the-box component usage.
    • Key result PES1.5: 20% of service SLOs result in an impactful decision made by the end of Q4.
      • Service Level Objectives (SLOs) are a tool used to determine priorities based on data from service reliability. For instance, whether a down service needs immediate attention. SLOs work most effectively when ownership is clear, and everyone is using them. To make this happen we need to shift development culture toward adopting SLOs for every service. Building on the last few quarters of creating SLOs and testing them with service teams, we've identified an opportunity to clarify the value of SLOs, so that we can continue to spread this culture.
        • We have 19 SLOs currently.
        • We want to incentivize SLOs for services that would be most likely to leverage them. If we get ~3-4 (~20% 0f 19) "impactful decisions" from our current crop, great, but we anticipate we'll need to make more. The denominator will increase, but that further incentivizes targeting the right services.
        • Q4 is the end of the timebox because we want more than one cycle of data, and each quarter is a cycle. It also gives us space to shore up tooling, pilot SRE-alerting, etc.
      • Success looks like:
        • Impactful decision = “is this service currently reliable enough, or do we need to prioritize work to fix it” -- that is, it's as much a decision to find an error and say it's OK not to prioritize it, as it is to find an error and prioritize correcting it.
        • We want decisions to be diverse (e.g. Architectural vs Organizational vs Implementation; or affirmative vs deciding not to do something), because this is about spreading the value of SLOs and shifting culture. All the same type of decision or all from the same team doesn't accomplish that, even if it's good.
        • Even if we don't meet the KR target, we hypothesize that we'll have learned valuable information about why (e.g. we're targeting the wrong services).
        • Important: 80% of our SLOs not having an impactful decision is not a failure state for those, because most of the time services should not be failing.
    • Key result PES1.6: 20% of critical unowned services, according to a risk analysis framework, get owners committed by the end of Q4.
      • Clear code and service ownership is critical to ensuring the Wikimedia Foundation’s technical infrastructure remains reliable, scalable, and secure. Addressing current gaps in ownership will improve accountability, enhance cross-team collaboration, fast-track effective decision-making, and reduce risks to platform stability, security and sustainability. Additionally, it will provide greater clarity for Wikimedia affiliates and volunteers, helping them understand who is responsible for maintaining and supporting key services.
        • We estimate there are ~20 critical services without owners.
        • We think we can assign 4 owners over 4 months during Q3/4. The first 2 months or so will be setting ourselves up for success with prep work.
        • We plan to develop a risk analysis framework to determine criticality, as part of hypothesis work under this KR.
    • Key result PES1.7: By the end of Q4, for Wishes received in Q3 and Q4, the rate of Wishes shipped improves to 5%.
      • We calculated that there have been 76 Wishes submitted since Q1 this FY, and 2 have been completed, for a rate of ~2.6%.
      • Commtech can, on average, complete a Wish per quarter (the time varies by size, hence the average).
      • If we assume that over the next 6 months we'll get a similar number of new Wishes, then we can do ~2 more without any other teams contributing. Since the whole point is more teams picking up Wishes, 5% total is roughly 2 more wishes on top of the baseline of 2, for a total of 4 by the end of June. One wish per P&T team would be ~3-4 teams depending on Commtech's contribution. In short, we want to double our Wish completion rate over the next 6 months.
      • Success:
        • Diversity of contribution: we want Wishes to be completed by several teams, not just one. We can count contractor support as one "team." We need to engage teams beyond ad-hoc requests; this is about operationalizing their commitment and delivery.
        • Diversity of Wish: we want a variety of Wishes, including service area, type (bug, feature, etc.), and size.

השערות עסקיות

רבעון ראשון

הרבעון הראשון (Q1) של התוכנית השנתית של קרן ויקימדיה כולל את החודשים בין יולי לספטמבר.

השערות לגבי חוויות ויקי (WE) [ תוצאות מפתח לחוויות ויקי ] שיחה
שם מקוצר להשערה	טקסט רבעון ראשון	פרטים ודיון
WE1.1.1	אם נבקש ממתנדבות וממתנדבים חדשים (או חדשים יחסית) לאשר שהטקסט שהם העתיקו והדביקו מאתר חיצוני הוא יצירה מקורית שלהם, נראה ירידה של 10% או יותר בשיעור השחזורים של עריכות מתנדבות ומתנדבים חדשים הכוללות תוכן חדש בשל הפרת זכויות יוצרים (או מדיניות דומה).
WE1.1.2	אם נציג גרסת בטא ראשונית של הצעת עריכה ב'נימה משופרת', נוכל לדעת אם המתכונת החדשה הזאת של הצעת עריכות תורמת משמעותית להגדלת העריכות הקונסטרוקטיביות לתורמי תוכן חדשים בלי להגביר את נטל הפיקוח המוטל על מנטרים או בודקי עריכות.
WE1.1.3	אם נציג 'מצב הצעות' חדש המיועד לעורכות ולעורכים בכירים ומשולב בעורך החזותי (נייד ומחשב) כתכונת בטא עם הצעות לשלוש עריכות חדשות או יותר הכלולות בתוכו, נגלה אילו התאמות (אם בכלל) צריך לעשות לפני הערכת החוויה עם מתנדבות ומתנדבים חדשים (או חדשים יחסית) באמצעות ניסוי מבוקר.
WE1.1.4	אם נפיץ 'בדיקת מקורות' בוויקי האנגלית באמצעות ניסוי מבוקר, נראה עלייה של 10% או יותר בעריכות הקונסטרוקטיביות שעורכות ועורכים חדשים מפרסמים ונדע אם יש תמיכה מספקת בקרב המנטרים והמנחים שמאפשרת את הרחבת השימוש בתכונה.
WE1.1.5	אם נבחן מערכות התקדמות באמצעות אבטיפוסים של עיצוב עם עורכות ועורכים חדשים, נוכל לזהות אילו סוגים של נקודות ציון, הדרכה והכרה נתפסים כטובים ביותר לעידוד מוטיבציה, ולהשתמש בתובנות האלה כדי להשלים את פיתוחו של עיצוב לניסוי פיילוט עתידי של ויקי.
WE1.1.6	אם נחקור את המחסומים והמאפשרים החברתיים וההתנהגותיים החשובים ביותר לעריכת web במכשיר נייד, באמצעות מחקר משתמשים וניתוח נתונים, נפיק לפחות 3 תובנות מעשיות שסוגרות פערי ידע עיקריים ומחזקות את יכולתנו לתעדף בביטחון השקעות במוצר למחצית השנייה של שנת התקציב 2025-26 ומעבר לה.
WE1.2.1	אם ניצור הוכחת היתכנות להצגת נתונים של תרומות תוכן שיתופיות במערכות הוויקי, נוכל לאסוף משובים מ־30 תורמי תוכן לפחות, 70% מהם יגידו שזו תכונה שימושית שתוכל לעזור לעודד צמיחה בשיתוף הפעולה.
WE1.3.1	אם נשתמש בצרכים שזוהו במחקר ובתכנון קודמים ונשתף הדמיות מוקדמות של X מודולי ניהול התוכן המשפיעים ביותר, נוכל לשנות את דף הבית כדי לכלול בו פעולות ניהול תוכן.
WE1.3.2	אם נשנה את דף הבית של עורכות ועורכים חדשים כדי להציג באופן מוּתנֶה מודולים של ניהול תוכן, נוכל להוכיח את ישימות השימוש בדף הבית למען מנהלי התוכן.
WE1.4.1	אם נכניס מספר שיפורים מאלה המוצעים ב־T396489, נצמצם את שאילתות 'השינויים האחרונים' האיטיות ב־X אחוזים במערכות הוויקי הגדולות. אז יוכלו כלי ניהול תוכן להפעיל מודולים של דף הבית על מערכות הוויקי האלה, בלי לחשוש מקשיים מיוחדים בביצועי מסד הנתונים.	T400696
WE2.1.1	אם נזמין דוברות ודוברים ילידיים של מערכות ויקי קטנות, באמצעות באנר CentralNotice בוויקיפדיה עם תעבורה גבוהה באזור שלהם, לתרום ל'הצעת עריכות' (SuggestedEdits) ותכונות צמיחה אחרות, נוכל להעריך אם הגישה הזאת מושכת דוברות ודוברים ילידיים חדשים ואם הם משתמשים בכלי העריכה האלה כדי לשפר תוכן חיוני.
WE2.1.2	אם נפתח ונפיץ הצעות לתרגום המיועדות במיוחד לעורכות ולעורכים חדשים, נוכל לבחון אם הגישה הזאת מייצרת תוצאות תרגום טובות יותר בהשוואה לגישה הנוכחית שלנו. זהו מענה לאתגרים ידועים שעורכות ועורכים חדשים עומדים בפניהם, שיש בהם סיכון גבוה יותר למחיקת ערכים. באמצעות הפנייתם לתרגום תוכן קל יותר לניהול, אנחנו פועלים במטרה להכניס עורכות ועורכים לתהליך התרגום באופן פשוט ונגיש יותר. ערכים טובים ופסקאות הרחבה יכולים להיראות כסיבוך מוגבל מבחינת העיצוב והאורך הכולל.
WE2.1.3	אם נלמד על חוויית העורכים בעת שהם יוצרים ערכים חדשים או פסקאות הרחבה חדשות (בכלל זה מוטיבציה, נקודות כאובות והתגובה שלהם לרעיונות חדשים לגבי תמיכה יותר טובה בהם), נגלה את צורכי המשתמשים ואת התנהגותם, שיתנו לנו תובנות ואסטרטגיות מעשיות, מידע שנוכל להעביר לצוותי מוצר, עיצוב והנדסה כדי לשפר את חוויית יצירת הערכים.
WE2.1.4	אם נחקור באמצעות ראיונות או סדנאות משתתפים איך שלוש ויקיפדיות בינוניות מטפלות בפערי ידע ובקביעת חשיבות, נגלה הגדרות עבודה או רעיונות מסגרת, רלוונטיים לכל אחת מהקהילות, של המושג 'ידע חיוני'.
WE2.2.1	אם נעקוב אחר הכנסת 'פארסויד' (Parsoid) לשימוש ונשלב ויקיפונקציות ברוב הוויקימילונים ובכמה ויקיפדיות שהתעבורה בהן נמוכה, נקבל את הבדיקות שאנחנו צריכים כדי להכניס אותם לשימוש בביטחון במערכות ויקי גדולות יותר.
WE2.2.2	אם נאפשר לויקיפונקציות להפיק טבלאות, סגנונות וקישורים ב־HTML, נדגים באמצעות פונקציה שמציגה טבלת נטייה את היכולת שלה להפיק ידע חדש נטו בוויקימילונים, מעבר להמרות פשוטות.
WE2.2.3	אם נוסיף תמיכה בישויות ויקינתונים בקריאות פונקציה מוטמעות, נאפשר יותר מ־200 פונקציות חדשות שיכולות להפיק משפטים מלאים תוך שימוש בישויות ויקינתונים, ובכך נקל על השימוש בפונקציות במיזמי ויקימדיה.
WE2.2.4	אם נפתח תוכנית ארכיטקטורה לגבי מיקום 'תוכן אבסטרקטי' והאינטראקציה בינו לבין ויקיפדיה, נהיה מוכנים יותר ליישום פלטפורמת 'ויקיפדיה האבסטרקטית' כדי להגדיל אספקת תוכן אנציקלופדי באיכות גבוהה.
WE2.2.5	אם נגדיר את צורכי המוצר בציטוט מקורות הנחוצים ל'תוכן אבסטרקטי', ונפיץ אותם בקרב צוותי 'מוצר וטכנולוגיה', נוכל להניע עבודה בין־ויקימדית להעברת מידע ראשוני המלווה 'תוכן אבסטרקטי', שהיא קריטית להצלחת פרויקטים בין מערכות ויקי.
WE2.2.6	אם נהפוך את פורמט הבקשות של הבקנד הפנימי שלנו ליותר עשיר ומתומצת, נוכל להגביר את יציבות המערכת שלנו, ובכך לתמוך בשימוש רחב יותר.
WE2.2.7	אם נספק חלקים של אבטיפוסים תוך שימוש בקריאות ויקינתונים או ויקיפונקציות כדי להפיק תקצירים בשפה טבעית, נראה את מוכנותנו לפרויקט, ונהיה מוכנים לשימוש בו לאימון בינה מלאכותית, כך שבני־אדם לא יצטרכו לחשוב יותר מדי על פונקציות.
WE2.2.8	אם נספק יבוא של היגדים עם מגדירים מוויקינתונים, יתאפשר לנו להפיק עובדות רב־צדדיות (עובדות שכדי להביע אותן צריך יותר מנושא, פרדיקט וערך), שהן, לפי הערכה, 50% מהתוכן האנציקלופדי בוויקינתונים.
WE2.2.9	אם נספק מטמון ('קאשינג') של ישויות ויקינתונים מאוחזרות, נוכל להפחית ב־50% לפחות את זמן הריצה הממוצע של פונקציות מבוססות תוכן של ויקינתונים, ובכך נפחית זמני ריצה ותסכול של משתמשים.
WE2.2.10	אם נספק רכיב משמעות לֶקסֶמי לממשק Wikifunctions יוכלו תורמי התוכן לזהות ולבחור לֶקסמות רלוונטיות בלי לעזוב את הפלטפורמה או להחליף את ההקשר מצמצם־הוויקיפונקציות (Wikifunctions—reducing context). בכך יתאפשר להם ליצור מהר יותר ובהצלחה רבה יותר פונקציות הקשורות לשפה.
WE2.2.11	אם נתייחס לממצאי שימושיות מקהילת דגבאני (Dagbani) בשילוב ויקיפונקציות בוויקיפדיה, נבחין שהעורכות והעורכים נתקלים בבעיות שימושיות קריטיות מעטות או אפסיות כשהם מכניסים פונקציה לתוך ערך בזמן הבדיקה.
WE3.1.1	אם נערוך בדיקת A/B לגרסה משופרת של תכונת הגלישה בלשוניות (טאבים), ביישומוני IOS, נראה עלייה של 5% בשימוש רב־יומי בקרב משתמשי הלשוניות.
WE3.1.3	אם נספק למשתמשות ולמשתמשים דרך חדשה לגלישה בין תמונות או תוכני וידיאו רלוונטיים המשולבים בדפי ערכים, נראה לפחות 3 אחוזי הקלקה (click-through rate) בקרב משתמשות ומשתמשים שנחשפו לתכונה הזאת.
WE3.1.4	אם נראה לקוראות ולקוראים כמה רעיונות למעבר ברשת הידע שבמערכות הוויקי, נצא עם רשימת תיעדופים של רעיונות להמשך פיתוח.
WE3.1.5	אם נספק לקוראות ולקוראים בווב את האפשרות לראות גרסת תרגום־מכונה של תוכן ויקיפדיה שאינו זמין בשפה שלהם, נלמד אם יש עלייה בפעילות הקריאה, שתימדד כעלייה של 3% באינטראקציות עם הדף, משיכת קוראות וקוראים לוויקי בשפה המקומית, עם עלייה פוטנציאלית בפעילות העריכה המקומית. מדובר בסביבה לבדיקת A/B מבוקרת למשך 6 חודשים לכל היותר, וב־13 ויקיפדיות לאחר קבלת הסכמה מראש, תוך שימוש בשירותים פתוחים של תרגום־מכונה שכבר זמינים לעורכי ויקיפדיה.
WE3.2.1	אם נשתף פעולה עם גיוס התרומות, נפתח מצגות תורמים יותר מזמינות, משולבות ומותאמות אישית בסקירה השנתית של iOS, לפי מדידות באמצעות בדיקת משתמש. בעקבות זאת תבוא השערת המשך ברבעון השני כדי להעריך אם הסקירה השנתית המשופרת הראתה גידול של 5% בתרומות לעומת הסקירה השנתית של 2024.
WE3.2.2	אם נבקש מקוראות ומקוראים שמשתמשים ביישומון של 'אנדרואיד' בשווקים ללא קמפיין להתקין תזכורת אופציונלית וניתנת להתאמה אישית (סכום ותדירות) לתרומות בהתאם לשימוש שלהם בוויקיפדיה, נראה גידול של 5% בתרומות דרך תפריט היישומון בשווקים האלה.
WE3.2.3	אם נערוך בדיקת A/B על משתמשות ומשתמשים מחוץ לחשבון שתציג הבדלים קלים בנקודת הכניסה לתרומות הן בניידים והן במחשבים, נבחין במספר גבוה ב־2% של תרומות דרך מסלולי הטיפול בהשוואה לקבוצת הבקרה.
WE3.3.1	אם נוסיף אלמנטים מותאמים אישית, בהשקעת מאמץ נמוכה עד בינונית, שביקשו משתמשות ומשתמשים של iOS בשנה הנסקרת 2024 עד 2025, נראה עלייה של 3% בשביעות הרצון בהשוואה לשנה שעברה, במדידה באמצעות בדיקת שימושיות או בדיקת בטא.
WE3.3.2	אם נרחיב את לשונית העריכה הקיימת ב'אנדרואיד' ונהפוך אותה לצומת פעילות מותאמת אישית שכולל תובנות לגבי קריאה והשתתפות ללא עריכה, נראה גידול של 5% במעורבות הרב־יומית באמצעות הלשונית בהשוואה לגרסה המקורית.
WE3.3.3	אם נוסיף אוואטר נפתח (unlockable avatar) אחד לפחות ביישומון 'אנדרואיד' לבעלי חשבון שישיגו אותו באמצעות פעולות קריאה משמעותיות, כמו שמירת מספר מסוים של ערכים, נגדיל מעורבות חוזרת של משתמשות ומשתמשים רשומים באמצעות פעולה מקושרת ב־10% לאורך ימים רבים.
WE3.3.4	אם ניתן למשתמשות ולמשתמשים רשומים את האפשרות לשמור ערכים לרשימת קריאה פרטית, נצפה לגידול במעורבות באתר, שתשתקף במדידת גידול של 5% בתעבורה פנימית באמצעות קישורים אצל קוראות וקוראים שמשתמשים בתכונה, וגידול מובהק סטטיסטית אצל כל המשתמשות והמשתמשים.
WE3.3.5	אם נערוך מחקר משתמשים שיאפשר לקוראות ולקוראים בווב לאסוף או לאצור תוכן מוויקיפדיה, לפחות 10% מהמשתתפות והמשתתפים ישמרו סוג ייחודי אחד או שניים של תוכן (כגון, ערכים, מובאות, מדיה) לאוסף.
WE3.4.1	אם נעבוד על מערכת היברידית של 'נקודת נוכחות' (PoP) ו'רשת הפצת תוכן' (CDN), נוכל להציג גם נקודות נוכחות מלאות (full) וגם נקודות נוכחות מוקטנות (mini), ממשיות ובענן, כפי הצורך, ובכך נפרוס את התשתית לאבטיפוס של הפעלת נקודת נוכחות מוקטנת בעתיד.
WE3.6.1	אם נערוך בדיקת A/A על אחוז השימור של משתמשות ומשתמשים מחוץ לחשבון, נבסס קו התחלה לאחוז שימור שנוכל להשתמש בו ברבעונים עתידיים.
WE3.6.2	אם ניצור ונפרסם הגדרה של קוראת רשומה או קורא רשום, נוכל להשתמש בהגדרה הזאת בכל הצוותים ובכל ההשערות העסקיות הקשורים ל־WE 3.3 KR.
WE3.6.3	אם נשתף קהילות בשיחות על הצרכים המתפתחים של קוראות ושל קוראים, ועל טבעו המשתנה של ידע באינטרנט, נוכל לבנות מיקוד משותף בשאלה איך לשרת את הקוראות ואת הקוראים ובשאלה איך לעבוד יחד על אם וכיצד יש לבדוק את רעיונותינו השונים (כולל אלה העוסקים במולטימדיה, חיפוש וגילוי ולמידת מכונה).
WE3.6.4	אם נחקור את המניעים, ההתנהגויות והצרכים הייחודיים שנמצאים בבסיס השאלה למה ואיך משתמשים קוראות וקוראים בוויקיפדיה ופלטפורמות ידע אחרות, יהיו לנו ממצאים שנוכל להשתמש בהם כדי להוסיף ידע לאסטרטגיית הצרכנים שלנו וכדי לפתח אותה.
WE4.1.1	אם נכין אבטיפוס של זרימה שמתקיימת באופן מינימלי ולא למצבי חירום ונשאיר לולאת משוב איטֶרָטיבית פתוחה בשעה שאנחנו מפתחים אותה עם משתמשות ומשתמשים בעלי הרשאות רחבות, אז תתמוך הקבוצה הזאת בהפצה מורחבת של הזרימה הזאת.	Project page
WE4.2.1	אם נציף את רמת הסיכון של hCaptcha בקשר ליצירת חשבונות לבעלי תפקידים אמינים, נפחית את הזמן הדרוש לזיהוי בעלי כוונות רעות ונעלה את מספר הזיהויים של חשבונות בעלי כוונות רעות שנוצרו בפלטפורמה. נוכל למדוד את הצלחת ההשערה בבדיקת אחוז החסימות המוטלות על חשבונות, ההתאמה בין רמות הסיכון של hCaptcha וחסימת חשבונות באופן כללי ומשוב איכותני מבעלי תפיקידים.
WE4.2.2	אם נייצר הצעות לחקירות לבדיקת משתמשים (CheckUsers) לשם מעקב, נראה ירידה בזמן הדרוש לזיהוי חשבונות בעלי כוונות רעות ועלייה במספר החשבונות המזוהים של בעלי כוונות רעות. נדע שהצלחנו כשנראה שימוש סדיר בתכונת "הצעות לחקירות" ועלייה בהגבלות על חשבונות שזוהו דרך הצעות לחקירות ודרך סקר משוב איכותני.
WE4.2.3	אם ננתח נתונים מניסוי יצירת חשבונות ב־hCaptcha נבין את משפך יצירת החשבונות ואת האפקטיביות של התצרף והניקוד של hCaptcha. כמו כן, נקבל את הנתונים הנחוצים כדי להוסיף ידע להפעלות העתידיות של hCaptcha ביצירת חשבונות.
WE4.2.4	אם ניישם את כרטיס מידע המשתמש (UserInfoCard) בכל מערכות הוויקי, ניתן כלים בידי בעלי תפקידים ומנהלי תוכן לזיהוי יעיל יותר של חשבונות בעלי כוונות רעות ולצמצום הנזק שהם גורמים.	Project page
WE4.2.5	אם נערוך מחקר, נתייעץ עם קהילות ונחקור פתרונות טכניים, נוכל להגדיר סדרה של עילות מובנות לחסימה שאפשר להשתמש בהן בכל מערכות הוויקי של קרן ויקימדיה.
WE4.2.6	אם נפתח את היכולת להפעיל אשכולות מבוססים על חיפוש חופשי (OpenSearch) בפלטפורמת הנתונים, ניתן כלים בידי צוותי הנדסת תכונות המוצר לפיתוח מערכות המשלבות את היכולת הזאת עם אוטונומיה רחבה, עמידות ועצמאות ממערכות מבוססות־חיפוש אחרות. הלקוח (tenant) הראשון והעיקרי של המערכת הזאת יהיה שירות IPoid.
WE4.2.7	אם נפעיל שילוב של hCaptcha Enterprise בכמה ויקיפדיות ייצור כניסוי פיילוט, נוכל לאסוף מידע על היעילות והערך של hCaptcha Enterprise נגד השחתות, על זיהוי בוטים, על שימושיות ועל נגישות.
WE4.3.1	אם נשלב תמיכה בקובצי העוגייה החדשים של Edge Uniques לתוך requestctl, שהוא מנוע הקצה לחוקים למאבק בהשחתות SREs, נוכל להתגונן טוב יותר מפני DDoS ושימוש חוזר בתוכן.
WE4.4.1	אם נוכל להכניס שיפורים מבוססי משוב מניסויי פיילוט, ולהפעיל חשבונות זמניים בכל המיזמים, נוכל להגן מפני חשיפת מידע מזהה אישי (כתובות איי־פי) של משתמשים לא־רשומים בכל המיזמים שלנו, כך שהוא יהיה זמין רק לפחות מ־0.1% מכל המשתמשים הרשומים שלנו.	Project page
WE4.4.2	אם נתקשר עם בעלי העניין הרלוונטיים בתנועה (בכלל אלה, קהילות ויקי ובעלי תפקידים ברמה הגלובלית) באופן ברור ובזמן, נוכל להפעיל חידושים בכל מערכות הוויקי הנותרות, להפחית עומס עבודה המתגלה ברגע האחרון ולהימנע משחזור לאחור של חידושים.
WE4.4.3	אם נקל על מנטרים לסנן פעולות לפי קריטריונים ולראות את פעולות החשבונות הזמניים לפי כתובות האיי־פי שלהם, נאפשר הפצה מוצלחת של החשבונות הזמניים בכל מערכות הוויקי.
WE4.4.4	אם נאפשר ביטול של הגישה לחשיפת כתובות איי־פי של חשבונות זמניים לפי מדיניות הגישה לחשיפת כתובות איי־פי, ונציף את התכונה במקומות נוספים, נאפשר את הצלחת ההפצה של החשבונות הזמניים בכל מערכות הוויקי.
WE4.5.1	אם נערוך מחקר איכותני כדי לזהות דוגמאות של השחתה מבעלי כוונות רעות הנעזרים בבינה מלאכותית יוצרת (כגון ספאם, הטרדות, משחיתים חוזרים, עריכה בתשלום בלי גילוי נאות או קמפיינים של דיסאינפורמציה), נוכל להעריך את הנזק למודלים הקהילתיים שלנו ולייצר רעיונות לבלימת סוגים שונים של השחתות הנעזרות בבינה מלאכותית יוצרת.
WE4.6.1	אם נהפוך את תהליך סנכרון החשבונות לאוטומטי בתוך Zendesk לאיפוס סיסמאות, נקל על הנטל המוטל על צוות האמון והתמיכה ונאפשר להם לטפל ביותר בקשות לאיפוס אימות דו־שלבי.
WE4.6.2	אם נתמוך במשתמשות ובמשתמשים ונעודד אותם להירשם באמצעי אימות מרובים, תפחת הסבירות שמשתמשים שיפעילו אימות דו־שלבי ינעלו את עצמם מחוץ לחשבון שלהם.
WE4.6.3	אם נאפשר לכל המשתמשות והמשתמשים בעלי כתובת דוא״ל מאומתת להפעיל אימות דו־שלבי בחשבונות שלהם, אבל לא נפרסם באופן יזום את השינוי הזה למשתמשות ולמשתמשים, הנטל על צוות התמיכה בשחזור יישאר ברמה משמעותית.
WE5.1.1	אם נשתמש בבקנדים שונים לאחסון להתחברות מאומתת ולהתחברות אנונימית, נוכל להגן על Sessionstore מפני התקפות DDoS והצפה של בקשות, על־ידי כך שלא נכביד עליו בהתחברויות אנונימיות שנוצרו כדי למנוע CSRF בעמודי האימות.	T398814
WE5.1.2	אם נשנה את עוגיות מדיה־ויקי הזמניות לפורמט מובנה עם חתימה קריפטוגרפית, נוכל להשתמש בנוכחות של הפעלה (session) כגורם בהגנה מפני מציפי בקשות, בכך שנאפשר וידוא אמין של הפעלות בקצה באופן יעיל שאפשר להרחיב אותו בקלות.	T398815
WE5.1.3	אם ניצור פתרון להגבלת היקף לשער ה־API תוך שימוש בסביבת פיתוח מקומית מבוססת על Kubernetes, נוכל לקבוע את האפשרות הטובה ביותר לבדיקה עם תעבורת ייצור באמצעות השוואת הביצועים והפונקציונליות של שלושה שירותי הגבלת היקף שונים לפחות.	T398913
WE5.2.1	אם נעצב מחדש את ממשק REST API הניסיוני כדי לתת מענה לצורכי המידע של המפתחים, נשפר את בהירות התיעוד, כפי שיתוקף באמצעות בדיקת שימושיות.
WE5.2.2	אם ננתב את כל ה־APIs הכלולים ב־rest.php דרך שער מרכזי, נפתח את אמצעי הניהול הריכוזי של ה־API ונוכל להתחיל למדוד באופן עקבי תעבורת REST API ודפוסי שימוש בו, כדי לקבל תובנות שיוסיפו ידע להחלטות ולפעולות עתידיות.
WE5.2.3	אם ניישם לוחות מחוונים לניטור והתרעות ב־REST API של מדיה־ויקי, נוכל להדגים דרך יציבה, מועילה וניתנת לשחזור לשיפור האיתור המוקדם של בעיות מוצפות ובעיות התנהגות של המערכת שלנו, בייחוד בזמן שינויים קריטיים.
WE5.3.1	אם נרחיב ונייעל את חוויית המשתמש של הנחיות הייחוס תוך עדכון ההנחיות הקיימות לפי הצורך, נבסס סדרת ליבה של הנחיות משופרות מוכנות לבדיקה פנימית, שיהיו מלוטשות באמצעות איטרציות כדי שיהיו מוכנות לשימוש ציבורי רחב.
WE5.3.2	אם ניצור מצגת שתדגים את יתרונות הייחוס לוויקיפדיה לצדדים שלישיים העושים שימוש חוזר בתוכן של ויקיפדיה ולמשתמשי הקצה שלהם, נוכל לתמוך ב־WME4.1 וב־WME4.2 בכך שנאפשר לשותף נוסף אחד לפחות מאלה המשתמשים בתוכן שלנו להופיע בדוגמה או בדמו של ייחוס עד סוף הרבעון הראשון.
WE5.4.1	אם נבטיח שרוב בקשות הווב יקבלו 'עוגיות' קצה ייחודיות, יהיה קל יותר לזהות בוטים ובקשות מזויפות.
WE5.4.2	אם נבנה אמצעי ניתן להרחבה לזיהוי לקוחות ידועים, נוכל לאפשר חריגים להגבלות הכלליות על ההיקף לבוטים ממקור מאומת, ולחתור לאכיפה שיטתית של החוקים שלנו.
WE5.4.3	אם נארגן מחדש בקשות לסינון טקסט ב־CDN סביב גישה של רשימת אישור/רשימת דחייה, נוכל לאכוף מגבלות היקף כלליות נוקשות יותר לבוטים ולסינון יעיל של תעבורה.
WE5.4.4	אם נפתח אסטרטגיית מדידה אחידה, נאפשר הערכה של האסטרטגיה הרב־שנתית ל'שימוש אחראי בתשתית' והגדרה של מפת־דרכים לליווי פיתוח של מטריקה ויכולות דיווח.
WE6.1.1	אם נעביר מבנים (builds) של תמונות יומיות לשרת ההפצה ונוסיף עדכוני תמונות שיופעלו על־ידי פעולות בחירת הפצה, נחשוף אילוצים ונקבע קו בסיס לזמן הנדרש לביצוע הפצות יותר רציפות.
WE6.1.3	אם נוסיף חווֹת ויקי לסביבת בדיקה לפני מיזוג, יתאפשר לצוותי פיתוח הבונים נגד פרודקשן, הזקוקים למערכות ויקי מרובות כדי לבדוק את הטלאים (patches) שלהם בנפרד, לקבל לפני ההפקה ביטחון רב יותר ותוצאות שיש בהן פחות באגים שהסתננו למרות הבדיקות.
WE6.2.1	אם נסקור ונפרסם את רשימת בדיקות המוכנוּת לקראת פרודקשן, שמגדירה באופן ברור את הדרישות המקדימות משירות כדי שייחשב מוכן לפרודקשן, יחד עם משימות בשירות עצמי, נתאם ציפיות בין מהנדסי יציבות האתר (SREs) לבין צוותי הפיתוח, ובכך נשפר את כלל היעילות הביצועית וכושר הגדילה שלנו.
WE6.2.2	אם נכריז על יצירת ספריית Golang ו־nodejs ובכך נזקק משימות מפרכות רבות למפתחים, הם יגיבו באמצעות הצעת משוב וגילוי עניין.
WE6.2.3	אם ניצור רשימת מטלות/גיליון עבודה, מפתחים יוכלו להתכונן מראש באופן מלא לסקירת העיצוב של התמדת הנתונים (Data Persistence).
WE6.3.1	אם נשלב חידושים בלפחות 70 ויקיפדיות עם תעבורה נמוכה ברבעון הראשון, למעט ויקיפדיות עם תמיכה בווריאציות לשוניות, נגביר את ביטחוננו בכך שהשילוב הסופי בעשר הוויקיפדיות הגדולות ביותר ישפיע טוב יותר על צפיות בעמודים באמצעות Parsoid.
WE6.4.1	אם נוציא לדרך פיצול של טבלת הקישורים בוויקישיתוף באשכול המיוחד לו, נגביר את הסיכויים שהגידול של מסד הנתונים בוויקישיתוף יישאר בר־קיימה.	T398709
WE6.4.2	אם מהנדסי יציבות האתר (SRE) יסייעו לצוותי ההנדסה של מדיה־ויקי, באמצעות יצירת תיעוד, הכנת תשתית נחוצה (למשל, חבילות PHP, תמונות קונטיינרים) והצעת הדרכה ובדיקה, צוותי ההנדסה יוכלו להתחיל בביטחון את הפקת השדרוג PHP 8.3 עד תחילת הרבעון השני.	T360995
WE6.4.3	אם נדרוש גורם שני פיזי (מפתח אבטחת חומרה) להתחברויות SSH של משתמשות ומשתמשים בעלי הרשאות מערכת מתקדמות, נפחית את הסיכון שמחשב נייד מותקף יגרום לפרצת אבטחה חמורה.
WE6.4.4	אם נאחד את הדומיינים שלנו באמצעות טיפול בכל הצפיות בדפים באתרי מדיה־ויקי דרך דומיין קאנוני, נצמצם את הסיבוך של הפלטפורמה ואת סיכוני האופטימיזציה למנועי חיפוש (SEO) באמצעות ביטול ההפניה אל הסאב־דומיין למכשירים ניידים. השלמת המהלך נמדדת בירידה במספר ההפניות לביקורים ממכשירים ניידים בדומיינים קאנוניים מ־100% ל־0%.	T214998
WE6.4.5	אם צוות הנדסת מדיה־ויקי ינטר ויתקן באופן פעיל תקלות במדיה־ויקי הקשורות לשדרוג PHP 8.3, יוסר החסם מעל צוות הנדסת אמינות האתר להמשך השדרוג PHP 8.3 עד תחילת הרבעון השני.	T360995

השערות עסקיות בעניין שירותי איתות ונתונים (SDS) [ תוצאות מפתח לשירותי איתות ונתונים ] שיחה
שם מקוצר להשערה	טקסט רבעון ראשון	פרטים ודיון
SDS1.1.1	אם ננתח את היעילות של ההיוריסטיקות לזיהוי תעבורה אוטומטי במערכי הנתונים של צפייה בעמודים שיש לנו, נוכל לפתח מטריקות לאיכות נתונים כדי לתאר את הביצועים שלהן ולקבוע את הצורך להשקעה נוספת בהיוריסטיקות האלה.
SDS1.2.2	אם נעביר את תהליך XML Dumps מתשתית Dumps 1 הנוכחית לצינור נתונים המנצל את צינורות התוכן של מדיה־ויקי, נוכל להבטיח יעדי רמת שירות ולכבות את שירות היצוא ל־XML המבוסס על Dumps 1.
SDS1.2.3	אם נעבור היטב על יעדי רמת השירות של היסטוריית תוכן ופלטפורמת אירועים/שער אירועים של מדיה־ויקי ונבחן אותם, נוכל לתקף את הלקוחות, המטריקות ובעלי העניין התלויים, ולזהות שיפורים שעשויים להיות נחוצים ליעדי רמת השירות, ויעזרו לנו להבהיר כל פער בערבויות השירות השבועיות.
SDS2.1.1	אם נעבוד בצמידות לצוותים שמריצים ניסויים, נלמד איך להרחיב את 'השירות העצמי' במערכת בעתיד, ומהם האתגרים הקונספטואליים או הטכניים שהם עלולים להיתקל בהם.
SDS2.1.2	אם נוכל ליישם דיבאגינג טוב יותר לרישום אירועים, צוותי המוצר יידעו שהניסוי שלהם אוסף נתוני אירועים כמצופה, וכך יגבר ביטחונם של בעלי הניסוי.
SDS2.1.3	אם נשפר את התיעוד ואת הנראות לטובת רכיב מערכת ניסויי A/B (המכוּנה xLab) של פלטפורמת הניסויים, ולטובת חלקי מדיה־ויקי קשורים, נוכל לקבוע קווי התחלה לביצועי המערכת ולהגיב לכשלים הקשורים בניסויים.
SDS2.1.4	אם נשתף סיפורים על ניסויים ותוצאות בכל הארגון פעם בחודש (באמצעות ישיבות של מפעילי מוצר, של צוות העיצוב, ובאמצעות מצגות בין־צוותיות), ניצור הטמעה טבעית של פלטפורמות הניסויים.
SDS2.1.5	אם נספר למשתמשות ולמשתמשים שהכלי שלהם, אם הוא נוצר ב־xLab, כולל תכונות המשנות את קטגוריית הסיכון, נרתיע משתמשי כלים מאיסוף מוגזם של נתונים ונגביר את הבהירות סביב השאלה איזה שילוב תכונות מצריך סקירת פרטיות.

השערות עסקיות בעניין קהל עתידי (FA) [ תוצאות מפתח לקהל עתידי ] שיחה
שם מקוצר להשערה	טקסט רבעון ראשון	פרטים ודיון
FA1.1.1	אם (1) נציע דרכים לאספני מדיה בפלטפורמות אחרות (כגון Letterboxd, Goodreads ו־RateMyMusic) לשדרג את האוספים שלהם באמצעות ידע המצוי רק בוויקיפדיה, או (2) נציע לאספני המדיה האלה קטעי שיתוף מעניינים מרשתות חברתיות, נוכל להגביר את החשיפה לוויקיפדיה מחוץ לפלטפורמה שלה.
FA2.1.1	אם נרחיב את היכולת הפנימית שלנו ליצור תוכני וידיאו קצרים (באמצעות הגדלת הצוות שלנו, וכן זיהוי והערכה של הזדמנויות להגברת היעילות בתהליך ההפקה הנוכחי שלנו) ברבעון הראשון, נוכל לפעול לפי הלקחים שנלמדו מתכנים שנוצרו בשנת התקציב 2024-5 ולהשיג חשיפה גדולה יותר, לאורך שנים, של תוכן שהופק ברבעון השני של שנת התקציב 2025-6.

השערות עסקיות לתמיכת מוצר והנדסה (PES) [ תוצאות מפתח לתמיכת מוצר והנדסה ] שיחה
שם מקוצר להשערה	טקסט רבעון ראשון	פרטים ודיון
PES1.1.1	אם נתמוך ב־xLab, ב־Charts וב־ToneCheck בהגדרת מטריקות למדד רמת השירות (SLIs) ב־Prometheus, וביעדי רמת השירות (SLOs) ב־Pyrra, נלמד את המגבלות ואת מקרי הקצה של הכלים שלנו בתרחישים מורכבים מרובים, וגם נבהיר אילו איטרציות נחוצות לתבנית ה־SLO, שתעזור לנו לתמוך טוב יותר בששת יעדי השירות המתוכננים לתוצאות המפתח.
PES1.1.2	אם נערוך ניסוי פיילוט לשתי סדרות של לוחות מחוונים להתרעות יעדי רמת השירות, נלמד עד כמה יהיה קשה ליישם כלים מתאימים, כך שבעלי השירות יבינו בבירור את ההתחייבויות שלהם, וגם אם עלינו לעבור לכלי חדש המציע אפשרות צפייה רק ביעד שירות אחד ספציפי. לוח מחוונים אחד יהיה לדיווחים רבעוניים (שבהם נמצא הסכם רמת השירות עצמו לתקציבי שגיאות), ולוח מחוונים דינמי קטן יותר (מכוּנה 'רולינג' rolling) ישמש לפעולות ולהתרעות יומיומיות.
PES1.1.3	אם נמשיך לתמוך בעבודת כתיבת יעדי רמת שירות (SLO) של קבוצת 'ויקיפדיה אבסטרקט' למיזם ויקיפונקציות, נלמד איך להגדיר רשימה של יעדי שירות (יחד עם מטריקות מדדי רמת שירות שלהם) לתכונה מורכבת הנוספת כעת לתהליך עבודת משתמשים קריטי: הפקת תצוגה (rendering) של ערכי ויקי. כמו כן, נלמד איך להציג בצורה נכונה ובאופן חזותי את תקציבי השגיאות ולהתריע מפניהם באמצעות לוח מחוונים וצגים שיסופקו על-ידי מהנדסי יציבות האתר (SRE).
PES1.1.4	אם נתמוך בקבוצת פלטפורמת הנתונים באמצעות סקירה ואיטרציה של יעדי רמת השירות (SLO) לפרויקט 'היסטוריית תוכן של מדיה־ויקי', נלמד איך למנף יעדי רמת שירות כדי לתמוך בבעלות על שירות כששילוב של שירותי עיבוד של batch ו־stream מתוזמרים יחד לשם עדכון מערך הנתונים ולשמור אותו עקבי וזמין למשתמשים במורד הזרם.
PES1.2.1	אם ניצור שלושה שיפורים ממוקדים ל'רשימת המשאלות', נעודד תוספת 30% של המשתתפים הייחודיים של 'רשימת המשאלות'.
PES1.2.2	אם נתעדף משאלות שמגיעות אלינו ונמנה איש־מעקב (כגון מנהלת או מנהל מוצר) בתוך 72 שעות (כולל דחייה, הבהרה, סימון שירותים לא מתוחזקים וכו׳) באמצעות יצירת הפניות צולבות בין משאלות חדשות לבין טבלת אנשי־המעקב, והצמדת 'קטגוריית אנשי־המעקב' לאדם או לצוות המוצר הרלוונטיים ביותר, אנשי־המעקב (מנהלת או מנהל מוצר) יוכלו להעריך משאלות ולהגיב עליהן בתוך 10 ימים או פחות.
PES1.2.3	אם כניסוי פיילוט נפעל לזהות אותות מהקהילה הרחבה, נשלב יותר קולות של מתנדבות ושל מתנדבים בעבודת התעדוף המבוססת על מידע מהקהילה.
PES1.2.4	אם כניסוי פיילוט נערוך פעם ברבעון תהליך סקירת משאלות ואותות מהקהילה, עם שלושה צוותים ברבעון הראשון, נעודד את מנהלי המוצר לשלב אותות מהקהילה בתהליכי התכנון הרבעוניים והשנתיים שלהם.
PES1.3.1	אם עד סוף הרבעון הראשון נתאם שלוש ישיבות תכנון פונקציונלי עם מחלקת התקשורת וצוותי המוצר כדי ליישר קו בנושאי שליחת מסרים, צורכי יצירה ולוח־זמנים לקמפיין יוזמות ויקיפדיה 2025, נשלים את התדרוכים היצירתיים לכל שלושת ניסויי הקמפיין (25YiR, Easter Eggs, WikiRun).
PES1.3.2	אם נקים ועדת היגוי עם נציגים של הנדסת עיצוב ותכונות, נוכל להגדיר קו התחלה למטריקות על תרומות ל־Codex: מוּדעוּת, שימוש, איכות התרומה וכמות. תובנות מההערכה מול מטריקות קו ההתחלה האלה יעזרו לנו להגדיר מפת־דרכים לצמיחה ולגיוון כלל־ארגוניים של בסיס תורמי התוכן ל־Codex.

רבעון שני

הרבעון השני (Q2) של התוכנית השנתית של קרן ויקימדיה כולל את החודשים בין אוקטובר לדצמבר.

השערות לגבי חוויות ויקי (WE) [ תוצאות מפתח לחוויות ויקי ] שיחה
שם מקוצר להשערה	טקסט רבעון שני	פרטים ודיון
WE1.1.1	אם ננתח סדרת אינדיקטורים מובילים שנקבעו מראש־מראש (pre-predetermined) שבועיים לפחות לאחר תחילת בדיקת A/B של 'הדבקה' (paste), נוכל לזהות אילו היבטים - אם בכלל - של חוויית הקצה־אל־קצה יש להתאים או לחקור לפני שנוכל להעריך בביטחון את השפעת התכונה.
WE1.1.4	אם נפרוס 'בדיקת ייחוס' (Reference Check) בוויקי האנגלית באמצעות ניסוי מבוקר, נראה עלייה של 4% או יותר בעריכות הקונסטרוקטיביות שמתנדבות ומתנדבים חדשים או חדשים יחסית מפרסמים, ונדע אם יש די תמיכה בקרב המנטרים ובעלי ההרשאות בהרחבת השימוש בתכונה.
WE1.1.7	אם ננתח סדרת אינדיקטורים מובילים שנקבעו מראש־מראש (pre-predetermined) שבועיים לפחות לאחר תחילת בדיקת A/B של הנימה (tone), נוכל לזהות אילו היבטים - אם בכלל - של חוויית הקצה־אל־קצה יש להתאים או לחקור לפני שנוכל להעריך בביטחון את השפעת התכונה.
WE1.1.8	אם ניישם את מודל 'בדיקת הנימה' (Tone Check) על ערכים שפורסמו, נדע אם אנחנו יכולים לזהות את עשרת־אלפים או יותר סוגיות הנימה (כל אחת עם ניקוד סבירות של 0.8 או יותר) שנחוצות כדי לבנות מאגר איכותי (דיוק של 70% ומעלה) של הצעות כדי לעזור בהדרכת עורכות ועורכים בשיפור נימת הערכים.
WE1.1.10	אם נראיין כ־10 מתנדבות ומתנדבים מנוסים בוויקי האנגלית והצרפתית, שכותבים מסנן השחתות (AbuseFilters, וכלים, סקריפטים, תבניות והודעות עריכה אחרים) כדי להפוך את זרימת העבודה של המנטרים והמודרטורים לאוטומטית, נזהה 3 דפוסים או צרכים לפחות שיעזרו לעצב את פרופורציית הערך של בדיקות עריכה שנכתבו על־ידי הקהילה.
WE1.1.11	אם נפיץ סקר ל־500 מצטרפים חדשים מצליחים לפחות, ונשיג נתונים איכותיים שמייצגים את אוכלוסיית המצטרפים החדשים המצליחים הרחבה יותר, נוכל לזהות לפחות 4 תובנות מעשיות שנוכל להשתמש בהן כדי לתעדף את שיפור ההיבטים של חוויית ההיכרות.
WE1.1.12	אם נאפשר ל־3 מתנדבות ומתנדבים לפחות להעריך 30 דגימות עריכה לפחות כל אחד, בשביל כל אחת מ־10 השפות החדשות שאנחנו רוצים ליצור להן סולם בדיקת נימה, נדע באיזו תדירות המתנדבות והמתנדבים מסכימים עם ניבויי המודל ונוכל להחליט לאילו מערכות ויקי לפנות בעניין פריסת בדיקת הנימה.
WE1.1.13	בהנחה שאנחנו מרחיבים את 'הוספת קישור' ל־100% מהמתנדבות ומהמתנדבים החדשים בוויקיפדיה האנגלית, אז ההפעלה והשימור הקונסטרוקטיביים של המצטרפים החדשים ישתפרו, מה שיגדיל את העריכות הקונסטרוקטיביות מאת מתנדבים חדשים יחסית ב־4% או יותר.
WE1.2.3	אם נסיר את הדרישה שצריך הרשאה ל'ארגון אירועים' (Event Organizer) כדי להשתמש ב'רישום אירועים' (Event Registration) במערכות ויקי קטנות ובינוניות, אז נראה תוספת של X אירועים לפחות✲ שייווצרו במערכות ויקי קטנות ובינוניות עד סוף שנת הכספים. ✲תלוי בחישוב קו בסיס/מטרה.
WE1.2.4	אם נשפר בהתמדה את המוצר הבר־קיימה המינימלי 'תרומות שיתופיות' (Collaborative Contributions MVP) ונכניס בו 2 שיפורים, ייווצרו עוד שיתופי פעולה דרך 'רישום אירועים' (Event Registration).
WE1.2.5	אם נקבע אסטרטגיית הטמעה אחת ל'רישום אירועים' בוויקישיתוף בתחילת הרבעון השני, נוכל לבדוק אותה עם המארגנות והמארגנים של קמפיין גדול אחד לפחות, ונאפשר ל־5 מארגנות ומארגנים מקומיים להשתמש בתכונה.
WE1.3.3	אם נוציא לדרך ניסוי להגברת המודעות של עורכות ועורכים חדשים לדשבורד של בעלי ההרשאות (moderator dashboard), 10% מתורמי התוכן המבקרים בו, יבקרו בו שבועיים ברצף.
WE1.4.1	אם נכניס שיפורים המוגדרים ב־T396489, נפחית את השאילתות האיטיות ל'שינויים אחרונים' ב־30% לפחות במערכות ויקי גדולות, מה שיאפשר לקהילת הטכנולוגיה להפעיל תוויות רשימת מעקב בלי להעמיס יותר מדי על מסד הנתונים של 'שינויים אחרונים'.
WE1.4.3	אם נטמיע מדדים (instrumentation) ב'שינויים אחרונים' וב'רשימת מעקב', נוכל להגדיר קו בסיס לתדירות שבה אנשים מקליקים כדי להגיע לדפים.
WE1.5.1	אם נפעיל דשבורד כדי לחקור 7 מטריקות של תורמי תוכן ונקבע תקן לחישוב של מטריקה אחת לפחות באמצעות כלי שבנוי על נתונים (dbt), נוכל לאפשר לצוותי מוצר תורמי תוכן להגיע בעצמם לתובנות שמבוססות על מטריקות ולפתח תקן לאחסון לוגיקת חישוב מטריקות.
WE1.5.2	אם נקבע ברבעון השני אילו פעולות של בעלי הרשאות ייכללו בהגדרה של מיהו בעל הרשאות (מודרטור), יוכל צוות תובנות התנועה להרחיב את המטריקה של 'בעלי הרשאות פעילים החודש' (Monthly Active Moderators) ברבעונים השלישי והרביעי.
WE2.1.3	אם נלמד על חוויית העורכים בעת שהם יוצרים ערכים חדשים או פסקאות הרחבה חדשות (בכלל זה מוטיבציה, נקודות כאובות והתגובה שלהם לרעיונות חדשים לגבי תמיכה יותר טובה בהם), נגלה את צורכי המשתמשים ואת התנהגותם, שיתנו לנו תובנות ואסטרטגיות מעשיות, מידע שנוכל להעביר לצוותי מוצר, עיצוב והנדסה כדי לשפר את חוויית יצירת הערכים.
WE2.2.12	אם נקדם שילוב של ויקיפונקציות במערכות ויקי שיש בהן Parsoid מופעל, נוכל להמשיך לבדוק אם הביצועים של המערכת נשארים טובים ואם היא נשארת שימושית בתוכניות שילוב הולכות ומתרחבות.
WE2.2.13	אם נביא למודעוּת קהילת ויקימילון את הזמינות של פונקציית טבלת נטיות הפועל, נשיג משוב רב־ערך על השימוש בפונקציה ותובנות על אופיים של המשתמשות והמשתמשים שנוכל להפעיל בשילובים עתידיים של פונקציות.
WE2.2.14	אם נבחן את עבודת 'תיבת הנתונים' (Databox) של הקהילה לגבי שימוש בוויקינתונים ליצירת תיבות מידע, ונבדוק אם 'ויקיפונקציות' תוכל לעזור, נוכל לזהות ניסוי ראשון לוויקיפונקציות בתיבות מידע.
WE2.2.15	אם ניצור מודעוּת קהילתית ליכולת ליצור ולתרגם הודעות שגיאה בוויקיפונקציות, נראה עלייה במספר הודעות השגיאה המועילות.
WE2.2.16	אם נדגים לקהילה פונקציות סמנטיות זמינות, נראה עלייה של 50% בפונקציות הדקדוקיות.
WE2.2.17	אם נספק רכיב מותאם לצפייה בהצהרות ויקינתונים בוויקיפונקציות, יוכלו משתמשות ומשתמשים להבין טוב יותר נתונים שנשלפו מוויקינתונים, וירגישו פחות מבולבלים.
WE2.2.18	אם נוכל למנוע 10x שיאים בצריכת זיכרון, האורקסטרטור יוכל לטפל טוב יותר באובייקטים של ויקינתונים ולתמוך בשירותים של ויקיפונקציות כפלטפורמה ל'ויקיפדיה האבסטרקטית' (Abstract Wikipedia).
WE2.2.19	אם נאפשר למשתמשות ולמשתמשים לשתף קישורים ישירים לקריאות פונקציה ספציפיות - כולל הקלט שלהן - יוכלו תורמי תוכן לשחזר, לאמת ולדון בהתנהגות פונקציות יותר בקלות, מה שיזרז בתורו את הדיבאגינג, ישפר את זרימת העבודה של הבדיקות, ויתמוך בשיתוף פעולה לפתרון בעיות בכל רחבי קהילת ויקיפונקציות.
WE2.3.1	אם נשלים את ההחלטה ליצור מערכת ויקי חדשה, ונחליט עם הקהילה על שמה, נוכל להעביר את המסר על הקמת הוויקי החדשה בצורה רחבה יותר לבעלי העניין שלנו ולהתכונן ללוגיסטיקה של שינוי אפשרי של שם המוצר.
WE2.3.2	אם נגדיר מוצר בר־קיימה מינימלי (MVP) לאבטיפוס של מערכת ויקי אבסטרקטית שיכלול את הניסוי הפשוט ביותר האפשרי לבדיקת צד השרת (back-end) ויכולות ייצור השפה הטבעית (NLG) שלנו, ושיאפשר לנו לעצב באופן חוזר, נוכל לתכנן ולהוציא לדרך אבטיפוס חי ברבעון השלישי.
WE2.3.3	אם נתחיל לדבר עם הקהילה ונבחן עיצובים פוטנציאליים לחוויית המשתמש של מערכת ויקי אבסטרקטית, נוכל לדאוג להתקדמות העבודה ברבעון השלישי.
WE2.4.1	אם נאסוף תרחישי שימוש של ויקינתונים ושל שירות השאילתות של ויקינתונים (WDQS) מוויקימדיה גרמניה ומצוותי קרן ויקימדיה, נוכל להגדיר דרישות מוצר לשיפורים בתשתית.
WE2.4.2	אם נפיק תצוגת דיווח מצטבר של מדדי ביצוע מובילים (KPIs) עם יעדי רמת שירות (SLOs) קיימים לוויקינתונים ולשירות השאילתות של ויקינתונים (WDQS), נוכל לעקוב אחר קריטריונים להצלחה ולתקשר אותם בכל הקשור לשיפורים בתשתית הטכנית התומכת בתרחיש השימוש הקריטי של ויקינתונים.
WE2.4.3	אם נעריך ונבחן חנויות חלופיות ל־Blazegraph תוך שימוש בקריטריוני הפקה ריאליסטיים במהלך הרבעון, נוכל לקבל החלטה על העברה (migration) לפי נתונים, ולהכין מפת דרכים קונקרטית עם לוח זמנים ודרישות משאבים.
WE3.1.1	אם נערוך בדיקת A/B לגרסה משופרת של תכונת הגלישה בלשוניות, נראה עלייה של 5% בשימוש במשך ימים רבים בקרב משתמשי הלשוניות.
WE3.1.3	אם נספק למשתמשות ולמשתמשים דרך חדשה לגלישה בתוכן תמונות רלוונטי בתוך דפי הערך, ונבדוק אותה עם קבוצת משנה של משתמשות ומשתמשים לא־רשומים באמצעות בדיקת A/B בקבוצה של מערכות ויקי, נראה שיעור של 3% לפחות בלחיצות על קישורים מוצגים בקרב משתמשות ומשתמשים שייחשפו לתכונה הזאת.
WE3.1.4	אם נראה לקוראות ולקוראים כמה רעיונות לחציית רשת הידע במערכות הוויקי, נקבל רשימת רעיונות מתועדפים להמשך פיתוח.
WE3.1.5	אם נספק לקוראות ולקוראים דרך הווב אפשרות לצפות בגרסת תרגום מכונה של תוכן ויקיפדיה שאינו זמין בשפתם, נדע אם פעילות הקריאה מתגברת, לפי מדידה של 3% תוספת באינטראקציה עם הדף, ואם הקוראים נמשכים לוויקי בשפה שלהם עם פוטנציאל עלייה בפעילות העריכה בוויקי המקומית. זה יסופק כבדיקת A/B מבוקרת שתימשך לא יותר מ־6 חודשים ב־13 ויקיפדיות עם תוכן קיים. שירותי תרגום מכונה פתוחים כבר זמינים לעורכות ולעורכים בוויקיפדיה.
WE3.1.6	אם נפיק אבטיפוס לחיפוש סמנטי ולשאלות ותשובות בערך עצמו, שיוצג כממשק דמו שיכלול גישות חיפוש חדשות ומנוגדות לגישה הנוכחית, צוותי הקריאה יוכלו להעריך באופן איכותני את התועלת שבכל גישה במסעות שונים של משתמשים, ולהציף פערים או הזדמנויות לשיפור בהמשך.
WE3.1.7	אם נסקור מחקר קיים לגבי האופן שבו קוראות וקוראים מפעילים את כלי החיפוש והגלישה בוויקיפדיה, ואיך הם משתמשים בחיפוש חיצוני כדי למצוא ידע בוויקיפדיה, נוכל לספק לצוותי הקריאה לפחות 3 המלצות וממצאים מעשיים שיעזרו להם להעריך את היקף המוצר המינימלי (MVP) לחיפוש ולגילוי כדי לטפל בפערים בציפיות הקוראים ובצורכיהם.
WE3.1.8	אם נבדוק 2 אבטיפוסים של חיפוש סמנטי (חיפוש בשפה טבעית, שאלות ותשובות) עם משתתפות ומשתתפים חיצוניים, נוכל ללמוד אם משתמשים מוצאים ערך בכלי חיפוש משופרים, ולספק לצוותי הקריאה המלצות לגבי אופן ההתקדמות לעבר מוצר בר־קיימה מינימלי לחיפוש ולגילוי.
WE3.1.9	אם נדגים רעיונות עיצוב בנאמנות גבוהה לגילוי תוכן באמצעות חיפוש סמנטי ל־10–20 קוראי ויקיפדיה מזדמנים במחקר איכותני, נראה יחס חיובי לתכונה ונשיג את האמון הדרוש להתקדמות לעבר מוצר חיפוש וגילוי המתבסס על מובאות קצרות שנכתבו בידי אדם לחיפוש שאילתות.
WE3.1.10	אם נראה ל־10 קוראות וקוראים מזדמנים אבטיפוס חי של חוויית העיון בתמונות החדשה במחקר משתמשים ללא הנחיה, נחשוף לפחות שיפור UX אחד לשיפור הדרגתי עתידי של התכונה.
WE3.1.11	אם נרופף את התאמת מילות המפתח בחיפוש, נתמוך טוב יותר בשאילתות בשפה טבעית, ונאפשר לצוות המוצר להעריך את היכולת הזאת, לכלול אותה בדרך העיצוב שלהם, ולתעדף ולבצע עבודה במרחב החיפוש הסמנטי.
WE3.1.14	If we launch an A/B test of a version of the mobile site which introduces navigation that opens all sections by default, we will see early indicators that signal towards an increase in session length (will report on full A/B test results in Q3)	T409163
WE3.2.5	אם נוסיף תכונת 'סקירת שנה' ל'אנדרואיד', שתדגיש את השפעת המשתמשת או המשתמש ותכלול הודעות מוטמעות לגבי תרומות כספים, נעודד התנהגות תרומות חדשה ונראה עלייה של 5% בתפריט היישומון לעומת 2024.
WE3.2.6	אם ניצור את שקופיות תורמי הכספים ב'סקירת שנה' של iOS, באופן יותר מוטמע ומותאם אישית, נראה עלייה של 5% בתרומות הכספים לעומת 2024.
WE3.3.3	אם נוסיף אוואטר נפתח (unlockable avatar) אחד לפחות ביישומון 'אנדרואיד' לבעלי חשבון שישיגו אותו באמצעות פעולות קריאה משמעותיות, כמו שמירת מספר מסוים של ערכים, נגדיל מעורבות חוזרת של משתמשות ומשתמשים רשומים באמצעות פעולה מקושרת ב־10% לאורך ימים רבים.
WE3.3.4	אם ניתן לקוראות ולקוראים רשומים את היכולת לשמור ערכים לרשימת קריאה פרטית, אנחנו צופים עלייה ברמת המעורבות באתר, שתימדד כעלייה של 5% בתעבורה הפנימית בין דפי האתר אצל קוראות וקוראים המשתמשים בתכונה, ועלייה מובהקת סטטיסטית אצל כל המשתמשות והמשתמשים האחרים.
WE3.3.6	אם ננגיש את נתוני הסקת נושא הערך דרך שירות שעונה על דרישות הרחבה וזמינות מוסכמות, וגם כל השלמת נתונים הכרחית, נבסס את היסוד הטכני ההכרחי לתמיכה בחוויית קריאה מותאמת אישית, הצפויה בקרוב, שתלויה בנתונים האלה.
WE3.3.7	אם נמנף את יכולות העיבוד של פלטפורמת הנתונים לאגור מטריקות עריכה ונתוני השפעה מותאמות אישית, ונשרת את הנתונים הנאגרים באמצעות שירותים מתאימים עם יעדי רמת שירות מוגדרים, נוכל להגביר תהליכי שיפור עתידיים של 'סקירת שנה' (Year in Review) WE3.3.1 ושל 'לשונית פעילות' (Activity Tab) WE3.3.2.
WE3.3.9	אם נכניס לשימוש את 'סקירת שנה' ב'אנדרואיד' ובדיקת A/B, ונציע למשתמשות ולמשתמשים מעורבים פרס לשמירת רשימת קריאה מותאמת אישית, נראה עלייה של 1% בשיעור הכולל של שימור היישומון בקרב קוראות וקוראים שקיבלו את הצעת הפרס לעומת אלה שלא קיבלו.
WE3.3.10	אם נערוך ניסוי A/B שידרוש מחשבון לצפות בתובנות הקריאה המותאמות אישית של 'סקירת שנה', נראה עלייה של 1% בשיעור השימור הכולל למשתמשות ולמשתמשים שהתבקשו לפתוח חשבון, בהשוואה לאלה שלא התבקשו.
WE3.3.11	אם נערוך בדיקת A/B לגרסה משופרת של לשונית ה'פעילות' ("Activity") ב־iOS, שמדגישה קריאה, עריכה והתנהגויות השתתפות אחרות, נראה עלייה של 5% בכניסות הרב־יומיות של קוראות וקוראים רשומים ללשונית, בהשוואה לגרסת האבטיפוס.
WE3.4.1	אם נעבוד לקראת פריסה היברידית של נקודת נוכחות (PoP/CDN), יתאפשר לנו להביא גם נקודות נוכחות מלאות וגם נקודות נוכחות קטנות (ממשיות וענן) כנדרש, ונניח את היסוד לאבטיפוס של פריסת נקודת נוכחות קטנה בעתיד.
WE3.5.1	אם צוותי מוצר וטכנולוגיה וגיוס תרומות ישתפו פעולה בהערכה ובתיעוד של גישות טכנולוגיות לזיהוי תורמי כספים בתוך הפלטפורמות שלנו, נוכל להמליץ על פתרון קצר־טווח וארוך־טווח שמאזן פרטיות, היתכנות והשפעה. ההבנה המשותפת הזאת תעזור לתאם קבלת החלטות, תאפשר זיהוי תורמי כספים מתמידים בכל הפלטפורמות, כמו גם ניסויים ממוקדים יותר בתכונות עתידיות הקשורות בגיוס תרומות.
WE3.6.3	אם נערב קהילות בשיחות על הצרכים המתפתחים של קוראות וקוראים, ועל טבעו המשתנה של הידע באינטרנט, נוכל להתמקד במשותף בצורת שירות הקוראות והקוראים ולעבוד יחד על השאלה אם ואיך לבדוק את הרעיונות המגוונים שלנו (כולל אלה העוסקים במולטימדיה, חיפוש וגילוי ולמידת מכונה).
WE3.6.4	אם נחקור את המניעים, ההתנהגויות והצרכים הייחודיים הקובעים מתי, מדוע ואיך קוראות וקוראים משתמשים בוויקיפדיה ובפלטפורמות ידע אחרות, נוכל להציע אזורי עדיפות ויוזמות ספציפיות לאסטרטגיית הצרכנים.
WE3.6.5	אם צוותי מוצר וטכנולוגיה וגיוס תרומות ישתפו פעולה ליצירת אסטרטגיה משותפת לגיוון ההזדמנויות לתרום כספים בפלטפורמה עצמה, ולשרת ולזהות קוראות וקוראים שתורמים כסף, נקבע מטרות ברורות ומתואמות, ומטריקות הקשורות לאסטרטגיות הצרכנים וגיוס התרומות שלנו.
WE3.6.6	אם נפתח אסטרטגיית מדידה מאוחדת, נאפשר הערכה של האסטרטגיה הרב־שנתית של הצרכנים ונגדיר מפת דרכים להדרכת פיתוח יכולות מדידה ודיווח.
WE4.1.1	אם נכין אבטיפוס של זרימה שמתקיימת באופן מינימלי ולא למצבי חירום ונשאיר לולאת משוב איטֶרָטיבית פתוחה בשעה שאנחנו מפתחים אותה עם משתמשות ומשתמשים בעלי הרשאות רחבות, אז תתמוך הקבוצה הזאת בפריסה מורחבת של הזרימה הזאת.
WE4.1.3	אם נעדכן 7 ויקיפדיות (בצרפתית, בגרמנית, בספרדית, בהונגרית, באיטלקית, בפולנית ובפורטוגלית) עד סוף אוקטובר, נשלים את שלב 1 של הפצת דף התנאים המשפטיים החדש בתגובה לדרישות 'חוק השירותים הדיגיטליים'.
WE4.1.4	אם נפרוס את המוצר המינימלי של מערכת הדיווח על תקריות ב־15 מערכות ויקי לפחות, תוך התמקדות בקהילות גדולות ומורכבות, נראה את הקהילה משתמשת בו כמצופה ונדגים מודל עבודה לדיווח על תקריות לא־דחופות.
WE4.1.5	אם נעצב תרשים זרימה לדיווח על תקריות השחתה של מערכות ויקי, בלי תהליכים מבוססים לטיפול בהשחתה, הדבר יעודד הטמעה של מערכת הדיווח על תקריות במערכות ויקי כאלה, ויאפשר למשתמשות ולמשתמשים במערכות הוויקי האלה לקבל מסלולי תמיכה ברורים ובני־קיימה.
WE4.2.3	אם ננתח נתונים מניסוי יצירת חשבונות ב־hCaptcha נבין את משפך יצירת החשבונות ואת האפקטיביות של התצרף והניקוד של hCaptcha. כמו כן, נקבל את הנתונים הנחוצים כדי להוסיף ידע להפעלות העתידיות של hCaptcha ביצירת חשבונות.
WE4.2.5	אם נערוך מחקר, נתייעץ עם קהילות ונחקור פתרונות טכניים, נוכל להגדיר סדרה מובנית של סיבות לחסימה שתוכל להיות בשימוש בכל מערכות הוויקי של קרן ויקימדיה.
WE4.2.6	אם נפתח את היכולת לפרוס אשכולות מבוססים על חיפוש חופשי (OpenSearch) בפלטפורמת הנתונים, ניתן כלים בידי צוותי הנדסת תכונות המוצר לפיתוח מערכות המשלבות את היכולת הזאת עם אוטונומיה רחבה, עמידות ועצמאות ממערכות מבוססות־חיפוש אחרות. הלקוח (tenant) הראשון והעיקרי של המערכת הזאת יהיה שירות IPoid.
WE4.2.7	אם נפעיל שילוב של hCaptcha Enterprise בכמה ויקיפדיות ייצור כניסוי פיילוט, נוכל לאסוף מידע על היעילות והערך של hCaptcha Enterprise נגד השחתות, על זיהוי בוטים, על שימושיות ועל נגישות.
WE4.2.8	אם נדאג שהפרוקסי של hCaptcha יהיה מוכן להפקה על־ידי שיפור הזמינות והנראות שלו, נציע שירות יציב ואמין יותר לוויקיפדיות ההפקה ברבעון הראשון.
WE4.2.9	אם נשלב את ערכת פיתוח התוכנה (SDK) של hCaptcha בתוך יישומוני ניידים מקומיים, נעריך את חוויית המשתמש של יישומון מקומי ונשקול לאפשר אתגרי hCaptcha כחלק מה־API ליצירת חשבון, תהיה לנו הבנה מספקת כדי לספק נתונים לחשיפה נוספת של hCaptcha ל־API של יצירת חשבון.
WE4.2.11	אם נאפשר hCaptcha לאיתור בוטים בתרחישי עריכה בסיכון גבוה, נראה ש־hCaptcha יכול להפחית השחתות אוטומטיות.
WE4.2.16	אם ניוועץ בצוותי קרן ויקימדיה רלוונטיים, נוכל לפתח תוכנית מוסכמת לניהול גישת משתמש מפורטת יותר לנתונים לא־ציבוריים ולתמוך בפריסת כללים לתוכנת הגנה לא־ציבורית.
WE4.2.17	אם ננתח דוגמאות מהעולם האמיתי ונראיין 'בודקים' (CheckUsers) כדי לזהות לפחות 2 אותות להתנהגות עם פוטנציאל השחתה מאבטיפוס של היסטוריית עורך, צוות בטיחות המוצר ושלמותו יוכל לשלב את האותות האלה מאוחר יותר בתכונת 'הצעות לחקירה' ברמה גבוהה יותר של ביטחון שהאותות בעלי ערך.
WE4.3.2	אם נפרוס טביעות אצבע JA4H, שמסכמות את התנהגות HTTP של הלקוח, נוכל לזהות ולסווג תעבורת בוטים בצורה טובה יותר.
WE4.4.1	אם נוכל להכניס שיפורים מבוססי משוב מניסויי פיילוט, ולפרוס חשבונות זמניים בכל המיזמים, נוכל להגן מפני חשיפת מידע מזהה אישי (כתובות איי־פי) של משתמשים לא־רשומים בכל המיזמים שלנו, כך שהוא יהיה זמין רק לפחות מ־0.1% מכל המשתמשים הרשומים שלנו.
WE4.4.2	אם ניצור קשר עם בעלי עניין רלוונטיים של התנועה (כולל קהילות ויקי ובעלי תפקידים גלובליים) בצורה ברורה ובזמן, נוכל לפרוס מוצרים בכל מערכות הוויקי הנותרות, להפחית עומס עבודה שמתגלה ברגע האחרון ולהימנע מביטול פריסת מוצר.
WE4.4.5	אם נפחית את החיכוך למנטרים כדי לזהות גורמים בעלי כוונות רעות שמשתמשים בחשבונות זמניים לצורך השחתה, נוכל למנוע עלייה בוונדליזם באמצעות מדידת היעדר עלייה בשיעור השחזורים בכל מערכות הוויקי עם חשבונות זמניים.
WE4.4.6	אם נוריד את המסך על ההרחבה LiquidThreads, נוכל להסיר את החסימה מעל חשבונות זמניים הנפרסים בכל המיזמים שמשתמשים כעת בהרבה הזאת.
WE4.6.1	אם נהפוך את תהליך סנכרון החשבונות לאוטומטי בתוך Zendesk לאיפוס סיסמאות, נקל על הנטל המוטל על צוות האמון והתמיכה ונאפשר להם לטפל ביותר בקשות לאיפוס אימות דו־שלבי.
WE4.6.3	אם נאפשר לכל המשתמשות והמשתמשים בעלי כתובת דוא״ל מאומתת להפעיל אימות דו־שלבי בחשבונות שלהם, אבל לא נפרסם באופן יזום את השינוי הזה למשתמשות ולמשתמשים, הנטל על צוות התמיכה בשחזור יישאר ברמה משמעותית.
WE4.6.4	אם נמשיך לבנות מחדש את חוויית המשתמש במערכת האימות הדו־שלבי שלנו, ונוסיף תמיכה במפתחות גישה (passkeys), יותר משתמשות ומשתמשים ירשמו גורמי אימות מרובים ויהיו מוגנים יותר מפני איבוד הגישה לחשבון.
WE4.6.5	אם נעצב ונבנה מסגרת כללית לקביעת דרישות מסוימות שחברי קבוצה מקומית או גלובלית צריכים לעמוד בהן, נשתמש במסגרת הזאת כדי לאכוף על חברי קבוצת בודקי האיי־פי של חשבונות זמניים את דרישות המדיניות.
WE4.6.6	אם נחקור איך משתמשות ומשתמשים עם הרשאות מורחבות (UWER) נסמכים על 'סקריפט משתמש', נוכל להציע תוכנית, שקהילת בעלי ההרשאות המורחבות תוכל לתמוך בה, להתערבות טכנית משמעותית אחת או יותר שתבטיח היטב את מערכת 'סקריפט המשתמש' (User Scripts system).
WE4.6.7	אם נעריך את השינויים הטכניים ואת השינויים בחוויית המשתמש הנחוצים ליישומונים המיועדים למכשירים ניידים, כדי להתאים בין חוויית הכניסה לחשבון במכשיר נייד לאותה חוויה בפלטפורמה הוובית, וזאת באמצעות בדיקת מנגנונים חלופיים כמו OAuth, נוכל לקבוע את היתכנות האינטגרציה, כדי לספק חוויה בטוחה ועקבית יותר למשתמשות ולמשתמשים.
WE4.6.8	אם נעקוב אחר ההשפעה של טופסי Zendesk ומדיה־ויקי שבנינו ברבעון הראשון, נוכל להציע התערבויות טכניות לרבעונים העתידיים שישפרו את האוטומציה של שאר תהליכי שחזור החשבון.
WE5.1.2b	אם נשלב שיטות מרובות לזיהוי ולאימות של מפַתחות ומפתחים בשער ה־API, נוכל לקבוע מגבלה סבירה על ההיקף של כל בקשה על־ידי זיהוי נכון של בקשות המגיעות מקוהורטות שונות של משתמשים.
WE5.1.3b	אם נריץ על יבש מערכת הגבלת היקף על 3 נתיבים לפחות של שער ה־REST, הדבר יאפשר לנו לוודא היתכנות של הגבלת היקף ביחס לצריכת משאבים ולהגדיר סדרה התחלתית של הגבלות שנוכל לאכוף תוך השפעה מינימלית על המשתמש.
WE5.1.4b	אם נתקף את מנגנוני ה־API המוצעים לפילוח משתמשים באמצעות מערכי נתונים רחבים יותר וסקירות ידניות של הקבוצות המזוהות, נוכל להשלים את קוהורטות המשתמשים, ללטש את המתודולוגיות המשמשות לחישוב ולהבין טוב יותר את היעילות שלהם.
WE5.1.5	אם נשתף פעולה עם צוות פלטפורמת מדיה־ויקי בעניין זיהוי תעבורה והגבלת היקף, נוכל להוציא לדרך הגבלת היקף לבדיקה בהרצה יבשה בהפקה, באמצעות תמיכה בצוות הפלטפורמה ביצירת היכולת הזאת והשקתה.
WE5.2.1b	אם ניצור קשר עם משתמשות ומשתמשים שצפויים להשתמש ב־REST API Explorer החדש, הדבר יעזור לנו בזיהוי תובנות מפתח של שימושיות שמסמנות אם העיצוב החדש קל לשימוש ומתאים למודל המנטלי של משתמשות ומשתמשים.
WE5.2.2b	אם ננתב את Action API דרך שער ה־API המרכזי, נוכל להתחיל למדוד בצורה עקבית תעבורה ודפוסי שימוש כדי לקבל תובנות שישמשו בסיס להחלטות ולפעולות עתידיות.
WE5.2.4	אם ניישם דפוסי תיעוד סטנדרטיים לשני APIs, נוכל ללטש את הנחיות התוכן, להבין מה בעלי API צריכים כדי להטמיע את ההנחיות, ולכמת את המאמץ הנדרש ליישום ההנחיות בכל שאר מסמכי ה־API של ויקימדיה.
WE5.2.5	אם נערוך ניסוי להגדרה וליישום של כללי איתור השגיאות (linting rules) של OpenAPI על ה־REST APIs של מדיה־ויקי, נדגים אמצעי אכיפה תוכניתית של מדריכי סגנון ל־API לשם שיפור האיכות והעקביות של APIs המתפרסמים בכל ויקימדיה והקהילות שלנו.
WE5.3.1	אם נרחיב ונזרים כללי ייחוס בחוויית המשתמש בעוד אנחנו מעדכנים כל כלל קיים, נבסס מערך ליבה של כללים משופרים מוכנים לבדיקה פנימית ולליטוש הדרגתי, כדי שיהיו מוכנים לשימוש ציבורי רחב.
WE5.3.1b	אם נפרסם ונשפר בהדרגה את טיוטת הקווים המנחים והדמו של חוויית המשתמש, נבסס מסגרת ליבה מוכנה לבדיקה פנימית ומלוטשת בהדרגה, כדי שתהיה מוכנה לשימוש ציבורי רחב.
WE5.3.2	אם ניצור מצגת שתדגים את יתרונות הייחוס לוויקיפדיה לצדדים שלישיים העושים שימוש חוזר בתוכן של ויקיפדיה ולמשתמשי הקצה שלהם, נוכל לתמוך ב־WME4.1 וב־WME4.2 בכך שנאפשר לשותף נוסף אחד לפחות מאלה המשתמשים בתוכן שלנו להופיע בדוגמה או בדמו של ייחוס עד סוף הרבעון הראשון.
WE5.4.2b	אם נבנה דרך לזיהוי לקוחות ידועים, שניתנת להרחבה, נוכל להרשות חריגות מהגבלות ההיקף הכלליות לבוטים ממקור שנבדק, ולהתקדם לעבר אכיפה שיטתית של הכללים שלנו.
WE5.4.5	אם נתחיל לאכוף הגבלות היקף שנועדו לקבוצות שונות של לקוחות אינדיבידואליים, נפחית את נטל הזחלנים על התשתית שלנו.
WE5.4.6	אם עד סוף הרבעון השני נסווג את N ה'עכבישים' העיקריים כבוטים ידועים, נוכל להגביל את כמות המשאבים שהם משתמשים בהם.
WE5.4.7	אם נסכים על מערכים סטנדרטיים של גדלים מותרים של תמונות ממוזערות (thumbnails) בתשתית המדיה שלנו, ואם ניצור מראש את היקרות ביותר תוך הגבלת יצירת תמונות בגדלים אחרים, נפחית את הנטל על התשתית שמשרתת את המדיה.
WE6.1.2	אם נוסיף חווֹת ויקי לסביבת בדיקה לפני שילוב, יתאפשר לצוותי פיתוח הבונים מול הפקה, הזקוקים למערכות ויקי מרובות כדי לבדוק את הטלאים (patches) שלהם בנפרד, לקבל לפני ההפקה ביטחון רב יותר ותוצאות שיש בהן פחות באגים שהסתננו למרות הבדיקות.
WE6.2.1	אם נבדוק ונפרסם את הרשימה שלנו לבדיקת מוכנות להפקה, שמגדירה בבירור את התנאים המוקדמים לקביעה ששירות כלשהו מוכן להפקה, יחד עם משימות שיכולות לשרת את עצמן, נתאם ציפיות בין צוותי הנדסת אמינות האתר לבין צוותי הפיתוח ונשפר את כושר הגדילה שלנו ואת היעילות הביצועית הכוללת.
WE6.2.2	אם נכריז על יצירת ספריית Golang ו־nodejs ובכך נזקק משימות מפרכות רבות למפתחים, הם יגיבו באמצעות הצעת משוב וגילוי עניין.
WE6.2.4	אם ניישם ונתמוך באופן פעיל בבדיקת העיצוב של 'התמדת נתונים' (Data Persistence), אולי נזהה מסלולים סלולים להפקה.
WE6.3.2	אם נפתח מטריקות חדשות, נשפר את תשתית מטמון Parsoid ונפיץ אותן בשתי ויקיפדיות מבין עשר הגדולות ביותר, נפתח קריטריוני ביצועים למסגרת האמינות שתעזור לתקף את המוכנות שלנו להפצה למערכות ויקי גדולות אחרות ונדגים את יכולתנו לטפל בנפחי תעבורה גדולים בקנה מידה גדול.
WE6.3.3	אם ניישם שיפורים קריטיים בתמיכה בווריאנטים של שפות, ונפיץ בהצלחה את Parsoid ל־3 מערכות ויקי לפחות של וריאנטים של שפות ברבעון השני, נאתר ונפתור את אתגרי המפתח הטכניים הנחוצים כדי להפיץ אותו בביטחון לכל מערכות הוויקי האחרות המטפלות בווריאנטים של שפות.
WE6.4.6	אם צוות הנדסת אמינות האתר יציע עזרה לצוותי הנדסת מדיה־ויקי באמצעות ניהול קיבולת ותעבורה, הכנת שינויי תצורה ובדיקתם ושיתוף פעולה לחקירת בעיות וטיפול בהן, נשלים יחד את הפקת השדרוג PHP 8.3 ברבעון השני, ונתעד סדרה של המלצות למזעור עניינים בעלי מסלול קריטי התלויים בצוות הנדסת אמינות האתר לשדרוגים עתידיים.	T360995
WE6.4.7	אם נעביר לפחות 90% מכל המשתמשות והמשתמשים עם גישת שורש גלובלית (global root access) לשימוש במפתח SSH מגובה בחומרה לשם גישה לשרתי הפקה של ויקימדיה, נפחית את הסיכון שמחשב נייד פרוץ יגרום לתקלת אבטחה חמורה.
WE6.4.8	אם צוות ההנדסה של מדיה־ויקי ינטר ויתקן באופן פעיל בעיות במדיה־ויקי הקשורות לשדרוג PHP, הדבר יאפשר לצוות הנדסת אמינות האתר להשלים את הפקת השדרוג PHP 8.3 עד נובמבר 2025.	T360995

השערות עסקיות בעניין שירותי איתות ונתונים (SDS) [ תוצאות מפתח לשירותי איתות ונתונים ] שיחה
שם מקוצר להשערה	טקסט רבעון שני	פרטים ודיון
SDS1.2.1	אם נעביר את תהליך XML Dumps מתשתית Dumps 1 הנוכחית אל צינור נתונים שמנצל את 'צינורות התוכן של מדיה־ויקי', נוכל להבטיח יעדי רמת שירות ולהפסיק את היצוא ל־XML המבוסס על Dumps 1.
SDS1.2.2	אם נסקור ונבדוק את יעדי רמת השירות של 'היסטוריית התוכן' ושל 'פלטפורמת האירועים' או 'שער האירועים' של מדיה־ויקי, נוכל לתקף את הלקוחות, המטריקות ובעלי העניין הנלווים, ולזהות שיפורים שעשויים להיות נחוצים לשירותי רמת התוכן, שיעזרו לנו לגלות כל פער בערבויות הביצוע השבועיות שלנו.
SDS1.3.1	אם נוסיף אותות בצד הלקוח ונבדוק אותם בהשוואה ללוגים של בקשות־ווב בצד השרת, נמצא דפוסי בוט נוספים שאפשר לאפיין אותם.
SDS1.3.2	אם נניח את תפוצת ה'בוט מול אדם' הנוכחית כקו בסיס וניצור התרעות אוטומטיות לגבי תזוזות בתפוצה, נקצר את זמן האיתור של דפוס התעבורה האוטומטית הבלתי־צפוי הבא משבועות לדקות.
SDS1.3.3	אם נהפוך את מנגנון מילוי החוסרים (backfill) לבקשות ווב (webrequest) לאוטומטי, ונשתמש בו ללוגים של מאי, נצמצם את זמן הריפוי (remediation) של תקריות בעתיד מחודשים לימים, ונפתור את תקרית 'עלייה בצפיות דפים במאי'.
SDS1.3.4	אם ניצור תהליך בקרה פנימי, שגרתי ומוכן לפעולה לפלטי סיווג של בוטים, נבנה אמון בפתרונות שלנו ונצפה לשינויים בדפוסי תעבורה שאינם מאותרים באופן אוטומטי.
SDS1.3.5	אם ננתח את אות צד הלקוח הבסיסי ונכניס אותו לתוך ההיוריסטיקות שלנו, נאתר דפוסי בוט נוספים ב'פלטפורמת הנתונים'.
SDS1.3.6	אם נייבא, ננתח ונכניס להיוריסטיקות שלנו את המוניטין של האיי־פי של Spur.us, נאתר דפוסי בוט נוספים ב'פלטפורמת הנתונים'.
SDS1.3.7	אם נייבא, ננתח ונכניס לתוך ההיוריסטיקות שלנו אות אחד מהקצה, נאתר דפוסי בוט נוספים ב'פלטפורמת הנתונים'.
SDS1.4.1	אם נאשר מחדש ניתוח קיים של מגמות באקוסיסטם של ויקימדיה - צפיות בדפים, תורמי תוכן ומטריקות של קריאה, תעבורה וכולי - נוכל לתמוך בביטחון בנקודות שיחה עיקריות לתובנות התנועה החשובות ביותר שלנו.
SDS1.4.2	אם נאשר מחדש ניתוח קיים של מגמות באקוסיסטם של ויקימדיה - צפיות בדפים, תורמי תוכן ומטריקות של קריאה, תעבורה וכולי - נוכל לתמוך בביטחון בנקודות שיחה עיקריות לתובנות התנועה החשובות ביותר שלנו.
SDS2.1.1	אם נעבוד בצמידות לצוותים שמריצים ניסויים, נלמד איך להרחיב את 'השירות העצמי' במערכת בעתיד, ומהם האתגרים הקונספטואליים או הטכניים שהם עלולים להיתקל בהם.
SDS2.1.2	אם נוכל ליישם דיבאגינג טוב יותר לרישום אירועים, צוותי מוצר יוכלו לדעת שהניסוי שלהם אוסף נתונים על אירועים כמצופה, ובכך נגביר את אמון בעלי הניסוי.
SDS2.1.3	אם נשפר את רישום האירועים ואפשרות התצפית לרכיב מערכת (xLab) לבדיקת A/B של פלטפורמת הניסוי ולחלקי מדיה־ויקי הקשורים אליו, נוכל לקבוע קווי בסיס לביצועי המערכת ולהגיב לכשלים הקשורים לניסוי.
SDS2.1.4	אם נשתף דיווחים על ניסויים ותוצאות שלהם בכל רחבי הארגון פעם בחודש (באמצעות ישיבות של מפעילי מוצר, של צוות העיצוב, ומצגות בין־צוותיות) ניצור הטמעה אורגנית של פלטפורמת הניסוי.
SDS2.1.5	אם נספר למשתמשות ולמשתמשים שהכלי שלהם, אם הוא נוצר ב־xLab, כולל תכונות המשנות את קטגוריית הסיכון, נרתיע משתמשי כלים מאיסוף מוגזם של נתונים ונגביר את הבהירות סביב השאלה איזה שילוב תכונות מצריך סקירת פרטיות.
SDS2.1.6	אם צוות הצמיחה יפעל להוספת מנגנוני איסוף נתונים (instrumenting) לשני תרחישי שימוש (use-cases) - אחד עם בדיקת A/B כדי להשיג תובנות לגבי יכולות מיון סלים (bucketing capabilities), ואחד עם איסוף נתונים לטווח ארוך כדי ללמוד על תמיכה במטריקות הדומות ל'מדדי ביצוע מרכזיים' (KPI) - עם מעבדת הניסויים, נוכל להעריך אם אם היא ממלאת באופן מספק את הדרישות להחלפת מערך הניסויים הייחודי שלנו ב־GrowthExperiments.

השערות עסקיות בעניין קהל עתידי (FA) [ תוצאות מפתח לקהל עתידי ] שיחה
שם מקוצר להשערה	טקסט רבעון שני	פרטים ודיון
FA1.1.4	[המשך משנת הכספים הקודמת] אם נבנה חוויית ויקיפדיה חדשה ב־Roblox, נדע אם זו יכולה להיות דרך אפקטיבית להציג את המותג שלנו בפני קהלים צעירים יותר (דור אלפא).
FA1.1.2	אם נבנה צומת מרכזי לחוויות ויקיפדיה חדשות ב־itch.io, נוכל להצמיח קהל של מתעניינים לא־ויקיפדים בני 50 ומעלה, שיתנו לנו משוב שיעזור לנו להבין מה עובד במשחקים ומה לא.
FA2.2.1	אם נשקיע בניהול קהילה בפלטפורמות שונות של סרטוני וידיאו קצרים, נראה עד סוף הרבעון השני (דצמבר 2025) עלייה של 30% לעומת הרבעון הקודם בשיעור הצפיות מ־New Viewers ומ'טיקטוק' — ובכל פלטפורמות הסרטונים הקצרים, נרוויח 50 אלף מעורבויות סה״כ (לייקים ותגובות) על הערות מותג על תוכן חיצוני. זה יעזור לנו להגביר נראוּת ומעורבות עם קהלים שאיננו מגיעים אליהם כרגע.
FA2.2.2	אם נפתח אסטרטגיה פנימית וחומרי שיתוף חיצוניים ל'תוכנית שותפות יוצרים של ויקיפדיה' שתקבל אישור רשמי (כולל הסבר כללי על הערך שלנו ליוצרים, קריטריונים לשותפות, תהליך חתימה על חוזים, ואיך תוכן יוצרים יופיע בערוצים פרטיים ובערוצי יוצרים), נוכל לבסס אסטרטגיית יוצרים משוכללת שתעזור לנו להגיע לקהלים חדשים במדיה החברתית עם תוכן הידע שלנו.

השערות עסקיות לתמיכת מוצר והנדסה (PES) [ תוצאות מפתח לתמיכת מוצר והנדסה ] שיחה
שם מקוצר להשערה	טקסט רבעון שני	פרטים ודיון
PES1.1.5	אם נטמיע את יעדי רמת השירות (SLOs) ב'היסטוריית התוכן' ובוויקיפונקציות של מדיה־ויקי ל־Sloth/Pyrra, נקבל עוד 2 יעדי רמת שירות להפקה.
PES1.1.6	אם נערוך ניסוי פיילוט ב־Sloth עם נתונים רטרואקטיביים מיעדי רמת שירות קיימים, נבין אם Pyrra או Sloth (או משהו אחר) הם הכלי הנכון לגישת החלון הקבוע לחלונות טעויות תקציב. נמצא איך לתמוך בבעלי השירות בגישת שירות עצמי למטריקות של יעדי רמת שירות, ואיך להשתמש בהם בקבלת החלטות.
PES1.2.4	אם נערוך ניסוי פיילוט בתהליך עיון רבעוני באותות ומשאלות קהילתיים עם 3 צוותים ברבעון הראשון, נדחוף מנהלי מוצר לשלב אותות קהילתיים בתהליכי התכנון הרבעוניים והשנתיים שלהם.
PES1.2.5	אם נוסיף את היכולת לסנן ולמיין משאלות בתוסף רשימת המשאלות לשיפורים המאפשרים קטגוריזציה עם תגים והצבעה, 3 השיפורים יעלו את מספר המשתתפים הייחודיים ברשימת המשאלות ב־30% לפחות.
PES1.3.3	אם ניצור לפחות 5 התערבויות נעימות בפלטפורמה שיקרו בהתבסס על אינטראקציות של משתמשים, נגדיר מה יהיו הטריגרים לדף הפורטל ולגדג׳ט מצב ימי ההולדת. בדיקת שימושיות תראה לנו אילו התערבויות יוצרות אסוציאציות חיוביות עם המותג שלנו. ההשערה הזאת מוגבלת בזמן ותסתיים עד WikiCon North America בסוף אוקטובר.
PES1.3.4	אם ניצור אתר ווב חווייתי ללימוד ההיסטוריה, ההווה והעתיד של ויקיפדיה, בשיתוף פעולה עם חברים של מחלקת התקשורת, שמטרתו לשתף קהלים מקוונים בגילים בין 18 ל־34 באזורי מטרות קמפיין, הוא ידמה קשר חזק יותר עם ויקיפדיה דרך שיתופים חברתיים ופעולות מקוונות אחרות. דבר זה יתרום לתוצאת המפתח של מחלקת התקשורת להגדלת נוכחות המותג ב־10 נקודות אחוז, ויראה לנו אם גישות דינמיות לתוכן משפרות את המשיכה של המותג.

Q3

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

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

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

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

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

תכנון יחד

עדכון ינואר 2025

התוכנית השנתית היא תיאור של מה שקרן ויקימדיה מקווה להשיג בשנה הקרובה. אנחנו עובדים קשה כדי שהתוכנית תגובש בהשתתפות רחבה ותהיה שאפתנית ובת־השגה. בכל שנה, בשעה שאנחנו מגבשים את התוכנית, אנחנו מבקשים מתורמי תוכן לשתף איתנו את נקודות המבט שלהם, את תקוותיהם, וגם בקשות ספציפיות. המידע הזה מתקבל, בין היתר, באמצעות שיחות של צוות המוצר עם קהילות, רשימת המשאלות של הקהילה, שיחות קהילתיות - כמו סדרת השיחות של ויקישיתוף, שיחות בכינוסים ובאמצעות דפי ויקי כמו הדף הזה.

לגבי התוכנית השנתית הבאה שלנו, לתקופה שבין יולי 2025 ליוני 2026, אנחנו חושבים על האופן שבו נוכל לקדם חזון רב־דורי, לאור שינויים מהירים בעולם ובאינטרנט והאופן שבו הם משפיעים על משימת הידע החופשי שלנו.

כפי שאמרתי בשנה שעברה, אנחנו צריכים להתמקד במה שמייחד אותנו: יכולתנו לספק תוכן מהימן גם בשעה שבה מידע מוטעה ומטעה מתפשט ברחבי האינטרנט ובפלטפורמות המתחרות על תשומת־הלב של הדורות החדשים. במסגרת זו עלינו להבטיח את השגת המטרה של איסוף כלל הידע האנושי בעולם והגשתו באמצעות הרחבת היריעה כך שתכלול מידע חסר עקב חוסר הגינות, אפליה או הטיה. כמו כן, המידע שלנו צריך להוסיף להיות מועיל וחיוני באינטרנט משתנה שמונע בידי בינה מלאכותית וחוויות עשירות. לסיום, עלינו למצוא דרכים להשגת מימון יציב לתנועה שלנו באמצעות בניית אסטרטגיה משותפת למוצרים ולגיוס הכספים שלנו, כך שנוכל לתמוך בעבודה הזאת לאורך זמן.

כדי לקבל החלטות ולהפעיל שיקול דעת לגבי מיקוד מאמצינו בשנה הקרובה, העלינו יחד שאלות ומחשבות על הקצאת משאבינו המוגבלים לשם השגת ההשפעה המרבית.

אם אתם מתעניינים באופן ספציפי בתכונות ובשירותים שמחלקת המוצר והטכנולוגיה תבנה בהתבסס על סדרי העדיפויות הקבועים כאן, יהיה זמן בחודש מרץ להעיר הערות על יעדים ספציפיים ותוצאות מפתח. (כאן נמצאים היעדים ותוצאות המפתח לתוכנית השנתית הנוכחית, לשם השוואה.)

אם אתם רוצים לחשוב על האתגרים ועל ההזדמנויות בסביבתנו הטכנולוגית, ועל הכיוון שעלינו לקבוע לתוכנית השנתית הבאה, אנא תנו דעתכם, יחד איתנו, על השאלות להלן.

אנחנו קולטים בהתמדה מידע על השאלות האלה בדרכים רבות, החל בשיחות קהילתיות, מידע שאנחנו אוספים, ראיונות מחקר שאנחנו עורכים ועוד. כבר שאלנו ולמדנו בעבר על חלק גדול מהנושאים האלה, וכבר טיפלנו בדברים הקשורים בהם. אנחנו רוצים לשאול את השאלות האלה שוב עכשיו ולהמשיך ללמוד, כיוון שהן בראש סדר העדיפויות שלנו בשלב זה של התכנון.

שאלות:

• מדדים ונתונים
  • באילו דרכים יכולים הנתונים והמדדים לתמוך טוב יותר בעבודה שלכם כעורכים? האם תוכלו לחשוב על נתונים לגבי עריכה, קריאה או ארגון שיוכלו לעזור לכם לבחור איך להקדיש את זמנכם או מתי עניין כלשהו זקוק לתשומת ליבכם? זה יכול להיות מידע על הפעילות שלכם או על פעילותם של אחרים.
• עריכה
  • מתי אתם מרגישים סיפוק או הנאה רבים במיוחד מפעילות העריכה שלכם? מתי אתם מרגישים תסכול או קושי גדולים במיוחד?
  • אנחנו רוצים שתורמי תוכן יקבלו יותר משוב והכרה על עבודתם, כדי שלא ירגישו כאילו איש אינו מבחין במאמץ שהם משקיעים במיזמי הוויקי. איזה סוג משוב או הכרה נותן לכם מוטיבציה? מה מניע אתכם להמשיך לערוך?
  • כיוון שמיזמי הוויקי גדולים כל כך, אולי לא יהיה קל לעורכים להחליט מהי פעילות הוויקי החשובה להם ביותר ואשר ראוי להקדיש לה זמן מדי יום. איזה מידע או אילו כלים עשויים לעזור לך לבחור איך להקדיש את זמנך? האם תועיל יצירת מקום מרכזי, מותאם אישית שיאפשר לך למצוא הזדמנויות חדשות, לנהל את המטלות שלך ולהבין מה ההשפעה שלך?
  • אנחנו רוצים לשפר את חוויית שיתוף הפעולה במיזמי הוויקי, כך שיהיה קל יותר לתורמי תוכן למצוא זה את זה ולעבוד על פרויקטים יחד, באמצעות מבצע להשלמת משימות, מרתון עריכה, מיזמי ויקי מיוחדים או אפילו עבודה משותפת של שני עורכים. איך לדעתך נוכל לעזור ליותר עורכים למצוא אלה את אלה, ליצור קשר ולעבוד יחד?
• קריאה/למידה
  • אתרי הוויקי עולים מהר יותר או לאט יותר, תלוי באיזה חלק של העולם אנשים חיים. האם יש חלק כלשהו של העולם שזקוק לדעתך במיוחד לשיפור הביצועים?
  • איך נוכל לעזור לדורות חדשים של קוראים למצוא עניין בתוכן של ויקיפדיה ולהיות מעורבים? דנו בעבר ברעיונות הקשורים בתוכן אינטראקטיבי ובווידאו, ובשנה הנוכחית התמקדנו בתרשימים ובניסוי דרכים חדשות להצפת תוכן ויקיפדי קיים. איך נוכל להמשיך במסלול הזה, להשתמש בתוכן קיים בדרכים חדשות ייחודיות לוויקימדיה?
• מנהלי התוכן
  • מה צריך אולי להשתנות בוויקיפדיה כדי שיותר אנשים ירצו להיות מעורבים בתפקידי מתנדבים מתקדמים, כמו מנטרים או מפעילי מערכת?
  • איזה מידע או הקשר לגבי עריכות או משתמשים יכול לעזור לך לקבל החלטות בנושא טיפול בהשחתות או כמפעיל/ת מערכת במהירות ובקלות רבה יותר?
• מגמות חיצוניות
  • מהם השינויים החשובים ביותר שאתם רואים בעולם מחוץ לוויקימדיה? שינויים כאלה יכולים להיות מגמות חדשות בטכנולוגיה, בחינוך או באופן שבו אנשים לומדים.
  • מחוץ לתנועת ויקימדיה, באילו קהילות מקוונות אחרות אתם משתתפים? אילו לקחים אנחנו יכולים ללמוד מכלים ומתהליכים בפלטפורמות קהילתיות אחרות?
  • איך אתם משתמשים בכלי בינה מלאכותית (AI) במסגרת פעילותכם בוויקימדיה ומחוץ לה? במה לדעתכם הבינה המלאכותית מועילה?
• ויקישיתוף
  • אילו החלטות אנחנו יכולים לקבל עם קהילת ויקישיתוף כדי ליצור פרויקט בר־קיימא שתומך ביצירת ידע אנציקלופדי?
• ויקינתונים
  • איך הייתם רוצים לראות את ההתפתחות של ויקינתונים בעתיד? איך הוא יכול להועיל במיוחד לבניית תוכן אנציקלופדי מהימן?

שיחה

–– Selena Deckelmann