Survei Harapan Komunitas/Penentuan prioritas

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:

Skor Penentuan Prioritas untuk Proposal Community Tech

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.

Kompleksitas Teknis

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.

Skala

Setiap ini diurutkan dalam skala 1-6.

1 - Kompleksitas Rendah	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 - Kompleksitas Rendah Menengah	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 Pemeliharaan hampir tidak dibutukan Minimal code refactoring is required Possible third party code dependencies Light QA testing required, less than 5 tasks worth of QA
3 - Kompleksitas Menengah	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 - Kompleksitas Menegah Tinggi	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 Pemeliharaan dibutuhkan 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 - Kompleksitas Tinggi	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 Pemeliharaan dibutuhkan 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 - Kompleksitas Sangat Tinggi	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 Pemeliharaan dibutuhkan 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.

Skala

Setiap ini diurutkan dalam skala 1-6.

1 - Kompleksitas Rendah	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 - Kompleksitas Rendah Menengah	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 - Kompleksitas Menengah	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 - Kompleksitas Menegah Tinggi	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 - Kompleksitas Tinggi	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 Penyunting Pembaca 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: Penyunting Pembaca Kontributor Pendatang baru

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. [[Community Wishlist Survey 2022/Editing/Autosave edited or new unpublished article|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. [[Community Wishlist Survey 2022/Bots and gadgets/Tool that reviews new uploads for potential copyright violations|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. [[Community Wishlist Survey 2022/Admins and patrollers/Show recent block history for IPs and ranges|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. [[Community Wishlist Survey 2022/Editing/Select preview image|Select preview image]] adalah contoh proposal yang diprioritaskan.
• Konten nonteks dan data terstruktur – kami memprioritaskan proposal yang berkaitan dengan multimedia, grafik, dan sebagainya. [[Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader|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. [[Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor|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. [[Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|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
[[Community Wishlist Survey 2022/Editing/Autosave edited or new unpublished article|Autosave edited or new unpublished article]]	29	69	1.0	0.3	2	2.66
[[Community Wishlist Survey 2022/Miscellaneous/Get WhatLinksHere's lists in alphabetical order|Get WhatLinksHere's lists in alphabetical order]]	22	74	1.3	0.3	2	2.63
[[Community Wishlist Survey 2022/Search/Enable negation for tag filters|Enable negation for tag filters]]	26	71	2.0	0.3	2	2.47
[[Community Wishlist Survey 2022/Wikisource/Fix search and replace in the Page namespace editor|Fix search and replace in the Page namespace editor]]	11	93	2.3	0.7	2	2.47
[[Community Wishlist Survey 2022/Multimedia and Commons/Improve SVG rendering|Improve SVG rendering]]	5	108	4.0	0.8	3	2.44
[[Community Wishlist Survey 2022/Anti-harassment/Notifications for user page edits|Notifications for user page edits]]	2	123	1.3	1.7	1	2.38
[[Community Wishlist Survey 2022/Miscellaneous/Check if a page exists without populating WhatLinksHere|Check if a page exists without populating WhatLinksHere]]	14	89	2.7	0.7	2	2.38
[[Community Wishlist Survey 2022/Bots and gadgets/Tool that reviews new uploads for potential copyright violations|Tool that reviews new uploads for potential copyright violations]]	4	109	4.3	2.7	4	2.21
[[Community Wishlist Survey 2022/Reading/IPA audio renderer|IPA audio renderer]]	9	97	3.0	2.7	3	2.15
[[Community Wishlist Survey 2022/Reading/floating table headers|floating table headers]]	24	73	1.0	2.7	2	2.14
[[Community Wishlist Survey 2022/Admins and patrollers/Mass-delete to offer drop-down of standard reasons, or templated reasons.|Mass-delete to offer drop-down of standard reasons, or templated reasons.]]	25	72	1.0	2.7	2	2.14
[[Community Wishlist Survey 2022/Editing/Formatting columns in table|Formatting columns in table]]	19	77	4.0	0.3	2	2.11
[[Community Wishlist Survey 2022/Editing/Select preview image|Select preview image]]	8	100	3.0	2.0	2	2.07
[[Community Wishlist Survey 2022/Translation/Add DeepL as a machine translation option in ContentTranslation|Add DeepL as a machine translation option in ContentTranslation]]	20	75	3.3	0.0	1	2.06
[[Community Wishlist Survey 2022/Search/Change default number of search results displayed|Change default number of search results displayed]]	12	92	2.0	1.7	1	2.05
[[Community Wishlist Survey 2022/Editing/Better diff handling of paragraph splits|Better diff handling of paragraph splits]]	1	157	3.3	2.3	1	2.04
[[Community Wishlist Survey 2022/Mobile and apps/Table sorting on mobile|Table sorting on mobile]]	17	83	2.3	1.7	1	1.92
[[Community Wishlist Survey 2022/Miscellaneous/Enhanced Move Logs|Enhanced Move Logs]]	10	96	2.7	2.3	1	1.79
[[Community Wishlist Survey 2022/Bots and gadgets/Gadget: Who is active|Gadget: Who is active]]	26	71	1.3	4.0	2	1.76
[[Community Wishlist Survey 2022/Admins and patrollers/Show recent block history for IPs and ranges|Show recent block history for IPs and ranges]]	3	120	4.0	3.7	2	1.61
[[Community Wishlist Survey 2022/Admins and patrollers/Reminders or edit notifications after block expiration|Reminders or edit notifications after block expiration]]	20	75	3.3	3.2	2	1.57
[[Community Wishlist Survey 2022/Wikidata/Autosuggest linking Wikidata item after creating an article|Autosuggest linking Wikidata item after creating an article]]	12	92	3.3	3.8	2	1.53
[[Community Wishlist Survey 2022/Mobile and apps/Full page editing|Full page editing]]	30	67	2.0	3.7	1	1.42
[[Community Wishlist Survey 2022/Miscellaneous/Allow filtering of WhatLinksHere to remove links from templates|Allow filtering of WhatLinksHere to remove links from templates]]	6	106	5.0	3.3	2	1.40
[[Community Wishlist Survey 2022/Citations/Automatic duplicate citation finder|Automatic duplicate citation finder]]	6	106	3.0	4.2	1	1.36
[[Community Wishlist Survey 2022/Editing/VisualEditor should use human-like names for references|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:

• Kompleksitas Produk dan Desain
• Kompleksitas Teknis
• Dampak Komunitas

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
[[Community Wishlist Survey 2022/Anti-harassment/Deal with Google Chrome User-Agent deprecation|Deal with Google Chrome User-Agent deprecation]]	15
[[Community Wishlist Survey 2022/Mobile and apps/Show editnotices on mobile|Show editnotices on mobile]]	15
[[Community Wishlist Survey 2022/Mobile and apps/Categories in mobile app|Categories in mobile app]]	18
[[Community Wishlist Survey 2022/Multimedia and Commons/Mass uploader|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

Pengumpulan data kuantitatif

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

Pengumpulan data kualitatif

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.