Апытаньне пажаданьняў супольнасьці-2021

From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Community Wishlist Survey 2021 and the translation is 6% complete.
The Community Wishlist Survey 2021 is over...

Агулам: 268 прапановаў, 1773 удзельнікаў, 8596 галасоў падтрымкі

Паглядзець выпадковую прапанову

Катэгорыі
Для прагляду прапановаў абярыце катэгорыю

Admins and patrollers
25 прапановаў
Супрацьдзеяньне перасьледам
3 прапановы
Робаты й інструмэнты
15 прапановаў
Categories
12 прапановаў
Крыніцы
12 прапановаў
Рэдагаваньне
39 прапановаў
Рознае
27 прапановаў
Мабільны прагляд і праграмы
18 прапановаў
Мультымэдыя і Вікісховішча
31 прапанова
Notifications
7 прапановаў
Reading
13 прапановаў
Пошук
9 прапановаў
Translation
10 прапановаў
Сьпісы назіраньня
17 прапановаў
Вікізьвесткі
21 прапанова
Вікікрыніцы
5 прапановаў
Вікіслоўнік
4 прапановы

 

Starting this July 2021, the team will start engineering work on the following wishes:

We will also begin the product and design research for the following wish:

We fully expect to be able to complete more wishes than the above. The above list is only what is in our plate starting this July.

How did we arrive at our next steps? We recently completed the 2021 Wish prioritization process.

 

Усе этапы апытаньня пачынаюцца і сканчаюцца а 18:00 UTC.

  • Падача, абмеркаваньне і перагляд прапановаў: 16 лістапад – 30 лістапад 2020
  • Каманда Community Tech разглядае і ўкладае прапановы: 23 лістапад – 7 сьнежань 2020
  • Галасаваньне па прапановах: 8 сьнежань – 21 сьнежань 2020
  • Публікацыя вынікаў: 23 сьнежань 2020

 

Hello, everyone!

We're excited to share an update on the Community Wishlist Survey 2021. This will be our sixth annual survey, and we've decided to update the process:

One backlog per year: The team will now have one backlog per year. This means that, each year, volunteers will vote on our new backlog. They can propose new wishes or re-propose old ones. Once the voting is complete, we'll have one new backlog. This is a change from our old format, which allowed us to work on multiple backlogs per year. With this change, we can simplify our work, ensure the most important wishes get addressed, and reassess old wishes each year.

Status of remaining 2019 and 2020 wishes: There are 3 remaining wishes from the 2019 and 2020 surveys that we have not worked on or addressed yet. Since they received a high number of votes, we will include them in our 2021 backlog. In the 2019 wishlist, there are 2 wishes that will be included: section name in diff and named references in VE. In the 2020 wishlist, there are 4 wishes that we have already begun or have been worked on. There is 1 wish from the 2020 wishlist that we have not worked on yet, so it will also be included in the 2021 backlog: insert attestation using Wikisource as a corpus. You can review our status report for the 2019 wishlist.

Research and regular updates to replace "top 10": We have decided to no longer commit to a number (such as "top 5" or "top 10") in advance. Here's why: Software development teams usually conduct extensive research before committing to a project. This way, they can determine if the project is feasible, understand how long the project may take, and identify potential risks. With the current wishlist process, we don't do that, which often leads to delays, stress, and confusion. We want to fix this.

With the new system, we'll research projects before committing to them. We will evaluate wishes in the order of popularity, going from the top down. During our research phase, we'll analyze the following criteria: popularity (i.e., number of votes), size and scope of the project, level of technical feasibility, risks and dependencies, and potential conflicts with other teams. Once our analysis is complete, we'll share our findings. This means that we'll still work on multiple projects per year. We'll just be more communicative about what we can or cannot take on (and why), and we'll share updates over the course of the year about our roadmap.

Separate leaderboards for categories: We will keep the normal structure of displaying all proposals, sorted by the number of votes, in the main leaderboard. In addition, we will now have separate leaderboards for each category. This way, we can work on proposals that are popular for large communities (from the main leaderboard) and underrepresented communities (from specific leaderboards). We’ll use the criteria described above to help select which proposals we work on.

Why these changes?: We knew that the wishlist process was ready for an upgrade. Wishes have grown bigger and more complex over the years, and we wanted to improve our communication with volunteers. Additionally, we wanted to continue to address the wishes of smaller communities (as we did in the 2020 wishlist) and the high-impact wishes of all Wikimedians (as we did in previous wishlists). This led to a series of conversations on how we could improve the process. From these conversations, we came up with these changes. Overall, we hope these changes make the wishlist process more transparent, sustainable, and impactful. This way, the survey is strengthened for years to come. Thank you, and we look forward to reading your proposals!

 

Каманда тэхнічнай супольнасьці — каманда Фундацыі Вікімэдыі, засяроджаная на патрэбах актыўных удзельнікаў Вікімэдыі па паляпшэньні інструмэнтаў курыраваньня і мадэраваньня. Праекты, над якімі мы працуем, абраныя супольнасьцю Вікімэдыі шляхам штогадовага апытаньня пажаданьняў супольнасьці.

Аднойчы ў год актыўныя ўдзельнікі Вікімэдыі могуць падаваць прапановы новых функцыяў і выпраўленьняў, над якімі трэба папрацаваць нашай камандзе. Праз два тыдні можна галасаваць за найбольш упадабаныя вамі ідэі. 5 самых папулярных пажаданьняў будуць вывучаныя і перададзеныя камандзе тэхнічнай супольнасьці. Некаторыя зь іншых папулярных пажаданьняў могуць быць перададзеныя іншым камандам распрацоўнікаў.

Once the survey is closed, the Community Tech team will choose some proposals from the survey to work on. Proposals will be selected based on the following criteria: popularity (i.e., number of votes), size and scope of the project, level of technical feasibility, risks and dependencies, and potential conflicts with other teams. Some of the wishes may be addressed by volunteer developers or other development teams.

Працэс апытаньня быў распрацаваны камандай тэхнічных пажаданьняў Вікімэдыі Нямеччыны, якая ладзіла апытаньне пажаданьняў у нямецкай Вікіпэдыі. Працэс стварэньня міжнароднага сьпісу пажаданьняў адбываўся пры падтрымцы каманды тэхнічнага супрацоўніцтва.

 
Талісман тэхнічнай супольнасьці: сабака ў шапцы сьв. Мікалая.

На этап прапановаў адведзеныя першыя два тыдні апытаньня.

На этапе прапановаў удзельнікі з кожнага праекту і мовы могуць падаваць прапановы функцыяў і выпраўленьняў, якія б хацелі мець у 2021 годзе. Падаваць прапановы можна любой мовай. Калі прапанова будзе не ангельскай, а любой іншай мовай, мы пастараемся перакласьці яе, каб прачытаць і прагаласаваць мог кожны ахвотны.

Прапановы мусяць быць канкрэтнымі, добра апісанымі задачамі, якія прынясуць непасрэдную карысьць удзельнікам праектаў Вікімэдыі. Прапановы мусяць адказваць на наступныя пытаньні:

  • Якую праблему вы хочаце вырашыць?
  • Якіх удзельнікаў гэта закранае? (рэдактараў, адміністратараў, рэдактараў Вікікрыніцаў і да т. п.)
  • Якім чынам праблема вырашаецца цяпер?
  • Якія магчымыя рашэньні? (калі маеце ідэі)

Вашая прапанова мусіць быць як мага болей акрэсьленай, асабліва ў фармуляваньні праблемы. Ня варта казаць проста «функцыя X састарэла», «трэба палепшыць» ці «мае шмат хібаў». Гэта недастатковая інфармацыя для вызначэньня таго, што трэба зрабіць. Добрая прапанова канкрэтна тлумачыць праблему і каго яна закранае. Нічога страшнага, калі вы ня маеце варыянту ейнага вырашэньня ці маеце некалькі, але ня ведаеце, які зь іх лепшы.

Падача прапановы — толькі пачатак працэсу. Двухтыднёва этап — гэта час, калі супольнасьць можа разам дапрацаваць ідэю, каб яна атрымала як мага болей галасоў на этапе галасаваньня. Пасьля падачы прапановы ўсе запрашаюцца да камэнтаваньня, каб зрабіць яе лепшай — запытаньняў і прапановаў зьмяненьняў. Падобныя прапановы могуць быць аб’яднаныя; вельмі маштабныя прапановы могуць быць падзеленыя на канкрэтнейшыя. Мэтаю ёсьць стварэньне найлепшай прапановы для этапу галасаваньня.

Ад асобы, якая падае прапанову, чакаецца актыўны ўдзел у абмеркаваньні і дапамога ва ўнясеньні зьмяненьняў. З-за гэтага мы плянуем абмежаваць колькасьць прапановаў аднаго ўдзельніка да трох. Калі вы зьмесьціце больш, мы папросім пакінуць тры зь іх. Прапануйце найлепшыя ідэі!

З гэтае ж прычыны ўносіць прапановы могуць толькі зарэгістраваныя ўдзельнікі, каб быць пэўнымі, што яны будуць сачыць за абмеркаваньнем і адказваць на пытаньні. Як і пры галасаваньні, вы мусіце быць актыўным удзельнікам прынамсі аднаго з праектаў Вікімэдыі. Калі вы не адпавядаеце гэтаму крытэру ці вычарпалі ліміт прапановаў, а маеце яшчэ ідэі, пашукайце іншых удзельнікаў, якія змогуць вылучыць вашыя прапановы.

Яшчэ адна заўвага: прапановы, якія заклікаюць да выдаленьня ці адключэньня функцыі, над якой працавала каманда распрацоўнікаў ФВМ, знаходзяцца па-за сфэрай кампэтэнцыі Тэхнічнай каманды супольнасьці. Яны ня трапяць у этап галасаваньня.

 

Так, вы можаце паўторна выставіць прапановы, якія раней атрымалі недастаткова галасоў і заслугоўваюць другое спробы.

Калі вырашыце скапіяваць прапанову з старога ў новае апытаньне, дык спадзяемся, што вы будзеце «апекавацца» гэтай прапановай — то бок будзеце актыўна ўдзельнічаць у абмеркаваньні і жадаць унесьці зьмены ў прапанову, каб зрабіць яе яшчэ выгаднейшай да пачатку галасаваньня. Як мы казалі вышэй, ад аднае асобы можна вылучыць максымум тры прапановы, і ў гэтай квоце ўлічваюцца і ўнясеньне мінулагодніх прапановаў.

Будзе карысна спаслацца на папярэдняе абмеркаваньне прапановы, але не капіруйце, калі ласка, галасаваньні і абмеркаваньні. Калі ў мінулых абмеркаваньнях ёсьць нешта карыснае, уключыце гэтыя прапановы ці абумовы ў новую прапанову.

 

Пасьля этапу прапановаў мы робім тыднёвы перапынак дзеля разгляду прапановаў перад пачаткам этапу галасаваньня.

Усе актыўныя ўдзельнікі могуць пісаць водгукі і галасаваць за прапановы, якія хочуць падтрымаць. Можна галасаваць зя любую колькасьць розных прапановаў. Каб забясьпечыць справядлівае галасаваньне, галасаваць могуць толькі зарэгістраваныя ўдзельнікі, а галасы ад новазарэгістраваных уліковых запісаў могуць быць выдаленыя.

Улічваюцца толькі галасы падтрымкі. Канчатковы сьпіс пажаданьняў будзе адсартаваны паводле колькасьці такіх галасоў. Калі вы зьяўляецеся аўтарам прапановы, ваш голас аўтаматычна залічваецца ў яе падтрымку.

Аднак на этапе галасаваньня заахвочваецца і жывое абмеркаваньне. Калі вы хочаце выказацца нэўтральна ці супраць прапановы, сьмела рабіце гэта з тлумачэньнем. Такія абмеркаваньня могуць дапамагчы людзям вызначыцца з уласным меркаваньнем што да галасаваньня па гэтых прапановах. Таксама абмеркаваньні даюць карысную інфармацыю для асобаў, якія зьбіраюцца працаваць над рэалізацыяй прапановы.

Дапушчальная таксама агітацыя ў разумных памерах. Вы маеце магчымасьць прадаць сваю ідэю такой колькасьці людзей, як зможаце. Сьмела зьвяртайцеся да людзей у вашым праекце, Вікіпраекце ці карыстальніцкай групе. Відавочна, што пры гэтым нельга карыстацца «лялькамі» ці патрабаваць ад людзей галасаваць або зьмяніць свой голас. А вось кампанія «добрай волі» цалкам нармальная.

 

Каманда тэхнічнай супольнасьці можа адхіліць прапановы, якія не адпавядаюць наступным крытэрам:

  • Прапанова мусіць тычыцца тэхнічнай зьмены, а ня зьмены палітыкі ці супольнасьці
  • Прапанова мусіць тычыцца праблемы, а не запытваць канкрэтнага разьвязаньня
  • Прапанова мусіць быць добра акрэсьленаю праблемаю, а не мяшанкай розных незьвязаных праблемаў
  • Прапанова адсутнічае ў дарожнай мапе іншай каманды ці не адхілялася іншымі камандамі раней
  • Прапанова не адхілялася камандай тэхнічнай супольнасьці раней
  • Прапанова мусіць уваходзіць у сфэру адказнасьці каманды

The Community Tech team may decline proposals that fail to meet the above criteria.

 

Рэйтынгі падтрымкі ствараюць прыярытэтны сьпіс пажаданьняў, і каманда тэхнічнай супольнасьці адказвае за ацэнку і апрацоўку першых 5 пажаданьняў. Каб гэта выканаць, мы вывучаем усе найлепшыя пажаданьні і разглядаем іх з улікам тэхнічных і сацыяльных/палітычных фактараў рызыкі.

Вельмі карысныя ў выяўленьні патэнцыйных адмоўных аспэктаў галасы супраць і нэўтральныя. Па супярэчлівых пажаданьнях мы ўраўнаважваем вынікі галасаваньня з водгукамі, больш заснаванымі на кансэнсусе. Напрыклад, так адбылося ў апытаньні 2015 году: мноства галасоў атрымала пажаданьне «дадаць сьпіс назіраньня карыстальніка», аднак былі некалькі шчырых галасоў супраць. Мы выслухалі ўсе баку і прынялі рашэньне, ці варта займацца гэтым праектам.

As an example, this worked in the 2015 survey: The wish to "add a user watchlist" received a lot of votes but also some heartfelt Oppose votes. Community Tech listened to all sides, and made a decision on whether to pursue the project or not.

 
Кожны сабака, які носіць шапку сьвятога Мікалая, працуе на Тэхнічную супольнасьць.

…замест таго, каб заняцца мінулагоднімі прапановамі, ніжэйшымі за 10-е месца?

Асноўная прычына для стварэньня штогадовага апытаньня — нашае жаданьне прыцягнуць больш людзей! Зараз больш людзей даведаюцца пра каманду і апытаньне, і праз год пасьля выкананьня найлепшых пажаданьняў мы спадзяемся, што людзі яшчэ больш зацікавяцца і заахвоцяцца ўдзелам. Хочам даць усім шанец прадставіць новыя ідэі.

We also want to make sure that older ideas are still wanted. As software evolves, so do the user’s needs. Sometimes a really good wish from last year isn’t so important anymore, or the description has simply become outdated. Conducting the survey annually helps reconfirm what the community needs.

Калі вы лічыце, што леташнія пажаданьні заслугоўваюць яшчэ аднае спробы, глядзіце «[[Ці магу я паўторна адсылаць прапановы зь мінулых апытаньняў?|Ці магу я паўторна адсылаць прапановы зь мінулых апытаньняў?]]»