Community Wishlist Survey 2023/Larger suggestions

Community Wishlist Survey 2023

Larger suggestions

30 proposals, 395 contributors, 842 support votes

The survey has closed. Thanks for your participation :)

Here are the Community Wishlist Survey 2023 results!

This page groups all of the Community Wishlist Survey 2023 proposals that are out of scope for the Community Tech team.

What will happen to these wishes?
Good ideas should not get lost in the Archive. In 2022, the Community Tech Team committed to showing the larger ideas to the Wikimedia Foundation leadership so that they may be aware of them during annual planning. Leadership, as well as other Wikimedia Foundation Product department teams will be made aware about these larger asks.
Can participants vote on these larger suggestions wishes?
During the voting phase, participants are welcome to add their "Support" on these wishes, but please note that regardless of popularity, there is no guarantee these proposals will be implemented. Supporting the idea helps communicate its urgency.

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.

Edit proposal/discussion

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]

Discussion

Thank you TheDJ for the existing Phab ticket number. Although the title refers to Safari & Firefox, I note that the ticket does cover other browsers. I still have this problem on Google Chrome. Fayenatic london (talk) 14:56, 2 February 2023 (UTC)[reply]
Yes this is because the problem has slowly grown over the last couple of years from applying to just safari, then firefox and eventually all browsers as they one after another have increased their privacy settings. The problem is essentially the same for each browser however. —TheDJ (talk • contribs) 15:14, 2 February 2023 (UTC)[reply]

There are a bunch of different tasks for more or less the same issue (but different browsers/features), e.g. T202028, T257803. Tgr (talk) 06:19, 5 February 2023 (UTC)[reply]
I have worked on this a bit recently (in a staff capacity). T326281, which is a limited improvement, will be hopefully deployed soon. Beyond that, I think a large-scale refactoring of Wikimedia authentication would be needed. Which is definitely something we should do, but it is large enough that it needs to be slotted into annual planning, I think. --Tgr (talk) 06:49, 3 February 2023 (UTC)[reply]
This is an old problem apparently affecting all wikis and all browsers. YES, please fix the unified login to WMF wikis. Taylor 49 (talk) 17:05, 3 February 2023 (UTC)[reply]
Yes, this would be very nice! After some years of struggle (G Chrome), I have given up asking for solution. Thanks for proposing. — Draceane ^talk_contrib. 20:56, 8 February 2023 (UTC)[reply]
See also: Community Wishlist Survey 2022/Miscellaneous/Automatically log in to all projects if you are logged in to one --JopkeB (talk) 16:24, 11 February 2023 (UTC)[reply]
My problem is that I am automatically logged in to the Commons and to here. But I am no longer automatically logged in to Wikipedia and other wikis. Why is this? Krok6kola (talk) 20:35, 11 February 2023 (UTC)[reply]
Meta also don't login automatically--Jaguar K (talk) 22:07, 23 February 2023 (UTC)[reply]

Voting

Support Although I used to be logged in to all wikis, now suddenly I'm not. I don't want to have to log in over and over to Wikipedia for example. My password is too complicated to use easily. Krok6kola (talk) 18:30, 10 February 2023 (UTC)[reply]
Support as someone who was confused why they were not logged in here in particular and was worried I could not vote here because of the note that comments from very new accounts might be deleted (this is my first non userpage edit on this particular wiki but I have had a WP account since 2016). DarkSide830 (talk) 19:02, 10 February 2023 (UTC)[reply]
Support Xbypass (talk) 20:08, 10 February 2023 (UTC)[reply]
Support Fallbackintoreality (talk) 20:51, 10 February 2023 (UTC)[reply]
Support SeGiba (talk) 21:16, 10 February 2023 (UTC)[reply]
Support. Also the language settings are disabled--Proeksad (talk) 22:05, 10 February 2023 (UTC) I have problem with MediaWiki, Multilingual Wikisource, Wikidata, Wikispecies, Wikibooks, Wikinews, Wikiquote, Wikisource, Wikiversity, Wikivoyage, Wiktionary and Wikitech --Proeksad (talk) 17:49, 24 February 2023 (UTC)[reply]
Support Significa liberdade (talk) 22:25, 10 February 2023 (UTC)[reply]
Support Geert Van Pamel (WMBE) (talk) 23:14, 10 February 2023 (UTC)[reply]
Support Hyruspex (talk) 01:07, 11 February 2023 (UTC)[reply]
Support Hehua (talk) 02:38, 11 February 2023 (UTC)[reply]
Support Tgr (talk) 04:41, 11 February 2023 (UTC)[reply]
Support HHill (talk) 08:09, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:13, 11 February 2023 (UTC)[reply]
Support Kekavigi (talk) 08:55, 11 February 2023 (UTC)[reply]
Support Kou07kou (talk) 09:01, 11 February 2023 (UTC)[reply]
Support Exilexi (talk) 09:02, 11 February 2023 (UTC)[reply]
Support Muted Red Tulip (talk) 09:44, 11 February 2023 (UTC)[reply]
Support Grabado (talk) 10:02, 11 February 2023 (UTC)[reply]
Support Oltrepier (talk) 10:10, 11 February 2023 (UTC)[reply]
Support OtherPrivacyGuy (talk) 10:52, 11 February 2023 (UTC)[reply]
Support CaféBuzz (talk) 11:07, 11 February 2023 (UTC)[reply]
Support timawesomeness ⟨talk⟩ 11:55, 11 February 2023 (UTC)[reply]
Support --Crosstor (talk) 13:55, 11 February 2023 (UTC)[reply]
Support Guerillero ^{Parlez Moi} 14:08, 11 February 2023 (UTC)[reply]
Support -- A solution to this old problem would be great ... --Spielvogel (talk) 14:52, 11 February 2023 (UTC)[reply]
Support JopkeB (talk) 16:24, 11 February 2023 (UTC)[reply]
Support Rots61 (talk) 16:54, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:52, 11 February 2023 (UTC)[reply]
Support Conny (talk) 18:07, 11 February 2023 (UTC)[reply]
Support Matěj Suchánek (talk) 18:40, 11 February 2023 (UTC)[reply]
Support VastV0idInSpace0 (talk) 20:38, 11 February 2023 (UTC)[reply]
Support This is currently an annoying issue, and a fix would be beneficial. — Red-tailed hawk _(nest) 21:37, 11 February 2023 (UTC)[reply]
Support Ivario (talk) 22:03, 11 February 2023 (UTC)[reply]
Support --Furfur^{⁂ Discussion} 00:02, 12 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:21, 12 February 2023 (UTC)[reply]
Support In fact wiktionary and something else also don't appear to work. Aaron Liu (talk) 03:19, 12 February 2023 (UTC)[reply]
Support HLFan (talk) 09:05, 12 February 2023 (UTC)[reply]
Support Ameisenigel (talk) 09:23, 12 February 2023 (UTC)[reply]
Strong support Akela (talk) 13:23, 12 February 2023 (UTC)[reply]
Support --everyone's favorite Blua lago(let's have a chat y'all) 13:42, 12 February 2023 (UTC)[reply]
Support Tryvix ^t 13:52, 12 February 2023 (UTC)[reply]
Support SpiderMum (talk) 14:47, 12 February 2023 (UTC)[reply]
Support Thomas Kinz (talk) 01:26, 13 February 2023 (UTC)[reply]
Support Izno (talk) 08:07, 13 February 2023 (UTC)[reply]
Support, the problem is eveywhere, this should be a high priority, currently prevents me making some changes on wikis where I'm not automatically logged in. Stryn (talk) 12:05, 13 February 2023 (UTC)[reply]
Strong support —Yahya (talk • contribs.) 21:50, 13 February 2023 (UTC)[reply]
Support JAn Dudík (talk) 22:04, 13 February 2023 (UTC)[reply]
Support Taylor 49 (talk) 04:16, 14 February 2023 (UTC)[reply]
Support Libcub (talk) 06:07, 14 February 2023 (UTC)[reply]
Support SpacedShark (talk) 06:40, 14 February 2023 (UTC)[reply]
Support Katsutoshi Seki (talk) 11:48, 14 February 2023 (UTC)[reply]
Support Labdajiwa (talk) 00:00, 15 February 2023 (UTC)[reply]
Support resolving all problems with unified login Wargo (talk) 00:29, 15 February 2023 (UTC)[reply]
Support Laurent Meesseman (talk) 14:51, 15 February 2023 (UTC)[reply]
Support WomenArtistUpdates (talk) 23:58, 15 February 2023 (UTC)[reply]
Support AshLooming (talk) 00:49, 16 February 2023 (UTC)[reply]
Support Mikhail Ryazanov (talk) 01:20, 16 February 2023 (UTC)[reply]
Support Sadads (talk) 01:27, 16 February 2023 (UTC)[reply]
Support Vis M (talk) 06:55, 16 February 2023 (UTC)[reply]
Support Doktor Züm (talk) 15:49, 16 February 2023 (UTC)[reply]
Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:34, 16 February 2023 (UTC)[reply]
Support Fuchs B (talk) 20:21, 17 February 2023 (UTC)[reply]
Support Geraki ^T_L 20:23, 17 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:30, 18 February 2023 (UTC)[reply]
Support Lupe (talk) 14:47, 18 February 2023 (UTC)[reply]
Support Jotamide (talk) 16:02, 18 February 2023 (UTC)[reply]
Support Vulcan❯❯❯Sphere! 16:36, 18 February 2023 (UTC)[reply]
Support Sir Gawain (talk) 23:59, 19 February 2023 (UTC)[reply]
Support DerMaxdorfer (talk) 00:12, 20 February 2023 (UTC)[reply]
Support Lightoil (talk) 01:51, 20 February 2023 (UTC)[reply]
Support --Mombacher (talk) 09:37, 20 February 2023 (UTC)[reply]
Support — Draceane ^talk_contrib. 12:54, 20 February 2023 (UTC)[reply]
Support --Carlos-X (talk) 14:20, 20 February 2023 (UTC)[reply]
Support Nashona (talk) 18:27, 20 February 2023 (UTC)[reply]
Support Lukas Raich (talk) 20:14, 20 February 2023 (UTC)[reply]
Support Qxyz123 (talk) 04:24, 21 February 2023 (UTC)[reply]
Support --Cbyd (talk) 09:38, 21 February 2023 (UTC)[reply]
Support Hkoala (talk) 17:35, 22 February 2023 (UTC)[reply]
Support Morten Haan (talk) 18:56, 22 February 2023 (UTC)[reply]
Support Madacs (talk) 20:38, 22 February 2023 (UTC)[reply]
Support This should be fixed. Thingofme (talk) 01:50, 23 February 2023 (UTC)[reply]
Support Althair (talk) 04:13, 23 February 2023 (UTC)[reply]
Support I thought this was a design change. You mean it's a bug? Daniel Case (talk) 05:57, 23 February 2023 (UTC)[reply]
Support cyrfaw (talk) 13:43, 23 February 2023 (UTC)[reply]
Support NicoScribe (talk) 21:08, 23 February 2023 (UTC)[reply]
Support Meta also don't login automatically Jaguar K (talk) 22:06, 23 February 2023 (UTC)[reply]

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.

Edit proposal/discussion

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]

Discussion

@Michael Cieslik: A major new data model like this is a large project, and so is out of scope for Community Tech. Moving to the 'Larger suggestions' category. SWilson (WMF) (talk) 08:23, 31 January 2023 (UTC)[reply]
@Michael Cieslik: You may want to check out the Abstract_Wikipedia project, which might provide solutions to your problem. DWalden (WMF) (talk) 09:05, 31 January 2023 (UTC)[reply]
No, for me Wikidata is a databank that indeed describes things (including concepts, locations and probably also other things). But it does a lot more: it connects those things to descriptions and files in other parts of Wikimedia, like Wikipedias, Commons and Wikibooks (with recipes for pizza's; see Pizza in Wikidata), at the bottom of Wikidata items. There (in the Wikipedias, Commons, Wikibooks, Wikivoyage and so on) is the knowledge that you asked for. Wikidata is the signpost to that knowledge. I think it is not up to Wikidata to be more than that, there would be a lot of doubling. --JopkeB (talk) 15:58, 11 February 2023 (UTC)[reply]

Voting

Very strong support I believe that this is a strongly needed edition to Wikidata and can boost the community as a whole. NPRB (talk) 22:06, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 04:54, 14 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:00, 18 February 2023 (UTC)[reply]
Support Definitely needed, but I don't think that an existing project can or should handle it. Maybe a new project for knowledge? Lukas Raich (talk) 20:27, 20 February 2023 (UTC)[reply]
Support cyrfaw (talk) 10:57, 22 February 2023 (UTC)[reply]
Support An interesting idea, but it would obviously be a massive undertaking. Snowmanonahoe (talk) 14:34, 22 February 2023 (UTC)[reply]
Support This is middle-lined between Wd and Wikifunctions. Thingofme (talk) 01:53, 23 February 2023 (UTC)[reply]

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.

Edit proposal/discussion

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]

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]
@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]
@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]
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]
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]
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]

Voting

Support Nardog (talk) 18:15, 10 February 2023 (UTC)[reply]
Support Like hello? Userscripts help enable editors to make a significant portion of their edits faster every day. Getting this finished means -> more people using userscripts -> more contributions to our wikis. Lectrician1 (talk) 22:37, 10 February 2023 (UTC)[reply]
Support Magnoliasouth (talk) 23:28, 10 February 2023 (UTC)[reply]
Support Tgr (talk) 04:18, 11 February 2023 (UTC)[reply]
Support EpicPupper (talk) 05:39, 11 February 2023 (UTC)[reply]
Support NMaia (talk) 06:06, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:32, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:23, 12 February 2023 (UTC)[reply]
Support Ameisenigel (talk) 09:22, 12 February 2023 (UTC)[reply]
Support Waldyrious (talk) 04:46, 13 February 2023 (UTC)[reply]
Support Izno (talk) 07:57, 13 February 2023 (UTC)[reply]
Support Titore (talk) 14:55, 13 February 2023 (UTC)[reply]
Support JAn Dudík (talk) 22:02, 13 February 2023 (UTC)[reply]
Support per above NPRB (talk) 14:00, 15 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 08:57, 16 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:00, 18 February 2023 (UTC)[reply]
Support Lightoil (talk) 01:53, 20 February 2023 (UTC)[reply]
Support Althair (talk) 01:58, 20 February 2023 (UTC)[reply]
Support — Draceane ^talk_contrib. 12:53, 20 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:29, 21 February 2023 (UTC)[reply]
Support Madacs (talk) 20:37, 22 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:03, 23 February 2023 (UTC)[reply]
Support Helder 10:59, 23 February 2023 (UTC)[reply]
Support MichaelSchoenitzer (talk) 11:27, 24 February 2023 (UTC)[reply]

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.

Edit proposal/discussion

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]

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]
@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]
- 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]
  - @Thingofme: Isn't that what the InternetArchiveBot is though? SWilson (WMF) (talk) 01:14, 25 January 2023 (UTC)[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]
  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]
  @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]
  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]

Voting

Support Xbypass (talk) 20:08, 10 February 2023 (UTC)[reply]
Support Tom Ja (talk) 21:43, 10 February 2023 (UTC)[reply]
Support Significa liberdade (talk) 22:26, 10 February 2023 (UTC)[reply]
Support ·addshore· ^{talk to me!} 00:16, 11 February 2023 (UTC)[reply]
Support Hehua (talk) 02:36, 11 February 2023 (UTC)[reply]
Support Tgr (talk) 04:14, 11 February 2023 (UTC)[reply]
Support EpicPupper (talk) 05:39, 11 February 2023 (UTC)[reply]
Support NMaia (talk) 06:00, 11 February 2023 (UTC)[reply]
Support HoHo3143 (talk) 07:36, 11 February 2023 (UTC)[reply]
Support Jurbop (talk) 08:04, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:32, 11 February 2023 (UTC)[reply]
Support SunDawn (talk) 12:39, 11 February 2023 (UTC)[reply]
Support Bluerasberry (talk) 15:04, 11 February 2023 (UTC)[reply]
Support CROIX (talk) 15:19, 11 February 2023 (UTC)[reply]
Support Nicereddy (talk) 16:57, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:58, 11 February 2023 (UTC)[reply]
Support Ivario (talk) 22:04, 11 February 2023 (UTC)[reply]
Support Furfur^{⁂ Discussion} 00:06, 12 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:30, 12 February 2023 (UTC)[reply]
Support Mauricio V. Genta (talk) 08:06, 12 February 2023 (UTC)[reply]
Support Fvtvr3r (talk) 13:57, 12 February 2023 (UTC)[reply]
Support Waldyrious (talk) 04:53, 13 February 2023 (UTC)[reply]
Support JAn Dudík (talk) 22:01, 13 February 2023 (UTC)[reply]
Support Ɱ (talk) 02:39, 14 February 2023 (UTC)[reply]
Support SpacedShark (talk) 06:37, 14 February 2023 (UTC)[reply]
Support essential Just N. (talk) 15:00, 14 February 2023 (UTC)[reply]
Support Lousyd (talk) 18:58, 17 February 2023 (UTC)[reply]
Support Fuchs B (talk) 20:18, 17 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:31, 18 February 2023 (UTC)[reply]
Support -- Ferien (talk) 16:17, 18 February 2023 (UTC)[reply]
Support Vulcan❯❯❯Sphere! 16:35, 18 February 2023 (UTC)[reply]
Support · · · Peter (Southwood) ^(talk): 18:00, 18 February 2023 (UTC)[reply]
Support Jklamo (talk) 12:18, 19 February 2023 (UTC)[reply]
Support DerMaxdorfer (talk) 00:20, 20 February 2023 (UTC)[reply]
Support Althair (talk) 01:54, 20 February 2023 (UTC)[reply]
Support Hans5958 (talk) 02:46, 20 February 2023 (UTC)[reply]
Support Mbrickn (talk) 03:24, 20 February 2023 (UTC)[reply]
Support Cmarsch (talk) 06:29, 20 February 2023 (UTC)[reply]
Support — Draceane ^talk_contrib. 12:54, 20 February 2023 (UTC)[reply]
Support PamD (talk) 15:55, 20 February 2023 (UTC)[reply]
Support — Omegatron (talk) 16:55, 20 February 2023 (UTC)[reply]
Very strong support There are many pages where the references are already dead, this should not happen! With dead links there are no references for our articles, the affected sections are then without a source. No source means unreliable article/section. Lukas Raich (talk) 20:21, 20 February 2023 (UTC)[reply]
Support Qxyz123 (talk) 04:34, 21 February 2023 (UTC)[reply]
Support — DaxServer (t · m · c) 16:57, 22 February 2023 (UTC)[reply]
Support Fcastillo (talk) 22:17, 22 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:05, 23 February 2023 (UTC)[reply]
Support Yes, that would be nice. But in such a case I think WMF should provide financial aid to Web Archive also. Juandev (talk) 11:47, 23 February 2023 (UTC)[reply]
Support cyrfaw (talk) 13:49, 23 February 2023 (UTC)[reply]
Support having pdf of a source when used would be a great step forward I have see genealogy software like Family Search doing it - Salgo60 (talk) 18:09, 10 February 2023 (UTC)[reply]
Neutral however, there are also problems with this bot + many users do not understand how to fix archiving mistakes --Proeksad (talk) 17:59, 24 February 2023 (UTC)[reply]

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.

Edit proposal/discussion

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]

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]
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]
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]
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]
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]
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]
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]

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]

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]
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]
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]
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]

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]
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]
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]
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]
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]

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]

Question: Further to a recent comment of mine, this is also made solely in my capacity as a volunteer and not on behalf of my team.

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]

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]

@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]

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]

@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]

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]

(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]

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]

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]

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]

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]

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]

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]
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]

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]

@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]

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]

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]

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]

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:

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.
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]

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]

@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]

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]

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.

Google Knowledge panels
Google auto translate tool
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.
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]

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:

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.
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%.
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]

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 (talk • contribs) 11:47, 21 February 2023 (UTC)[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]

@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]

Voting

Support --Ivanics (talk) 19:22, 10 February 2023 (UTC)[reply]
Support again. —2dk (talk) 20:00, 10 February 2023 (UTC)[reply]
Support This would help a lot. Boehm (talk) 20:36, 10 February 2023 (UTC)[reply]
Support Pamputt (talk) 22:19, 10 February 2023 (UTC)[reply]
Support Hehua (talk) 02:37, 11 February 2023 (UTC)[reply]
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]
Oppose. This is Brainstorming--Sunfyre (talk) 04:34, 11 February 2023 (UTC)[reply]
Support //Lollipoplollipoplollipop::talk 10:14, 11 February 2023 (UTC)[reply]
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]
Support Radio-Somewhere (talk) 17:06, 11 February 2023 (UTC)[reply]
Support Hadi (talk) 20:21, 11 February 2023 (UTC)[reply]
Support Huxly (talk) 20:23, 11 February 2023 (UTC)[reply]
Support Ivario (talk) 21:57, 11 February 2023 (UTC)[reply]
Support Betseg (talk) 03:42, 12 February 2023 (UTC)[reply]
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]
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]
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]
Support Gotzon (talk) 17:42, 12 February 2023 (UTC)[reply]
Support PtolemyXV (talk) 18:47, 12 February 2023 (UTC)[reply]
Support --Luistxo (talk) 07:44, 13 February 2023 (UTC)[reply]
Support Galahad (sasageyo!)^(esvoy) 14:21, 13 February 2023 (UTC)[reply]
Support Ksarasola (talk) 16:02, 13 February 2023 (UTC)[reply]
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]
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]
Support Demonocrazy (talk) 18:19, 13 February 2023 (UTC)[reply]
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]
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]
Support --Ernestobanpiroa (talk) 19:24, 13 February 2023 (UTC)[reply]
Support MER-C 20:33, 13 February 2023 (UTC)[reply]
Support --Amadalvarez (talk) 21:18, 13 February 2023 (UTC)[reply]
Support -- Lainobeltz (talk) 21:53, 13 February 2023 (UTC)[reply]
Support --Robertgarrigos (talk) 05:53, 14 February 2023 (UTC)[reply]
Support Yes, same as past years Noé (talk) 07:59, 14 February 2023 (UTC)[reply]
Support Dirk123456 (talk) 09:38, 14 February 2023 (UTC)[reply]
Support --Townie (talk) 11:59, 14 February 2023 (UTC)[reply]
Support Wakelamp (talk) 14:03, 14 February 2023 (UTC)[reply]
Support an essential proposal Just N. (talk) 14:58, 14 February 2023 (UTC)[reply]
Support As per my comment. Ciridae (talk) 04:20, 15 February 2023 (UTC)[reply]
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]
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]
Support If a vote means nothing, then no point participating. Doktor Züm (talk) 15:44, 16 February 2023 (UTC)[reply]
Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:33, 16 February 2023 (UTC)[reply]
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]
Support DoublePendulumAttractor (talk) 05:58, 18 February 2023 (UTC)[reply]
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]
Support Lightoil (talk) 10:10, 18 February 2023 (UTC)[reply]
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]
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]
Support Althair (talk) 01:57, 20 February 2023 (UTC)[reply]
Support --Cbyd (talk) 09:35, 21 February 2023 (UTC)[reply]
Oppose baby, bathwater, shortsighted etc etc.. —TheDJ (talk • contribs) 11:50, 21 February 2023 (UTC)[reply]
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]
Oppose per DarkSide830 and TheDJ. dwadieff ✉ 12:01, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 10:58, 22 February 2023 (UTC)[reply]
Support w:en:WP:CANCER. Thingofme (talk) 01:47, 23 February 2023 (UTC)[reply]
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]
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]
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]
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]

Future of the Wishlist Update – January 2024

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]

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]

Updates

Community Wishlist Survey is now Community Wishlist

Thank you everyone who has participated in the restructuring and rebranding conversations of the Wishlist so far.

Regarding the renaming, based on your feedback, we will keep the 'Community Wishlist' and remove 'Survey'.

Please read more about the renaming, check out the vote results and learn more about the re-opening of the Community Wishlist on July 15, 2024, in our latest update.

–– STei (WMF) (talk) 21:46, 28 June 2024 (UTC)[reply]

Pinging discussants –– STei (WMF) (talk) 21:51, 28 June 2024 (UTC)[reply]

Pinging more discussants. ––

Voting on the renaming of the Wishlist – June 17, 2024

Hello participants of Dismantle Wishlist Larger Suggestion, the next steps for the renaming is for you to vote on a few names we have selected. Please read about the rationale for the names, and proceed to the voting page to make a choice.

Pinging discussants –– STei (WMF) (talk) 21:15, 17 June 2024 (UTC)[reply]

Pinging more people. –– STei (WMF) (talk) 21:17, 17 June 2024 (UTC)[reply]

Renaming of Wishlist – May 21, 2024

The Wishlist needs a new name to reflect the new direction and we are inviting you all to help create a new name. Please visit the announcement and name proposal page, to participate.

Pinging discussants ––STei (WMF) (talk) 20:54, 21 May 2024 (UTC) Pinging more people. –– STei (WMF) (talk) 20:55, 21 May 2024 (UTC)[reply]

Updates on Wishlist Redesign – 18 May 2024

Hello, there are updates regarding the Wishlist Survey. A mockup of the new wish proposal form is available. There is also an update on changes coming to how participants vote. Additionally, come let's explore this idea to group wishes into Focus Areas; a Focus Area may be adopted by various movement stakeholders for addressing. The first example is the Template Picker Improvements Project, which groups four related wishes about template improvements (e.g. adding infoboxes and bookmarking templates). You can read more and join the discussion. –– STei (WMF) (talk) 00:06, 18 May 2024 (UTC)[reply]

Pinging more people. –– STei (WMF) (talk) 00:09, 18 May 2024 (UTC)[reply]

New Community Tech Manager and Future of the Wishlist Update – March 2024

Hello all, thank you to those who have given feedback so far on the future of the Wishlist.

I am happy to introduce Jack Wheeler, who has recently joined the Wikimedia Foundation as the Lead Community Tech Manager responsible for the Future of the Wishlist. Jack would like to have a conversation with the community to get input for the design of the new Wishlist, starting with how to define a "Wish."

Community Tech would appreciate you chatting with him; your input will be invaluable. You can check out Jack's first message to the community to get started.

Thank you! –– STei (WMF) (talk) 15:07, 13 March 2024 (UTC) [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.

Edit proposal/discussion

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]

Discussion

@Kitabc12345: Developing a mobile app would be out of scope for Community Tech. However, moving it into larger suggestions so people can still vote on it and we can get an idea what the support for this is. Thanks for participating. DWalden (WMF) (talk) 15:23, 30 January 2023 (UTC)[reply]
Maybe this is dumplicate to my proposal. Hehua (talk) 02:53, 1 February 2023 (UTC)[reply]
See my response at Community Wishlist Survey 2023/Larger suggestions/Develop mobile versions for projects like Wikivoyage app#Discussion —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:36, 18 February 2023 (UTC)[reply]

Voting

Support HoHo3143 (talk) 02:27, 11 February 2023 (UTC)[reply]
Support EpicPupper (talk) 05:39, 11 February 2023 (UTC)[reply]
Support Apps for non-Wikipedia projects, please! NMaia (talk) 06:06, 11 February 2023 (UTC)[reply]
Support AirbusA220 (talk) 07:23, 11 February 2023 (UTC)[reply]
Support Muted Red Tulip (talk) 10:14, 11 February 2023 (UTC)[reply]
Support I see this as an idea to improve the existing app, to improve it as a newsreader. Plaga med (talk) 11:48, 11 February 2023 (UTC)[reply]
Support Shizhao (talk) 13:59, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:50, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:41, 12 February 2023 (UTC)[reply]
Support Fvtvr3r (talk) 13:49, 12 February 2023 (UTC)[reply]
Support PtolemyXV (talk) 18:55, 12 February 2023 (UTC)[reply]
Support Chetao (talk) 08:31, 13 February 2023 (UTC)[reply]
Support Leo067 (talk) 08:40, 13 February 2023 (UTC)[reply]
Support Doktor Züm (talk) 07:14, 16 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 08:59, 16 February 2023 (UTC)[reply]
Support IMHO Wikinews needs to be Great and Elegant looking on larger mobile phones and tablets ASAP if it is to make any impact with newer users Zblace (talk) 11:13, 16 February 2023 (UTC)[reply]
Support Lousyd (talk) 18:57, 17 February 2023 (UTC)[reply]
Support Cryorett (talk) 13:12, 19 February 2023 (UTC)[reply]
Support Mbrickn (talk) 03:27, 20 February 2023 (UTC)[reply]
Support β₁₆ - (talk) 14:33, 20 February 2023 (UTC)[reply]
Support MichaelRostom (talk) 23:38, 20 February 2023 (UTC)[reply]
Support Qxyz123 (talk) 04:37, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:10, 21 February 2023 (UTC)[reply]
Support Thingofme (talk) 01:59, 23 February 2023 (UTC)[reply]
Support Althair (talk) 04:14, 23 February 2023 (UTC)[reply]

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.

Edit proposal/discussion

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]

Discussion

I think this is impossible as the Search engine technology does not support it. See https://www.elastic.co/guide/en/elasticsearch/reference/current/regexp-syntax.html#regexp-unsupported-operators But i'm sure DCausse (WMF) has the exact details. Additionally, there are almost always better ways to do a search like this, probably via Quarry. —TheDJ (talk • contribs) 23:31, 29 January 2023 (UTC)[reply]
Indeed, the underlying regular expression engine we do use does not support such syntax. Adding support for this (while not completely impossible and without going into the details) would require a non negligible effort to do properly (adapt/rewrite the regex parser, possibly use reserved unicode characters as start/end markups in the index, ...). DCausse (WMF) (talk) 10:55, 30 January 2023 (UTC)[reply]
Doesn't this just require converting /^<regex>/ into /<regex>/ AND NOT /.(<regex>)/? Tgr (talk) 01:40, 1 February 2023 (UTC)[reply]
Indeed! I haven't thought about this possibility but this does seem to be a valid workaround, for searching for pages that end with test one can search for intitle:/test/ -intitle:/test./, see it in action on wiktionary. @CitationsFreak: would documenting this workaround be good-enough? DCausse (WMF) (talk) 14:59, 3 February 2023 (UTC)[reply]
Actually after discussing with my colleagues, this workaround does not quite work because it will ignore words that have the suffix you want elsewhere in the word, e.g. intitle:/ed$/ is not equivalent to intitle:/ed/ -intitle:/ed./ as the later will exclude educated but actually should match with the former. DCausse (WMF) (talk) 18:19, 8 February 2023 (UTC)[reply]

Voting

Support if possible, but it would probably mean introducing proper regexp support (e.g. PCRE) which would have many other major benefits. Certes (talk) 21:47, 10 February 2023 (UTC)[reply]
Support * Pppery * _{it has begun} 04:05, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:30, 11 February 2023 (UTC)[reply]
Support NguoiDungKhongDinhDanh 09:45, 11 February 2023 (UTC)[reply]
Support //Lollipoplollipoplollipop::talk 10:09, 11 February 2023 (UTC)[reply]
Support Nw520 (talk) 12:59, 11 February 2023 (UTC)[reply]
Support Wotheina (talk) 16:33, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:54, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:36, 12 February 2023 (UTC)[reply]
Support Izno (talk) 08:00, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 07:13, 14 February 2023 (UTC)[reply]
Support —Locke Cole • t • c 08:57, 15 February 2023 (UTC)[reply]
Support ZandDev (talk) 09:59, 15 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 09:06, 16 February 2023 (UTC)[reply]
Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:31, 16 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:55, 18 February 2023 (UTC)[reply]
Support Christian (talk) 20:35, 18 February 2023 (UTC)[reply]
Support PCRE-support would be great, but it’s not for the average Joe. Kays (talk) 04:01, 19 February 2023 (UTC)[reply]
Support β₁₆ - (talk) 14:32, 20 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:22, 21 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:08, 23 February 2023 (UTC)[reply]
Support GoingBatty (talk) 03:54, 23 February 2023 (UTC)[reply]

Train a language model to perform SPARQL queries

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

Edit proposal/discussion

Problem: Even with the new query builder, the queries are not intuitive and they are hard to write if you are not knowledgeable in SPARQL.
Proposed solution: Use all the queries that have been solved by editors to train a model that can translate text into SPARQL queries.
Who would benefit: People who cannot write SPARQL queries but who want to query wikidata using natural language.
More comments:
Phabricator tickets:
Proposer: MathTexLearner (talk) 23:00, 29 January 2023 (UTC)[reply]

Discussion

@MathTexLearner: Thanks for this proposal, unfortuntately this is out of scope for our team, but we will move this one to larger suggestions. KSiebert (WMF) (talk) 12:57, 30 January 2023 (UTC)[reply]
For what it's worth, ChatGPT does a pretty good job at writing common SPARQL queries for Wikidata. At least the kind of queries that do not rely on obscure properties or have performance problems. MarioGom (talk) 21:36, 31 January 2023 (UTC)[reply]
I tried it and it doesn't work well. The query I tried is: "Can you write me a sparql query for Wikidata that provides a list of all majors in Bavaria displaying their name and the town they are major of?", and while it provided a SPARQL code, it was not right and it did not produce any result. MathTexLearner (talk) 22:53, 31 January 2023 (UTC)[reply]
I tried my hand at it as well - and found that ChatGPT could not generate a workable query. Ottawajin (talk) 12:15, 14 February 2023 (UTC)[reply]
There have been a few (pre-LLM) attempts like Platypus. It would certainly be very powerful; no idea how feasible it is. I suspect it is hard to do this without having a huge training set of SPARQL queries with natural-language descriptions. --Tgr (talk) 00:28, 1 February 2023 (UTC)[reply]
There is a large amount of queries at d:Wikidata:Request_a_query, however some work would be needed to create proper descriptions for all the generated queries. MathTexLearner (talk) 14:56, 1 February 2023 (UTC)[reply]
Some queries are long and difficult to learn for new users. Thingofme (talk) 02:02, 23 February 2023 (UTC)[reply]
MathTexLearner you may be interested in this tool https://observablehq.com/@pac02/hello-sparql-queries-dataset. This makes it easy to find examples of SPARQL queries. PAC2 (talk) 06:28, 3 February 2023 (UTC)[reply]

Voting

Support Strainu (talk) 20:19, 10 February 2023 (UTC)[reply]
Support //Lollipoplollipoplollipop::talk 20:41, 10 February 2023 (UTC)[reply]
Support NMaia (talk) 06:00, 11 February 2023 (UTC)[reply]
Support Plaga med (talk) 11:32, 11 February 2023 (UTC)[reply]
Support Conny (talk) 18:09, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:36, 12 February 2023 (UTC)[reply]
Support Ameisenigel (talk) 09:20, 12 February 2023 (UTC)[reply]
Support Waldyrious (talk) 05:01, 13 February 2023 (UTC)[reply]
Support Althair (talk) 01:53, 20 February 2023 (UTC)[reply]
Support Ropaga (talk) 11:26, 20 February 2023 (UTC)[reply]
Support Ταπυρ (گپ) 12:11, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 19:00, 21 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:01, 23 February 2023 (UTC)[reply]

Wiki-ancestry

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

Edit proposal/discussion

Problem: People can't find the person or can't find distant relatives
Proposed solution: This project will allow many people to tell about their relatives and find other relatives. You can also lay out a person who could be lost without a trace. Everyone (registered user only) creates a page on which he describes his relative (one page - one person). The structure of a relative's page may be identical to a Wikipedia article. Illustrated via wikimedia commons. People will create pages and other people can find each other through distant relatives. A family tree can be created using a separate template page.
It will also be possible to post the results of DNA tests.
Who would benefit: Poor people who do not have enough money for a DNA test and people who are desperate to look for their loved ones
More comments: The project itself can consist of two parts:
- Wiki-ancestry
- Search for the missing

Or a project to search for the missing can be done separately.

See also the Wikimedia genealogy project for an overview of similar projects and proposals.

Phabricator tickets:
Proposer: Пётр Тарасьев (talk) 14:43, 24 January 2023 (UTC)[reply]

Discussion

Support. While I can see a whole host of potential issues (after all, my real life last name is that of a very famous confederate general from the U.S.), including the relative impossibility of verifying the accuracy of such a project; I think this a really really good idea, and I feel like it's a niche that fits nicely in with what we do! Foxtrot620 (talk) 22:58, 24 January 2023 (UTC)[reply]
It's worth noting that there's legitimate privacy concerns with getting a DNA test, and probably other reasonable concerns other than money. Eiim (talk) 21:59, 25 January 2023 (UTC)[reply]
There already exists WikiTree with 33 milions entries. It would be fine, if this project will use some wikidata specific things, but creating new project is doubtful. JAn Dudík (talk) 20:40, 26 January 2023 (UTC)[reply]
See Proposals for new projects (or Wikispore). This isn't a technical proposal. The technical infrastructure for handling DNA data on MediaWiki already exists (see SNPedia). --Tgr (talk) 21:24, 29 January 2023 (UTC)[reply]

Voting

Support good idea. Pmsyyz (talk) 01:13, 11 February 2023 (UTC)[reply]
Oppose not within the scope of the technical team. Consider submitting your proposal on Proposals for new projects. --SHB2000 (talk | contribs) 01:38, 11 February 2023 (UTC)[reply]
Strong oppose. Perhaps cool, but there are real security concerns here and this is ultimately not the best use of the project's money. DarkSide830 (talk) 02:44, 11 February 2023 (UTC)[reply]
Strong oppose — The preceding unsigned comment was added by CROIX (talk) 15:22, 11 February 2023 (UTC)[reply]
Support DF476 (talk) 18:05, 11 February 2023 (UTC)[reply]
Support THainaut (talk) 09:26, 15 February 2023 (UTC)[reply]
Support JFremd (talk) 16:23, 16 February 2023 (UTC)[reply]
Support Fuchs B (talk) 20:23, 17 February 2023 (UTC)[reply]
Oppose: Outside of CWS scope. Proposal for new projects go to Proposals for new projects. Wikimedia genealogy project is one such proposed project and might be what you're looking for. If not, start a new project proposal at the above link. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:14, 18 February 2023 (UTC)[reply]
Strong oppose Outside of the project goal, and as noted there are security/privacy concerns --Anonimo88 (talk) 16:41, 18 February 2023 (UTC)[reply]
Strong oppose Seboloidus (talk) 17:31, 18 February 2023 (UTC)[reply]
Support Crainsaw (talk) 11:44, 19 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:13, 21 February 2023 (UTC)[reply]
Support Would absolutely love it. Zimmy (talk) 14:20, 22 February 2023 (UTC)[reply]
Strong oppose There are specific professional organizations for this service accessible for free, no need to spend Wikimedia Foundation resources for just-an-other (amateur) ascendancy portal. These information meant to be connected, in the first place. And, as mentioned above, there are lots of privacy issues which are not in the normal workflow of Wikipedia participants. Madacs (talk) 20:36, 22 February 2023 (UTC)[reply]
Strong oppose This should be a new wiki for itself. Thingofme (talk) 01:51, 23 February 2023 (UTC)[reply]
Oppose I'm not against the idea but it would be better to create a new Wikimedia project, even if it will cost a little too much money when there are already Wikimedia projects that not many people watch. Manjiro91💬 12:20, 23 February 2023 (UTC)[reply]

Explore evasion methods of state-level censorship across Wikimedia movement

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

Edit proposal/discussion

Problem: As WMF's HRIA suggests, censorship is a major threat to Wikimedia movement, whose goal is to provide free educational content for everyone. Some governments, like China, have blocked access to Wikipedia entirely. This has significant impact to us:
- Reading: People from censored states (especially China) have to use 3rd-party proxies or manually configurate their device to access Wikipedia normally. This discourage users from accessing Wikipedia.
- Editing: Due to Wikimedia's block of open proxies and the complexity of IPBE requesting process, newcomers may feel frustrated and discouraged from participating in Wikimedia projects.
Proposed solution: The WMF can explore methods and provide official technical support for people from censored states (e.g. China) to read and edit Wikimedia projects directly without a VPN. This can solve both problems. If it is not feasible, we can refine our no open proxy policy and make it more friendly to newcomers, which can solve the user-engagement problem.
Who would benefit: People from censored states
More comments: I know fighting with state-level censorship is a cat-and-mouse game and requires a lot of resources, but I still believe there are some actions we can take rather than simply watch all sites get blocked finally.
Phabricator tickets: phab:T327286 (probably)
Proposer: Diskdance (talk) 08:37, 29 January 2023 (UTC)[reply]

Discussion

First step: What about integrating In-App domain fronting to evade censorship? Added ticket T327286.--Shinohara Chihiro (talk) 09:47, 29 January 2023 (UTC)[reply]
AFAIK WMF staff are internally working on trying to resolve the open proxy blocking issue, although this is still in early stages. See also Talk:No_open_proxies/Unfair_blocking#Help_from_WMF. Thanks. SCP-2000 10:48, 29 January 2023 (UTC)[reply]
Note that WMF facilitating circumvention methods (e.g. phab:T327286) is probably very complex, with many legal and security ramifications. On the other hand, there're quite a few smaller things that can be done to make it easier for users facing censorship to edit (e.g. phab:T306751). MarioGom (talk) 15:34, 29 January 2023 (UTC)[reply]
Not complex actually. My proposal contains no use of cloud providers or CDNs, it's as simple as modifying your hosts file. And I have given example implementations which is done by even personal, amateur app developers. Shinohara Chihiro (talk) 15:24, 31 January 2023 (UTC)[reply]
I have updated the proposal to clearify some ambiguities.--Diskdance (talk) 08:22, 30 January 2023 (UTC)[reply]
Mitigate the damage caused by proxy blocks is a similar but more realistic proposal. SmallJarsWithGreenLabels (talk) 18:57, 12 February 2023 (UTC)[reply]

Voting

Support Xbypass (talk) 20:09, 10 February 2023 (UTC)[reply]
Support Mapatxea (talk) 21:33, 10 February 2023 (UTC)[reply]
Support Joshbaumgartner (talk) 21:36, 10 February 2023 (UTC)[reply]
Support Significa liberdade (talk) 22:28, 10 February 2023 (UTC)[reply]
Support – allowing users in censoring countries to edit would also help with systemic bias. SmallJarsWithGreenLabels (talk) 23:01, 10 February 2023 (UTC)[reply]
Support Jensbest (talk) 23:42, 10 February 2023 (UTC)[reply]
Support Gohan 02:58, 11 February 2023 (UTC)[reply]
Support Lt2818 (talk) 03:29, 11 February 2023 (UTC)[reply]
Support Tgr (talk) 04:13, 11 February 2023 (UTC)[reply]
Support Goliv04053 (talk) 06:28, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:11, 11 February 2023 (UTC)[reply]
Support Muted Red Tulip (talk) 09:41, 11 February 2023 (UTC)[reply]
Support Oltrepier (talk) 10:09, 11 February 2023 (UTC)[reply]
Support SunDawn (talk) 12:39, 11 February 2023 (UTC)[reply]
Support Hehua (talk) 13:22, 11 February 2023 (UTC)[reply]
Support Bluerasberry (talk) 15:07, 11 February 2023 (UTC)[reply]
Support JopkeB (talk) 15:16, 11 February 2023 (UTC)[reply]
Support JrawX (talk) 15:51, 11 February 2023 (UTC)[reply]
Support Conny (talk) 18:08, 11 February 2023 (UTC)[reply]
Support Abzeronow (talk) 19:23, 11 February 2023 (UTC)[reply]
Support Fvtvr3r (talk) 13:49, 12 February 2023 (UTC)[reply]
Support Firestar464 (talk) 15:23, 12 February 2023 (UTC)[reply]
Support Pmorgan1998 (talk) 00:53, 14 February 2023 (UTC)[reply]
Support Libcub (talk) 05:54, 14 February 2023 (UTC)[reply]
Support Ottawajin (talk) 12:12, 14 February 2023 (UTC)[reply]
Support Just N. (talk) 14:56, 14 February 2023 (UTC)[reply]
Support please do not target China alone. Censorship is everywhere. Bert76 (talk) 09:31, 15 February 2023 (UTC)[reply]
Support Husky22 (talk) 19:25, 16 February 2023 (UTC)[reply]
Support I agree with Bert76. Kays (talk) 01:35, 17 February 2023 (UTC)[reply]
Support Dmytro Tvardovskyi (talk) 03:16, 18 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:54, 18 February 2023 (UTC)[reply]
Support One method the Great Firewall & perhaps other censors use is a w:TCP reset attack; when they detect something they do not like, they send a reset signal to both client & server, so the connection is dropped. It would certainly be possible to make WMF servers ignore such signals, or at least those from China, but I am not certain if that would have other consequences that might be problematic. Pashley (talk) 14:47, 18 February 2023 (UTC)[reply]
Support Jotamide (talk) 16:02, 18 February 2023 (UTC)[reply]
Support Vulcan❯❯❯Sphere! 16:42, 18 February 2023 (UTC)[reply]
Support Albinfo (talk) 22:39, 18 February 2023 (UTC)[reply]
Support Zache (talk) 05:40, 19 February 2023 (UTC)[reply]
Support Qxyz123 (talk) 04:39, 21 February 2023 (UTC)[reply]
Support _hugarheimur 09:56, 21 February 2023 (UTC)[reply]
Support PauAmma (talk) 12:25, 21 February 2023 (UTC)[reply]
Support MyCatIsAChonk (talk) 14:10, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:26, 21 February 2023 (UTC)[reply]
Support I absolutely love the idea of free knowledge for all. Cryorett (talk) 08:33, 22 February 2023 (UTC)[reply]
Support It is dangerous for Chinese users. Thingofme (talk) 01:49, 23 February 2023 (UTC)[reply]
Support Daniel Case (talk) 05:55, 23 February 2023 (UTC)[reply]

A way to see WhatLinksHere directly, excluding transcluded links

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

Edit proposal/discussion

Problem: Special:WhatLinksHere includes links via templates or other transcluded pages. This can make it difficult to trace and update redlinks after moves, e.g. after category renames. We can filter WhatLinksHere by namespace (thanks for this) so that we can first update any links that are in templates. However, we then have to wait 10 minutes or longer (sometimes much longer) for the daemons to update transclusions, before we can see the residual list of pages that link directly to the old page name and need editing one by one.
Proposed solution: Make a way to show only What Links Here directly from links coded in pages.
Who would benefit: Admins mopping up after CfD, AfD etc.
More comments: There is a workaround by searching in source, but this requires more typing & pasting.
Phabricator tickets:
Proposer: Fayenatic london (talk) 14:46, 2 February 2023 (UTC)[reply]

Discussion

Related tasks: T14396, T5241. Was on the wishlist for 2016. --Tgr (talk) 06:22, 5 February 2023 (UTC)[reply]
Way back, before every article seemed to have large navigation templates (say 2008), one of the first things I'd do after creating an article was to check "what links here". Inevitably I'd get something - maybe just something little - that would fit into the article. It was a nice trick until the mass navigation templates came along and 100s of (usually worthless) results would show up. Smallbones (talk) 16:06, 11 February 2023 (UTC)[reply]
Was also on Wishlist 2021: Community Wishlist Survey 2021/Search/Suggest to Exclude Indirect Linked Articles from "What links here" Akela (talk) 16:20, 13 February 2023 (UTC)[reply]
And in 2022: Community Wishlist Survey 2022/Miscellaneous/Allow filtering of WhatLinksHere to remove links from templates. --Pequod76^(talk) 17:03, 20 February 2023 (UTC)[reply]

Voting

Support Ngoclong19 (talk) 19:58, 10 February 2023 (UTC)[reply]
Support (Note that this means links that got included in a template that was transcluded) Aaron Liu (talk) 20:28, 10 February 2023 (UTC)[reply]
Support Use case: which pages link directly to a target which has become a disambiguation page and need to be fixed? Certes (talk) 21:44, 10 February 2023 (UTC)[reply]
Support Sabelöga (talk) 23:52, 10 February 2023 (UTC)[reply]
Support Graham11 (talk) 23:56, 10 February 2023 (UTC)[reply]
Support Lupe (talk) 00:12, 11 February 2023 (UTC)[reply]
Support SHB2000 (talk | contribs) 01:33, 11 February 2023 (UTC)[reply]
Support Hehua (talk) 02:40, 11 February 2023 (UTC)[reply]
Support * Pppery * _{it has begun} 04:07, 11 February 2023 (UTC)[reply