Community Wishlist Survey 2022/Larger suggestions/50 wishes

50 wishes

  • Problem: The wishlist system creates scarcity, making volunteers compete for solution to bugs that should be working without volunteer's need to ask for. Each year, only the 10 most voted are evaluated and, some of them, are declined despite the popular vote. This creates more frustration. Even those that are not declined after the vote, may be forgotten or even not done: 2021 1/10 done, 2020 2/5 done, 2019 4/10 done. In the last three years, 25 proposals were made, and only 7 of those are done. Most of the projects proposed here, discussed and voted by volunteers, investing [hundreds of] hours of volunteer time, are declined, postponed or never done. Only a minority (less than a third) of the projects may be done, and some of them are even proposed to be voted... the next year. This creates even more frustration. Why should we be here proposing or discussing something that we know won't be ever done?

    On the other side, we find that the Wikimedia Foundation has funds and budget. The WMF is in good financial shape, but delivers a really scarce part of their budget to solve serious infrastructure issues that can put all our other efforts at risk.

    Finally, most of the things that are asked here are not even wishes... but only asking for things to work, even things that were working but broke due to some change made by the WMF. Solving basic infrastructure issues shouldn't be something we ask for in [a scarce handful of] wishes, this should be solved by default, without users and volunteers noting that things are broken.

  • Proposed solution: Just implement the first 50 wishes [each year]. That would make thinks work.
  • Who would benefit: All the community and volunteers. All the readers, who are reading us in obsolete ways. All the free software environment, because we create more free resources.
  • More comments:
  • Phabricator tickets:
  • Proposer: Theklan (talk) 20:12, 10 January 2022 (UTC)[reply]


  • Wait... I thought all suggestions would be voted on "Support" or "Reject", and the Support's would be then be tried to tackle. Only 10 get selected per year?? --Enyavar (talk) 12:17, 11 January 2022 (UTC)[reply]
    Sort of, generally about 5-7 actually get actually completed. —TheDJ (talkcontribs) 13:34, 11 January 2022 (UTC)[reply]
    The real data is 7 done from the last 25 voted proposals. Theklan (talk) 16:07, 11 January 2022 (UTC)[reply]
  • I mean sure.. but realistically this is like asking the genie, as one of your 3 wishes, to give you 50 wishes. Sounds a bit unrealistic. I'd prefer more concrete proposals, like the 'x%' one on this page. —TheDJ (talkcontribs) 13:37, 11 January 2022 (UTC)[reply]
    Both can work together. Furthermore, the 1% is short. Theklan (talk) 16:08, 11 January 2022 (UTC)[reply]
  • I fully support the description of frustration and desperation this process produced. I was one of the most motivated promoter for Wiktionary community and our proposals increased year after year (in quantity and votes) to finally have one proposal that reached #5 in 2020 (the year dedicated to undersupported projects) but it was finally not done neither. So, I will just copy-past this proposal and not do any publicity for the process anymore. This is just a loss of time for any wikimedian from a small community. I know the Community Tech Team is really well informed of this issue and willing to improve the situation. Thanks a lot for all the job you do, really. I am not judging any decision you made about your priorities, you did what you can do, but it is not what is needed. I think this discussion about funding more people to challenge more issues is fundamental now, but it is also a choice of organization and I think more teams are needed to have product managers closer to the communities, and teams dedicated to each project rather than only team for transversal issues that do not adapt properly the new features to small communities. Noé (talk) 11:10, 12 January 2022 (UTC)[reply]
  • The wishlist process to date has been treated as a way of 'satisfying a few popular community needs', something nice to have on the fringes of development, rather than 'listening to the most active users and community developers to help prioritize where to tune / generalize / fix systems and pay down technical debt'. The top proposals may be a better source for the latter than the former. [The historical list of most-popular wishes covers a range of things, and is not just "most popular quality of life improvements" :) ]
Energy spent ensuring that wishes can be resolved effectively at the scale of a few dozen a year would likely be more impactful than many other current initiatives. Some of the wish-granting effort seems to go into overhead that might scale nicely if this were part of a thorough plan for refactoring codebases and related architecture, and the wishes simply helped determine which areas were tackled first. –SJ talk  23:30, 23 January 2022 (UTC)[reply]