Проучване на желанията на общността 2021
Проучването на желанията на общността за 2021 г. приключи... Общо: 268 предложения, 1773 сътрудници, 8596 гласове "за"
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.
All phases of the survey begin and end at 18:00 UTC.
- Изпращане, обсъждане и преглед на предложенията: 16 ноември – 30 ноември 2020
- Community Tech reviews and organizes proposals: 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!
Екипът на Техническата общност е екип на Фондация Уикимедия, фокусиран върху нуждите на активните сътрудници на Уикимедия от подобрени инструменти за работа и модериране. Кои да са проектите, върху които да работим, се решава от уикимедианската общност, чрез годишното проучване за желанията на общността.
Веднъж годишно активните сътрудници на Уикимедия могат да изпращат предложения за функции и поправки, върху които биха искали екипът ни да работи. След две седмици можете да гласувате за идеите, от които се интересувате. Топ 10-те желания ще бъдат разгледани и адресирани от екипа на техническата общност. Някои от другите най-добри желания могат да бъдат разгледани от други развойни екипи.
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.
This survey process was developed by Wikimedia Deutschland's Technical Wishes team, who run a wishlist survey on German Wikipedia. The international wishlist process is supported by the Community Relations Specialists team.
The proposal phase is the first two weeks of the survey.
In the proposal phase, contributors from every project and language can submit proposals for features and fixes that you'd like to see in 2021. Proposals may be submitted in any language. If you submit a proposal in a language other than English, we will attempt to get it translated so everyone can read and vote on it more easily.
Предложенията трябва да бъдат обособени, добре дефинирани задачи, които ще бъдат от полза за активните сътрудници на Уикимедия. Предложенията трябва да отговарят на следните въпроси:
- Какъв е проблемът, който искате да разрешите?
- Кои потребители са засегнати? (редактори, администратори, потребители на Общомедия, потребители на Уикипедия и т.н.)
- Как се решава този проблем в момента?
- Какви са предложените решения? (ако има някакви идеи)
Предложението ви трябва да бъде възможно най-конкретно, особено в описанието на проблема. Не просто да кажете, че "(x функцията) е остаряла", "трябва да се подобри" или "има много бъгове". Това не е достатъчно информация, за да разберем какво трябва да се направи. Доброто предложение обяснява какъв точно е проблемът и кой е засегнат от него. Всичко е наред, ако нямате конкретно решение, което да предложите, или ако имате няколко възможни решения и не знаете кое е най-доброто.
Представянето на предложение е само началото на процеса. Двуседмичната фаза за предложения е време, в което общността може съвместно да работи по предложение, което представя идеята по начин, който най-вероятно ще успее във фазата на гласуване. Когато се подаде предложение, всички се приканват да го коментират и да спомогнат за най-доброто му възможно представяне - да задават въпроси и да предложат промени. Подобни предложения могат да бъдат комбинирани; предложения, които са големи, трябва да бъдат разделени на по-конкретни идеи. Целта е да се създаде възможно най-доброто предложение за фазата на гласуване.
От лицето, което представя предложение, се очаква да е активно в дискусията и да помогне да се направят промени в течение на обсъждането му. Поради това ще ограничим предложенията до три на човек. Ако публикувате повече от три предложения, ще ви помолим да го намалите на три. Дайте най-добрите си идеи!
Similarly, only registered users can make proposals to ensure they can watchlist the discussion and respond to questions. Just as with voting, you should be an active editor on at least one Wikimedia project. If you do not meet this criteria, or you have hit your proposal limit but have more ideas, you can seek other users to adopt your proposals.
Още една бележка: Предложенията, които изискват премахване или деактивиране на функция, върху която е работил продуктовия екип на Фондация Уикимедия, са извън възможния обхват на техническата общност. Те няма да участват във фазата на гласуване.
Да, определено има някои полезни предложения, които не получиха в подкрепа достатъчно гласове миналата година и заслужават втори опит.
Ако решите да копирате предложение от старото проучване в новото, очакваме да "осиновите" това предложение, което означава да участвате активно в дискусията за тази идея и да имате желание да направите промени в предложението, за да го превърнете в по-добра идея, която да се придвижи до етапа на гласуване. Както казахме по-горе, има лимит от три предложения на човек и публикуването на предложение от миналата година се включва в тях.
Полезно ще е да публикувате линк към предишната дискусия, но моля, не копирайте гласовете и дискусиите от миналата година. Ако има основателни гледни точки, засегнати в дискусиите от миналата година, включете предложенията или предупрежденията в новото предложение.
After the proposal phase, we take a break to review the proposals before the voting phase begins.
Всички активни сътрудници могат да прегледат и гласуват за предложенията, които искат да подкрепят. Можете да гласувате за колкото искате различни предложения.
Единствените гласове, които се броят, са гласовете "За". Окончателният списък на желанията ще бъде подреден по реда на по-големия брой получени гласове "За". If you are the proposer, a support vote is automatically counted for your proposal.
Все пак, оживената дискусия се насърчава по време на гласуването. Ако искате да дадете вот "Против" или "Неутрален" с коментар, не се колебайте да го направите. Тези дискусии могат да помогнат на хората да се замислят дали искат да гласуват за предложенията. Дискусиите също така осигуряват полезни приноси за насочване на работата, която да бъде осъществена през годината.
Разумно количество агитиране е приемливо. Имате възможност да "продадетe" идеята си на толкова хора, колкото можете да достигнете. Чувствайте се свободни да се свържете с други хора във вашия проект, уикипроект или потребителска група. Очевидно това не би трябвало да включва марионетки или хора, които да гласуват и да променят своя вот. Но добросъвестната кампания "Гласувайте!" е абсолютно наред.
Each proposal should meet the following criteria:
- The proposal is about a technical change and not for a policy or social change
- The proposal is about the problem and not necessarily ask for a specific solution
- The proposal is a well-defined problem and not a mix and match of different unrelated issues
- The proposal is not already in another team's roadmap or has not been declined by other teams in the past
- The proposal has not been declined by Community Tech or other teams in the past
- The proposal is within the team's scope
The Community Tech team may decline proposals that fail to meet the above criteria.
Класирането по гласове "За" създават приоритетни неизпълнени желания, а техническият екип на общността е отговорен за оценяването и адресирането на първите 10 желания. За да направим това, ние изследваме всички най-добри желания и разглеждаме както техническите, така и социалните и свързаните с политиките рискови фактори.
Гласовете "Против" и "Неутрален" също са много полезни за осведомяването за потенциалните недостатъци. При противоречиви желания балансираме гласуването с основан на консенсус преглед. Например това сработи при проучването през 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.
…instead of addressing other wishes from older surveys?
Основната причина, поради която правим проучването ежегодишно събитие, е, че искаме да включим повече хора! За екипа и проучването сега знаят повече хора, а след година, през която много от най-добрите желания са завършени, очакваме, че хората ще бъдат още по-заинтересовани и развълнувани от участието си. Искаме да дадем на всеки един шанс да допринесе с нови идеи.
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.
If there are wishes from last year's survey that you think deserve another shot, see “Мога ли отново да изпратя предложение от предишни проучвания?” above.