Survei Harapan Komunitas/Penentuan prioritas

This page is a translated version of the page Community Wishlist Survey/Prioritization and the translation is 13% complete.

Artikel ini ditulis bagi para sukarelawan, penggemar Survei Harapan Komunitas, dan penyunting lanjutan. Kami, Community Tech, ingin menjelaskan bagaimana kami membuat rencana pengerjaan proposal setelah fase pemungutan suara berakhir. Kami harap ini bisa menjelaskan proses pengembangan perangkat lunak kami. Kami menerima saran mengenai kejelasan dokumen ini.

Sebagai hasil dari setiap edisi Survei Harapan Komunitas, dihasilkan daftar proposal yang diurutkan berdasarkan banyak suara. Setelah beberapa tahun, kami mempelajari bahwa berkomitmen pada 10 proposal teratas bukanlah ide yang terbaik.

Jadi, kami mengembangkan metode untuk menentukan prioritas proposal. Kami menilai mereka secara sistematis dan transparan. Penentuan prioritas membantu kami memutuskan bagaimana kami akan bekerja sehingga kami bisa menyelesaikan proposal sebanyak mungkin. Terdapat beberapa asumsi:

  • Popularitas proposal sebaiknya menjadi faktor yang sangat penting dalam penentuan oleh kami, tetapi bukan satu-satunya faktor.
  • Sebaiknya proposal dikerjakan dalam urutan yang strategis dan diselesaikan sebanyak mungkin.
  • Para insinyur dan desainer sebaiknya bisa bekerja sama tanpa saling menghalangi. Contohnya, ketika desainer meneliti proposal dan membuat komponen visual untuk proposal, insinyur berfokus pada proposal yang murni bersifat teknis.
  • Sebaiknya dilakukan komunikasi yang transparan dengan komunitas daripada menyembunyikan detail. Keterbukaan membangun kepercayaan dan dialog.

Ringkasan kriteria

Ketika menentukan prioritas, kami menilai 30 proposal yang paling populer. Kami tidak meninjau proposal yang lebih rendah, karena kami tidak mampu mewujudkan lebih dari 30 harapan per tahun. Kami memberikan proposal skor berdasarkan popularitas, kerumitan teknis, kerumitan produk & desain, dan dampaknya pada komunitas. Berikut adalah ringkasan kriterianya:

Begitu semua proposal mendapat skor, kami mengurutkan mereka dan bekerja berdasarkan peringkat ini. Setelah itu, baru kami bisa:

  • Mengerjakan sebanyak mungkin harapan dengan sumber daya yang kami punya.
  • Memilih untuk membuat sebesar mungkin dampak dengan mempertimbangkan pemeliharaan dan kerumitan.

Kami juga berkonsultasi dengan tim-tim lain di Foundation, dan mencari tahu apakah mereka sedang mengerjakan proyek yang berkaitan dengan proposal.

Technical Complexity

Kriteria

Para insinyur kami memperkirakan berapa besar usaha yang dibutuhkan untuk mengabulkan sebuah harapan. Mereka memprioritaskan proyek yang lebih sederhana (lebih mudah dikerjakan). Jika ada hal yang tidak pasti, mereka mencoba untuk melebih-lebihkan perkiraan bukannya meremehkannya.

  • Dependensi teknis – kami memeriksa apakah pekerjaannya membutuhkan interaksi dengan tim Wikimedia Foundation yang lain. Bisa jadi sebagian pekerjaannya harus ada di peta jalan tim lain atau kami butuh masukan dari tim lain sebelum kami bisa mengabulkan harapannya. Contohnya adalah perubahan skema, peninjauan keamanan, menambahkan ekstensi baru, dan meningkatkan pustaka pihak-ketiga.
  • Penelitian teknis – kami meneliti apakah kami tahu pendekatan untuk memecahkan masalah tertentu. Terkadang kami harus menilai dan mempertimbangkan pilihan-pilihan kami sebelum kami bisa mulai memikirkan solusinya. Terkadang kami perlu mengonfirmasi bahwa apa yang harus dikerjakan bisa dikerjakan atau berada dalam hal yang bisa kami kerjakan.
  • Usaha teknis – kami meneliti seberapa paham kami dengan kode yang ada dan seberapa besar atau rumit pekerjaannya. Skor usaha yang tinggi bisa juga berarti kode yang akan kami kerjakan sudah tua, kaku, atau punya utang teknis yang harus diurus sebelum kami bisa mulai mengerjakan pekerjaan yang sesungguhnya.

Scale

Each of these is ranked on a 1-6 scale:

1 - Lowest Complexity
  • Technical solution is very simple - the problem exists in a contained part of the user experience as well the codebase
  • Solution might already exist, developed by a community member in the form of a pre-existing gadget, extension, or code in a public repository
  • Members of the engineering Community Tech team are familiar with the code
  • Light QA testing required, just 1 task worth of QA
2 - Low Medium Complexity
  • Technical solution is discrete- the problem exists in a contained part of the user experience as well the codebase
  • Solution might already exist, developed by a community member in the form of a pre-existing gadget, extension, or code in a public repository
  • Members of the engineering Community Tech team are familiar with the code
  • Almost no maintenance required
  • Minimal code refactoring is required
  • Possible third party code dependencies
  • Light QA testing required, less than 5 tasks worth of QA
3 - Medium Complexity
  • Technical solution is open-ended-- the problem exists in multiple parts of the user experience as well as one or multiple parts of the codebase or repositories
  • Partial or no solution exists
  • Members of the Community Tech team have limited knowledge of or are unfamiliar with the code
  • A bit of maintenance required
  • Code refactoring might be required
  • Potentially adding third party dependencies
  • QA testing required prior to release, 5+ tasks worth of QA
4 - Medium Large Complexity
  • Technical solution is open-ended-- the problem exists in multiple parts of the user experience as well as one or multiple parts of the codebase or repositories
  • Solution hasn’t been implemented
  • Members of the Community Tech team have limited knowledge of or are unfamiliar with the code
  • Maintenance is required
  • Some database schema changes may be required
  • Code refactoring is required
  • Changes to authentication/security components are required i.e. authentication, feature flags, access controls
  • Potentially adding third party dependencies
  • QA testing required prior to release, 5+ tasks worth of QA
5 - Large Complexity
  • The technical solution has unknowns-- the problem exists in multiple parts of the user experience as well as one or multiple parts of the codebase or repositories
  • A system or new tool may need to be developed
  • Members of the Community Tech team are unfamiliar with the code
  • Maintenance required
  • Some database schema changes may be required
  • Code refactoring is required
  • Changes to authentication/security components are required i.e. authentication, feature flags, access controls
  • Potentially adding third party dependencies
  • QA testing required prior to release, 5+ tasks worth of QA
6 - Extra large Complexity
  • The technical solution has many unknowns-- the problem exists in multiple parts of the user experience as well as one or multiple parts of the codebase or repositories
  • A system or new tool may need to be developed
  • Members of the Community Tech team are unfamiliar with the codebase the wish pertains to
  • Maintenance required
  • Substantial code refactoring is required
  • Difficult database schema changes may be required
  • Substantial code refactoring is required
  • Changes to authentication/security components are required i.e. authentication, feature flags, access controls
  • Add third party code dependencies
  • QA testing required prior to release, 10+ tasks worth of QA

Product and Design Complexity

Kriteria

Seperti penilaian di atas, desainer kami memperkirakan usaha apa yang sebaiknya dilakukan untuk menyelesaikan proyek. Dia memprioritaskan proyek yang lebih sederhana (lebih mudah dikerjakan). Jika ada hal yang tidak pasti, mereka mencoba untuk melebih-lebihkan perkiraan bukannya meremehkannya.

  • Usaha penelitian desain – kami mencoba memahami tingkat penelitian yang dibutuhkan untuk setiap proposal. Dalam kasus ini, penelitian adalah memahami masalah, baik saat sangat awal melalui usaha penemuan awal (cakupan dan detail proyek, survei atau wawancara dengan anggota komunitas), atau nanti melalui diskusi komunitas dan uji coba kegunaan (contohnya, bagaimana pengguna berkontribusi dengan dan tanpa fitur baru ini).
  • Usaha desain visual – banyak proposal membutuhkan perubahan antarmuka pengguna di proyek Wikimedia. Jadi, kami memperkirakan perubahan pada antarmuka pengguna, berapa banyak elemen yang harus dirancang dan kompleksitas mereka. Contohnya, menggunakan komponen yang sudah ada dari sistem desain kami atau membuat yang baru, dengan memperhatikan berapa banyak keadaan atau peringatan yang harus dibuat untuk membantu memandu pengguna, termasuk pendatang baru.
  • Kompleksitas aliran kerja – kami meneliti bagaimana suatu masalah mempengaruhi aliran kerja atau langkah-langkah yang sudah ada dalam pengalaman pengguna penyunting. Contohnya, skor tinggi di sini berarti ada banyak skenario atau tempat berbeda di antarmuka pengguna di mana kontributor bisa berinteraksi dengan fitur baru. Ini juga bisa berarti kami harus merancang untuk kelompok pengguna yang berbeda-beda, baik yang lanjutan maupun pendatang baru.

Scale

Each of these is ranked on a 1-6 scale:

1 - Lowest Complexity
  • Design Solution is embedded into the wish proposal itself-- it’s a technical fix and no UI changes are necessary
  • No data collection necessary
  • No discovery user survey collection
  • No unmoderated user research
  • No design
2 - Low Medium Complexity
  • Changes are isolated to just a single page inside of the experience with limited number of states (i.e. changes only impact one page / one wikimedia project)
  • Requires little to no initial data collection to understand behavior and pain point via survey or quantitative data
  • Requires little to no unmoderated research
  • Prior to tackling the wish, we already collected the data necessary to make informed product & design decisions
3 - Medium Complexity
  • Prior to tackling the wish, we already collect most of the data to make informed product & design decisions but may require tracking new data prior to starting to understand the problem
  • Requires unmoderated user research but it is not difficult to “source” users for those flows
  • May touch more than one page in the experience but it is generally limited to a subset of the experience and straightforward
  • Limited to designing for one type of user need
4 - Medium Large Complexity
  • Prior to tackling the wish, we already collect some of the data to make informed product & design decisions but may require tracking new data prior to starting to understand the problem
  • Requires unmoderated user research but it is not difficult to “source” users for those flows
  • May touch more than one page in the experience but it is generally limited to a subset of the experience and straightforward
  • Requires a survey at the beginning of wish
  • Limited to designing for two types of user needs
  • Touches more than one page in the experience but it is generally limited to a subset of the experience and straightforward
5 - Large Complexity
  • Requires qualitative discovery and quantitative data collection
  • Requires unmoderated user research and the users for the research are hard to source given the complexity of wish
  • Can require designing new technical information into the UI
  • Requires touching multiple pages in the flow
  • Requires a survey at the beginning of wish
  • Requires touching multiple pages in the flow and or has cross-project implications
  • Impacts across multiple user states, for example
    • Editors
    • Readers
    • Proofreaders etc.
6 - Extra Large Complexity
  • Requires investigation by the process of qualitative discovery and quantitative data collection
  • Potentially controversial implications that must be mitigated by working with communities
  • Requires unmoderated user research and the users for the research are hard to source given the complexity of designs
  • Requires designing for a “learning curve” or introducing new technical information into the UI
  • Requires touching multiple pages in the flow and or has cross-project implications
  • Impacts across multiple user states and across needs:
  • Editors
  • Readers
  • Contributors
  • Newcomers

Dampak Komunitas

Berbeda dengan dua sudut pandang di atas, bagian ini tentang kesetaraan. Pada praktiknya, ini adalah tentang memastikan bukan hanya mayoritas saja yang kebutuhannya kami kerjakan.

Tergantung skor ini, proposal dengan banyak suara yang serupa dan kompleksitas yang mirip kemungkinan akan diprioritaskan. Jika kriteria tertentu dipenuhi, proposalnya menerima +1. Semakin banyak irisan, semakin tinggi skornya. Penilaian ini ditambahkan oleh Spesialis Hubungan Komunitas kami.

  • Bukan hanya untuk Wikipedia – proposal yang terkait pada berbagai proyek dan proposal yang tidak memandang proyek, mendapatkan peringkat yang lebih tinggi daripada proyek khusus untuk Wikipedia. Autosave edited or new unpublished article adalah contoh proposal yang diprioritaskan.
  • Proyek saudari dan wiki kecil – kami juga memprioritaskan proposal tentang proyek-proyek yang kurang terdukung (seperti Wikisource atau Wiktionary). Kami menghitung Wikimedia Commons sebagai proyek tersebut. Tool that reviews new uploads for potential copyright violations adalah contoh proposal yang diprioritaskan.
  • Kelompok pendukung kritis – kami memprioritaskan proposal untuk steward, pemeriksa, dan pengurus, yaitu kelompok-kelompok yang melayani dan mendukung komunitas luas secara teknis. Show recent block history for IPs and ranges adalah contoh proposal yang diprioritaskan.
  • Pengalaman membaca – kami memprioritaskan proposal yang meningkatkan pengalaman kelompok pengguna terbesar, yaitu para pembaca. Select preview image adalah contoh proposal yang diprioritaskan.
  • Konten nonteks dan data terstruktur – kami memprioritaskan proposal yang berkaitan dengan multimedia, grafik, dan sebagainya. Mass uploader adalah contoh proposal yang diprioritaskan.
  • Urgensi – kami memprioritaskan masalah lama, proposal yang berkali-kali diusulkan, dan perubahan yang akan membuat kontribusi jauh lebih mudah. Fix search and replace in the Page namespace editor adalah contoh proposal yang diprioritaskan.
  • Penghalang untuk bergabung – kami memprioritaskan proposal tentang komunikasi dan proposal yang akan membantu orang membuat kontribusi pertama mereka. Show editnotices on mobile adalah contoh proposal yang diprioritaskan.

Hasil tahun 2022 diurutkan berdasarkan Skor Prioritas

Skor ini mungkin berubah ketika kami mulai mengerjakan proposal. Seperti yang kami jelaskan di atas, kami mencoba melebih-lebihkan perkiraan daripada meremehkan. Bacalah proposal-proposal, yang diurutkan berdasarkan prioritas:

Harapan Peringkat Popularitas Suara Skor Rekayasa Skor Produk dan Desain Skor Dampak Komunitas Skor Peringkat
Autosave edited or new unpublished article 29 69 1.0 0.3 2 2.66
Get WhatLinksHere's lists in alphabetical order 22 74 1.3 0.3 2 2.63
Enable negation for tag filters 26 71 2.0 0.3 2 2.47
Fix search and replace in the Page namespace editor 11 93 2.3 0.7 2 2.47
Improve SVG rendering 5 108 4.0 0.8 3 2.44
Notifications for user page edits 2 123 1.3 1.7 1 2.38
Check if a page exists without populating WhatLinksHere 14 89 2.7 0.7 2 2.38
Tool that reviews new uploads for potential copyright violations 4 109 4.3 2.7 4 2.21
IPA audio renderer 9 97 3.0 2.7 3 2.15
floating table headers 24 73 1.0 2.7 2 2.14
Mass-delete to offer drop-down of standard reasons, or templated reasons. 25 72 1.0 2.7 2 2.14
Formatting columns in table 19 77 4.0 0.3 2 2.11
Select preview image 8 100 3.0 2.0 2 2.07
Add DeepL as a machine translation option in ContentTranslation 20 75 3.3 0.0 1 2.06
Change default number of search results displayed 12 92 2.0 1.7 1 2.05
Better diff handling of paragraph splits 1 157 3.3 2.3 1 2.04
Table sorting on mobile 17 83 2.3 1.7 1 1.92
Enhanced Move Logs 10 96 2.7 2.3 1 1.79
Gadget: Who is active 26 71 1.3 4.0 2 1.76
Show recent block history for IPs and ranges 3 120 4.0 3.7 2 1.61
Reminders or edit notifications after block expiration 20 75 3.3 3.2 2 1.57
Autosuggest linking Wikidata item after creating an article 12 92 3.3 3.8 2 1.53
Full page editing 30 67 2.0 3.7 1 1.42
Allow filtering of WhatLinksHere to remove links from templates 6 106 5.0 3.3 2 1.40
Automatic duplicate citation finder 6 106 3.0 4.2 1 1.36
VisualEditor should use human-like names for references 22 74 3.3 4.0 1 1.12

Selain itu, jika Anda tertarik membaca versi yang lebih granular dari para subkomponen yang menentukan skor prioritas, kami telah mengumumkan masing-masing subkomponen tersebut:

Berikut adalah proposal yang kami ketahui akan dikerjakan oleh tim lain di WMF atau oleh pihak-ketiga secara sumber-terbuka ketika kami sedang memperkirakan kerumitannya:

Pekerjaan untuk tim Produk lain
Harapan Peringkat Popularitas
Deal with Google Chrome User-Agent deprecation 15
Show editnotices on mobile 15
Categories in mobile app 18
Mass uploader 28

Helpful Terminology

Unmoderated user research

Using a tool like UserTesting.com to run “mocks” of our proposed design changes and see if we are designing the right wish solution-- it’s called “unmoderated” because we let users click around and see our designs makes sense without having to explain it to them

Quantitative data collection

The process of collecting data to understand how users are interacting with the current UI to understand the wish’s pain points -- be it data regarding clicks, visits, downloads, sessions etc. Data is often limited when we first tackle a wish due to lack of tracking it prior to wish, or nonexistent data due to privacy reasons

Qualitative data collection

Understanding the wish’s problem space by talking directly to users, be it interviews or via a survey at the beginning of the wish to understand the pain points and clarify how to tackle a solution

“Sourcing” users

The process of finding users who have the knowledge required to participate in our user tests and give us the information we need to understand if our design and product decisions are headed in the right direction. Some wishes are for advanced users, which are hard to source and not available in tools like UserTesting.com

Code refactoring

The process of making the existing code more maintainable so that other people may contribute to the code, as well as removing technical debt and bugs.

Database schema changes

The alteration to a collection of logical structures of all or part of a relational database. When a change to an existing database is needed, it must be designed and then approved by a team external to CommTech. This usually takes more time and adds structural complexity to the project.

Third party code

Code written outside of the Community Tech team, examples include APIs or libraries.