Community Wishlist Survey 2023/Larger suggestions

Larger suggestions
30 proposals, 395 contributors, 842 support votes
The survey has closed. Thanks for your participation :)



Fix unified login to Wikidata and Commons

 B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: I often find I can switch to other Wikipedias and be logged in already, but when I switch to Commons or Wikidata, unified login is not working and my first edit is saved as an IP edit.
  • Proposed solution: Make unified login work consistently across Wikimedia projects.
  • Who would benefit: (i) Wikipedia editors who also make edits at Commons or Wikidata. (ii) Other editors who might want to trace edits by the first group.
  • More comments: I looked on Phabricator but could not see any existing ticket about this issue.
  • Phabricator tickets: T226797
  • Proposer: Fayenatic london (talk) 11:33, 2 February 2023 (UTC)Reply[reply]

Discussion

Voting

Add semantics of processes

 B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: Wikidata describes things, not knowledge.
  • Proposed solution: extend wikibase model to also contain sequences, transformations, actions and processes, like "add", "move", "remove", "rotate", "wait", "first, "second", "last"
  • Who would benefit: chemistry, cooking, BPMN, Process Management, robotics,
  • More comments: If wikidata wants to be a database for knowledge, we should not stop at objects (pizza) and properties (consists of dough, tomatoes and cheese). We should also add a capability to describe, HOW to build objects. Papers are available at: K. Agyapong-Kodua, Csaba Haraszkó, István Németh, "Recipe-based Integrated Semantic Product, Process, Resource (PPR) Digital Modelling Methodology", Procedia CIRP, Volume 17, 2014, Pages 112-117 or "Cooking with Semantics", Jon Malmaud, Brain and Cognitive Sciences, MIT, Cambridge, MA and Earl J. Wagner, Nancy Chang, Kevin Murphy, Google, Mountain View, MA, Proceedings of the ACL 2014 Workshop on Semantic Parsing, pages 33–38, Baltimore, Maryland USA, June 26, 2014, Association for Computational Linguistics.
  • Phabricator tickets:
  • Proposer: Michael Cieslik (talk) 21:31, 23 January 2023 (UTC)Reply[reply]

Discussion

Voting

Finalize Gadgets 2.0

 B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: It is not clear what the status of the Gadgets 2.0 project is. In the past, it was worked on, but it never made it to production.
  • Proposed solution: Spend some time on investigating what the status is and what still needs to be done, and then finish the project.
  • Who would benefit: Gadget maintainers.
  • More comments: Maybe running a feedback collection round will be necessary.
  • Phabricator tickets: phab:T31272
  • Proposer: Matěj Suchánek (talk) 10:47, 30 January 2023 (UTC)Reply[reply]

Discussion

  • Thanks for the proposal, we will move this to larger suggestions, which brings extra attention to other teams, as this proposal requires more work than we can do as a team within a quarter. KSiebert (WMF) (talk) 20:03, 30 January 2023 (UTC)Reply[reply]
    @KSiebert (WMF) could this be downscoped into something you feel more comfortable about? E.g. switching from MediaWiki:Gadgets-definition to the Gadget: namespace? (Although I'm not sure Gadgets 2.0 as a whole is that challenging to do within a quarter.) Tgr (talk) 00:38, 1 February 2023 (UTC)Reply[reply]
  • @Tgr: @Matěj Suchánek: We would like that, if Matěj agrees, it would be nice if you could collaboratively adjust the proposal text to be able to reduce scope and then we could move it back into it's appropriate column KSiebert (WMF) (talk) 19:35, 1 February 2023 (UTC)Reply[reply]
    I think @SD0001 was the last person to work in this area and @Krinkle has the widest perspective on gadgets work, so maybe they have insights on what would be a reasonably-scoped step. Tgr (talk) 20:26, 1 February 2023 (UTC)Reply[reply]
    No problem with reducing the scope. But since the status of the project is not clear, I am not sure what the next step could be. --Matěj Suchánek (talk) 08:54, 2 February 2023 (UTC)Reply[reply]
    AIUI what's missing from the original Gadgets 2.0 roadmap is these things:
    • migrating to the Gadgets namespace (this is the main chunk of the Gadgets 2.0 functionality, but it's mostly already done, just not enabled)
    • a nice UI for defining gadget properties (T31398) - which doesn't offer new functionality so I'm not sure if it's the best thing to direct limited development resources at
    • allow declaring i18n messages used by the gadget
    AIUI even the three together would be a relatively small amount of work.
    There is also ongoing work on user-namespace gadgets (T36958) which might only need some code review love (plus it needs the namespace migration). Tgr (talk) 06:44, 3 February 2023 (UTC)Reply[reply]

Voting

Improve speed at which InternetArchiveBot archives links

 B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: citations suffer linkrot and arent archived quickly enough
  • Proposed solution: have an automatic bot that archives links straight away that is built into the automatic citations bit
  • Who would benefit: everyone who uses citations
  • More comments: I already know that it is done automatically eventually, however, I feel that it is too slow
  • Phabricator tickets:
  • Proposer: HoHo3143 (talk) 22:28, 23 January 2023 (UTC)Reply[reply]

Discussion

  • I think an argument can be made that this would be an outstanding redundancy in times and places where news media and even academia may be an enemy of the state. Such a robust automatic backup could insure that versions of events and information is retained before a take down can occur. Not that it is necessarily overly common, but in an ever changing geopolitical landscape, there is a certain utility to automatic duplicates. Foxtrot620 (talk) 02:33, 24 January 2023 (UTC)Reply[reply]
  • @HoHo3143: I've retitled this to make it clearer and more general. I hope the new title accurately reflects your intention. Note that you can manually submit pages to have the InternetArchiveBot process them (not that that necessarily solves your issue, but it's a useful workaround). There are also other tools such as the Internet Archive's Wayback Machine browser extension which allow instance archiving of any page or URL. SWilson (WMF) (talk) 03:50, 24 January 2023 (UTC)Reply[reply]
    • May be there would be some tools to automatically archive pages to Internet Archive and add archiver link into the article. Thingofme (talk) 09:22, 24 January 2023 (UTC)Reply[reply]
      @HoHo3143 Pinging again in case the above question was missed. We're wondering if the manual archiving tool meets your needs, since it gives you a way to fetch archive URLs in real-time, should the bot have not processed recently enough.
      I worry "making InternetArchiveBot go faster" may be out of scope. The bot is wholly maintained by a volunteer, and from we understand it already edits essentially as quickly as it can. MusikAnimal (WMF) (talk) 21:42, 3 February 2023 (UTC)Reply[reply]
      Ok thank you for letting me know. There are large numbers of sources which haven't yet been archived so I thought why not suggest speeding it up. If this isn't possible as it is volunteer based, that is ok. HoHo3143 (talk) 04:25, 4 February 2023 (UTC)Reply[reply]
      @HoHo3143 I wouldn't say it's impossible because it's volunteer-based, rather it's just out of scope for our team since we know it to be a very massive codebase and the production setup is quite complex. We'd rely wholly on the volunteer assisting us. I'm pretty sure making it faster isn't an infrastructural issue (which seemingly is something we could help with), but I could be wrong. I just know reviewing the contributions, the bot already seems to go pretty dang fast. Maybe it could be ran as a second bot to go even faster. Let's just ping the maintainer and ask: @Cyberpower678 Do you have any thoughts on this? MusikAnimal (WMF) (talk) 03:05, 6 February 2023 (UTC)Reply[reply]
      Actually, there is an infrastructure issue. Cloud VPS was recently removed from rate limit exceptions and now the bot is being throttled by a webservice rate limit, not to be confused with the API rate limit. We've reached a scalability limit here. Of course, we are working on optimization to make it be more efficient with the production servers, but ultimately, IABot 3 is what will be the ultimate solution to scaling and speed. IABot 3 is not around the corner though, and is still in the planning and design stages. I agree, the bot is too slow as it stands right now. —CYBERPOWER (Chat) 17:09, 17 February 2023 (UTC)Reply[reply]

Voting

Dismantling of the annual Wishlist Survey system

 B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: From the top 10 proposals that came up from last year, the Tech team has completed a total of 0. From the top 10 that won in 2021, only 1. And in 2020, only 2 out 5 were fully resolved with success. We can track further back and the stats, unfortunately, get even worse. It is clear to me that, even though the good faith of this campaign, the outcome is failing. It makes the Wikimedia community to hope and participate in a demanding process that turns out to be unsustainable with the current human resources allocated by the WMF for the community-driven software development. Besides, even the responsible team for the Wishlist specifies that the voting ranking is not even the ultimate method to proceed...:
"Since 2021, we expressly do not commit to the top 10. Instead, we use a prioritization framework to help us ascertain what we can afford to do annually. It's far from perfect, but we believe it's a step up from the old "top 10" commitment that we used to have, which left a lot of wishes undone." (Extracted from a MusikAnimal (WMF) clarification on a talk discussion on the 23rd Jan 2023)
  • Proposed solution: To dismantle the annual Community Wishlist Survey and put it on hold until there is a clear governing direction of which is the expected outcome, who or how must get accountable when throughout the years most voted tasks are not completed, and which is the scalability that this idea can really assume.
  • Who would benefit: All the Wikimedia ecosystem. We could avoid the loss of volunteering time in thinking, defining, assessing, reading, and voting splendid ideas that seem to be doable but then end up in endless task lists for years. Some of them, even resumed when perhaps they have already become obsolete or not needed anymore in our technological global wave.
  • More comments: I place this idea in the anti-harassment section, not because I think the current situation represents a harassment towards the volunteers. But I do find that the drift of this process is starting to get somehow disrespectful with our public involvement. More accountability and transparency is needed to not disappoint or disengage our users, which is part of a sustainable transition towards Wikimedia Strategy 2030. I'd like that the responsible would take the courtesy to leave this proposal here as a respectful, reasoned, justified and realistic one. Thank you in advance.
  • Phabricator tickets:
  • Proposer: Xavier Dengra (MESSAGES) 19:03, 23 January 2023 (UTC)Reply[reply]

Discussion

  • Hey there, we are Archiving this proposal due to the nature of this ask not being technical. Dismantling the annual survey would require conversations between the Communities and the WMF and that is different in nature than what the Survey entails, which is to propose ideas for tools or improvement of a technical nature.

    As for the factual nature of the problem statements, we've completed 4 wishes so far from the 2022 wishlist overall, and are on track to complete 2 more from the top 10. Feel free to check out the status of the wishes in the Results table. As I am moving to the Archive, feel free to consult me in the Talk Page if you have any follow-up questions. Best, NRodriguez (WMF) (talk) 19:40, 23 January 2023 (UTC)Reply[reply]

    The archiving strikes me as draconian seeing wishes like "1%" and "50 wishes" were allowed in the "Larger suggestions" section last year. Nardog (talk) 20:01, 23 January 2023 (UTC)Reply[reply]
    Yes, and that was a mistake then, too. We allowed it, but "Larger suggestions" became really large, to the point that the voting gadget and mw:DiscussionTools failed work. My browser actually freezes when I try to load the page! For this reason we need to ensure everything that goes into voting is truly technical in nature, and actionable at least to some degree. Perhaps in the future if there's enough interest, we can create a new category dedicated to survey improvements and criticisms, but it's too late for that now.

    That said we definitely are not trying to suppress any opinions. We welcome all criticisms and feedback about the survey at Talk:Community Wishlist Survey. MusikAnimal (WMF) (talk) 21:14, 23 January 2023 (UTC)Reply[reply]

    Those "larger suggestions" were moved to "larger suggestions" before the voting, so no voting gadget failed to work. Furthermore, if the voting gadget breaks when too many people participates, then someone whould solve it. — The preceding unsigned comment was added by Theklan (talk) 21:48, 23 January 2023 (UTC)Reply[reply]
    I have now moved this proposal to the Larger suggestions as per the precedent demonstrated and the community consensus to move on with this proposal. --Base (talk) 22:14, 23 January 2023 (UTC) -Theklan (talk) 22:29, 23 January 2023 (UTC)Reply[reply]
    Thanks @Base. I don't know if @Xavier Dengra agrees, but un-archiving it is a good starting point for a discussion. -Theklan (talk) 22:29, 23 January 2023 (UTC)Reply[reply]
    Yes, that's the best move. At least it won't be intentionally hidden to the discussion page with the excuse of a bot nor that debates should be kept there (as far as I know, this whole campaign is about suggesting and debating). Thank you for committing to defend the right of expression and the precedents from last year, @Base. Xavier Dengra (MESSAGES) 07:45, 24 January 2023 (UTC)Reply[reply]
    Sorry, but I can't see which four proposals where completed. There is one in progress, one started but the Phab ticket is not closed, two not even started, then one "mostly being done" (so is not being done what it was asked and voted2"), then two more that didn't start, then another one that what was implemented was the opposite and the phab ticket is open, the 9th is in progress but not done and the 10th is in progress but seems stalled. So from the first 10 proposals 0 have been done. -Theklan (talk) 22:41, 23 January 2023 (UTC)Reply[reply]

I have made this table:

Projects Project status

2022

Better diff handling of paragraph splits
   In development
1%   Declined before voting. Second most voted proposal.
Notifications for user page edits
   In development
Show recent block history for IPs and ranges
   Not done
Tool that reviews new uploads for potential copyright violations
   Not done
Improve SVG rendering
   Not done
Allow filtering of WhatLinksHere to remove links from templates
   Not done
Automatic duplicate citation finder
   Not done
Select preview image
   Not done
Generate Audio for IPA
   In development
Enhanced Move Logs
   Not done

2021

Templates translation
   Not done
Warn when linking to disambiguation pages
   Done
Copy and paste from diffs
   Done
Live preview
   In development
Add sorting options in category pages
   Not done
Improve graphs and interactive content
   Not done
Multiple watchlists
   Not done
InternetArchiveBot for Wikidata
   Not done
Better diff handling of paragraph splits
   In development
Add filters to history pages
   Not done
  • Support. Maybe it is somehow reasonable. — 2dk (talk) 19:43, 23 January 2023 (UTC)Reply[reply]
  • Support for obvious reasons. The system is broken, and nothing has been done to solve it after one yerar. -Theklan (talk) 20:34, 23 January 2023 (UTC)Reply[reply]
  • Support. The Community Wishlist is a great tool for volunteers to make their voices heard, but unfortunately, it no longer yields tangible results. Running it every year will only cause the list of unfulfilled wishes to grow longer and longer. --Townie (talk) 21:47, 23 January 2023 (UTC)Reply[reply]
  • Looking at the 2022 wish board, I find it disheartening that my petition with forty votes has been ignored while others with fewer votes have been implemented.
Perhaps that is why the system must change or be dismantled. What is the point of voting then. Best, Galahad (sasageyo!)(esvoy) 23:57, 23 January 2023 (UTC)Reply[reply]
  • Support. As it stands, this is my first year participating in this process, as in prior years, I didn't even know it existed. It's disheartening to see lists like these, and while the plight of the foundation, and wider the volunteer driven nature of the project as a whole is noble, when the results are this ridiculous, one has to question why we bother holding the survey when surely the time it takes to execute it could be better spent working on the horrendous backlog. Further I posit that it is likely that we're asking the wrong people. As we are so fond of noting, the mere act of a single edit sets you apart from the large majority of users. Aren't the wants and needs of the readers as important to those of the builders? If were going to ask for suggestions like these, surely there should be an opportunity for contribution from the millions, (possibly) billions who rely on the Wiki on a consistent basis. I started editing Wikipedia as a kid, and I've watched it grow, only getting into serious editing in my High School years, and more so now as a postsecondary student. I feel that this projects failure is a symptom of a much wider problem, as many projects have become abandoned, and there project pages stand as unupdated ghost towns. We are stewards of knowledge. When we use our hands and minds to contribute to this, grandest of projects we are answering a higher call, and it's time to make sure that we are meeting that call, and that starts with making sure we aren't biting off more than we can chew; and from a outside perspective, this feels like that. Foxtrot620 (talk) 03:58, 24 January 2023 (UTC)Reply[reply]
  • Support as per nom. I'll add that given the resources available to WMF, such a poor result on past wishlists (and NPP) shows that the Foundation doesn't much care about the community, and this is just another exercise in distraction. What on earth is the point of the ridiculous size and extent of those funding campaigns, taken up in spite of community protest, if this is result? Ciridae (talk) 05:55, 24 January 2023 (UTC)Reply[reply]
  • Support. Indeed, it makes no sense to have a list of hundreds of proposals, thus dispersing the efforts of the developer's community. It would be much more effective to end with a list of 10-12 new features to work with. In any case, this actual format is not working, as results are crying out. --Robertgarrigos (talk) 07:26, 24 January 2023 (UTC)Reply[reply]
  • Support the existence of this discussion, and also the fine proposal by MusikAnimal to add "a new category dedicated to survey improvements and criticisms". In the past, new categories have been added after the process started, it is not an issue to add it now. Sure, it would have been better to gather more feedback during the year, but it is under attention now, so it is the right time to discuss it. Anyway, I repost my old proposals without any motivation, as I know this survey is useless. As an editor of Actualités du Wiktionnaire, monthly wikipress about French Wiktionary (with about 300 readers monthly), I will continue to ignore the process and not communicate at all about it. In the past, I spent hours and hours to engage my community to participate, but nothing positive came from it, so I will rather discourage people to participate now. Noé (talk) 09:37, 24 January 2023 (UTC)Reply[reply]
  • Support. The probability of success is far too low for my participation to be a worthwhile exercise. MER-C 20:47, 25 January 2023 (UTC)Reply[reply]
  • Note It should be interesting to note that, as stated here, the voting is only worth 1/4 of the final result. The other 3/4 of the results are based on decisions taken by a team in an opaque way. Is linke voting in an election where 25% of the Congress is chosen by the people and the other 75% appointed directly by the President. -Theklan (talk) 21:45, 25 January 2023 (UTC)Reply[reply]
I'd like to ask Theklan/Xavier Dengra and any other concerned community members how they forsee the proposed solution ("To dismantle the annual Community Wishlist Survey and put it on hold until there is a clear governing direction of which is the expected outcome, who or how must get accountable when throughout the years most voted tasks are not completed, and which is the scalability that this idea can really assume.") playing out? Namely, I'm interested in;
  • Who do you believe would define the "clear governing direction"? The community, or the WMF?
  • What do you think the "expected outcome" should be?
  • Who would be the best person/team to hold "accountab[ility]" for the wishlist?
  • What would they be "accountable" for?
  • Who would hold them "accountable", and how?
  • If you were in charge of the Community Wishlist Survey, what changes would you make?
As I noted at Talk:Community Wishlist Survey/Editions and projects, well reasoned criticism helps build a case for more time/resources/support — if we all share the goal of getting more community-requested improvements and tools implemented (an admirable goal, which I believe we all do share!), then we're in a really strong position to build on what the wishlist stands for and make things better for everyone — TheresNoTime (talk • they/them) 23:02, 25 January 2023 (UTC)Reply[reply]
You are right, it is always better to suggest options to make a better world. So, I think not everyone can write a good definition of an issue nor define the priorities for a specific community/project. It may be more efficient to have liaisons like the positions created a couple of years ago for the rebranding operation. The job I am think of here is product owner, i.e. people trained to summarize the needs and issues, working as translators between the communities and the WMF teams (dev but also communication, reading, outreach, mobile, etc.). And I consider this kind of position useful for each of the Wikimedian projects: Wikisource, Wiktionary, Wikiversity, Wikimedia Commons, Wikidata (well they already have this kind of people), Wikipedia and more. Then, those people could share their findings with the others and help each other to find similarities in the needs and to document their work to the Wikimedia Foundation board. Finally, an informed decision could be made, approved by the communities as they were really part of the process. It is not an extraordinary process, but it may please the communities and the dev team, as they may be able to have a better evaluation of the proposals and more feedback from the users in the way. Well, English is not my mother tongue, sorry if my explanation are unclear or seem unrespectful of the work made by the teams. I think volunteers and WMF members are doing a great job and eager to explore new solutions. Good luck with all this on-going process! Noé (talk) 01:08, 26 January 2023 (UTC)Reply[reply]
@Noé: Thank you for these comments, they're very insightful and I appreciate them   I like the idea of involving "people trained to summarize the needs and issues, working as translators between the communities and the WMF teams" — I know this is something that members of the community tech try very hard to do when they interact with wishes and help clarify intentions, but maybe this is something which could be considered in the future. As an example; do you think a "product owner" for fr.wiktionary should be a volunteer from the fr.wiktionary, or a dedicated member of WMF staff? — TheresNoTime (talk • they/them) 01:35, 26 January 2023 (UTC)Reply[reply]
Hi TheresNoTime 🙂 I agree, people from Community Tech are good guides to help the clarification of wishes, and they improve each year. It positively reminds me the assistance during grant process. But they arrive late in the process, and are not part of the communities. Well, I have to clarify something here. There is a narrative saying the Wikimedia Movement is one and unique, sharing one goal and one set of values and everyone is part of a movement. It is an oversimplification of the story. There is multiple communities with thousand movement, depending of projects and languages, most of them going in a similar direction, but with specific profile of individuals and specific visions. One example is about the functionalities of MediaWiki. The tool is made to write long segment of texts, not to manage data, align a picture scanned from a book with the transcript or build a structured dictionary. There is specific needs in order to display those type of content and to build them. WMF never investigated to improve MediaWiki in order to build a dictionary. In twenty years.
WMF structure is with dedicated teams for transversal needs, but they mostly solve issues raised by the majority, i.e. for Wikipedia, Wikimedia Commons and Wikidata. The peculiar needs of the other projects are always left behind, even when their idea may also improve Wikipedia (such as my proposal to have a script to add quotes from Wikisource like we add pictures from Wikimedia Commons). There is no vision for what a good Wiktionary could become, or what a better Wikisource could be.
Few years ago, I tried to explicit my proposal of having one referee/liaison/product owner for each project in Wikimedia Space. Sadly the forum was closed and I didn't find any other space to have this conversation. I think it is important to have dedicated peoples with at least three-years commitment, as the onboarding and acculturation could be long. One reason is multilingualism and distance, another is the quantity of teams in WMF staff to meet, with specific workflows. As a volunteer, I tried to animate a User Group for Wiktionaries, and it was not a success, for some reasons, including the lack of communication with WMF staff. Then, I got a job (in real life) as a product owner (turned product manager recently) and it led me to consider the lack of this kind of position in the WMF organization. I feel a clear governing direction must be based on a proper diagnostic, and this may take time to be established 🙂 Noé (talk) 09:44, 26 January 2023 (UTC)Reply[reply]
@Noé: I intend to read your response in detail and give it the attention it deserves before replying proper, but I just wanted to thank you again for engaging here on this topic — TheresNoTime (talk • they/them) 10:46, 26 January 2023 (UTC)Reply[reply]
There's no need for more bureaucracy or more intermediated liasons. There's need of a manager who will do their job (i.e. planning the job in order to get it done) and hiring developers to accomplish the wishes. Surely, asking volunteers to write, refine, discuss and approve wishes and *then*, planning how those wishes should be made is pretty abusive. -Theklan (talk) 10:16, 26 January 2023 (UTC)Reply[reply]
(Edit conflict.) @Theklan: CommTech's managers do a very good job, thank you — I'd kindly ask that you refrain from unsubstantiated claims to the contrary. Resourcing for Community Tech is one thing (and a thing which I believe much of the community would like to see increased), but the management of the finite resources currently available is second to none. I'd be keen to hear your thoughts on the questions I raised above — TheresNoTime (talk • they/them) 10:46, 26 January 2023 (UTC)Reply[reply]
Well, we have discrepancies on what a very good job means, then. For me, making 0/10 of the expected job is far from being a very good job. I have no doubts that they have plenty of other things to do, and they do them diligently. Because if managers do a great job, and every developer is commited with this, then the problem is elsewhere. I don't know how the WMF is organized, but we have to find [who/what team] is accountable for the failure. -Theklan (talk) 11:21, 26 January 2023 (UTC)Reply[reply]
Hey, Theklan, this is interesting, and I will try to explain why I disagree. Developers are one part of a process that include the idea, the definition of the task, evaluation of the technical environment and dependency, interface design, testing of prototypes with a diversity of profile (users, readers, reusers, etc.), graphic conception, and so on. I consider the step of definition to be a difficult task, as the MediaWiki environment is very old and complex, with layers of code unequally maintained. This is not a straight path from idea to coding, and there is a space to improve this workflow. Based on my experience with the wishlist survey this past years, I am quite sure volunteers can't refine wishes by republishing them years after years. Another process for refining and decision should be possible, and I think it should be with expert assistants 🙂 Noé (talk) 10:40, 26 January 2023 (UTC)Reply[reply]
Right. We have yet expert assistants. There are product managers, UX managers and many other managers. Is their job to build all the process from the idea to the done status. They are so good on that, that they even archive proposals before voting, without any research, because they know if they are possible within our framework. So we have expert people working on things. Not on wishes, obviously. But as they are asking here for wishes, we should expect that they are going to fulfill them, because there is a genie-lamp in the icon. -Theklan (talk) 11:23, 26 January 2023 (UTC)Reply[reply]
Let me disagree with you on this, @Noé. Wikipedians (volunteers) are the experts who edit day after within the Mediawiki system and know their needs and gaps of technology to keep doing their task greatly. Pretending to set up a process for them in which they, as a community, present a problem and a tech solution (later ratified and supported by other ideas and votes) to, afterward, hire someone to "reinterpret" their will is only a loss of money and probably the main “illness” that surrounds the WMF (prioritization on how allocate staffing budget). There are years of pending coding work to do with explicit, precise, extraordinary well-defined tickets both here (especially on the sister projects) and on Phabricator. What we need are investments in developers, not swelling those economic resources in positions that will not solve the real bottleneck: coding and solving tickets.
Regarding to @TheresNoTime: and trying to be the softest and respectful to your questions. I already spend so many hours of my volunteering time on thinking how to strategically improve the content and community resilience of the wikis in which I edit and the future of the Wikimedia language thematic organization that I belong to. And, additionally, part of this time is also dedicated to uncovering uncomfortable situations on Meta that I don't like -because I don't think they serve the community as they should (in this specific case, even struggling so that my reasoned proposal was not dumped after 5 minutes of posting it). I hope that you kindly understand that, within this proposal and after being so clear in the first summary, I am not elected as any councilor nor I am earning 10 times my current annual salary to be the one designing a strategic line on those questions for someone else on how accountability and outcome should be traced in a company (that I even do not believe in). Best. Xavier Dengra (MESSAGES) 11:00, 26 January 2023 (UTC)Reply[reply]

I Support this Xavier Dengra proposal. One may say that this is not the place to find the solution which, I believe, should be taken at higher levels of WMF. However, they must listen and understand that we are not talking about a technical problem or a technical way of doing the job, but about management. The most popular PRODUCT of the Wikimedia project is the Wikipedias. Its content, of course, but first of all its availability and access, the interface, the response time, the platforms on which it runs, etc. Content (quality, images, etc.) is the responsibility of the editors. But the interface technology (or any other layer of technology) is the responsibility of the development team, from the managers to the last programmer or server installer. We, from this space, give the technicians our ideas, suggestions or point of view. We don't want to say "how to organize your work". Then, if we did, you might understand that you should change your point of view, because your internal customers do not agree with the results received. Before you give me a quick answer, think about how other platforms manage their IT departments. Platforms, like our WP, with millions of daily transactions, with much more stressed environment than WP; think for instance, online stock market, social media, mapping apps used by thousands of APIs, etc. I don't know their methodology, it's not my job. But I am sure they are result oriented: matching functionalities, easier operation, better interface, short response time and of course no errors. Can developers discuss, disagree with the task and ask for more resources?. Yes, but only after doing your job well. Or maybe the real problem is team organization, team management, or team personnel. Try to solve your problems with our help, but not against us. Thanks, Amadalvarez (talk) 12:33, 27 January 2023 (UTC)Reply[reply]

  • Weak support: While I'm generally happy such a wishlist exists and look forward to it each year, its results haven't been that fulfilling. The way it is set up, the banner calling for proposals globally, the pre-proposals and then the list listing literally hundreds of them and the countless votes that flow in, makes you feel like big changes are about to come. Then from that long list, only a very small percentage of that list gets chosen, many of which are generally minor things (at least that's how they look from a "front-end POV") and from that small list only a handful of requests actually come into fruition, usually after enough time has passed that some of the proposers/voters have forgotten about them. This process kills the drive that the event itself tends to set up and I believe many users are left more or less with some confusion about it. I for one, having participated in the last 2-3 wishlists, have been left with some questions like "What happens with all what may be good proposals that don't get chosen? Do they just get forgotten? Wouldn't it be better if the majority of proposals were taken into consideration and at least evolved into phab tasks for any volunteer to take up? Sure anyone can open up phab tasks and anyone can volunteer in solving them but if that is so why even have such a wishlist? Personally I've had better luck at w:en:WP:US/R and then evolving such scripts in gadgets. That said, I do understand that the wishlist is a good way to bridge the gap between volunteer work/requests and paid teams work/updates but I think it needs to change some of its factors. Either it should tone down it's "hype" or it should be more responsive to the hundreds of requests it opens itself up to. Or at least to those 10 lucky ones that get selected. - Klein Muçi (talk) 17:21, 27 January 2023 (UTC)Reply[reply]
  • Oppose: Removing the most visible process for community input on technical issues? No, thank you. However, I think the results of the survey need to be considered by all Product teams at the WMF, not just the Community Tech Team. It does not make sense that the Top 2 proposal in 2022 is still flagged as Lowest priority in Phabricator. Even if something is not selected by Community Team, results should be a strong signal for priorization at WMF. MarioGom (talk) 17:00, 28 January 2023 (UTC)Reply[reply]

Response from Selena Deckelmann, CPTO of the Wikimedia Foundation

Hi Everyone!

My name is Selena Deckelmann and I joined the Wikimedia Foundation about six months ago as the Chief Product and Technology Officer. Since then, I’ve been busy trying to learn fast from staff and contributors what’s working well and what needs to change. The Community Wishlist process has been high on that list and I wanted to provide context and accountability for why we decided to complete this year’s Wishlist, and use this feedback to change things next year.

The Community Tech team raised with me concerns about the current survey system, including their worry about volunteer time spent on the Wishlist to submit similar, ungranted wishes every year. Their proposal to me was that we should only hold the Wishlist every two years. I have not yet observed a Wishlist process and was concerned that a 2-year cycle might not solve the root cause issues being raised as these need more than just the Community Tech team to solve sustainably. I asked the team to proceed for this year, in part so I could learn from the process and support them more directly in making improvements for the future.

We started by asking how all of the Foundation’s Product and Technology teams think about the Wishlist process, and got a lot of interest from staff who took time in December to contribute to a week-long Wishathon. As several people have noted, this Wishathon process meant that engineers and product folks worked on areas that were familiar to them, and where they could make a meaningful difference. But this didn’t necessarily line up to the ranked order list from the 2022 Community Wishlist. I can see that in order to “grant” wishes, there are a number of steps needed to generate clear software requirements, establish criteria for evaluating whether or not we are solving the right problems, and then how we might ship the changes to wikis. I agree that this needs more clear governing direction about the outcomes, accountability, and future scalability. I plan to make this a topic for resolution in our planning processes underway now, with a report back to you after the start of our next fiscal year in July.

Much of our current planning is looking harder at prioritizing contributor-driven requests, like for PageTriage. After consultation with community members and staff, we determined that allocating time to PageTriage would likely be beneficial to multiple wikis, and in alignment with our Foundation and department goals this year. This kind of prioritization process is critical for giving direction to our teams, and included several consultation meetings with volunteers, an evaluation of current work on the plate of several teams, and then a decision by me to move this particular priority forward. I don’t think this is the most efficient process for community members or the Foundation, so I am actively looking for your recommendations on how we can do this at scale across our 803 projects. I know this is critical to creating more useful, efficient and transparent processes for us all - please let me know if you have any ideas or suggestions. — The preceding unsigned comment was added by SDeckelmann-WMF (talk) 01:21, 27 January 2023 (UTC)Reply[reply]

@SDeckelmann-WMF, Hi, thanks for the extended answer! It seems to me that the main solution to the problem will still be an assessment of the current debt and an attempt to understand how many employees it will take to close it in the next 1/2/5/10 years. Most of the proposals from our surveys are such dinosaurs that were needed 10 years ago, but at the same time no one was working on these dinosaurs, because the corresponding pieces of code simply did not have support.
There is one more idea, the participants are often divided, and some of the "necessary" ideas simply do not appear. Perhaps within the framework of this survey, a separate section "Wishlist from developers" is needed, where developers offer:
1. Your personal ideas
2. Ideas based on the results of community research, what gadgets they use, what modules. And which of these gadgets would be cool to move to the core.
This will help to understand how versatile ideas are presented and what actually happens with the technical part of the projects. Iniquity (talk) 22:12, 27 January 2023 (UTC)Reply[reply]
Wikimedia Foundation is known to have a CANCER. It seems that WMF are spending the money inappropriately and not concerning the editor's wishes and burying the Community wishes for previous years. Now, after a announcement that CWS will be organized once every two years for C.Tech team to do the wishes, I felt much more relief but there are a lot of backlog over the needed tools to develop over the last 5 years, within the control of WMF over Wikipedia and the Foundation has been separating away from the volunteer editors for some time, and Editors of enwiki have been disagreeing about the new Vector 2022 skin, and yet WMF still ignores our community consensus... Thingofme (talk) 15:56, 1 February 2023 (UTC)Reply[reply]
I'm not sure they have cancer. There are some great commands like the Growth team. It's just that the software development and support department has absolutely no plan to improve this software. This is bad. Iniquity (talk) 20:13, 1 February 2023 (UTC)Reply[reply]
They are ignoring user needs and do not listen to editors of Wikipedia, who have formed a large society for now. Thingofme (talk) 02:28, 4 February 2023 (UTC)Reply[reply]
Thanks @SDeckelmann-WMF for the insights. I need to declare that my point of view is that we are getting more obsolete every year, with more issues to solve each year in the queue. This is my POV as wikimedian and instructor of students in our education program. From my point of view, there are two solutions to the dilemma we are facing, and deciding which is the solution should be guiding our next steps:
  1. We can aknowledge that the wishlist system was a good idea, but it have failed to deliver. We can create a relate in which every year the team makes something, but the reality is hard, and numbers are numbers. Only 7 of the most voted 35 wishes were awarded in the last 4 years, and some of them in a sum-optimal way, with tools that only work in some very specific conditions. The system is not working, and is not going to work better in the future, so creating scarcity and promotig a wishlist that is not going to work is not the best idea. The WMF can't spend more money on this, and solving issues should be done by the community. This would need a better path for volunteers in order to make such contributions.
  2. We can aknowledge that the wishlist system is a good idea, it have failed to deliver, but changes can be made to fulfill the wishes and make our product better. This would need a team, probably larger than what we have, more money to invest on hiring people with coding skills and more time for this functions, eventually having a full-time dedicated team unblocking the huge tech debt, and making our product the best one... before 2030. This will create other problems with the community, because hiring more people is not always welcome, and some of the new products will have opposition.
Is up to the leadership to decide which path is better. Theklan (talk) 16:32, 2 February 2023 (UTC)Reply[reply]
So what's the hold-up with dark mode? It is a perennial request and something that most other major websites have already done.mw:Skin:Citizen could be made available for logged-in users. Example. Flounder ceo (talk) 17:12, 2 February 2023 (UTC)Reply[reply]
@Flounder ceo Thanks for your question. I was also interested in why when I started at the Foundation, and the answer is surprisingly complex. One blocking issue was the size of our caches ballooning due to bigger CSS files, and there's been recent work done that would make it possible to provide dark mode for most of the website without doubling cache size. The next issue is that we have a vast ecosystem of gadgets, templates, user-generated content and extensions made by our many contributors, that have custom CSS. We don't currently have a system in place that integrates these with multiple "modes". As a result, many pages in dark mode would look hopelessly broken to readers. We're discussion options for managing this, but it will take some time to sort out. SDeckelmann-WMF (talk) 22:35, 3 February 2023 (UTC)Reply[reply]
Thank you for the explanation and it is good to see that you are working on it. Firefox has a great dark mode. I think the best way forward is making the Citizen skin available (opt-in only for logged in users, just like Monobook or Timeless) so that volunteers can begin to catch up. Waiting for the ecosystem to be ready otherwise just isn't working. The Wikipedia App already has a working dark mode. Another skin to be aware of is mw:Skin:DarkVector but it doesn't work with 1.39+. I don't completely understand the caching situation but my feeling is that if it is stifling important usability improvements, then it needs to be changed. Flounder ceo (talk) 22:30, 4 February 2023 (UTC)Reply[reply]
Hi Selena, You asked for comment.
  • Scalability and "in alignment with our Foundation and department goals this year.' ‘2 year cycle’ - This means that all change must be strategic, centralised, one size fits all, and Waterfall. It would also tends to encourage a very low risk mentality (avoidance of refactoring or modernising or change) , makes most changes unjustifiable in terms of costs, a reluctance to challenge current system architecture and past policies, increased difficulty for volunteer devs (changes must align with strategy), and poor stakeholder relations,
  • 803 Wikis'. It's not sustainable in terms of volunteers or systems, has been imposed by WMF, and has diffused wikipedias focus and stopped development on features that could be used in all WMF. To support it your will need about 2000 staff, but it is part of WMF branding/mission/metrics. The only group that comes close to this number are theBible translation societies

Currently there are 4 ways that wikipedia translations are consumed in terms of popularity.

  1. Google Knowledge panels
  2. Google auto translate tool
  3. The 803 Wikis .The vast majority of these are very small, have many outdated auto-translated articles, and have very few active editors. It is interesting to see how few articles are organically created there (especially by editors who only edit in that wiki), and what types of articles. Many of these wikis do not have the volunteer resources to paper over the wikimedia software and process limitation, to be a community, to detect scammers, and to remove bias. It is difficult for a reader to know which wikipedia the text was sourced from, so that cultural/political bias can be taken into account.
  4. Wikidata was going to allow translation of core data between Wikipedias to create unbiased articles, and fill info boxes. enWIkipedia is reluctant to use it because of missing references, reliability of sources, no update link with source data (single source of truth), and what happens when different wikipedias have different field values. I believe this also feeds into google knowledge panels. Wakelamp (talk) 07:48, 3 February 2023 (UTC)Reply[reply]
Hi SDeckelmann-WMF. Thanks so much for assigning software resources based on open letters (PageTriage, Commons), and for engaging with the communities on talk pages by making statements like you did in this section. These are both great steps towards improving community relations. I think you and the current executive team are good faith contributors and are doing great work. Please keep it up.
Here's a possible roadmap for CommTech and the wishlist:
  1. Refocus to getting the top 10 wishes worked on. The community spends a lot of energy lobbying for and voting on wishes. This energy gets us a fairly accurate picture of what the community wants. Comments on this talk page about top 10 wishes barely getting worked on are alarming, and should be taken seriously. It possibly indicates a broken process when folks can spend a month of bureaucratic energy prioritizing stuff, and then those priorities are not closely followed.
  2. Assign more developers to CommTech. I'd suggest double or triple, and following the spirit of the wish Community Wishlist Survey 2022/Larger suggestions/1%.
  3. Once 1 and 2 are fixed, it should become possible to run the wishlist more often. Perhaps every 6 months. It is important to find ways to shorten the amount of time between the community requesting software and the community receiving software. Both the Annual Plan and the Wishlist seem to take over a year. This cycle should ideally be shortened.
Hope this helps. Happy editing. –Novem Linguae (talk) 18:26, 13 February 2023 (UTC)Reply[reply]
I would like to point out that several people in this discussion (and others like it) are pretending this is all for nothing if the top 10 isn't completed. But I'd say that is far from true. If you look at the history of wishlists, there is a surprising amount of wishes in the top 5 - top 100 that get picked up and solved either during the wishlist or in the year or so after it, by either volunteers and or staff employees. And some wishes that didn't make it initially have made it in followup editions. I personally make a point out of going through the result list a couple of times over the year and updating it to reflect this, as clearly a lot of them are solved directly because of the visibility of the wishlist. To denounce all of that and say only the top of the list is what matters and what should be worked on seems shortsighted. The point isn't to prioritise, it is to show interest with the goal of getting things prioritised. this is somewhat a side effect of organising this as a vote, it gives the idea that this is some sort of'competition'. —TheDJ (talkcontribs) 11:47, 21 February 2023 (UTC)Reply[reply]

Hi @Nardog, 2dk, Townie, Galahad, Foxtrot620, Ciridae, Robertgarrigos, Noé, MER-C, Amadalvarez, Klein Muçi, MarioGom, Thingofme, Iniquity, Flounder ceo, Wakelamp, and Novem Linguae: the voting is open. I encourage you to participate in the last phase of the proposal. I think it's critical to communicate you that the user (Theklan) that mostly helped to not bury this proposal only 5 min after I wrote it, and that has tried to expose many of the flaws, problems and fallacies related to it, has been blocked in Meta during the voting for some "disruptive editing" reasons that you can read and critically try to understand here (including his feeling of being harassed as a first reason). I have felt like not debating more here as I think I may even suffer the same fate. Thank you all for having engaged so much in here, kudos! Xavier Dengra (MESSAGES) 19:58, 13 February 2023 (UTC)Reply[reply]

@Xavier Dengra "I think I may even suffer the same fate" I dont think what you are doing is disruptive, and I think raising this as a proposal is fair. The good news is that @SDeckelmann-WMF has committed to doing a review after this round
I do think your comment that "I have felt like not debating more here" is a good idea for a different reason. When you debate on meta hardly anyone reads it, the ideas tend to be dliuted over multiple pages (or discussed once per year on budget/wishlist page), and the chance of change is low
We need a better place to discuss, and I am not certain whether even on-wiki is the right place (maybe a project??) because talk pages don't work well to consolidate ideas, have a short term focus, and tend towards opinion rather than root cause analysis and a focus on issues.
Looking at our proposals from the past WMF IT perspective,
  • they would be hard to justify on a cost/benefit basis as volunteer time is not costed,and editors are considered as an infinite resource,
  • they are not part of an overall strategy,
  • they do not align with the WMF mission/budget/project evaluation procedure/approach/metrics.
  • WMF has had a policy of sustaining existing systems and focusing on new editors. Wakelamp (talk) 15:19, 21 February 2023 (UTC)Reply[reply]

Voting

  1.   Support --Ivanics (talk) 19:22, 10 February 2023 (UTC)Reply[reply]
  2.   Support again. —2dk (talk) 20:00, 10 February 2023 (UTC)Reply[reply]
  3.   Support This would help a lot. Boehm (talk) 20:36, 10 February 2023 (UTC)Reply[reply]
  4.   Support Pamputt (talk) 22:19, 10 February 2023 (UTC)Reply[reply]
  5.   Support Hehua (talk) 02:37, 11 February 2023 (UTC)Reply[reply]
  6.   Oppose. Baby, bathwater, you know the idiom. I fail to see the point of not having proposals simply because they haven't gotten done in the past. Perhaps this system isn't perfect but I'd wager more proposals get done when there are, you know, proposals, than if there are none at all. And the real question is if THIS proposal would be done in the end. DarkSide830 (talk) 02:48, 11 February 2023 (UTC)Reply[reply]
  7.   Oppose. This is Brainstorming--Sunfyre (talk) 04:34, 11 February 2023 (UTC)Reply[reply]
  8.   Support //Lollipoplollipoplollipop::talk 10:14, 11 February 2023 (UTC)Reply[reply]
  9.   Support Wikimedia Foundation have a conflict of interest in judging the efficacy of this process, yet they also spend money doing just this. The wiki community needs resources to speak up for itself if the wishlist is to become relationship without destructive power imbalance. Bluerasberry (talk) 15:10, 11 February 2023 (UTC)Reply[reply]
  10.   Support Radio-Somewhere (talk) 17:06, 11 February 2023 (UTC)Reply[reply]
  11.   Support Hadi (talk) 20:21, 11 February 2023 (UTC)Reply[reply]
  12.   Support Huxly (talk) 20:23, 11 February 2023 (UTC)Reply[reply]
  13.   Support Ivario (talk) 21:57, 11 February 2023 (UTC)Reply[reply]
  14.   Support Betseg (talk) 03:42, 12 February 2023 (UTC)Reply[reply]
  15.   Support Obvious reasons. This proposal was intended to be deleted after few minutes by the WMF staff and it has only been after many users defended its legitimacy and reasoning, that more information and even a formal reply by its boss has been posted. This reinforces the idea that many things are being done very poorly in the technical debt, and that a change in this system (that creates false expectations in many wikipedians) must be undertaken. Our colleague Theklan, for requesting and compeling more undisclosed information about this exact topic during the debating phase, has been blocked for a month. This lack of accountability is unacceptable and there has been enough evidence of lack of good faith in some aspects. Xavier Dengra (MESSAGES) 15:59, 12 February 2023 (UTC)Reply[reply]
    Theklan's block was for disruptive behavior, was placed by a volunteer admin, and has been endorsed by six other admins. Nardog (talk) 17:07, 12 February 2023 (UTC)Reply[reply]
    Thank you for sharing the link. It's indeed important that everyone can fully track and critically understand the trajectory of events and how this "disruptive editing" (sic) block has been placed and for which kind of pleas. Xavier Dengra (MESSAGES) 16:15, 13 February 2023 (UTC)Reply[reply]
  16.   Support Gotzon (talk) 17:42, 12 February 2023 (UTC)Reply[reply]
  17.   Support PtolemyXV (talk) 18:47, 12 February 2023 (UTC)Reply[reply]
  18.   Support --Luistxo (talk) 07:44, 13 February 2023 (UTC)Reply[reply]
  19.   Support Galahad (sasageyo!)(esvoy) 14:21, 13 February 2023 (UTC)Reply[reply]
  20.   Support Ksarasola (talk) 16:02, 13 February 2023 (UTC)Reply[reply]
  21.   Support This is a very huge topic affecting minority wikis. As said by Theklan, 'we need to fund a dedicated team that will work on the top wishes, will close the tech debt and will start to integrate all the tools created in the previous year into an unique selling-point.' Personal views of... Llywelyn2000 (talk) 16:08, 13 February 2023 (UTC)Reply[reply]
  22.   Support Community Wishlist needs a reset, a reboot. When the team chooses the priorities and what it will do on its own this is no longer a community wishlist, but just another internal Phabricator board with the only difference that here proposals get submitted via Meta, and not the Phabricator interface itself (which unfortunately leads to the fact that not all proposals even end up getting a corresponding Phabricator ticket at all). The only difference is that unlike Phabricator tasks, one can actually indicate how much does one want this here, but that is something that can be done on Phabricator this way or the other too, it is just that we are yet to have that process of doing so there established. Either the wishlist resets, which I see as a commitment to indeed work on the most popular proposals, this obviously has to be backed by WMF (CTO, BoT, I don't know) so that the team has all the resources to do that (which was the sentiment of one of the larger suggestions last year too). The only exception would be things that are just technologically impossible at the moment (such as requiring artificial consciousness), but would not be things that are just difficult to do (such as having to reimplement a major third party invention, such as a modern CAPTCHA service). If this isn't done, I think the team should just focus on some of the neglected tasks accross the Phabricator boards wilst trying to find more useful ones accross them (what they basically do now, but in a quirky way of this process). Base (talk) 16:14, 13 February 2023 (UTC)Reply[reply]
  23.   Support Demonocrazy (talk) 18:19, 13 February 2023 (UTC)Reply[reply]
  24.   Support Not keeping up with the latest developments in the discussion, but it looks to me from time ago that progress in Community Wishlist proposals is next to none. Needless to say, I see with deep concern Theklan's temporary ban. Iñaki LL (talk) 18:55, 13 February 2023 (UTC)Reply[reply]
  25.   Neutral You can see different useful or useless things here, but the results... It looks like another platform for discussion. Perhaps for variety it would be an interesting idea to organize a separate simple poll for readers (through banners or in some other way in their language) what they would like to offer or see on Wikipedia? --Proeksad (talk) 19:14, 13 February 2023 (UTC)Reply[reply]
  26.   Support --Ernestobanpiroa (talk) 19:24, 13 February 2023 (UTC)Reply[reply]
  27.   Support MER-C 20:33, 13 February 2023 (UTC)Reply[reply]
  28.   Support --Amadalvarez (talk) 21:18, 13 February 2023 (UTC)Reply[reply]
  29.   Support -- Lainobeltz (talk) 21:53, 13 February 2023 (UTC)Reply[reply]
  30.   Support --Robertgarrigos (talk) 05:53, 14 February 2023 (UTC)Reply[reply]
  31.   Support Yes, same as past years Noé (talk) 07:59, 14 February 2023 (UTC)Reply[reply]
  32.   Support Dirk123456 (talk) 09:38, 14 February 2023 (UTC)Reply[reply]
  33.   Support --Townie (talk) 11:59, 14 February 2023 (UTC)Reply[reply]
  34.   Support Wakelamp (talk) 14:03, 14 February 2023 (UTC)Reply[reply]
  35.   Support an essential proposal Just N. (talk) 14:58, 14 February 2023 (UTC)Reply[reply]
  36.   Support As per my comment. Ciridae (talk) 04:20, 15 February 2023 (UTC)Reply[reply]
  37.   Support Removal of Dark Mode from the wishlist in 2021 and declaring it "out of scope" in 2022 seemed rather arbitrary. Flounder ceo (talk) 21:54, 15 February 2023 (UTC)Reply[reply]
  38.   Support I've participated in five out of the seven previous Wishlists, in most cases spending many hours carefully reading through every single proposal and very selectively !voting on only those that I thought were the highest priority. I can't stomach that this year. I have no ill will towards the team that organise the Wishlist or the teams that have worked on wishes; my ill will is essentially towards the decision-making parts of the WMF that don't work on the Wishlist and spend millions and millions of dollars on things that the community did not ask for.
    If done correctly, essential maintenance tasks would always be done by the WMF and new features would be worked on based on community priority (with size and feasibility as factors). Instead, we have a situation where the WMF decline to allocate resources to essential maintenance tasks, so they pop up in the community Wishlist, where the Wishlist team then reject most of them and most of the "accepted" wishes are not completed (in a reasonable timeframe). Mixed in ad hoc are some new features and some projects that make it to completion, which makes it seem like the WMF just works on what it wants undemocratically, and any resemblance to community wishes is coincidental. Well, I'm not participating in a show trial this year. — Bilorv (talk) 22:25, 15 February 2023 (UTC)Reply[reply]
  39.   Support If a vote means nothing, then no point participating. Doktor Züm (talk) 15:44, 16 February 2023 (UTC)Reply[reply]
  40.   Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:33, 16 February 2023 (UTC)Reply[reply]
  41.   Support Until the WMF decides to take this seriously, and actually work on the wishes of the community Ignacio Rodríguez (talk) 18:06, 16 February 2023 (UTC)Reply[reply]
  42.   Support DoublePendulumAttractor (talk) 05:58, 18 February 2023 (UTC)Reply[reply]
  43.   Neutral sensible proposal, but I guess this at least helps us find how much things need fixing but how much we are actually there. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:46, 18 February 2023 (UTC)Reply[reply]
  44.   Support Lightoil (talk) 10:10, 18 February 2023 (UTC)Reply[reply]
  45.   Oppose - just removing one of the few venues for technical input and collaboration between the community and the WMF will make things worse. I'm all for improving the Survey system, expanding the number of people working on it at WMF, and using it as part of the input for all Product teams at the WMF, not just Community Tech. MarioGom (talk) 12:13, 18 February 2023 (UTC)Reply[reply]
  46.   Neutral - I don't think it's very benefitial to the community to remove avenues of comunication but I appreciate bringing light to the ineffectiveness of previous Community Wishlist initiatives. For as long as dark mode isn't implemented, the whole thing is a failure imo. Jotamide (talk) 16:00, 18 February 2023 (UTC)Reply[reply]
  47.   Support Althair (talk) 01:57, 20 February 2023 (UTC)Reply[reply]
  48.   Support --Cbyd (talk) 09:35, 21 February 2023 (UTC)Reply[reply]
  49.   Oppose baby, bathwater, shortsighted etc etc.. —TheDJ (talkcontribs) 11:50, 21 February 2023 (UTC)Reply[reply]
  50.   Oppose. Per MarioGom. But I share the opinion that the WMF does not allow enough ressources to reduce the technical debt and to improve the tools that wikimedians use every day. — Jules* talk 11:59, 21 February 2023 (UTC)Reply[reply]
  51.   Oppose per DarkSide830 and TheDJ. dwadieff 12:01, 21 February 2023 (UTC)Reply[reply]
  52.   Support cyrfaw (talk) 10:58, 22 February 2023 (UTC)Reply[reply]
  53.   Support w:en:WP:CANCER. Thingofme (talk) 01:47, 23 February 2023 (UTC)Reply[reply]
  54.   Oppose This definitely needs improvements, but dismantling the Wishlist Survey itself is not the way to go. Part of the problem is that the community has a habit of wishing for things that do not fit the scope of CommTech. Often, the top-10 are large proposals that take a lot of work and cross-department collaboration. Improving Wishlist for everyone requires a change on both sides IMO. Sennecaster (talk) 02:53, 23 February 2023 (UTC)Reply[reply]
    I can only be astonished by the fact that some kind of the discourse is moving towards blaming wikipedians for "dreaming too much". This is literally called Wishlist and it is announced in Village Pumps as "If you have ever used our software and thought of an idea to improve it, this is the place to come share those ideas!". First of all, not only the communities do not have any need to know about who is the CommTech and how it works. But if some of you think that people are too ambitious and you feel the need to restrict the scope of their ideas, then why the heck should we open a page like this and lie to them. Xavier Dengra (MESSAGES) 09:48, 25 February 2023 (UTC)Reply[reply]
  55.   Neutral I think that no one said, wishes will be fulfilled. On the other hand we can at least see what is the major pain in the a* of the community. Juandev (talk) 11:31, 23 February 2023 (UTC)Reply[reply]
  56.   Oppose Per MarioGom. Improvement would be better than destroying everything. But, WMF should provide more resources to solve huge technical debt (instead of developing new features), otherwise Wishlist only waste community and WMF 's time. Thanks. --SCP-2000 12:32, 24 February 2023 (UTC)Reply[reply]

Future of the Wishlist Update

Hello all, thank you for your feedback about the survey and your patience in waiting for a response. We have reviewed your requests and made some preliminary decisions to share with you.

In summary, Community Tech would like to develop a new, continuous intake system for community technical requests that improves prioritization, resourcing, and communication around wishes. Until the new system is established, the Community Tech team will prioritize work from the recently audited backlog of wishes rather than run the survey in February 2024. We are also looking to involve more volunteer developers in the wishlist process, beginning with the first-ever community Wishathon in March 2024.

Please read the announcement in detail either on the Diff blog or MetaWiki, and give your feedback.

The new intake system will need your ideas and involvement, and we’ll reach out on this topic in the next few months.

We look forward to hearing from you. –– STei (WMF) (talk) 14:28, 5 January 2024 (UTC)Reply[reply]

Thanks for the news, @STei (WMF), and congratulations to all of those who have supported this proposal, as taking the decision wasn't easy. I would like to note that this proposal was archived by the team without even allowing the discussion and it was recovered from the archive by @Base. I was also blocked in the way for defending the position that has been taken. We are all allowed to make errors, but it would be interesting to note what was the antidemocratic position of the WMF when this proposal was opened, even disallowing the possibility of discussion.
Thanks again to those that decided to go on with this. Let's hope the new solution is better than what we had. Theklan (talk) 18:52, 5 January 2024 (UTC)Reply[reply]

Wikinews mobile app

 B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: Wikipedia has also launched a mobile app, which also allows a lot of people to use the app to read articles, and since it's a news medium, it's possible that more of our audience can reach it. Some people do prefer to use apps to read news.
  • Proposed solution: Start and create a mobile app.
  • Who would benefit: The Wikinews community and readers
  • More comments: Mobile apps are a good vehicle for reading. People in many different regions are used to reading news articles using mobile apps, which may be easier to design as news websites than encyclopedias. We can also send SMS notifications through mobile applications.
  • Phabricator tickets:
  • Proposer: Kitabc12345 (talk) 12:20, 30 January 2023 (UTC)Reply[reply]

Discussion

Voting

Allow for searching for the start and end of a string

 B This proposal is a Larger suggestion. There is no guarantee this proposal will be implemented. Supporting the idea helps communicate its urgency.

  • Problem: If one searches for a regex term in Wikipedia, such as intitle:/[a-z]{5} [a-z]{6}/ , they get junk like Topographic prominence.
  • Proposed solution: Adding a start and an end function to this term would remove the junk.
  • Who would benefit: People who want to search pages by their enumeration. This is especially true with Wiktionary. Also, this would help reduce load on the Wikimedia servers, as they would start need to search pages that started/ended with the start/end query.
  • More comments: You can use the standard regex start and end functions, ^ and $.
  • Phabricator tickets: T317599
  • Proposer: CitationsFreak (talk) 21:33, 28 January 2023 (UTC)Reply[reply]

Discussion