Jump to content

Daftar Harapan Komunitas/2027

Add links
From Meta, a Wikimedia project coordination wiki
This page is a translated version of the page Community Wishlist/Community Wishlist 2027 and the translation is 38% complete.
Outdated translations are marked like this.
Other languages:

Updated Community Wishlist Process 2027/2028

Below you will find an updated version of the new wishlist process, taking into account the feedback we’ve received. I've added "Updated!" to the sections that have significant changes. If you'd like to see in detail all that changed, I set this up in a way that lets you view a clear diff.

Stage 1: Triage

While wishes can already be submitted now, there will be a widely advertised call for wish submissions in the last 2 weeks of the submission period in October/November. After the wish submission window closes, a working group will come together to triage the wishes submitted before that date. We need to do it this way logistically, because we want to start working on wishes as early as February in this first cycle and because we want to respect the end of year holiday season when volunteers and staff have less availability. This means that wish submission will be closed between early November 2026 and mid January 2027.

 

We heard your feedback that ideally wish submission and voting should be close together. In future years we plan to reduce the time between these two phases to a ~2 week window for triage, likely with the next cycle happening between early January and early March 2028. Note that we considered keeping wish submission open during the voting period, but because we want triage to be completed before the vote so that all wishes have an equal opportunity to get assessed, we decided against that.

Working Group

The working group will include community members familiar with the wishlist process and the mediawiki codebase alongside WMF staff:

  • Community members, ideally to include people from:
    • Small and medium-sized Wikipedias
    • Large Wikipedias
    • Sister projects (e.g., Wiktionary, Wikisource, Commons, Wikidata, etc.)
  • Wikimedia Foundation staff who are on the teams that will be working on wishes:
    • Product managers and engineers from relevant product and engineering teams, such as Editing, Moderator Tools, PSI, Readers & Apps, and Content Transform.
    • Movement Communications

Updated!

Volunteers will be invited to contact us to indicate their interest in participating in this group, or to let us know about other volunteers who could be interested in joining. We will share a post with details within the next couple of weeks. We want the working group to consist of about equal numbers of staff and volunteers and to have representation from a diverse set of wikis, so while we don’t have a defined cap for how many people can participate, we may have to end up setting a limit if we get too much interest.

Triage activities

The working group will be active once a year for about 4 weeks to triage wishes in the period leading up to the vote. This process is intended to be relatively high level;  it is not meant to define in detail exactly how the wish would be implemented from an engineering perspective. That deeper planning will follow in the post-vote and implementation stages. For this first year, the group will convene primarily in November for wish triage. Once voting is complete in January, they will be asked for input on the final plan as well prior to posting it publicly for feedback from the community.

During triage, the working group will focus on:

  • Deduplication: Wishes that are substantially similar will be identified and merged, with both original submissions retained for reference.
  • Updated! Preliminary effort estimation: The working group will assign a relative size estimate to each wish (e.g., XS, S, M, L, XL). Sizing is relative, not absolute: it reflects the level of work required, meaning how a wish compares in effort to others, not a commitment to a timeline. Definitions are as follows:
    • S - not complex at all
    • M - mostly clear, but some complexity, solvable by one team
    • L - some complexity, potentially requiring help from multiple teams
    • XL - very complex, likely requiring multiple teams
  • Updated! Clarification and refinement: Wishes will be linked to related phab tickets, prior work, or existing wishes. Working group members will ask clarifying questions to the wishers. Where relevant, the working group will add context about why a wish has not been addressed previously. Ensuring that we understand the desired impact of the wish is part of clarification and refinement as well. This includes assessing whether wishes undo previous work or go counter to other planned work, making tradeoffs clear and linking contradicting wishes, where possible.
  • Grouping and merging / big investments: Where multiple wishes address the same underlying need, the working group may group or merge them and identify large underlying needs in the wishes (e.g. “these several wishes are all basically asking for an edit check system”). All constituent wishes will remain visible and attributed, and where possible duplicates will be closed.
  • Updated! Wishes don’t carry over: Only the top 10 wishes in terms of vote count from the prior wish year that would have been next up to be prioritized will be rolled into the next wish year to be voted on again (so that they don’t need to be resubmitted). Votes from the prior year will carry through and editors who voted on the wish before cannot submit another vote, but they can remove support if they wish to do so. For all other wishes, wish submitters will be asked to re-submit their wish, so that we can keep the wish backlog a manageable size. Note that in the first voting period happening this coming January 2027, we will include open wishes from the existing wishlist to ensure we include the wishes submitted during the months we’re in now.
  • Updated! Potential impact assessment: If pursuing this wish will sideline some other work that communities need, we’ll make that trade-off clear on the wish, including if the WMF currently would not have the needed resources to implement the wish (meaning it might not be possible to actually fulfill the wish). If data is available to determine the potential impact of a wish (such as the number of users who would see it), the working group will add this information to the wish so that the community can factor it in when casting their votes. They will note when a wish might have a positive impact for a given wiki or set of users but create a negative impact for another wiki or set of users.
  • Updated! Removal of wishes:  A wish may be removed if it falls within the below criteria:
    • Wishes that are legally prohibited, or could put WMF staff, contributors or readers at risk.
    • Wishes that would reduce accessibility.
    • Wishes that break with prior community consensus.
    • Wishes that go against the Founding principles .
    • Wishes that would require vast amounts of resources that are unambiguously out of proportion to the benefits the wish would bring.
    • Wishes that are meant as trolling, spam, or are on topics beyond technical wishes.

However, we would not decline a wish only because it’s large in size or because the relevant WMF team already has different plans. In those cases it is important to understand the vote count prior to determining whether or where the wish could fit onto a roadmap.

For each wish, someone from the working group will publicly note the reason for declining it. The goal of this exercise would be to identify that a wish-as-submitted is not going to be possible, and try to discuss with the wish submitter to find a feasible path for the wish. If there isn’t such a path, then the wish may be declined.

Updated!

One important change to call out for this iteration is that we specifically removed “wishes that undo previous work”, “wishes that provide a positive impact for one set of users and a significant impact for others”, “wishes where many support them but many likely oppose them” from this list. Rather than considering declining them during triage, the working group will add trade-offs to the wish, so that the community has all necessary information when deciding on what route to go by casting their vote. I still believe that it is important that any wishes we know for sure wouldn’t get worked on (as per updated list above) are removed before volunteers start voting to make vote count as powerful as possible in determining how wishes should get prioritized.

Updated! Wish Statuses

We heard your feedback that the previous status labels were confusing and too corporate. Below is a new set of labels we think will work better. Please speak up if you still find any of them confusing or misleading.

  • Proposed wish: All wishes come in with this status. Following triage, this status will again be used for all wishes that have not been prioritized or declined and are not well suited for community development.
  • Needs clarification: This wish requires additional clarification and context from the community, and the working group will be pursuing it with the wish submitter and potentially others interested in the wish.
  • Declined: The wish falls within the reasons for removal and therefore cannot be actioned by WMF and is not recommended for a volunteer to implement.
  • Help welcome: Wishes that have not been prioritized by the WMF due to vote count, or have not yet been voted on, but are specifically well suited for the community to pick up.
  • Prioritized by WMF: The wish has been prioritized by WMF for the current or upcoming fiscal year as a result of the wishlist vote, but work has not yet started. The description on the talk page should indicate when it’s prioritized for, i.e. which quarter or fiscal year. Wishes that are prioritized by community members or affiliates but not WMF should not use this status. They should move directly to “in progress” when work begins.
  • In progress: Work is in progress on the wish, or current work is inspired by needs articulated in the wish. Wishes that get done by the community or affiliates should also get this status once they are in progress. If the WMF is conducting experiments or research into the feasibility and impact of this wish, the wish should still be marked as “in progress”, with details about the experiment or research included in the custom response on the wish page.
  • Done: Wish has been fulfilled explicitly, or aspects of it are sufficiently addressed by alternative solutions, as described in the wish prior to the vote. Details about how the wish was completed should be included in the custom response on the wish page, including if the wish was completed by a volunteer.

Stage 2: Voting

Following triage, there will be an open voting period, advertised with banners across Wikimedia projects. The following rules will govern voting (these are roughly the same as how voting worked early in the wishlist’s existence):

  • Votes are cast on individual wishes, not on groups or categories of wishes.
  • Voters will be able to support a wish by clicking the “Support wish” button as in the last iteration of the wishlist.
  • Updated! Opposing comments can be added by commenting on the Talk page of the wish.
  • All logged-in Wikimedia users may vote, including users whose home wiki operates its own wishlist (such as communities served by Wikimedia Deutschland). Participation in a local wishlist process does not exclude a contributor from also participating in the global Wishlist. Temp Accounts are excluded.
  • There is no limit to the number of votes per volunteer, but each volunteer can only vote for each wish once.

Stage 3: Post-vote

Prioritization should be in the hands of the community via the votes, meaning the votes are what prioritize the wishes. After sorting wishes by vote count, the Foundation will work through the list to determine the specific set of wishes that we’ll plan to work on.

We want to make sure that smaller and sister projects also get attention, so, each wish would be categorized into one of three project families:

  • Large Wikipedias or covering all wikis
  • Small and medium-sized Wikipedias
  • Sister projects, including Commons, Wikidata, Wikisource, and Wiktionary

Once sorted by project family, we would look at top voted wishes per family to see if any wishes with high votes in smaller projects should be pulled in alongside top voted wishes from larger wikis, for example if a wish for a small community has a disproportionate impact. We understand this is imperfect but we also didn’t find a way to solve it all through the feedback we received. For that reason, we will try this version out this first time to keep it simple. We can learn from this approach and make changes once we know what did or did not work well and try out something else next year.

Reasons other than moving wishes up from a different project family that could prompt us to not entirely follow the vote count are, for example:

  • Multiple top voted wishes require the same team's expertise. For example, if two top-voted wishes are both large wishes that require the Editing team, it may not be possible to do both.
  • As mentioned back in the Triage section, we're going to indicate when wishes don't look like there can be enough resources, but allow voting on them anyway to make sure we understand how important the wish is for the community. If we don’t have the resources to fulfill the wish, we may have to decline it at this stage and we will include a clear explanation for why.
  • Determining whether to accomplish a smaller set of large wishes or a larger set of smaller wishes.

Updated!

Reasons that would NOT be enough for declining a wish:

  • Teams need to change their plans: We know and expect that this process will result in work that we don’t already plan on doing.
  • Wishes don’t align with our annual plan / goals: Again, we expect to work on things that otherwise would not have been prioritized, meaning we will very likely work on wishes that do not contribute to meeting our targets.

For any changes we would make to the order of the list, such as to prioritize a lower vote count wish from a smaller project, the WMF would provide transparent reasoning prior to implementation. The working group will be invited to consult in this process as well. After that, the community will be asked to provide feedback on the final list prior to us getting started on the work.

Stage 4: Implementation

  • Implementation of wishes and iteration of the process based on feedback from this cycle will be coordinated through the Wishlist Program, led by the Lead Program Manager we’re currently hiring and executed by the various WMF teams with the required subject matter expertise.
  • The new wish submission period for the next voting cycle begins once wishes from the current cycle have been prioritized. The new wishes can be submitted year round until the next voting period takes place.
  • If top voted wishes are for large audiences that do not typically participate in the wishlist (like readers or new editors), WMF may pursue research and concept testing of the idea before deciding to build further. This is the same standard applied internally to our own feature ideas for these audiences. It’s possible that in doing the research and testing, we discover that the wish won’t have a positive impact. We would then talk with the people who wrote and voted for the wish about those findings and what to do next.
  • Updated! After looking at successful wish years (thanks to @Barkeep49 for the suggestion) we determined that we can commit to accomplishing something like 2-5 Small, 2-5 Medium, and 1-2 L or 1XL wishes. Here is the breakdown for the years we looked at:

Note that we’re unable to give an exact wish count, because that depends on the wishes submitted each year. For example, if all top voted wishes are small or medium, we may only do small and medium wishes (but more of them!). If the top voted wish is XL, we would be able to deliver a few small and medium wishes as well, but we would likely not be able to commit to 2 XL wishes in a year (see definitions for sizes under Wish triage activities).

Potential timeline

For this year’s cycle, we plan to have the wish submission period in late October/early November and the triage process completed by late November. To respect the end-of-year holiday season, voting would happen in early to mid January. Prior to finalizing the list of wishes, it will be posted on meta in early February for community feedback. The goal is to have a list of wishes ready for our annual planning process beginning in February 2027 to inform our plans for the 2027/28 fiscal year (July 2027 through June 2028). We also want this first vote to prioritize wish work for the final months of the current fiscal year (so through June 2027), so that wish work can reflect community priorities as soon as possible.

Keberlanjutan Daftar Harapan Komunitas

Halo, perkenalkan nama saya Sonja dan saya memimpin beberapa tim di Wikimedia Foundation yang akan mengambil alih proses kerja dari Daftar Harapan Komunitas. Seperti yang mungkin Anda ketahui, Daftar Harapan Komunitas (Community Wishlist) bermula sebagai proses tahunan yakni kontributor Wikimedia mengirimkan dan menentukan ide untuk memperbarui pengalaman dalam berkontribusi di situs web Proyek Wikimedia. Setelah melalui proses pemilihan, maka tim dari Wikimedia Foundation akan berusaha untuk mengerjakan dan mengimplementasikan ide (yang telah dipilih) tersebut. Beberapa tahun terakhir, proses di balik alur kerja daftar harapan telah diubah, serta kami mendengar dari Anda bahwa hal tersebut tidak memenuhi kebutuhan komunitas. Maka dari itu, Wikimedia Foundation bersama dengan kontributor Wikimedia sedang merancang alur kerja daftar harapan yang baru agar lebih transparan. Saya mengusulkan kepada komunitas terkait tiga tahapan berikut:

  • Tahap pengelompokan: yakni bagaimana permohonan dikelompokkan dan disaring sebelum masuk ke tahap pemungutan suara.
  • Tahap pemungutan suara: termasuk siapa saja yang berhak ikut pemungutan suara, serta menyusun bagaimana prosesnya berlangsung.
  • Tahap pasca pemungutan suara: termasuk mengutamakan prinsip keadilan terkait proyek yang diprioritaskan.

Setelah membaca usulan di atas, kami mengharapkan masukan Anda perihal apakah ini akan berhasil atau ada cara lain yang lebih sesuai. Pada tahap ini dimaksudkan untuk langkah awal dalam mencoba proses yang baru, serta akan lebih banyak masukan selama ini berlangsung. Semoga kita sama-sama bisa menentukan dan menemukan proses yang sesuai untuk diterapkan pada tahun mendatang (dan seterusnya).

Tahap pertama: pengelompokan

Meskipun daftar harapan akan terus terbuka selama setahun penuh, nantinya akan ada pengumuman terbuka pada 2 minggu terakhir di bulan Oktober atau November agar kontributor mengirimkan permohonannya. Setelah itu, akan ada kelompok kerja yang akan menyaring permohonan yang masuk. Kelompok kerja ini beranggotakan kontributor yang paham akan alur kerja daftar permohonan, kontributor MediaWiki, dan staf dari Wikimedia Foundation:

  • Anggota komunitas atau kontributor (kurang lebih sekitar 4 atau 5 orang):
    • Berasal dari Wikipedia skala kecil dan menengah.
    • Berasal dari Wikipedia skala besar.
    • Berasal dari proyek kerabat (seperti: Wikikamus, Wikisumber, Wikimedia Commons, Wikidata, dsb.)
  • Staf Wikimedia Foundation yang akan menangani permohonan:
    • Manajer produk dan rekayasawan (engineers) dari tim terkait seperti Editing, Moderator Tools, PSI, Readers & Apps, dan Content Transform.
    • Tim Movement Communications.

Aktivitas

Kelompok kerja akan aktif setahun sekali pada bulan November selama 2-4 minggu, yakni pada saat permohonan masuk dan pemungutan suara. Mereka akan berfokus pada:

  • Menggabungkan permohonan ganda: permohonan yang mirip akan diidentifikasi dan digabungkan dengan permohonan yang sudah ada, serta kedua (atau lebih) permohonan tersebut akan dipertahankan sebagai rujukan.
  • Perkiraan kerja tahap awal: kelompok kerja akan memberikan perkiraan kerja untuk setiap permohonan (seperti: sangat kecil, kecil, sedang, besar, dan sangat besar). Perkiraan ini bersifat relatif, bukan sesuatu yang mutlak. Pemberian perkiraan ini dipertimbangkan berdasarkan seberapa banyak usaha yang diperlukan apabila dibandingkan dengan permohonan lainnya, serta bukan komitmen untuk waktu pengerjaannya.
  • Penyempurnaan dan klarifikasi: permohonan akan dihubungkan dengan tiket Phabricator terkait, hasil kerja sebelumnya, atau permohonan yang sudah ada. Anggota kelompok kerja akan bertanya kepada pemohon untuk memperjelas maksud dari permohonan tersebut jika diperlukan. Selain itu, kelompok kerja akan memberikan konteks mengapa suatu permohonan tidak dikerjakan sebelumnya. Hal ini bertujuan untuk memperjelas dampak yang ditimbulkan dari permohonan tersebut.
  • Penggabungan dan pengelompokan skala besar: apabila beberapa permohonan meminta hal yang kurang lebih sama, maka kelompok kerja mungkin akan menggabungkan dan mengelompokkannya dalam satu permohonan dengan memberikan keterangan (misalnya: "beberapa permohonan ini pada dasarnya meminta sistem pengecekan penyuntingan"). Semua permohonan tersebut akan tetap tersedia dan diatribusikan, serta permohonan ganda akan ditutup jika memungkinkan.
  • Permohonan yang tidak dilanjutkan: pada saat daftar harapan komunitas belum dibuka selama setahun penuh, maka permohonan yang tak dipilih tidak akan dilanjutkan pada tahun berikutnya. Hal ini dilakukan agar semua yang kami kerjakan bisa terwujud. Kami menyarankan untuk kembali ke struktur ini, yaitu dengan kata lain hanya permohonan baru yang bisa masuk ke tahap selanjutnya. Permohonan dari tahun sebelumnya yang tidak dilengkapi harus dikirimkan ulang apabila bermanfaat bagi kontributor lainnya. Sebagai catatan, pemungutan suara pada tahun sebelumnya tidak dihitung. Namun, pada masa pemungutan suara yang pertama di bulan Januari tahun depan akan menyertakan permohonan yang sudah ada sebelumnya.
  • Penilaian dampak dan potensi: apabila suatu permohonan yang berdampak pada alur kerja komunitas akan diterapkan, maka kami akan memaparkan dampak yang akan ditimbulkan dari permohonan tersebut. Sementara, apabila suatu permohonan memiliki potensi, maka kelompok kerja akan menambahkan informasi potensi dan manfaat agar komunitas bisa mempertimbangkannya pada saat pemungutan suara.
    • Contoh: tim dari Site Reliability akan menerapkan permohonan tersebut. Namun, ini akan berdampak pada kinerja dari deteksi akun bot secara masif yang menimbulkan risiko. Informasi ini akan ditambahkan ke permohonan agar menjadi bahan pertimbangan komunitas.
  • Penghapusan permohonan: suatu permohonan akan dihapus apabila masuk dalam kriteria berikut:
    • Permohonan yang dilarang secara hukum atau berpotensi membahayakan kontributor, pembaca, maupun staf Wikimedia Foundation.
    • Permohonan untuk membatalkan proyek sebelumnya atau menghambat proyek yang sedang berlangsung. Meskipun begitu, permohonan ini bisa menjadi titik awal dalam melakukan diskusi dengan komunitas.
      • Contoh: suatu permohonan untuk memperbarui wisaya (wizard) artikel di Wikipedia bahasa Inggris agar ramah pengguna baru, tetapi di permohonannya tertulis agar mempertahankan elemen menyunting secara terbuka di wisaya tersebut. Pada saat yang bersamaan, kami sedang mengerjakan fitur baru agar mempermudah pengguna baru dalam membuat artikel. Dua pendekatan ini saling tumpang tindih dan membutuhkan diskusi lebih lanjut.
      • Contoh: suatu permohonan untuk menonaktifkan Visual Editor. Kami akan menolak permohonan ini dengan alasan sebagai berikut: meskipun beberapa kontributor menginginkan hal ini, banyak kontributor yang tidak mengharapkan permohonan ini diterapkan. Selain itu, banyak proyek yang kami kerjakan menggunakan Visual Editor (seperti Periksa Suntingan). Apabila kami menyetujui permohonan ini, maka akan menghilangkan kerja keras tim (dan anggota komunitas) yang membantu menyempurnakan Visual Editor sejak dulu, kini, dan yang akan datang.
    • Permohonan dengan usulan penambahan dan/atau perubahan fitur yang membutuhkan konsensus komunitas. Contoh: suatu permohonan yang banyak mendapat dukungan, tetapi banyak juga yang menolaknya.
    • Permohonan yang menguntungkan salah satu pihak dan merugikan pihak lain. Contoh: suatu permohonan untuk memberikan dampak positif bagi kontributor berpengalaman, tetapi kontributor baru justru merasakan dampak negatifnya.
    • Permohonan yang ditujukan untuk promosi, trolling, atau di luar topik secara teknis.

Namun, kami tidak dapat menolak permohonan karena skalanya sangat besar atau tim yang ada di Wikimedia Foundation memiliki rencana lain. Dalam kasus ini, kami hanya melihat seberapa banyak suara yang masuk (pada masa pemungutan suara) untuk menentukan arah kerja kami ke depannya.

Untuk setiap permohonan, seseorang dari kelompok kerja akan memberikan alasan penolakan permohonan tersebut. Ini bertujuan untuk mengidentifikasi apakah permohonan itu tidak memungkinkan, serta berdiskusi kepada pemohon agar menjelaskan secara rinci permohonan tersebut. Apabila masih tidak membantu, maka permohonan akan ditolak. Saya berpikir ini penting untuk menentukan permohonan apa saja yang tidak akan dilanjutkan sebelum masa pemungutan suara berlangsung, serta menjelaskan permohonan yang harus diutamakan.

Discuss

Status labels

I'm also interested in hearing people's thoughts about status labels that would be used during the triage process, and their definitions. Here is what we're thinking about for English (translations would have to follow later, likely in collaboration with the community):

  • Needs clarification: This wish requires additional clarification and context from the community.
  • Declined: The wish cannot be actioned by WMF and is not recommended for a volunteer.
  • Patch welcome: Wishes that have not been prioritized by the WMF due to vote count, but are specifically well suited for the community to pick up.
  • Prioritized by WMF: The wish has been prioritized by WMF for the current or upcoming fiscal year as a result of the wishlist vote, but work has not yet started. The description on the talk page should indicate when it’s prioritized for, i.e. which quarter or fiscal year.
  • In progress: Work is in progress on the wish, or current work is inspired by needs articulated in the wish. Wishes that get done by the community or affiliates should also get this status once they are in progress.
  • Done: Wish has been fulfilled explicitly, or aspects of it are sufficiently addressed by alternative solutions. Details about how the wish was completed should be included in the custom response on the wish page, including if the wish was completed by a volunteer or an affiliate and whether the wish was completed as part of a larger effort.
  • (NO STATUS): Everything else. All wishes come in with no status. Following triage, this status will again be used for all wishes that have not been prioritized or declined and are not well suited for community patches.

Discuss

Tahap kedua: pemungutan suara

Setelah tahap pengelompokan, akan berlangsung masa pemungutan suara yang diumumkan melalui panji (banner) di seluruh proyek Wikimedia. Aturan pemungutan suara berikut akan berlaku (ini kurang lebih sama dengan pemungutan suara yang telah berlangsung):

  • Suara hanya berlaku untuk permohonan secara tunggal, bukan secara kumpulan atau kategori permohonan.
  • Semua pengguna yang memiliki akun di proyek Wikimedia dapat memberikan suaranya, termasuk wiki yang menyelenggarakan daftar harapan secara mandiri (seperti komunitas yang dikelola oleh Wikimedia Deutschland). Pengguna tidak masuk log atau akun sementara tidak diizinkan untuk memberikan suara.
  • Tidak ada batasan jumlah suara per pengguna, tetapi setiap pengguna hanya dapat memberikan satu suara di setiap permohonan.

Discuss

Tahap ketiga: pasca pemungutan suara

Penyusunan prioritas permohonan harus berada di tangan komunitas melalui pemungutan suara. Setelah mengurutkan permohonan berdasarkan jumlah suara, tim Wikimedia Foundation akan menyusun daftar kerja secara spesifik untuk dikerjakan.

Kami ingin memastikan bahwa proyek skala kecil dan situs kerabat juga mendapatkan perhatian, jadi setiap permohonan akan dikelompokkan dalam tiga keluarga proyek:

  • Wikipedia dan wiki skala besar
  • Wikipedia skala kecil dan menengah
  • Situs web kerabat (seperti Wikikamus, Wikikutip, dsb.)

Setelah diurutkan, kami akan melihat permohonan dengan suara tertinggi di setiap keluarga proyek. Apabila terdapat permohonan dengan suara tertinggi di proyek skala kecil, maka harus diambil bersama dengan permohonan suara tertinggi di proyek skala besar.

Ada kalanya kami tidak dapat sepenuhnya memilih permohonan berdasarkan suara terbanyak, yakni:

  • Beberapa permohonan dengan suara terbanyak membutuhkan keahlian dari tim yang sama. Contoh: apabila terdapat dua permohonan tertinggi yang memerlukan tim dari Editing, maka tidak mungkin untuk melakukan keduanya.
  • Menentukan untuk memenuhi beberapa permohonan dalam skala besar, atau banyak permohonan dalam skala kecil.

Sejujurnya, kami menyadari bahwa proses ini akan menghasilkan rencana kerja yang tidak sesuai dan tim terkait harus mengganti alur kerjanya. Maka dari itu, kami tidak akan menolak permohonan dengan mudah karena alasan di atas. Terkait perubahan yang akan dilakukan, seperti mengutamakan permohonan dengan suara paling sedikit dari proyek skala kecil, maka Wikimedia Foundation akan memberikan alasan kepada komunitas secara transparan. Pada akhirnya, komunitas diminta untuk memberikan masukan daftar kerja akhir sebelum kami mengerjakannya.

Discuss

Tahap keempat: implementasi

  • Implementasi permohonan, berdasarkan masukan dari komunitas, pada tahap ini akan dikoordinasikan melalui Program Daftar Harapan yang dipimpin oleh manajer program dari tim di Wikimedia Foundation.
  • Periode pengiriman permohonan baru untuk siklus pemilihan selanjutnya dapat dimulai jika permohonan pada saat ini sudah diprioritaskan.
  • Apabila permohonan dengan suara terbanyak akan berdampak pada pengguna yang tidak ikut serta di Daftar Harapan Komunitas (seperti pembaca dan pengguna baru), maka Wikimedia Foundation perlu melakukan penelitian lebih dalam sebelum menerapkannya. Selama proses penelitian dan uji coba, sangat memungkinkan permohonan tersebut tidak berdampak positif. Jika ini terjadi, kami akan berdiskusi dengan pemohon untuk menentukan langkah selanjutnya.

Discuss

Rencana linimasa

Untuk siklus tahun ini, kami berencana untuk mengumumkan masa pengiriman permohonan pada akhir Oktober atau awal November, serta proses pengelompokan akan selesai pada akhir November. Agar tidak mengganggu masa liburan akhir tahun, sesi pemungutan suara akan berlangsung selama awal hingga pertengahan Januari. Sebelum menyelesaikan daftar harapan komunitas, maka kami akan menerbitkannya di Meta-wiki pada awal Februari untuk masukan dari komunitas. Kami memiliki tujuan agar daftar harapan komunitas dapat rampung pada masa perencanaan (Februari 2027), serta mengumumkannya dalam rencana tahun fiskal 2027/2028 (Juli 2027 hingga Juni 2028). Kami juga memprioritaskan permohonan pada bulan terakhir tahun fiskal saat ini (hingga Juni 2027), sehingga kami dapat berfokus untuk mengerjakannya secepat mungkin.

Discuss


Pertanyaan untuk Anda sebagai anggota komunitas

Kami tertarik untuk mengetahui pendapat Anda terkait pertanyaan berikut di halaman pembicaraan, tetapi masukan dan/atau pendapat lainnya juga diperbolehkan.

  • Apakah dengan membagi tiga proyek utama (Wikipedia skala besar, kecil dan menengah, serta proyek kerabat) adalah hal yang tepat agar seluruh komunitas terwakilkan? Atau ada cara lain yang lebih sesuai dan pantas?
    Discuss
  • Proposal ini bertujuan untuk menyeimbangkan dua hal berikut: "memastikan Wikimedia Foundation dapat memenuhi permintaan yang telah ditentukan komunitas" dengan "keterbatasan terkait apa yang dapat diwujudkan secara teknis atau sesuai dengan kenyataan". Apakah rencana terkait "penghapusan permohonan" dan "pasca pemungutan suara" sudah sesuai menurut Anda?
    Discuss
  • Kami mengetahui bahwa persyaratan terkait permohonan dari tahun sebelumnya yang dikirimkan kembali akan menambah beban kerja komunitas. Namun, berdasarkan pengalaman kami, apabila tidak dibatasi maka beban kerja kami akan terus bertambah dan tidak terkendali. Menurut hemat Anda, apakah ada cara untuk mengurangi beban kerja komunitas terkait hal ini?
    Discuss
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist/Community_Wishlist_2027/id&oldid=31043606"