סקר / תיאור רצון הקהילה

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

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

רציונל

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

הסברה

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

מקום

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

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

היקף

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

דרישות להשתתפות

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

שלב 1: הגשת הצעות

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

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

פורמט של הצעות

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

• מה הבעיה שאתה רוצה לפתור?
• אילו משתמשים ירוויחו? (עורכים, מנהלים, משתמשי קומונס, משתמשי ויקיפדיה וכו')
• כיצד מטפלים בבעיה זו כעת?
• מהם הפתרונות המוצעים? (אם יש רעיונות)
• האם יש משימות רלוונטיות?

שלב 2: סקירה וארגון של הצעות

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

שלב 3: הצבעה

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

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

ניתוח ותעדוף

We've developed a method to help us approach our wish prioritization more systematically and with transparency over the years. There were a few assumptions built into our prioritization process which are helpful to name explicitly:

• Popularity of a wish should be a very important factor in our selection decision, but not the only one.
• It is best to stagger wishes so that specialists can collaborate with each other as we progress through work-- i.e. as the designer researches the wish and generates visual components for wish, the engineers focus on a wish that is purely technical.
• It is best to communicate transparently with the communities rather than hiding the details. Visibility builds trust and dialogue.

The process consists of going through any wish that scores in the top 30 for a wishlist (we cut off any wishes below that, because realistically, it takes time to investigate every wish and we know we will not be able to grant more wishes for a given year) and scores them based on the following criteria:

Prioritization Score for Community Tech Proposals

Once every wish is scored from every vantage point that impacts its feasibility and impact, we rank them. If we tackle those wishes first, we can tackle most wishes. Also, we can optimize for impact while taking maintenance and complexity into account.

This also means talking to other teams at the Foundation, and investigating if they were already working on projects related to wishes.

פיתוח

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

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