Survei Harapan Komunitas/Penentuan prioritas

This page is a translated version of the page Community Wishlist Survey/Prioritization and the translation is 33% 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.

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