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]

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]
Support Tgr (talk) 04:45, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:30, 11 February 2023 (UTC)[reply]
Support //Lollipoplollipoplollipop::talk 10:09, 11 February 2023 (UTC)[reply]
Support Oltrepier (talk) 10:12, 11 February 2023 (UTC)[reply]
Support CaféBuzz (talk) 11:10, 11 February 2023 (UTC)[reply]
Support --Tucvbif (talk) 15:47, 11 February 2023 (UTC)[reply]
Support Smallbones (talk) 16:07, 11 February 2023 (UTC)[reply]
SupportWotheina (talk) 16:25, 11 February 2023 (UTC)[reply]
Support DGG (talk) 03:02, 14 February 2023 (UTC)[reply]
Support Yilku1 (talk) 17:19, 11 February 2023 (UTC)[reply]
Support Pallor (talk) 19:18, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:37, 12 February 2023 (UTC)[reply]
Support Betseg (talk) 03:40, 12 February 2023 (UTC)[reply]
Strong support, very important in everday work both interactively and by bot. Dissolve real links from template links is a resource-consuming task that not only for users, but servers as well. Bináris^{tell me} 12:59, 12 February 2023 (UTC)[reply]
Strong support, it would be a very useful feature, to select direct and indirect links. Akela (talk) 13:21, 12 February 2023 (UTC)[reply]
Support --everyone's favorite Blua lago(let's have a chat y'all) 13:43, 12 February 2023 (UTC)[reply]
Support SpiderMum (talk) 14:51, 12 February 2023 (UTC)[reply]
Support – Csurla (talk) 16:38, 12 February 2023 (UTC)[reply]
Support --Dodi123 (talk) 20:10, 12 February 2023 (UTC)[reply]
Support Waldyrious (talk) 04:51, 13 February 2023 (UTC)[reply]
Support Titore (talk) 14:51, 13 February 2023 (UTC)[reply]
Support Eiim (talk) 16:31, 13 February 2023 (UTC)[reply]
Support JAn Dudík (talk) 22:04, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 07:29, 14 February 2023 (UTC)[reply]
Support Just N. (talk) 14:53, 14 February 2023 (UTC)[reply]
Support —Locke Cole • t • c 08:58, 15 February 2023 (UTC)[reply]
Support ZandDev (talk) 10:09, 15 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 09:01, 16 February 2023 (UTC)[reply]
Support Hey man im josh (talk) 16:48, 16 February 2023 (UTC)[reply]
Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:30, 16 February 2023 (UTC)[reply]
Support Geraki ^T_L 20:01, 17 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:52, 18 February 2023 (UTC)[reply]
Support I think this is more achievable then we think if we just give priority to direct links over transclusions and then accept that that the transclusions data might have gaps in it. Technically, the link table is still 1 dimensional then (1 db row if a page refers to another resource) and you won’t know about all the multiple reasons a page refers to a link (which would make this a way way way harder problem). —TheDJ (talk • contribs) 13:53, 18 February 2023 (UTC)[reply]
Support Jotamide (talk) 16:01, 18 February 2023 (UTC)[reply]
Support Sir Gawain (talk) 00:00, 20 February 2023 (UTC)[reply]
Support — Draceane ^talk_contrib. 12:54, 20 February 2023 (UTC)[reply]
Support Yes, a way to see "What links here" which excludes, or distinguishes, the links which are from navbox templates, would be a great help PamD (talk) 15:50, 20 February 2023 (UTC)[reply]
Strong support --Pequod76^(talk) 17:03, 20 February 2023 (UTC)[reply]
Support cyrfaw (talk) 19:03, 21 February 2023 (UTC)[reply]
Support Paul_012 (talk) 20:55, 21 February 2023 (UTC)[reply]
Support Hkoala (talk) 17:34, 22 February 2023 (UTC)[reply]
Support This is important for sortings. Thingofme (talk) 01:56, 23 February 2023 (UTC)[reply]
Support Helder 10:58, 23 February 2023 (UTC)[reply]

Allow querying the Commons tabular data with the Wikidata Query Service to better support large numerical datasets

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 are notoriously bad at storing large numerical datasets. The user interface of Wikidata and some downstream applications may currently fail on large items (items with too many statements). Therefore, some potentially useful quantitative data such as annual average temperature records or precise population data split by ethnicity cannot be currently accessed by Wikidata users. The Wikidata community maintains that large numerical datasets should instead go to tabular data files^[1]^[2]^[3], CSV-like tables stored on Wikimedia Commons. There are also plenty of types of data that will never have properties on Wikidata that could be stored on Wikimedia Commons that still would be useful to be able to query about or reuse on Wikipedia. One of the reasons these tables are not so widely used is their inaccessibility to the Wikidata Query Service.

Proposed solution: Wikidata Query Service should be extended to be able to read from tabular data on Wikimedia Commons. It will likely require some standardization of the field names in the CSV files in Wikimedia Commons and a community discussion on that should be a part of the overall process.

Who would benefit: WikiProject Tabular data, the whole Wikidata community, and, by extension, the whole world profitting from a better open data infrastructure.
Phabricator tickets: phab:T181319
Proposer: Vojtěch Dostál (talk) 07:54, 30 January 2023 (UTC) and ♥Ainali ^talk_{contributions} 08:03, 30 January 2023 (UTC)[reply]

Discussion

This is likely to be too big to be in scope for Community Tech. It is a valid proposal though, so I will move to Larger Suggestions. Thanks for participating. DWalden (WMF) (talk) 13:29, 30 January 2023 (UTC)[reply]
@DWalden (WMF): @Abbe98 was friendly and pointed me to this implementation by @Yurik that might be an inspiration for a solution to this. ♥Ainali ^talk_{contributions} 16:35, 16 February 2023 (UTC)[reply]
@Ainali Thanks! DWalden (WMF) (talk) 12:59, 17 February 2023 (UTC)[reply]
Both structured data from Wikidata (via WDQS) and tabular data (from Commons) can be read in a machine readable form, so it is up to the user to use common spreadsheet software to combine both datasets (LibreOffice Calc, MS Excel, Google Docs, but also DataFrames as in Python/pandas etc.). I don't think we should impose format constraints to make both worlds "compatible", and I don't think that WDQS should be loaded with even more secondary functionality. It is useful for the rather simple stuff, but it is not the one tool to solve problems of arbitrary complexity. —MisterSynergy (talk) 21:14, 10 February 2023 (UTC)[reply]

Voting

Support Strainu (talk) 20:19, 10 February 2023 (UTC)[reply]
Support EpicPupper (talk) 05:38, 11 February 2023 (UTC)[reply]
Support OwenBlacker (Talk) 14:44, 11 February 2023 (UTC)[reply]
Support Bluerasberry (talk) 15:04, 11 February 2023 (UTC)[reply]
Support CROIX (talk) 15:20, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:52, 11 February 2023 (UTC)[reply]
Support Matěj Suchánek (talk) 18:39, 11 February 2023 (UTC)[reply]
Support Moebeus (talk) 00:21, 13 February 2023 (UTC)[reply]
Support Mahir256 (talk) 00:29, 13 February 2023 (UTC)[reply]
Support Izno (talk) 07:58, 13 February 2023 (UTC)[reply]
Support JAn Dudík (talk) 21:59, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 06:00, 14 February 2023 (UTC)[reply]
Support ArthurPSmith (talk) 21:14, 17 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:35, 18 February 2023 (UTC)[reply]
Support Vulcan❯❯❯Sphere! 16:37, 18 February 2023 (UTC)[reply]
Support Zache (talk) 05:38, 19 February 2023 (UTC)[reply]
Support Jklamo (talk) 12:26, 19 February 2023 (UTC)[reply]
Support β₁₆ - (talk) 14:33, 20 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:00, 23 February 2023 (UTC)[reply]
Support Althair (talk) 04:13, 23 February 2023 (UTC)[reply]
Support Stevenliuyi (talk) 12:46, 23 February 2023 (UTC)[reply]

Develop community wishlist into crowdfunding platform

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: Too few community wishlist items get implemented each years, those that are implemented took too long to develop, not enough funding allocated by WMF to push these community wishes
Proposed solution: Let people put their money behind their ideas and use the money to hire professional people to contribute toward specific woshes once they are filled.
Who would benefit: Every Wikipedia users, and WMF
More comments: WMF can also get more donation from the process, and the Mediawiki can get more help in becoming more polished.
Phabricator tickets:
Proposer: C933103 (talk) 12:50, 30 January 2023 (UTC)[reply]

Discussion

Hello there @C933103, the Wikimedia Technology Fund may relate to the desired functionality of this wish. We've discussed this wish as a team. We are moving it to Larger Suggestions and brainstorming ways to receive feedback on the Wishlist process. Let us know if the Grants information helps with this idea! Thanks. NRodriguez (WMF) (talk) 19:50, 30 January 2023 (UTC)[reply]

Those funds require technical knowledges and expendable time that many users might not have. They also use up existing WMF funding instead of attracting more funding for the project. It would be like the opposite of the project: The grant programs mentioned let people who have time and technology contribute by receiving financial help from WMF, while the proposed crowdfunding would allow people provide financial assistance to development in specific way they desire in exchange for third party time and effort to help with development. C933103 (talk) 00:59, 31 January 2023 (UTC)[reply]

Putting a donation button on the relevant toolhub page would be nice. Most professional code forges have similar functionality. (Vaguely related discussion: T231814) --Tgr (talk) 03:15, 31 January 2023 (UTC)[reply]
This idea isn't possible (the methodology might be up for grabs, but true crowdfunding attached to ideas could be implemented). There would be fairly substantial queries about what to do with ideas that get some money but not really enough to act on - say a string of ideas with £5000. Nosebagbear (talk) 09:55, 31 January 2023 (UTC)[reply]
Usually crowdfunding platforms just return the money when that happens. Tgr (talk) 00:29, 1 February 2023 (UTC)[reply]
Just lump it in with wikimedia's general funds. So long as that result is made clear up front, I see no problem with it. Geofferic (talk) 20:14, 10 February 2023 (UTC)[reply]
WMF has enough money to fulfill most of the wishes from CWS. --NGC 54 (talk｜contribs) 01:32, 12 February 2023 (UTC)[reply]
If only they didn't give away so much to the Tides Foundation... Firestar464 (talk) 15:22, 12 February 2023 (UTC)[reply]

Voting

Support Geofferic (talk) 08:29, 12 February 2023 (UTC)[reply]
Support Libcub (talk) 06:14, 14 February 2023 (UTC)[reply]
Oppose There is enough money already, the WMF isn't in debt or something. So, there's no need for crowdfunding. I'd rather suggest crowdsourcing. If you want things get done faster, make it possible for community volunteers and/or non-Wikimedian programmers to claim a CWS task and work on it for some stipend. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:50, 18 February 2023 (UTC)[reply]
Support Jklamo (talk) 12:21, 19 February 2023 (UTC)[reply]
Support cyrfaw (talk) 13:42, 23 February 2023 (UTC)[reply]
Support منى ناصر ثابت علام حُزين (talk) 16:45, 23 February 2023 (UTC)[reply]

Keep Chinese (zh) editors safe

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: According to unnamed reliable source(s), Internet operators in mainland China (i.e. controlled by CCP & with GFW) often disable proxying or VPN being used by Wikimedia project editors, right after clicking on the "Publish / Show changes / preview" or during generating references by "automatic tab", which means those operators could identify Wikimedia project uploads. Thereby, combining detected upload traffics to Wikimedia project with publicly available "Recent changes" stats, mainland Chinese authorities might identify and locate individuals responsible for specific changes with unique features - the time and "byte size change" displayed on "Recent changes". In recent years, moreover, separate residents there have been caught, detained and even arrested, as claimed by mainland Chinese authorities, simply for viewing Wikipedia or Youtube without posting anything. Additionally, given that local laws require Internet operators to keep weblogs containing personal information for at least 6 months, editors of conscience located in Mainland China and even future Hong Kong and Macau inevitably face severe ricks including political repressions, maybe tougher than in Russia. Therefore, erasing or recoding "date / time stamp", "byte size change" and any other doxing-inducing stats should be done as follows in all chinese (zh) Wikimedia projects since 2022.
Proposed solution: Apply to all chinese (zh) Wikimedia projects since 2022:

Conceal exact "byte size change" and classify that into several grades, e.g.
- within ±20 bytes as "light" (輕); between ±21 and ±500 bytes as "medium" (中); more than ±500 bytes as "weighty" (重); or
- ~10~70~500~ or ~10~100~1000~ into 4 grades.
Conceal the actual time of each edit on "Recent changes", "History", "Watchlist" and similar pages in that date and order would be sufficient.
Recode and disguise timestamp where signature is needed such as talk / wiki- pages by one of two following ways:
1. Replace last digit of timestamp by an English letter assigned in line with the order of post in the thread within 10-minute period. E.g. if there are 2 comments posted at 14:20~30 (UTC) on the same day in the same thread, their timestamps should be 14:2A (UTC), 14:2B (UTC) respectively. In case of more than 26 comments emerged in the same thread within 10-minute period, Roman numerals would function like 14:2ⅡA, 14:2ⅡB, etc. OR
2. Replace timestamp by purely ordinal numbers assigned in line with the order of post in the thread history while remaining date unchanged. E.g. if in 2023 someone replied to a thread contained 3 comments from past years, the date / time stamp might be "#04 26 January 2023" (2023年1月26日 #04); if there are more than 99 comments in the same thread, corresponding number should be in place of "#".
Automatically delay the release of "Recent changes", "Watchlist" and "History" for each page ranging from 0 to 120 seconds, so as to mislead real-time crawling, while all edits are published immediately and "History" for each page are arranged in actual order. However, likely "bad-faith" or "problem" edits, changes to top edited articles in the latest hours or by recently (un)blocked users and protected titles creations should be excluded and their records displayed instantly.
Refactor links, elements and code that may reveal the actual time of edits.
Reframe and disguise data traffic of Wikimedia sites, especially uploads.
Automatically conceal essential personal information of user without any edit or log action in the past 6 months as default - which users could reject. Those information includes location, contacts and more.
Request the Internet archivers to delete all user page archives that contain the following userbox or word:
1. Anti- CCP / Xi Jinping / PRC / Tiananmen Square Massacre;
2. Pro- DPP / Pan-democracy camp / Occupy Central / Umbrella Revolution / 2019 HK protests;
3. Support independence of Taiwan / HK / Macau / Tibet / Uyghur.

Meanwhile, neither any (interface-) admin nor anyone else could access any concealed details, except certified Foundation staff.

Who would benefit: Chinese (zh) editors
More comments: Chinese (zh) Wikimedia projects means all Sinitic languages (Chinese languages) projects, including Southern Min (Min-nan / nan), Eastern Min (Cdo), Cantonese (Yue), Wu (Wuu), Classical Chinese (zh-classical / lzh), Hakka Chinese (Hak), Gan ones. Gohan 03:25, 11 February 2023 (UTC)[reply]
Phabricator tickets:
Proposer: Gohan 07:04, 30 January 2023 (UTC)[reply]

Discussion

This should be discussed on zhwiki Village pump first. It is out of the scope of Community Wishlist Survey. Thanks. SCP-2000 09:00, 30 January 2023 (UTC)[reply]

Less active zh (chinese) communities, where it is difficult to discuss effectively, have more pressing needs, since their upload datas are easier to be identified. Gohan 03:13, 11 February 2023 (UTC)[reply]

@神秘悟饭: have you informed Trust and Safety of these concerns ? —TheDJ (talk • contribs) 10:45, 30 January 2023 (UTC)[reply]
Not yet. Gohan 10:47, 30 January 2023 (UTC)[reply]
If these are reliable sources, surely they could be named here? MarioGom (talk) 20:56, 31 January 2023 (UTC)[reply]
This seems pointless. You cannot meaningfully hide diff sizes without hiding the wikitext of the involved revisions; you cannot hide upload sizes without hiding the uploaded file. I suppose you could obfuscate timestamps but it would do little to prevent deanonymizing someone who makes several edits. Using a proxy solution that the ISP is able to turn off just seems like a bad idea. Explore evasion methods of state-level censorship across Wikimedia movement szerkesztése seems like a more feasible approach. (Or doing something about Tor blocks, etc.) --Tgr (talk) 00:19, 1 February 2023 (UTC)[reply]
Yeah, it can't eliminate risks entirely. But the whole idea is to drastically increase the cost for catching wanted editors, forcing 99.9% of Chinese cyber police to give up their attempts. WMF censorship circumvention is more helpful, which brings concerns about how long it will work, and recalls memories of escalating VPN interfered and disconnected escalatingly that WMF's approach will be treated the same way. Also, censorship circumvention would not allay doubts about point 7 above. Gohan 04:20, 1 February 2023 (UTC)[reply]
So why don't simply hide username in the article history? Thanks. --SCP-2000 04:41, 1 February 2023 (UTC)[reply]
If so, I don't know how the community can figure out who's responsible for specific edit. Gohan 04:49, 1 February 2023 (UTC)[reply]
I mean, using Revision Deletion to hide username. Technically sysop (and oversighter) still could figure out who's responsible for specific edit. Thanks. SCP-2000 05:48, 1 February 2023 (UTC)[reply]
This can only hide the link between multiple edits by one user, not the link between one single detected edit with publicly visible time & byte size change and the netizen behind. Gohan 06:56, 1 February 2023 (UTC)[reply]

Moreover, not every zh local sysop may be trusted. Gohan 07:00, 1 February 2023 (UTC)[reply]

I don't know whether zh wikipedia uses similarly free licensing, but on enwp you can't do this because of copyright issues. In addition, I don't think I have to explain that there are a lot of issues with hiding the underlying identity of 90% of edits on zh wikipedia. Snowmanonahoe (talk) 14:39, 22 February 2023 (UTC)[reply]

In addition, direct connections with Wikimedia are still available in Hong Kong. We cannot force all Hong Kong users to use censorship circumvention method. Even if censorship circumvention works really well, Hong Kong National Security Police, which spends HK$8 billion a year on 7 million citizens, will have no trouble finding Hong Kong editors with direct connections. Gohan 04:56, 1 February 2023 (UTC)[reply]
People at risk should probably use some technology that hides their traffic entirely (such as Tor). Using unreliable security measures can be worse than not having security measures at all, as it gives a false sense of security and people might do things they wouldn't do if they realized that their edits can be traced back to them. Unless Wikipedia gets rewritten from scratch, there will always be many ways edit timestamps and sizes can be recovered, as the entire software stack was designed to be private about reading but transparent about editing. That might not be a satisfying answer but that's just the reality we have to work with IMO. (I'm not a censorship expert or anything but have been following work in this area for a while.) Tgr (talk) 07:46, 5 February 2023 (UTC)[reply]
One way or another, these Chinese editors (and other people at risk for political reasons) should be protected by Wikimedia. Perhaps a list with measures they can take themselves, supplemented with technical measures Wikimedia can take, as asked here. --JopkeB (talk) 14:56, 11 February 2023 (UTC)[reply]

Voting

Support TheAmerikaner (talk) 20:24, 10 February 2023 (UTC)[reply]
Support Great idea Pmsyyz (talk) 01:14, 11 February 2023 (UTC)[reply]
Support Hehua (talk) 02:34, 11 February 2023 (UTC) Weak oppose per scp--Hehua (talk) 13:18, 11 February 2023 (UTC)[reply]
Oppose Per Tgr above comments. And this should be discussed on zhwiki first. Thanks.--SCP-2000 03:03, 11 February 2023 (UTC)[reply]
Less active zh (chinese) communities, where it is difficult to discuss effectively, have more pressing needs, since their upload datas are easier to be identified. So where to discuss would be a problem. Gohan 03:10, 11 February 2023 (UTC)[reply]
Oppose The Chinese Wikipedia community haven't been informed of this propose, nor have the Trust and Safety team. Without a community consensus, I don't think the community will go along with this kind of action. --BlackShadowG (talk) 03:40, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:36, 11 February 2023 (UTC)[reply]
Support Smetanakaviar (talk) 12:10, 11 February 2023 (UTC)[reply]
Support HumbleLady (talk) 13:41, 11 February 2023 (UTC)[reply]
Support OwenBlacker (Talk) 14:45, 11 February 2023 (UTC)[reply]
Support JopkeB (talk) 14:55, 11 February 2023 (UTC)[reply]
Support There is very little documented conversation between Wikimedia Foundation and community groups with safety issues. Bluerasberry (talk) 15:06, 11 February 2023 (UTC)[reply]
Support Abzeronow (talk) 19:21, 11 February 2023 (UTC)[reply]
Weak oppose People should be free to make expressions in favor of the pro-democracy camp and/or speak fankly about Tienanmen Square without us rushing to delete their user pages. I don't know that the community would actually go for this, and these very same measures that are aimed to protect user privacy would also make it a lot easier to sock on the project without being detected. Wikipedians have so much fewer resources than nation-states, and while it would probably protect both good-faith editors and sockmasters from other Wikipedians, I'm not sure that the proposed solution above would be anywhere near enough to protect editors from the Chinese state. — Red-tailed hawk _(nest) 21:42, 11 February 2023 (UTC)[reply]
Point 8 only aims at external page archives, neither the current user page nor in Wikimedia sites. So it wouldn't limit free speech. And in fact, many Chinese Wikipedians have asked to delete their user pages out of the same concern. Gohan 02:32, 12 February 2023 (UTC)[reply]
Support Ivario (talk) 22:02, 11 February 2023 (UTC)[reply]
Support 我虽然用镜像站参与编辑，但仍旧冒着一定风险。此举对于和我一样身处中国大陆的编辑者来说无疑是社群给予的一重保障。/Although I participated in editing with the mirror site, I still took some risks. This is undoubtedly a guarantee given by the community to editors in Chinese Mainland like me. 范博2004 (talk) 01:42, 12 February 2023 (UTC)[reply]
Strong support QuickQuokka ^{[⁠talk • contribs]} 17:25, 12 February 2023 (UTC)[reply]
Support PtolemyXV (talk) 18:50, 12 February 2023 (UTC)[reply]
Support Libcub (talk) 06:21, 14 February 2023 (UTC)[reply]
Support Mikxth (talk) 11:53, 14 February 2023 (UTC)[reply]
Support Lion-hearted85 (talk) 11:56, 14 February 2023 (UTC)[reply]
Support ZandDev (talk) 11:22, 15 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:42, 18 February 2023 (UTC)[reply]
Support Lupe (talk) 14:37, 18 February 2023 (UTC)[reply]
Support Vulcan❯❯❯Sphere! 16:34, 18 February 2023 (UTC)[reply]
Oppose This is too much an “adapt to the circumstances” approach, it does not “fight” any measures. It singles out the PRC, but other entities monitor WP, too. Kays (talk) 04:19, 19 February 2023 (UTC)[reply]
Oppose As talked about in the discussion section, this doesn't really solve the problem. Zhwiki should advise their users to use Tor browser maybe. It's up to them to figure it out, not the WMF. Snowmanonahoe (talk) 14:49, 22 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:13, 23 February 2023 (UTC)[reply]
Support cyrfaw (talk) 13:42, 23 February 2023 (UTC)[reply]
Support E0126E (talk) 02:23, 24 February 2023 (UTC)[reply]

View the history of a section, add a section to the watchlist

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: Sometimes a user (like me) only follows a certain/chapters in a certain article，Now if I want to monitor these chapters, I can only click "View History", and then click on all the new edits that may have edited these chapters to see if there are edits about these chapters, which is very troublesome. I wish there was a handy tool for monitoring chapters.
Proposed solution: Added "view history of certain/some chapters" and/or "monitor certain/some chapters" functionality
Who would benefit: Users who do not follow the entire article, but only certain sections of it
More comments:
Phabricator tickets:
Proposer: GUT412454 (talk) 03:35, 24 January 2023 (UTC)[reply]

Discussion

@GUT412454: If I'm understanding your proposal correctly (via machine translation, sorry), you're asking for a way to watch page sections. This is tracked in phab:T2738 (open since 2004!) and was also proposed in the 2015 and 2016 Wishlist Surveys. Note that watching sections of talk pages is now possible thanks to DiscussionTools' TopicSubscriptions feature, but it sounds like you're talking about articles. SWilson (WMF) (talk) 04:09, 24 January 2023 (UTC)[reply]
- Yes. But you missed another proposal: view history of a section. GUT412454 (talk) 08:36, 24 January 2023 (UTC)[reply]
  - @GUT412454: Oh great, understood. That makes sense. SWilson (WMF) (talk) 08:49, 24 January 2023 (UTC)[reply]
I doubt this is feasible without way more resourcing than what the Wishlist has. Would require a 1) a new recentchanges table for sections, which would be larger than the normal RC table, which is already a performance nightmare; 2) probably some kind of section title normalization, like the recent linktarget table; 3) identifying which sections have been edited, which means messing with the parser. Maybe worth revisiting after T307328 gets fixed. --Tgr (talk) 04:48, 30 January 2023 (UTC)[reply]
@Tgr: That's probably true for the section watchlist, but what about viewing history of a section? I feel like these two things might be better off as separate wishes. SWilson (WMF) (talk) 06:51, 30 January 2023 (UTC)[reply]
@SWilson (WMF) they are both infeasible though. The revision table is so large that the last structural change to it took two years to run, and here you'd have to process every edit on top of that to fill up the revision-to-section mapping table. That's even more daunting than doing something similar to recentchanges. Tgr (talk) 01:21, 1 February 2023 (UTC)[reply]
@Tgr: Good point. Thanks. @GUT412454: I'll move this to Larger suggestions because it's too big for the wishlist. SWilson (WMF) (talk) 01:51, 1 February 2023 (UTC)[reply]
Putting feasibility aside for a moment, this would be especially useful for forums such as ANI and VPT which host multiple simultaneous discussions, of which only a few will interest the typical editor. Certes (talk) 00:08, 2 February 2023 (UTC)[reply]

Voting

Support being able to follow one VPT or ANI section without being alerted to every comment on every discussion there. Certes (talk) 21:49, 10 February 2023 (UTC)[reply]
Support Sabelöga (talk) 23:55, 10 February 2023 (UTC)[reply]
Support Skimel (talk) 00:41, 11 February 2023 (UTC)[reply]
Support Klein Muçi (talk) 00:42, 11 February 2023 (UTC)[reply]
Support * Pppery * _{it has begun} 04:05, 11 February 2023 (UTC)[reply]
Support EpicPupper (talk) 05:39, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:34, 11 February 2023 (UTC)[reply]
Support Muted Red Tulip (talk) 10:09, 11 February 2023 (UTC)[reply]
Support Sabiusaugustus (talk) 11:44, 11 February 2023 (UTC)[reply]
Support OwenBlacker (Talk) 14:43, 11 February 2023 (UTC)[reply]
Support Mike bzh (talk) 15:47, 11 February 2023 (UTC)[reply]
Support MoreInput (talk) 19:43, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:23, 12 February 2023 (UTC)[reply]
Support Gohan 05:02, 12 February 2023 (UTC)[reply]
Support Maxwxyz (talk) 12:49, 12 February 2023 (UTC)[reply]
Support It will be useful, because sometimes I'm editing small part of big article. and I want to see just interesting points of my article German Stimban (talk) 04:12, 13 February 2023 (UTC)[reply]
Support Doktor Züm (talk) 15:52, 16 February 2023 (UTC)[reply]
Support 40bus (talk) 19:56, 17 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:15, 18 February 2023 (UTC)[reply]
Support NaBUru38 (talk) 18:46, 20 February 2023 (UTC)[reply]
Support Qxyz123 (talk) 04:17, 21 February 2023 (UTC)[reply]
Support Thingofme (talk) 01:52, 23 February 2023 (UTC)[reply]
Support Althair (talk) 04:16, 23 February 2023 (UTC)[reply]
Support This would be very useful Daniel Case (talk) 06:00, 23 February 2023 (UTC)[reply]
Support cyrfaw (talk) 13:44, 23 February 2023 (UTC)[reply]

Report problem button for reader

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: Reader might find a problem with the text (article), but are not willing (for whatever reason, we won't discuss them here) to edit out the problem themselves. It could be factual error, possible error (the reader is uncertain), technical error, or other kind of problems.
Proposed solution: Provide tools for anonymous reader (or logged in Wikimedian as well) to give a quick feedback about the quality of the article.

Is this article useful for you? (yes/no)
Report error (with comments)

Then the reports would be automatically compiled, visible for public, and could be sorted by highest number of reports for active editors to handle the problem.

Technically I realize this would be challenging, but Wikimedia should stop treating the reader as passive observer whose only option after spotting mistake are either edit themselves or ignoring them.

I envision that there's a way to reset the usefulness and errors reported (that have been handled) so they keep being relevant and not outdated.

Is this article useful for you? (yes/no) -> the value would reset each month? They would be tabulated in a special statistics (i.e. the most useful/un-useful article of January 2023), similar, but more useful IMO than monthly pageviews.
Report error (with comments) -> It could automatically saved in the talk page (therefore increasing the usefulness of the talk pages), and admins/editors could mark them as resolved/won't be resolved/invalid/etc.. [Don't forget to automatically add the permalink to the version the reporter read]

Who would benefit: The general quality of the Wikipedia (or other projects) would hopefully increase, since we could easily identify problematic contents early and handle them soon, before getting worse (an uncaught vandalism for days, etc.). Admins and active editors would be glad if they could catch these vandalism and/or inaccuracies earlier. (rather than for example waiting for it to go viral on social media). Anonymous general reader would feel empowered and acknowledged, and they can participate easier without having to edit and/or creating account
More comments: In light of the unavailability of quality measurement that are common in social media (likes/disliks, thumbs up/down) or engagement measurements (comments), it's quite hard to know which content are problematic from the reader point of view (reader numbers > editor numbers). Some of the bad actors (or frustrated reader who didn't make the effort to edit the problem themselves) may vent out by posting in social media with the screenshot of the problematic content/vandalism, and such would be detrimental to the movement in general.
Phabricator tickets:
Proposer: ✒ Bennylin 10:47, 1 February 2023 (UTC)[reply]

Discussion

See mw:Article feedback/Version 5. That was an official WMF project for about two years. Got chopped because the community found the burden of reviewing and moderating feedback too heavy, and the WMF didn't want to invest a lot of resources (after already investing a lot of resources and not gaining acceptance). --Tgr (talk) 05:48, 5 February 2023 (UTC)[reply]
Having said that… this rejection and burden, to a large extent, was because the feedback went into a separate system, with separate reviewers and no RC bots reverting vandalism etc. So maybe if it just dumped reports on talk pages and then used the new section index of discussion tools or something to keep track of them and compile some reports out of. —TheDJ (talk • contribs) 11:08, 5 February 2023 (UTC)[reply]
I think this could be useful, but only if it provides a structured method for users who may be unfamiliar with the nuances of a particular area of content to provide useful input to whatever community is focused on that area. For example, I work a lot on Commons Categories for Discussion. When browsing a category, there is a link "Nominate category for discussion" which allows a user to start a new discussion on a category and give a free form comment about why. This is handy, but we do get a reasonable number of discussions on the CfD page that are not well formed and are hard to act on. Even when it is clear why the submitting user has posted (e.g. they simply say "duplicate category"), then experienced users have to prompt for more details (response rate is often low), or do research on their own to figure out the situation. Often, the discussion ends up getting closed (or left in backlog) without action and the user sees no result so is not interested in improving their engagement with the process. Thus I think it is best if it is a more structured process that prompts the user to share exactly what is the problem, what they would like to see get done, and (contextual to the specific issue being reported) detailed information to allow responders to quickly address the issue. This will necessitate specific communities being able to actively participate in crafting this process and refining it over time to facilitate that community's needs. Joshbaumgartner (talk) 21:34, 10 February 2023 (UTC)[reply]
This could be helpful, too, for individuals who feel uncomfortable editing a page due to lack of sourcing and/or connection to the subject. I recently had some trying to reach out for help on a Talk page, then contacting someone in a related Wiki Project because their own Wikipedia page had incorrect information on it (in this case, their date of birth). They did not feel comfortable editing it but wanted the information updated. I feel like this could cause some issues with spamming, but I think it fits well into the overarching goals of Wikipedia. I wonder if instead of going to a general location, the related projects could be pinged, so the notification could be added for relevant users. Significa liberdade (talk) 22:24, 10 February 2023 (UTC)[reply]

Just recently watching the promotional video of the next gen search engine, (youtu. be/rOeRWRJ16yY?t=1432) even they put thumb up, thumb down button for query results now (and I suspect report for problem as well). ✒ Bennylin 15:57, 14 February 2023 (UTC)[reply]

Voting

Support Sounds great, it could be comparable to OpenStreetMap. TheAmerikaner (talk) 20:18, 10 February 2023 (UTC)[reply]
Support Strainu (talk) 20:18, 10 February 2023 (UTC)[reply]
Support Sicarov (talk) 21:01, 10 February 2023 (UTC)[reply]
Support SeGiba (talk) 21:16, 10 February 2023 (UTC)[reply]
Support Significa liberdade (talk) 22:19, 10 February 2023 (UTC)[reply]
Strong support PureTuber (talk) 22:20, 10 February 2023 (UTC)[reply]
Support Geert Van Pamel (WMBE) (talk) 23:16, 10 February 2023 (UTC)[reply]
Oppose If people aren't using the talk page, then we need to make it more prominent. We don't need an additional system glued on top. Having what's basically a suggestions box also counters the message that "anyone can edit" and discourages boldness. SmallJarsWithGreenLabels (talk) 23:30, 10 February 2023 (UTC)[reply]
I absolutely support your opinion - theres no reason to have additional function for something that is already available. Tbartovic (talk) 20:11, 16 February 2023 (UTC)[reply]
Support Jensbest (talk) 23:42, 10 February 2023 (UTC)[reply]
Oppose disencourages participation and instead leads to more of a consumer culture. The test in German Wikipedia also showed that there isn't really coming additional valuable input, mostly just questions that are already answered in the respective article or vandalism. It would be more burden than use for the community. Lupe (talk) 00:37, 11 February 2023 (UTC)[reply]
Support Pmsyyz (talk) 01:14, 11 February 2023 (UTC)[reply]
Support Exilexi (talk) 09:01, 11 February 2023 (UTC)[reply]
Strong support Most of the people don't want to register Wikipedia and there is consumerist culture: “I see a problem, so 'they' must see it too”. It is very relevant for minor languages, where there are not many editors to fix and track everything. For a regular non-wiki person it is easier to write “they made a mistake, better use other language”, than to write directly “you've made a mistake here”. But maybe, it must be also a choice of every project to use or to reject this system. Maybe it is only relevant for minor languages. Plaga med (talk) 11:42, 11 February 2023 (UTC)[reply]
Support --Crosstor (talk) 13:59, 11 February 2023 (UTC)[reply]
Support Bluerasberry (talk) 15:07, 11 February 2023 (UTC)[reply]
Support Huxly (talk) 20:26, 11 February 2023 (UTC)[reply]
Support Ivario (talk) 22:02, 11 February 2023 (UTC)[reply]
Support Gohan 04:59, 12 February 2023 (UTC)[reply]
Support General Editor (talk) 06:31, 12 February 2023 (UTC)[reply]
Support Tryvix ^t 13:55, 12 February 2023 (UTC)[reply]
Oppose We have talk pages and "be bold" for that. --Firestar464 (talk) 15:32, 12 February 2023 (UTC)[reply]
Support QuickQuokka ^{[⁠talk • contribs]} 17:31, 12 February 2023 (UTC)[reply]
Support PtolemyXV (talk) 18:53, 12 February 2023 (UTC)[reply]
Support Syunsyunminmin 🗨️talk 14:08, 13 February 2023 (UTC)[reply]
Support JAn Dudík (talk) 22:00, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 05:57, 14 February 2023 (UTC)[reply]
Support While a few have commented that this discourages "boldness," it might have the opposite effect. Someone who sees their input transformed into an article improvement might be motivated by this small initial success to get more deeply involved in the editing process themselves. Newbies can be discouraged when they try to be bold from the start and contribute a large amount of text to an article - only to see much of it deleted because they have unknowingly contravened one of the many Wikipedia rules (that are largely unknown to casual editors). It could also be of assistance to those for whom English is a second or third language. Many of these users may have enough background knowledge on a topic to recognize and flag simple factual errors in an English text, but not yet have the ability or the confidence to write in a formal encyclopedic style. This would open the door for them to contribute in a small way to the improvement of English Wikipedia. Ottawajin (talk) 12:51, 14 February 2023 (UTC)[reply]
We already have talk pages; why would this be any better? I agree based on interacting with IRL friends that there's a disappointing lack of will to even make a note of basic problems on the page, but creating a three-layered system of suggest, talk, and edit can only make things more intimidating. I think adding something simple like a [leave a note at the talk page] link after [edit] in each section heading would be much better for encouraging participation. SmallJarsWithGreenLabels (talk) 12:42, 17 February 2023 (UTC)[reply]
Support needed Bert76 (talk) 09:30, 15 February 2023 (UTC)[reply]
Support ZandDev (talk) 09:58, 15 February 2023 (UTC)[reply]
Strong support The-erinaceous-one (talk) 10:56, 15 February 2023 (UTC)[reply]
Support Mike gigs (talk) 15:32, 15 February 2023 (UTC)[reply]
Support Strangesnow (talk) 00:47, 16 February 2023 (UTC)[reply]
Support Casual readers don't know about talk pages, and wouldn't use them if they did. Non-technical readers struggle editing WP, or won't even try. Doktor Züm (talk) 07:28, 16 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 09:08, 16 February 2023 (UTC)[reply]
Support JFremd (talk) 16:21, 16 February 2023 (UTC)[reply]
Support Fuchs B (talk) 20:21, 17 February 2023 (UTC)[reply]
Support Dmytro Tvardovskyi (talk) 03:15, 18 February 2023 (UTC)[reply]
Support Jayro79 (talk) 07:23, 18 February 2023 (UTC)[reply]
Oppose This is essentially asking for implementation of an issue tracking system. You really want to track which “problems” have been resolved and how (e. g. “won’t fix” vs. “fixed in revision 123”). Kays (talk) 04:04, 19 February 2023 (UTC)[reply]
Support Althair (talk) 01:57, 20 February 2023 (UTC)[reply]
Support - The “suggestion box” could simply generate a new topic on the article’s Talk page. That’s already where COI editors discuss proposed changes. That’s exactly what’s being solicited by this functionality. Zsinj (talk) 03:12, 20 February 2023 (UTC)[reply]
Support Cmarsch (talk) 06:30, 20 February 2023 (UTC)[reply]
Support Augend (talk) 07:58, 20 February 2023 (UTC)[reply]
Support PamD (talk) 16:01, 20 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:24, 21 February 2023 (UTC)[reply]
Support Knowing how hard Wiki is to edit, a knowledgeable users should be able at least to describe what's the problem to assign a competent editor to the problem. Santropedro (talk) 01:29, 22 February 2023 (UTC)[reply]
Support May be useful for readers. Thingofme (talk) 01:46, 23 February 2023 (UTC)[reply]
The duality between "readers" and "editors" is just the problem here. SmallJarsWithGreenLabels (talk) 17:11, 23 February 2023 (UTC)[reply]

Add VisualEditor or a similar tool to the 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: Source editing on mobile is very awkward, especially things like tweaking markup with large fingers.
Proposed solution: Add a visual editor to help with this, possibly similar to mobile apps for document editors.
Who would benefit: As many readers – especially those less likely to be familiar with wikitext – read using the mobile app, a more accessible editing tool on the platform would help more casual readers turn into editors, which would help the project.
More comments:
Phabricator tickets: T276785, T302615
Proposer: DecafPotato (talk) 19:05, 23 January 2023 (UTC)[reply]

Discussion

I think this is a good idea, but I also think that it should be an opt-in option toggled in the settings rather than accessible by default to minimize vandalism. DJ Cane (talk) 08:45, 24 January 2023 (UTC)[reply]
The mobile web already has a visual editor, so adding this to the mobile app should be workable. I think the features should be minimal, much like the visual editor in the mobile web. Hanif Al Husaini (talk) 11:58, 24 January 2023 (UTC)[reply]
I think we should add VE for mobile app - many people are using mobile app for Wikipedia editing. Thingofme (talk) 12:10, 29 January 2023 (UTC)[reply]
We may have which combines features of main Wikipedia and commons Wikimedia, works for both android and IOS, also even if user tries to access Wikipedia on mobile browser it should automatically redirects to mobile version for VisualEditor mode.--Work2win (talk) 13:34, 29 January 2023 (UTC)[reply]
I agree this might sound like a tantalizingly simple task, but it's vastly more complex under the hood, and would require significant architectural changes in the way the apps work, as well as the backend service layer. Therefore moving this to Larger Suggestions. DBrant (WMF) (talk) 16:50, 31 January 2023 (UTC)[reply]

Voting

Support Sabelöga (talk) 23:52, 10 February 2023 (UTC)[reply]
Support AirbusA220 (talk) 07:22, 11 February 2023 (UTC)[reply]
Support Kekavigi (talk) 09:21, 11 February 2023 (UTC)[reply]
Support This will increase engagement from mobile users. Editing from mobile (even with an app) is atrocious right now. SunDawn (talk) 12:40, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:53, 11 February 2023 (UTC)[reply]
Support VastV0idInSpace0 (talk) 20:44, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:28, 12 February 2023 (UTC)[reply]
Support Gohan 05:05, 12 February 2023 (UTC)[reply]
Support Handelsgeselschaft (talk) 09:02, 12 February 2023 (UTC)[reply]
Support This feature should be implemented as it is a core feature missing for many people. NPRB (talk) 21:13, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 06:08, 14 February 2023 (UTC)[reply]
Support SpacedShark (talk) 06:40, 14 February 2023 (UTC)[reply]
Support Grdhrakuta (talk) 03:26, 15 February 2023 (UTC)[reply]
Support Vis M (talk) 06:47, 16 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:37, 18 February 2023 (UTC)[reply]
Support Tutwakhamoe (talk) 22:51, 18 February 2023 (UTC)[reply]
Support Mbrickn (talk) 03:21, 20 February 2023 (UTC)[reply]
Support Cmarsch (talk) 06:30, 20 February 2023 (UTC)[reply]
Support Augend (talk) 07:55, 20 February 2023 (UTC)[reply]
Support Qxyz123 (talk) 04:25, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:30, 21 February 2023 (UTC)[reply]
Support Madacs (talk) 20:57, 22 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:04, 23 February 2023 (UTC)[reply]
Support Althair (talk) 04:14, 23 February 2023 (UTC)[reply]
Support Manjiro91💬 12:22, 23 February 2023 (UTC)[reply]

Search for sections, not pages (discussion thread search)

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: Searching for two or more words or phrases in discussion pages returns a lot of noise that you have to comb through and ignore, because it returns all pages that contain the search terms, even if no thread contains all of the terms.
Proposed solution: A CirrusSearch parameter/filter that specifies the minimum heading level where all keywords must appear, e.g. toclevel=2, which limits the results to pages where all keywords appear under the same == ... ==. If multiple sections on one page match, each section is given a separate link in the results.
Who would benefit: Readers
More comments: Ideally it should be both a URL parameter and a search filter, so it can be used in <inputbox> as well as in the search query itself (e.g. toclevel:2), much like prefix.
Phabricator tickets:
Proposer: Nardog (talk) 18:36, 23 January 2023 (UTC)[reply]

Discussion

Just noting that apparently the completion of T315510 will make this easier to implement — TheresNoTime (talk • they/them) 21:29, 23 January 2023 (UTC)[reply]
That is about the discussiontools_persistent table which contains the comment author and timestamp but not the comment text (as the goal is to resolve permalinks which are made from author and timestamp). So I don't think it's useful here. Tgr (talk) 06:33, 5 February 2023 (UTC)[reply]
Storing the nested structure of the section might be particularly complicated and costly for a search index. Is specifying the nesting level a crucial component of this request or would it solve most of the usecases if CirrusSearch provided a keyword insection:"one two" which would filter pages that have one and two anywhere in the same direct section? DCausse (WMF) (talk) 17:03, 24 January 2023 (UTC)[reply]
It doesn't have to store the nested structure. It can just perform a search the normal way and then narrow it down. That too can be costly when the results are large, of course, but it can just time out in that case, which is the way the regex search already currently works.

I do think specifying the nesting level is a crucial component, because not all pages use the same level (cf. CfD, TfD, etc.), and looking in the same immediate section only will miss many wanted results, because many discussions have subsections such as "arbitrary breaks". See e.g. w:WP:VPR to get an idea. (Also, how is one supposed to search for phrases in that scenario you suggest?) Nardog (talk) 19:12, 24 January 2023 (UTC)[reply]
Thanks for the precision, knowing that the section level is crucial will help a lot in determining the feasibility of your proposal. Regarding my suggestion sorry if it was a bit vague, you are correct the syntax is not very handy for combining other search features but perhaps something with parenthesis around might be more appropriate: insection:(word1 word2 "one two").DCausse (WMF) (talk) 10:47, 25 January 2023 (UTC)[reply]
Semi-relatedly it is worth noting that CirrusSearch is not doing a very good job at presenting section names in the search results, it is not able to correlate highlighted words and their corresponding section: phab:T131950. DCausse (WMF) (talk) 17:03, 24 January 2023 (UTC)[reply]
Wouldn't the right solution to the problem be to sufficiently boost hits where the keywords are in the section title? (Which I think might be happening already to some extent.) Readers won't use advanced search keywords, and an inputbox would restrict all the entered words to the section title which probably isn't a great experience. Just like when you are searching for an article - you want the search results to prioritize full or close title matches, but if some terms you have given don't appear in the title but appear a lot in the article, you don't want to disqualify that page from the results. --Tgr (talk) 06:38, 5 February 2023 (UTC)[reply]
It wouldn't. The proposal comes from frustration at not being able to find (usually archived) threads that contain this and this term (e.g. names of participants) without having to comb through the results involving lots of tabs and Ctrl-F. Nardog (talk) 08:16, 5 February 2023 (UTC)[reply]

Voting

Support Strainu (talk) 20:13, 10 February 2023 (UTC)[reply]
Support Fallbackintoreality (talk) 20:49, 10 February 2023 (UTC)[reply]
Support PureTuber (talk) 22:19, 10 February 2023 (UTC)[reply]
Support * Pppery * _{it has begun} 04:07, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:13, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:25, 12 February 2023 (UTC)[reply]
Support Gohan 04:55, 12 February 2023 (UTC)[reply]
Support Izno (talk) 08:06, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 06:12, 14 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 09:05, 16 February 2023 (UTC)[reply]
Support Doktor Züm (talk) 15:53, 16 February 2023 (UTC)[reply]
Support Dmytro Tvardovskyi (talk) 03:13, 18 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:51, 18 February 2023 (UTC)[reply]
Support This would've saved me hours. Snowmanonahoe (talk) 19:27, 18 February 2023 (UTC)[reply]
Support Ταπυρ (گپ) 12:09, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:55, 21 February 2023 (UTC)[reply]
Support Trillo.gm (talk) 13:22, 22 February 2023 (UTC)[reply]
Support May be useful. Thingofme (talk) 01:45, 23 February 2023 (UTC)[reply]
Support Althair (talk) 04:16, 23 February 2023 (UTC)[reply]

Re-use citation with different page number in VisualEditor

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: Often you want to cite a book or report multiple times, but citing different page numbers. In Visual Editor, you now have to create these citations separately; it's not possible to reuse a citation, and change the page number only in the new location.
Proposed solution: A possible solution would be to add a check box in the re-use tab of "cite" if you want to change page number, which would give you a deep copy of the citation.
Who would benefit: editors using VE
More comments:
Phabricator tickets: related: phab:T216817
Proposer: Femke (talk) 18:32, 24 January 2023 (UTC)[reply]

Discussion

Given WMDE Technical Wishes/Reusing references, would it make sense to archive this @MusikAnimal (WMF)? Or could this be something both teams work on? Femke (talk) 17:31, 30 January 2023 (UTC)[reply]

@Femke It looks like they declined that wish as it was too complicated. This makes me believe it's probably too much work for Community Tech as well. At the discretion of the Editing team, we're happy to see this proposal through voting here in this category. If they also feel it is too big, it may be better fit for Larger suggestions. MusikAnimal (WMF) (talk) 17:46, 30 January 2023 (UTC)[reply]

They declined the book referencing wish. The reusing references wish which followed was chosen as the winner of 2022, and contains this wish as one of the three focal points. Femke (talk) 17:49, 30 January 2023 (UTC)[reply]

Ah, I see! Thank you for clarifying. Given the scope of the project, I still think this may belong in Larger suggestions. It sounds like WMDE is willing to make it a "focus area", which I presume means they will devote significant time to it. Moving it to Larger suggestions will see it through voting and give their team the reassurance of the desires for this functionality beyond just German-speaking communities. Community Tech can assist as needed, but I think judging by WMDE's assessment, it wouldn't make sense for us to wholly commit to it. I'm happy to instead archive, though, if you so desire :) Thanks, MusikAnimal (WMF) (talk) 17:59, 30 January 2023 (UTC)[reply]

Sounds like a plan, moving it to larger suggestions. Femke (talk) 18:23, 30 January 2023 (UTC)[reply]

Okay, thank you! Done. MusikAnimal (WMF) (talk) 21:21, 30 January 2023 (UTC)[reply]

Howis this different from Easily add page numbers with "cite" automatic button for books and then easily "reuse" listed book references with/without new page number(s) if needed. (which ended up in the normal suggestion section)? Tgr (talk) 04:17, 11 February 2023 (UTC)[reply]

It's half of that (my other wish covers the other half). So there is some cleaning that probably should have been done before the Wishlist launched.. Femke (talk) 07:39, 11 February 2023 (UTC)[reply]

@MusikAnimal (WMF): is any further cleaning necessary? Or is it too late given the voting has started? Femke (talk) 07:41, 11 February 2023 (UTC)[reply]

Since there are two proposals that cover what you're asking for, both of which are in voting, this proposal should have been archived as redundant. But, it's not really hurting anything being here, either. Apologies I didn't catch the redundancy, and also for not replying sooner (I've been on holiday for most of the voting phase). Best, MusikAnimal (WMF) (talk) 15:24, 24 February 2023 (UTC)[reply]

Voting

Support TheAmerikaner (talk) 20:19, 10 February 2023 (UTC)[reply]
Support SeGiba (talk) 21:17, 10 February 2023 (UTC)[reply]
Support Mapatxea (talk) 21:32, 10 February 2023 (UTC)[reply]
Support Significa liberdade (talk) 22:27, 10 February 2023 (UTC)[reply]
Support Skimel (talk) 00:35, 11 February 2023 (UTC)[reply]
Support Would make things more convenient. SHB2000 (talk | contribs) 01:26, 11 February 2023 (UTC)[reply]
Support * Pppery * _{it has begun} 04:05, 11 February 2023 (UTC)[reply]
Support Jurbop (talk) 07:27, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:31, 11 February 2023 (UTC)[reply]
Support //Lollipoplollipoplollipop::talk 10:09, 11 February 2023 (UTC)[reply]
Support Oltrepier (talk) 10:12, 11 February 2023 (UTC)[reply]
Support Plaga med (talk) 11:30, 11 February 2023 (UTC)[reply]
Support Innitiative.35 (talk) 13:43, 11 February 2023 (UTC)[reply]
Support Mike bzh (talk) 15:48, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:54, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:33, 12 February 2023 (UTC)[reply]
Support Betseg (talk) 03:39, 12 February 2023 (UTC)[reply]
Support Gohan 04:54, 12 February 2023 (UTC)[reply]
Support Matěj Suchánek (talk) 09:04, 12 February 2023 (UTC)[reply]
Support Fvtvr3r (talk) 14:04, 12 February 2023 (UTC)[reply]
Support SpiderMum (talk) 14:48, 12 February 2023 (UTC)[reply]
Support Thomas Kinz (talk) 01:25, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 05:58, 14 February 2023 (UTC)[reply]
Support SpacedShark (talk) 06:34, 14 February 2023 (UTC)[reply]
Support Lion-hearted85 (talk) 12:13, 14 February 2023 (UTC)[reply]
Support ZandDev (talk) 10:17, 15 February 2023 (UTC)[reply]
Support Sadads (talk) 01:27, 16 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 09:05, 16 February 2023 (UTC)[reply]
Support Doktor Züm (talk) 15:11, 16 February 2023 (UTC)[reply]
Support JFremd (talk) 16:19, 16 February 2023 (UTC)[reply]
Support Geraki ^T_L 20:14, 17 February 2023 (UTC)[reply]
Support Fuchs B (talk) 20:18, 17 February 2023 (UTC)[reply]
Support ArtDataArt (talk) 20:38, 17 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:55, 18 February 2023 (UTC)[reply]
Support Herbert Ortner (talk) 15:07, 18 February 2023 (UTC)[reply]
Support Vulcan❯❯❯Sphere! 16:43, 18 February 2023 (UTC)[reply]
Support Albinfo (talk) 22:15, 18 February 2023 (UTC)[reply]
Support Kess (talk) 06:33, 19 February 2023 (UTC)[reply]
Support — Draceane ^talk_contrib. 12:53, 20 February 2023 (UTC)[reply]
Support I think there's a very similar proposal elsewhere in the wishlist PamD (talk) 16:00, 20 February 2023 (UTC)[reply]
Support I use {{rp}} for this purpose, but it's crude — Omegatron (talk) 16:16, 20 February 2023 (UTC)[reply]
Support Nashona (talk) 18:29, 20 February 2023 (UTC)[reply]
Support Qxyz123 (talk) 04:30, 21 February 2023 (UTC)[reply]
Support Gustamons (talk) 17:57, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:18, 21 February 2023 (UTC)[reply]
Support Serieminou (talk) 23:15, 21 February 2023 (UTC)[reply]
Support Madacs (talk) 20:59, 22 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:13, 23 February 2023 (UTC)[reply]
Support Althair (talk) 04:11, 23 February 2023 (UTC)[reply]

Develop mobile versions for projects like Wikivoyage 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: There are currently no official projects other than Wikipedia app
Proposed Solution: Develop mobile versions for projects like Wikivoyage app
Who would benefit: Readers using wiki projects on mobile. E.g. Wikivoyage app is convenient for travelers to view travel guides without logging into a web page.
More comments:
Phabricator Tickets: phab:T282500
Proposer: Hehua (talk) 13:08, 24 January 2023 (UTC)[reply]

Discussion

A new mobile app would be out of scope for Community Tech. It is a valid proposal though, so I will move to Larger Suggestions. See a similar proposal last year. Thanks for participating. DWalden (WMF) (talk) 12:08, 26 January 2023 (UTC)[reply]
OK, thank you. Hehua (talk) 02:29, 27 January 2023 (UTC)[reply]
Since all projects run in a similar fashion; the Wikipedia app should be evolved into Wikimedia app that supports all sites. But the app is extremely inefficient and useless, almost no one even uses it. Go to RecentChanges stream of any wiki, find the number of app edits v/s mobile-web edit for example. The ratio should be close to 1:50 or more. That should give an idea of the app's uselessness. It doesn't even support CSS/JS in the year 2023. If the WMF absolutely wants to keep an app, they should use Twitter Lite as an inspiration and create a browser-based app that directs users to mobile site but from within the app, which separates learning experience from regular surfing experience. The only feature lost will be the dark mode, but if WMF is serious, they should bring dark mode to the websites anyway, for it is going to be the #1 CWS Proposal this year by a landslide. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:10, 18 February 2023 (UTC)[reply]
In fact, the editing experience through the app is really not good, and this proposal has no intention to change this problem, I just want a Wikivoyage app which can be more convenient for instant browsing. Hehua (talk) 09:13, 19 February 2023 (UTC)[reply]
I think a unique app for all the Wikipedia projects would be easier to maintain and also would encourage mobile users to use and get involved in several projects, not just Wikipedia and wikivoyage.Ropaga (talk) 12:31, 20 February 2023 (UTC)[reply]
Maybe. Hehua (talk) 01:58, 21 February 2023 (UTC)[reply]

Voting

Support TheLionHasSeen (talk) 22:44, 10 February 2023 (UTC)[reply]
Support Yes! This should be more prioritized, since most web users nowadays browse from mobile devices. NMaia (talk) 00:16, 11 February 2023 (UTC)[reply]
Support as the proposer. Hehua (talk) 00:49, 11 February 2023 (UTC)[reply]
Support as proposed Pmsyyz (talk) 01:11, 11 February 2023 (UTC)[reply]
Support The Kiwix app just sucks. Full stop. SHB2000 (talk | contribs) 01:23, 11 February 2023 (UTC)[reply]
Support EpicPupper (talk) 05:40, 11 February 2023 (UTC)[reply]
Support Muted Red Tulip (talk) 10:14, 11 February 2023 (UTC)[reply]
Support Oltrepier (talk) 10:17, 11 February 2023 (UTC)[reply]
Support Der Fussi 12:23, 11 February 2023 (UTC)[reply]
Support --Crosstor (talk) 14:02, 11 February 2023 (UTC)[reply]
Support Bluerasberry (talk) 15:04, 11 February 2023 (UTC)[reply]
Support CROIX (talk) 15:20, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:53, 11 February 2023 (UTC)[reply]
Support Ivario (talk) 22:01, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:45, 12 February 2023 (UTC)[reply]
Support Betseg (talk) 03:40, 12 February 2023 (UTC)[reply]
Support Fvtvr3r (talk) 13:58, 12 February 2023 (UTC)[reply]
Support —Yahya (talk • contribs.) 21:45, 13 February 2023 (UTC)[reply]
Support SpacedShark (talk) 06:41, 14 February 2023 (UTC)[reply]
Support Strong support. Wikivoyage and Wiktionary are ideal to be read from mobile. Volunteer made Wiktionary mobile app had millions of users before terminating Vis M (talk) 06:52, 16 February 2023 (UTC)[reply]
Support Doktor Züm (talk) 07:18, 16 February 2023 (UTC)[reply]
Support Mbrickn (talk) 03:17, 20 February 2023 (UTC)[reply]
Support Irfan Shahid (talk) 16:01, 20 February 2023 (UTC)[reply]
Support MichaelRostom (talk) 23:40, 20 February 2023 (UTC)[reply]
Support Qxyz123 (talk) 04:30, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:30, 21 February 2023 (UTC)[reply]
Oppose the mobile layout of Wikimedia sites look and run fine. What do we need an app for? Snowmanonahoe (talk) 16:43, 22 February 2023 (UTC)[reply]
You should open the browser and input the web address to access the sites. If we have an app, we can browse the webpage directly. Hehua (talk) 07:35, 23 February 2023 (UTC)[reply]
Support Morten Haan (talk) 18:52, 22 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:07, 23 February 2023 (UTC)[reply]
Support Definitely, I find myself using Wikivoyage often as a reader. A mobile version would be useful. Juandev (talk) 11:34, 23 February 2023 (UTC)[reply]
Support I think that this is really a good idea (or else it would be possible to create an application that brings together all the projects in a single application) -- Manjiro91💬 12:16, 23 February 2023 (UTC)[reply]

Wikipedia in English

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:

The problem is easily expressed: there is no English Wikipedia. American Wikipedia does not provide the resources needed by English and other British users. Wikimedia probably does not think it is guilty of opressive cultural imperialism but it is: educating English and other British children inevitably involves reference to Wikipedia. However, Wikipedia's cursory nods to British culture and spelling (and, vanishingly rarely, British grammar and idiom) are far from adequate. Not all parents in the UK want their children to become little Americans.

The problem, of course, is not limited to the use of Wikipedia by children. Many British people find it frustrating and demeaning to be treated as though they don't matter. I believe the British are as generous as other nations in their donations to Wikipedia. Why not reward them with the most glaringly absent resource in the whole of Wikimedia?

Proposed solution: The solution is simple: create an English Wikipedia.

Who would benefit: Sixty million people in the UK would benefit from, at last, having a Wikipedia for their language, idiom and culture.

More comments: Wikipedia is available for much smaller language and cultural groups that the English one that has been, so far, ignored and swept under the rug. Strictly, this proposal should be entitled, "English Wikipedia", where English is an adjective. There is already a Wikipedia in (American) English.

Phabricator tickets:
Proposer: Ordishj (talk) 09:20, 27 January 2023 (UTC)[reply]

Discussion

Hello @Ordishj:, this is a really important proposal as all languages have the same right to be represented for the own language community. The wishlist survey, where you added your proposal, is specifically for technical proposals for relatively small features that you would like to see implemented, nevertheless we will make sure your proposal will be seen. KSiebert (WMF) (talk) 11:27, 27 January 2023 (UTC)[reply]
Thank you for your prompt response and assurance of visibility of the proposal. I have in the past tried to communicate this (obvious) need but without success. If an assurance of genuine and dispassionate consideration of implementing the proposal were forthcoming, that would be even better. Ordishj (talk) 12:22, 27 January 2023 (UTC)[reply]
This can be actually solved with a plugin that changes automatically American English to British English, like Chinese Wikipedias have for traditional and modern writing. You only need a set of rules, and it's done in both directions. Theklan (talk) 15:41, 27 January 2023 (UTC)[reply]
@Ordishj: This would be a good place to suggest a new wiki and in the meantime we will move this proposal to larger suggestions. https://meta.wikimedia.org/wiki/Proposals_for_new_projects KSiebert (WMF) (talk) 14:10, 27 January 2023 (UTC)[reply]
See w:MOS:ENGVAR. Articles in English Wikipedia are written in many national variants, including British and Indian, not just American. MarioGom (talk) 17:46, 28 January 2023 (UTC)[reply]
Wikimedia is internationalist. The reference to British people being "oppressed" by "imperialism" is particularly distasteful and ahistorical. — Bilorv (talk) 20:16, 29 January 2023 (UTC)[reply]
The proposal is talking about the use of British English. Or more generally the use of local variant of a language. Language imperiamism can exists in internationalist enviornment. But the problem is just that Wikipedia do not intend to deal with this problem not does it appears to be a right place. C933103 (talk) 05:31, 7 February 2023 (UTC)[reply]
In the form it this is being proposed, it's obviously a terrible idea and not going to happen. (See Language proposal policy: The language must be sufficiently unique that it could not coexist on a more general wiki. In most cases, this excludes regional dialects and different written forms of the same language. If you want to do an exercise in futility anyway, the right place to propose this is Requests for new languages, not the technical wishlist.)
That said, there might be a more reasonable way of approaching the problem: deploying LanguageConverter on English Wikipedia (T33015). @KSiebert (WMF): I'm not sure that's outsized for a Community Tech project. I don't know if it's a good idea, or even feasible, there might be all kinds of usability, compatibility and performance impacts, but investigating T33015 and turning it into a proposal that's sufficiently fleshed out that the enwiki community can discuss it seems like a reasonably-sized effort. --Tgr (talk) 21:44, 29 January 2023 (UTC)[reply]
A problem is how to implement language variants that "could coexist on a more general wiki" but is not close enough to make use of language converter. Currently some of those wiki make different pages for different versions of same article, and the result make cross-wiki and wikidata-related usage very difficult. C933103 (talk) 05:51, 7 February 2023 (UTC)[reply]
Even beyond the global policy set by LangCom here, I'm not sure what actions Ordishj has done to try and see if a consensus to create such a thing exists amongst editors - the ones who would have to maintain such a duplicate being. British spelling is frequently present on en-wiki. British "culture" is as present as the interested editor mass allows it to be - that is, creating a new wikipedia won't help in that regard because there will still be just as many editors writing about it. Finally, your proposal assumes a fairly drastic premise (that of cultural imperialism), without its sub-premises in any way logically leading to it. Nosebagbear (talk) 09:53, 31 January 2023 (UTC)[reply]
British contributor of long standing here; OP does not speak for me. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:53, 2 February 2023 (UTC)[reply]
No solution that involves creating a whole other Wikipedia is "simple". There's no reason why a British Wikipedia should exist over any other variety of English, the English Wikipedia includes all varieties of English, including both British and American. Saying that the English Wikipedia is the American Wikipedia ignores that many articles are in British English, both purposely and coincidentally. Lastly, by the same reasoning, we should create a Wikipedia for every different dialect in any given language, e.g. a Spanish Wikipedia, a Mexican Wikipedia, an Argentine Wikipedia, etc., which is clearly unnecessary when all those dialects can coexist within the same Wiki. Facu-el Millo (talk) 21:33, 10 February 2023 (UTC)[reply]
What is next: seperate Wikipedias in English for India, Australia, Canada, New Zealand, South Africa and many other countries? In Dutch for the Netherlands, Flanders and Suriname? In German for Germany, Austria, Switzerland and Belgium? In French for France, Wallonia, Canada and perhaps some African countries? I do not hope so. And what about Commons (working language is English)? I would like to have one English/Dutch/German Wikipedia to go to for information. And yes, sometimes it is annoying (in Commons) that a Category name is in American English instead of in the British English I learned at school, but so be it. --JopkeB (talk) 13:26, 11 February 2023 (UTC)[reply]
Wasn't there a discussion about having separate versions of pages or even an auto-converter similar to systems used for Wikipedias in multiple writing systems (or the Chinese wiki system specifically, which in addition to simplified and traditional characters, also converts between terms and proper nouns that are rendered with different characters based on location, more similar to English spelling differences) 10-15+ years ago? From what I've heard, however, that never got off the ground as most users agreed to implement a multidialectal wiki and navigate the challenges that came with that. MSG17 (talk) 18:22, 11 February 2023 (UTC)[reply]
Yes. See Tgr's comment above :) --Waldyrious (talk) 04:33, 13 February 2023 (UTC)[reply]
Having another English Wikipedia would be confusing to non-English speakers, and this will add more workload for people who want to tranlate articles into English, but aren't familiar with the differences between British and American English. It might be more practical to have a system akin to that of the Chinese wiki, as mentioned by MSG17 above. Tutwakhamoe (talk) 22:56, 18 February 2023 (UTC)[reply]

Voting

Oppose This is not a technical work that WMF can allocate time and resources, rather a generic real-world problem just not specific to Wikimedia. Without any concrete proposals for any tools that could [potentially] help editors/readers in achieving the desired result [to a possible extent], this is simply an utopian vision — DaxServer (t · m · c) 21:33, 10 February 2023 (UTC)[reply]
Oppose Significa liberdade (talk) 22:35, 10 February 2023 (UTC)[reply]
Oppose --HeyElliott (talk) 00:02, 11 February 2023 (UTC)[reply]
Oppose super trivial, IMO. --SHB2000 (talk | contribs) 01:33, 11 February 2023 (UTC)[reply]
Oppose Brits, Canadians, Aussies, Indians, etc. all use the "American" Wikipedia and most of them are perfectly fine with it. Are going to go down the rabbit hole for each of these nations? --Jnglmpera (talk) 01:55, 11 February 2023 (UTC)[reply]
Oppose * Pppery * _{it has begun} 04:05, 11 February 2023 (UTC)[reply]
Oppose en:Template:Use British English, en:Template:Use American English, en:Template:Use Australian English, etc. If an article is about a subject from a specific location, then these templates can be used to note how the article should be constructed. Aluminium is BrEng, Sulfur is AmEng. I use Br/AuEng, and I can read the sulphur article without issue. Additionally, when I create an article, it's established that DMY and Br/AuEng will be used. This isn't article ownership, it's just noting that the primary editor has chosen a style and that subsequent editors should respect that, just like how I'll use MDY and AmEng if someone else has already established this. Anarchyte (talk) 07:10, 11 February 2023 (UTC)[reply]
Oppose See the poor weeding of the Simple English Wikipedia for one reason why this is a bad idea. See the relatively poor quality of many articles on major topics in major non-English languages for another. As much as I support the continued existence of regional language variation, and certain American-standard spellings of things annoy my personal sensitivities, it is a bad idea to fork things in this way. Wikipedia is relatively low on idiom, and this is a good thing. I say use British terminology whenever you think it clearly communicates things in an encyclopedic style, but especially when it relates to matters about Britain.Transient-understanding (talk) 08:13, 11 February 2023 (UTC)[reply]
Oppose --//Lollipoplollipoplollipop::talk 10:08, 11 February 2023 (UTC)[reply]
Strong oppose Wikipedias are language projects, not "national" projects. CaféBuzz (talk) 11:04, 11 February 2023 (UTC)[reply]
Oppose JopkeB (talk) 13:28, 11 February 2023 (UTC)[reply]
Oppose As a Brit, I think this is a terrible idea — look at how the different language instances of the Serbo-Croatian language continuum have become polarised and contradictory on some topics, for example. The Americanisation of the English language is a battle we lost nearly a century ago and it's being supplanted by International English, where our former colonies and L2 speakers are having greater and greater impact on language. This is all fine; we're a decreasingly important island off the northwest coast of a continent we want to pretend is beneath us. And what about Welsh English, Scottish English, Hibernian English, Australian English, Kiwi English, South African English. Get over the shallow nationalism; it's all one language and different articles use different dialects. — OwenBlacker (Talk) 14:51, 11 February 2023 (UTC)[reply]
Support Resolved, That the American Wikipedia is, and of right ought to be, a free and independent Project, that it is absolved from all subservience to the English Yoke, and that all administrative connexion between it and the English Wikipedian community is, and ought to be, totally dissolved. Radio-Somewhere (talk) 17:12, 11 February 2023 (UTC)[reply]
Oppose While I do think that the broader global context does prioritize certain Englishes over others based on power structures, having separate wikis for each dialect would create unnecessary barriers on a faulty presumption that speakers of one dialect should not be exposed to others and fragment enwiki's mission. MSG17 (talk) 18:22, 11 February 2023 (UTC)[reply]
Oppose "Come see the violence inherent in the system!!" NillaGoon (talk) 22:59, 11 February 2023 (UTC)[reply]
Oppose CaféBuzz explained why. And my note: the proposal goes against what does Wikipedia is it. --NGC 54 (talk｜contribs) 01:44, 12 February 2023 (UTC)[reply]
Strong oppose LOL. Nah. --Firestar464 (talk) 15:29, 12 February 2023 (UTC)[reply]
Strong oppose We should not make new Wikis for every dialect or local variation of a language ever. See MOS:ENGVAR QuickQuokka ^{[⁠talk • contribs]} 17:29, 12 February 2023 (UTC)[reply]
Oppose Concerns exist but the solution should be to do something in the existing project to cater for different communities. Sun8908 (talk) 18:17, 12 February 2023 (UTC)[reply]
Support I support further investigation of what a technical solution might entail. It is to me not at all "obviously a terrible idea". Every language community should be able to have a project in their language variety, if they want it, and make the effort to develop it. I think it is right to revisit en:wp:MOS:ENGVAR, meta:Language proposal policy, and other policies from time to time, to ensure they remain desirable and/or technically justified. And there already exist multiple Wikipedias for to-some-degree mutually intelligible language varieties, such as the regional varieties of Italian.

Most of the oppose arguments seem to be from the perspective of editors, not readers. I would guess that many readers would prefer to read Wikipedia in their own language variety. I am perfectly fine reading the mixed Englishes in the English Wikipedia, but I don't think my comfort in that should inherently dictate the ability of others to read Wikipedia in the language form they prefer.

An additional possible use for a technical solution to this issue would be to display Wikipedia text at appropriate reading levels for children and other language learners.

I expect that someone at some point will develop a technical approach to solving this problem. I would rather that solution be developed within the WMF community than elsewhere. Libcub (talk) 05:52, 14 February 2023 (UTC)[reply]

@Libcub See en:Abstract Wikipedia — DaxServer (t · m · c) 07:50, 14 February 2023 (UTC)[reply]

Oppose // DE: Ablehnung des Aufwandes. Ich verstehe den Wunsch, halte aber den Aufwand für unangemessen, der dafür betrieben werden müsste. Es ist ein schwieriges Problem (de:Turmbau zu Babel). Es wäre meiner Ansicht nach unrealistisch, in dieser Hinsicht zufriedenstellenden Erfolg zu erwarten. Ähnliche Probleme gibt es auch in anderen Sprachen. // EN: Effort rejected. I understand the wish. But I guess the effort to be unreasonably high. It is a difficult problem (en:Tower of Babel). In my opinion, it would be unrealistic to expect satisfactory success in this regard. Similar problems exist in other languages as well. --Dirk123456 (talk) 09:30, 14 February 2023 (UTC)[reply]

Oppose I am a Japanese but I use English wikipedia because of the English language, but not because it is American wikipedia. Claiming that English wikipedia is only for American is just absurd. Katsutoshi Seki (talk) 11:30, 14 February 2023 (UTC)[reply]

Support FlagNerdGreen (talk) 13:07, 14 February 2023 (UTC)[reply]
Oppose Spanish, Chinese, French and Portuguese wikis have more language and cultural differences than English language and still have a single wiki, ifr we do it with english he would need to do with all those languages as wellMeganinja202 (talk) 15:53, 14 February 2023 (UTC)[reply]
Strong oppose ✠ SunDawn ✠ (contact) 10:27, 15 February 2023 (UTC)[reply]
Support Obviously, separate Wikipedias for each dialect is silly. But maybe templates for each idiomatic use, eg, {{idiom|aluminum}}, and a user preferences setting indicating which spelling is preferred. Doktor Züm (talk) 15:29, 16 February 2023 (UTC)[reply]
Oppose Hey man im josh (talk) 16:52, 16 February 2023 (UTC)[reply]
Oppose I think this is a rather silly issue, it is not important what english dialect is used. On top of that, at least where I'm from, wikepedia is not used in schools because everyone can edit it. It's the free encyclopedia, are you going to restrain what dialects we can use ? Alien333 (talk) 18:02, 16 Ferbruary 2023 (UTC)
Oppose, per OwenBlacker. As a British person I have never felt there has been a problem with the English Wikipedia being too American. I think w:WP:ENGVAR deals with different variants of English fairly. --Ferien (talk) 20:33, 17 February 2023 (UTC)[reply]
Oppose Lightoil (talk) 03:27, 18 February 2023 (UTC)[reply]
Strong oppose: Firstly, out of scope for CWS; and secondly and most importantly en:WP:ENGVAR. What variants articles are written in largely depends on who writes them. Maybe Americans are writing more articles than the British. Now, when you split the project into American/British, why should Indian English not have a separate project, what about South African English, or Australian English? When we split the project into a dozen different projects, we split editor time & resources across several projects. The entire administration system needs to be set up, the deletion processes, the anti-vandalism framework, and many more. We can't afford that. In fact, among the biggest losers will be the British English Wikipedia, more so than the American English Wikipedia, because of a smaller userbase. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:29, 18 February 2023 (UTC)[reply]
Oppose. Perhaps enwiki could convert spelling and units automatically with a solution similar to en:Chinese_Wikipedia#Automatic_conversion_between_traditional_and_simplified_Chinese_characters, but articles should offer both units and unmistakeable language anyways as per en:WP:ENGVAR. Trimton (talk) 15:39, 18 February 2023 (UTC)[reply]
Not yet. Finish Wikipedia first, then translate into the various English dialects. · · · Peter (Southwood) ^(talk): 18:11, 18 February 2023 (UTC)[reply]
Support I support language variety. It’s weird we have a Simple English Wikipedia. Unfortunately the English Wikipedia has grown so much and become such a cesspool, it’d possibly benefit from some dismantling. Kays (talk) 03:57, 19 February 2023 (UTC)[reply]
Oppose (1) Out of scope. (2) Separating dialects with minor differences (such as British/American English) would fracture the community and lead to two Wikipedias of inferior quality compared with the present state of affairs. (3) If this was extended to all regional varieties of English there'd be dozens of English Wikipedias which is not tenable (see comments by Anarchyte, Transient-understanding, CX Zoom, Meganinja202 above). Stockmausen (talk) 13:27, 19 February 2023 (UTC)[reply]
Oppose English Wikipedia benefits from having contributors from the wider community. We are better together. Constant314 (talk) 18:21, 19 February 2023 (UTC)[reply]
Neutral, as someone who prefers to stick to en-gb (though as a non-native speaker of the language my own English is quite a wild mixture of everything seasoned with terrible accent on top of it) I would welcome having a possibility to enforce British spelling at the least. I guess someone could write a userscript that will do just that, potentially package it into a browser extension too so that it can be shipped to non-registered users. On the other hand I agree that it is not something that I want WMF spending money on. It can be something WMUK could help with though, potentially at least (and it should not be impossible for them to secure funding through some external grant givers for such project). --Base (talk) 12:36, 22 February 2023 (UTC)[reply]
Strong oppose If a Wikipedia existed for every single dialect of English there would be over 160 English dialect Wikipedias, let alone every dialect for languages such as Chinese, Spanish, etc. I think WMF should focus on other priorities first, then maybe this will follow. NPRB (talk) 14:00, 22 February 2023 (UTC)[reply]
Strong oppose --Morten Haan (talk) 18:54, 22 February 2023 (UTC)[reply]
Strong oppose This is inconsistent with the LangCom's requirements. Thingofme (talk) 01:54, 23 February 2023 (UTC)[reply]
Oppose - If implemented, we'd double the number of articles to maintain, and each Wikipedia would have a smaller set of interested editors. GoingBatty (talk) 03:48, 23 February 2023 (UTC)[reply]
Oppose I really, really thought this proposal was a joke. Daniel Case (talk) 05:54, 23 February 2023 (UTC)[reply]
I thought English Wikipedia follows British grammar rules. Like Spanish Wikipedia follows Spanish grammar rules, not Mexican. If it's not happing it's up on community discussion on that language mutation. We are here not to represent nations, but to ease delivering knowledge and I guess the British could understand American English. So I Oppose this. Juandev (talk) 11:46, 23 February 2023 (UTC)[reply]
Oppose Shellwood (talk) 11:08, 24 February 2023 (UTC)[reply]

Make it simple and usable again

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: The thing is too bloated, complex, slow, and buggy, hard to use, and impossible to maintain (evidence).
Proposed solution: Restrict adding of new features, instead optimize. Remove the VisualEditor (or at least make it non-default), reduce number of open Phabricator tasks, dare to question existing features.
Who would benefit: All users, particularly the older ones, as well as those unable or refusing to buy a new computer every 3 months, those with slow or unreliable internet connections, and those who prefer to see the truth (ie wikitext) instead of illusions. Developers having more time to fix real bugs. Our environment because of reduced consumption of material and energy.
More comments:
- Remove features that are blatantly obsolete.
- I question the assumption that the VisualEditor attracts new good contributors. In order to contribute to a wiki (wiktionary, wikipedia, wikidata, ...), skills are required. Language skills, science skills, knowledge of policies (no plagiarism, notability, verifiability, ...), skills to write good definitions (for wiktionary), ... . People with zero skills unfortunately cannot contribute, without or with the VisualEditor. In fact the VisualEditor attracts mostly vandals, and wastes time of those not using it, as well as various other resources.
- The simple namespace list with checkboxes on the screen ca 10 years ago worked well. The current list flashing down runs out of the screen and is unusable.
- The old design of wikis was usable. The new one with an empty column on the left eating away ca 1/3 of the width of the screen is nonsense.
- The old design of interlanguage links in the lower part of the left column was simple and usable irrespective of the number of links. The new layout with the links hidden, access button that can be anywhere (top right on some wikis), and the links finally placed over page content with a eurocentristic grouping, not fitting on the screen, and vanishing when one tries to scroll, is nonsense.
- The "new" upload form on Commons is a nightmare. The old one was much better.
- Are explicit interwiki links still useful given that WikiData is used?
- Remove text encodings other than UTF8.
- Encourage more the switch to HTML5, then remove support for "cellpadding=" and similar stuff.
- Search preferably for stuff that the user asks for. Do not search for "Simmering" if the user asked for "simmer". Do not aggressively replace user's text by "suggestions" unrelated to the search intent.
- Keep LUA (2013) and WikiData (2013), they are the 2 real and good innovations, as well as Cognate (2017). Most other changes probably could be reverted to year 2010 or 2005. Less is sometimes more.
Phabricator tickets: all that have been open for an unreasonably long time, all about subsequent trouble of the VisualEditor
Proposer: Taylor 49 (talk) 12:10, 6 February 2023 (UTC)[reply]

Discussion

Oh my goodness, I am ready to subscribe under every single word of yours! —2dk (talk) 19:47, 10 February 2023 (UTC)[reply]

I suspect that the Visual Editor should be treated as an instance of w:The_Mythical_Man-Month#The pilot system, "a team will design a throw-away system (whether it intends to or not)". The basic idea is sound & putting a small team to work on a better version would be fine idea. The current system can be made available in the meanwhile but should not be the default for anyone & should not get large maintenance effort. Pashley (talk) 14:24, 18 February 2023 (UTC)[reply]

Voting

Strong support —2dk (talk) 19:46, 10 February 2023 (UTC)[reply]
Support TheAmerikaner (talk) 20:21, 10 February 2023 (UTC)[reply]
Support that would be better Boehm (talk) 20:40, 10 February 2023 (UTC)[reply]
Support Very important to think the easiest way. Sicarov (talk) 21:03, 10 February 2023 (UTC)[reply]
Support I hate to be a Luddite but find myself nodding in agreement at most of the points above. Please change things only when absolutely necessary. As a side-effect, this should free up some resource for bug-fixing. Certes (talk) 21:53, 10 February 2023 (UTC)[reply]
Oppose Significa liberdade (talk) 22:36, 10 February 2023 (UTC)[reply]
Strong oppose as these are all trivial. Give Wikimedia Foundation time to sort things out; it's like trying to revert Twitter to its old design or messing with things that just shouldn't be messed with (as has been seen lately over there). TheLionHasSeen (talk) 23:57, 10 February 2023 (UTC)[reply]
Strong oppose That would effectively shut down general audience participation, IMHO. Magnoliasouth (talk) 23:35, 10 February 2023 (UTC)[reply]
Strong oppose per the above. NMaia (talk) 00:16, 11 February 2023 (UTC)[reply]
Oppose I am an experienced editor and the Visual Editor has considerably improved my edits on Wikipedia, it's quicker, more straightforward, more visually appealing and comfortable. It is also very valuable for scholars and people with expertise on a topic, but not familiar with the wikicode. Skimel (talk) 00:29, 11 February 2023 (UTC)[reply]
Strong oppose seems like you're in the minority here. --SHB2000 (talk | contribs) 01:26, 11 February 2023 (UTC)[reply]
Support I acknowledge that this clearly doesn't have consensus, and don't necessarily agree with every one of the proposed changes, but I do think that MediaWiki's complexity has often been creeping up past what is warranted. * Pppery * _{it has begun} 04:07, 11 February 2023 (UTC)[reply]
Strong oppose This is a completely absurd proposal. Kill the Visual Editor? What complete nonsense. The Visual Editor was the best thing that Wikipedia and its project derivations implemented. User:Goliv04053 User talk:Goliv04053 06:36, 11 February 2023 (UTC)[reply]
It is not. It is merely a beta version if at all. Matthiasb (talk) 14:52, 20 February 2023 (UTC)[reply]
Support Throw VE to trash bin. Arado Ar 196 (talk) 08:29, 11 February 2023 (UTC)[reply]
Strong oppose Absurd. Many of us mainly use the Visual Editor because it is more accessible to our needs, eyes, reading, thinking. etc. User:St. Andrews Drive —Preceding undated comment added 09:23, 11 February 2023 (UTC).[reply]
Support This thing doesn't work, it is not understandable that it is the default choice while it is a buggy hardly usable stuff. It is actually an experimental alpha feature. CaféBuzz (talk) 11:16, 11 February 2023 (UTC)[reply]
Oppose VE makes it easier to edit, there is no reason to make it difficult for many editors. We need more editors, not less. SunDawn (talk) 12:42, 11 February 2023 (UTC)[reply]
Oppose Those of us who use wikitext are a minority, a wysiwyg editor is clearly advantageous to encouraging readers to become editors. The Foundation employs UX professionals, rather than asking the opinions of amateurs who happen to edit a lot for good reason. As Goliv04053 and St. Andrews Drive put it, this is absurd. The Internet is not what it was when we each started editing; that is not something we can (or should!) change. — OwenBlacker (Talk) 14:57, 11 February 2023 (UTC)[reply]
Oppose Visual Editor has made my work in Wikipedia, a large part of which is introducing small edits, twice easier. Especially useful for inline linking to other articles. Keep the thing. --Ivario (talk) 21:59, 11 February 2023 (UTC)[reply]
Oppose Well-intentioned but vague and unimplementable. Yes, UIs should be good and not bad. NillaGoon (talk) 22:51, 11 February 2023 (UTC)[reply]
Oppose VE has a lot of good inside (e.g. it makes editing references and text with refs a much more straight forward process). A lot of users use it with success. Throwing that away would just be wrong. Improve it? Sure. It does already happen though. Nux (talk) 09:28, 12 February 2023 (UTC)[reply]
Support as the proposer. Taylor 49 (talk) 04:14, 14 February 2023 (UTC)[reply]
Oppose This proposal is about too many things, and in places is too vague. Split it up, clarify, and resubmit next year. Libcub (talk) 07:26, 14 February 2023 (UTC)[reply]
Strong oppose I disagree on the opinions expressed about the VisualEditor, the new website design (including text width), the interlanguage links, the Commons uploader, and about not taking search queries verbatim. All these tools and designs may be perfected, but are definitely steps forward in my opinion. --Lion-hearted85 (talk) 12:53, 14 February 2023 (UTC)[reply]
Oppose Vincent Vega ^msg? 20:26, 14 February 2023 (UTC)[reply]
Support Agree 100% with the problem statement; not necessarily with the solutions given. Doktor Züm (talk) 15:08, 16 February 2023 (UTC)[reply]
Support KISS. Kays (talk) 01:47, 17 February 2023 (UTC)[reply]
Oppose --Fuchs B (talk) 20:17, 17 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:38, 18 February 2023 (UTC)[reply]
Oppose Lightoil (talk) 10:13, 18 February 2023 (UTC)[reply]
Strong oppose Visual Editor is very helpful, ridiculous idea to throw that away. ABPMAB (talk) 14:42, 18 February 2023 (UTC).[reply]
Oppose We are a wiki. Wikis work because they are constantly being changed and improved. That should apply to software, too. Furthermore, wikitext is not "the truth". It is converted into proper HTML, just like VisualEdits are converted into wikitext. Just because you don't use something doesn't make it worthless. HouseBlaster (talk) 18:07, 18 February 2023 (UTC)[reply]
Strong oppose This is an unactionable laundry list of vague personal grievances. Especially ditching the VE would be very detrimental to public participation. Stockmausen (talk) 13:17, 19 February 2023 (UTC)[reply]
Support Thank you for that suggestion, one of the few valuable ones here! DerMaxdorfer (talk) 00:16, 20 February 2023 (UTC)[reply]
Oppose An interesting opinion, but I think it is a step back when an open platform can't develop just because there are those people who can't adapt. Hans5958 (talk) 02:39, 20 February 2023 (UTC)[reply]
Support And keep magic words (PMID, RFC and mainly ISBN) and remove obsolete templates like the en:Template:ISBN-nonsense. --Matthiasb (talk) 14:48, 20 February 2023 (UTC)[reply]
Oppose This is very subjective, optimizing is good but preventing new features will keep Wikipedia behind. "Slow" is invalid because there could be a variety of problems for a slow website, but modern technology has also made a lot of progress. Perhaps the problem of slowness is not due to the features but to outdated technology (on the part of the cmplaining user or on the part of Wikipedia itself)? --Lukas Raich (talk) 20:13, 20 February 2023 (UTC)[reply]
Oppose Dajasj (talk) 13:22, 22 February 2023 (UTC)[reply]
Support Morten Haan (talk) 18:57, 22 February 2023 (UTC)[reply]
Oppose Fcastillo (talk) 22:16, 22 February 2023 (UTC)[reply]
Oppose VE is still a great thing, although it needs improvement. Thingofme (talk) 01:58, 23 February 2023 (UTC)[reply]
Oppose just because you like something, doesn't make it better to everyone. Snowmanonahoe (talk) 19:15, 23 February 2023 (UTC)[reply]
Strong oppose Community members should not have right to decide what any other member have on their private screen. --Wargo (talk) 23:09, 23 February 2023 (UTC)[reply]

Structured user pages

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: Users currently don't have structured user pages/profiles
Proposed solution: Allow for the possibility of structured user pages
Who would benefit: New users specifically, everyone generally
More comments: Currently users start the Wikimedia journey with a blank user page/a red link. This creates confusion among new users which have to learn the differences between the account and the user page, both concepts which can exist independently of each other in MediaWiki. (Some even use it as a place to write articles.) Most new users, expect to find "a profile" when they create an account, a premade structured user page that showcases some basic information like the languages they speak, maybe their contributions/achievements or even a way to easily reach into their preferences. Having the possibility of structured user pages (maybe starting by expanding the functionality of the homepage tab) would not only help in alleviating the confusion the current system creates on new users (witnessed it first hand in many wiki-workshops) and help them actually have a profile other than a page with the text "Hello!" at most, but it would also help in bringing more integrity to the account itself, possibly suppressing the multiple fake account creation process by one user, given that an account would appear to be more than a "random red link" then.
Phabricator tickets:
Proposer: Klein Muçi (talk) 13:49, 27 January 2023 (UTC)[reply]

Discussion

Hi @Klein Muçi: Is this suggestion more about creating some sort of content model to force a userpage to be "structured", or more about having some sort of "userpage wizzard" that would assist users in creating a basic userpage (the result would just be wikitext as it is now). — xaosflux ^Talk 15:27, 27 January 2023 (UTC)[reply]

Xaosflux, hello! I believe each way would be fine by me personally but maybe the userpage wizzard method could be preferred more. — Klein Muçi (talk) 16:34, 27 January 2023 (UTC)[reply]
In Fandom, there are basic information in a userpage, and it says "This user has not filled their profile yet". I think a userpage wizard would be acceptable into this site and explaining what should and what shouldn't be added into the userpage. Thingofme (talk) 12:03, 29 January 2023 (UTC)[reply]
@Thingofme Looks like translatewiki has that too? Tryvix1509 (talk) 12:21, 29 January 2023 (UTC)[reply]
When you register for Translatewiki it has a settings for people to choose their preferred language, and it has a option for people to set up their location. Thingofme (talk) 12:48, 29 January 2023 (UTC)[reply]
Ah yes, I don't remember this. Tryvix1509 (talk) 12:52, 29 January 2023 (UTC)[reply]
However the #babel template of the user page can be removed by user after setting up the userpage. The request seems to be a userpage instructions and maybe some default profile of a user. Thingofme (talk) 15:00, 29 January 2023 (UTC)[reply]
@Eetzie: Any thoughts on this one? We thought it might be of interest for the Growth team? KSiebert (WMF) (talk) 19:29, 31 January 2023 (UTC)[reply]
cc @KStoller-WMF. The Growth team looked at this idea in 2019 (see phab:T229052) but we did not pursue it further (mw:Growth/Personalized_first_day/User_profile).

The scope of the project is overall pretty big, but I wonder if there is a way we could have a minimal useful version of this as part of the wishlist work, at least to get things moving. KHarlan (WMF) (talk) 20:50, 31 January 2023 (UTC)[reply]
@Klein Muçi Thank you so much for adding this wish! The Growth team still hopes to consider refocusing on a User profile page in the future. I think it might be a larger project, unless we brainstorm a more minimal way to approach this. One smaller idea the Growth team has discussed is around allowing newcomers to easily share their "Impact Module" on their user page T219025. But perhaps you have other ideas for how we could move this from a larger wish to a smaller wish? Feel free to make adjustments to the proposal if you have ideas, but if not I'll accept as is after moving into the "Larger suggestions" category. - KStoller-WMF (talk) 21:30, 31 January 2023 (UTC)[reply]
My MVP proposal for structured user profiles would be to take the language proficiency that's currently collected as part of the welcome survey, turn it into profile-like data (privacy controls, some kind of preferences interface for updating it, an API) and make it interact with / replace similar Babel and ULS functionality. The other potential profile information that would be highly relevant to both Growth features and editor communities is some kind of "interested in" data, maybe via ORES topics or QIDs. (Also maybe CollaborationKit stuff although I don't know much about that extension.) Tgr (talk) 01:34, 1 February 2023 (UTC)[reply]

KStoller-WMF, thank you for the insight. Yes, 90% of the request above is coming from that wish last year. As I've asked elsewhere, I didn't know what happened with old wishes that didn't get chosen as part of that top 10 list. (At least this will tell me not to repeat wishes the next year. Interested users might find more information through that link by following a deep rabbit hole of links in it.)
No problem, feel free to move it to larger ideas. — Klein Muçi (talk) 11:16, 1 February 2023 (UTC)[reply]
@Klein Muçi I've moved this to the Larger suggestions category. I've reviewed the votes and comments on the similar proposal from last year, and I will be sure to continue to watch this proposal. I would love to see the Growth team pick up a project like this in the future, especially if there is community consensus on what a smaller "first iteration" version of this could be. What do you think of @Tgr's idea? Should we add a Phab task for MVP proposal like that? KStoller-WMF (talk) 22:13, 3 February 2023 (UTC)[reply]
KStoller-WMF, yes, everything is better than what we currently have which is practically nothing.
Maybe one can also showcase the account's age (maybe with some fun elements on wikiversaries) and hopefully the WikiLove awards that may have received. But even without these elements, it's good. As I said, everything is a good starting point. — Klein Muçi (talk) 11:45, 4 February 2023 (UTC)[reply]
Thanks, @Klein Muçi! Agreed, it would be good to start somewhere!

@Tgr - would you be willing to outline your MVP proposal for structured user profiles in a Phab task? Do we want to consider narrowing this wish description to just that MVP so it can be moved out of "Larger suggestions" and back to "New contributors"?

Klein Muçi, I also like the idea of sharing account age, and I certainly love the idea of somehow integrating some positive reinforcement moments like wikiversaries and Wikilove! If a structured user page MVP is worked on, it should ideally be build in an extensible way so it can continue to improve over time. KStoller-WMF (talk) 17:06, 5 February 2023 (UTC)[reply]
KStoller-WMF, having the account show the privileges one user may have (admin, reviewer, etc.) can also be a good idea, again something that already exists in many wikis with topicons. Just noting it down as an idea. Thank you for the sympathy shown! — Klein Muçi (talk) 18:13, 5 February 2023 (UTC)[reply]
Related: Allow users to specify their location in their profile. --Tgr (talk) 02:24, 1 February 2023 (UTC)[reply]
- Tgr, yes. This would be part of the same waters with my request. I believe social features should be introduced in the wikisphere. We already have many templates for those features like for languages, location, timezone, happy birthday/other festivities wishes, funny ones like trout slapping, etc. The problem is that most of these features are only accessible on big wikis and for medium to experienced users. New users who need them maybe more than other users to integrate themselves in the community can't usually reach or use them. If we want to foster communities, we need social features. The WikiLove extension is one of the best things that has happened in this direction and I've seen its effect in increasing productivity and creating long lasting contributors firsthand many times. Users' productivity skyrockets after receiving barnstars as recognition for their work. I dare say that having ways to message users privately on-wiki without using 3rd party features or check their online/offline status quickly would also be needed features in this direction which ultimately help in team-building and overall better harmony. Of course, privacy concerns should be heard and people that wish to remain anonymous for whatever reason should have the ability to do so but many of us have been contributing on this site for many years now (I've been around for almost half the age of Wikipedia itself). It's only human to want to socialize with the people you've worked on for over a decade. — Klein Muçi (talk) 11:42, 1 February 2023 (UTC)[reply]
See also Allow user to pin/unpin specific languages, which is also kind of profile-related functionality. Tgr (talk) 06:00, 5 February 2023 (UTC)[reply]
No, let User pages be free, a refuge, where you can write and place whatever you want (within the law and rules of Wikimedia). No strict formats as on many places on Wikimedia (with reason, I would not argue them). What you can do, however, is sending a message to new users (as is done now with Help pages) with suggestions, explaining why a user page is important and what might be there (on Commons a Babel infobox is desirable), perhaps give examples and suggestions without the obligation to make your page similar. That might be a less large project as the proposal here and will perhaps solve a lot of the described problem. --JopkeB (talk) 14:30, 11 February 2023 (UTC)[reply]
I think the "Userpage wizard" idea above is feasible, and may be used. Everyone can create their own userpage in their own taste, but anyone who struggles to edit it may use the wizard instead. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:59, 18 February 2023 (UTC)[reply]

Voting

Support —2dk (talk) 19:40, 10 February 2023 (UTC)[reply]
Support Fallbackintoreality (talk) 20:50, 10 February 2023 (UTC)[reply]
Support Don-vip (talk) 21:45, 10 February 2023 (UTC)[reply]
Support Userboxes need to die. Lectrician1 (talk) 22:35, 10 February 2023 (UTC)[reply]
Support Sabelöga (talk) 23:55, 10 February 2023 (UTC)[reply]
Support SHB2000 (talk | contribs) 01:38, 11 February 2023 (UTC)[reply]
Support Tgr (talk) 04:13, 11 February 2023 (UTC)[reply]
Support EpicPupper (talk) 05:40, 11 February 2023 (UTC)[reply]
Support NMaia (talk) 06:02, 11 February 2023 (UTC)[reply]
Support Grabado (talk) 10:02, 11 February 2023 (UTC)[reply]
Support //Lollipoplollipoplollipop::talk 10:12, 11 February 2023 (UTC)[reply]
Support Oltrepier (talk) 10:15, 11 February 2023 (UTC)[reply]
Support Plaga med (talk) 11:30, 11 February 2023 (UTC)[reply]
Oppose See Discussion --JopkeB (talk) 14:31, 11 February 2023 (UTC)[reply]
Support Bluerasberry (talk) 15:05, 11 February 2023 (UTC)[reply]
Support tsca (talk) 15:12, 11 February 2023 (UTC)[reply]
Support Prairie Astronomer (talk) 15:38, 11 February 2023 (UTC)[reply]
Support FinixFighter (talk) 15:54, 11 February 2023 (UTC)[reply]
Support Ivario (talk) 22:04, 11 February 2023 (UTC)[reply]
Support Furfur^{⁂ Discussion} 00:07, 12 February 2023 (UTC)[reply]
Support Izno (talk) 08:06, 13 February 2023 (UTC)[reply]
Weak support Although structured data on user pages sounds nice, I don't see it as providing enough value that it's a priority at this point. Eiim (talk) 16:17, 13 February 2023 (UTC)[reply]
Support Ottawajin (talk) 12:19, 14 February 2023 (UTC)[reply]
Support Thibaultmol (talk) 18:11, 14 February 2023 (UTC)[reply]
Support Doktor Züm (talk) 07:17, 16 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 08:52, 16 February 2023 (UTC)[reply]
Support Hey man im josh (talk) 16:54, 16 February 2023 (UTC)[reply]
Support 40bus (talk) 19:57, 17 February 2023 (UTC)[reply]
Support Lightoil (talk) 03:26, 18 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:59, 18 February 2023 (UTC)[reply]
Support Shisma (talk) 09:40, 18 February 2023 (UTC)[reply]
Support As long as it's optional, it could be helpful for new users. Mbrickn (talk) 03:22, 20 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:11, 23 February 2023 (UTC)[reply]
Support Althair (talk) 04:15, 23 February 2023 (UTC)[reply]
Support Juandev (talk) 11:25, 23 February 2023 (UTC)[reply]
Support cyrfaw (talk) 13:46, 23 February 2023 (UTC)[reply]

Create a large language model that aligns with the 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: ChatGPT and other large language models (better known as AI chatbots) are being developed, which could either disrupt or benefit Wikimedia projects in unexpected ways.
Proposed solution: create our own models open-source large language models that serve Wikimedia's mission
Who would benefit: Mainly editors by making fighting vandalism and writing content easier
More comments: There has been a proposal named Create Wikipedia article stub from Wikidata using ChatGPT that's related to the topic. Some of the potential uses for such a model includes:
- Brainstorming, identifying possible missing information
- Detecting more subtle context-dependent vandalism
- Generate SQL queries to Wikipedia's database without the user needing to know SQL
- Make templates without needing to know complex wikitext and Lua (probably the easiest to do)
- Copyediting, identifying prose issues
- Recommending known sources and further reading resources to a topic (can be done right now with ChatGPT, but the recommendation would be much more effective if the AI is trained on article references)
- Quickly make stubs on a large scale (Abstract Wikipedia wink wink)
- and more...
Phabricator tickets:
Proposer: CactiStaccingCrane (talk) 11:32, 2 February 2023 (UTC)[reply]

Discussion

We can either use existing language models (e.g. GPT) or develop our own model based on an existing model. But creating a whole new one sounds like very complex and difficult. Thanks. SCP-2000 07:50, 3 February 2023 (UTC)[reply]

Have you seen phab:T328494?--Strainu (talk) 20:17, 10 February 2023 (UTC)[reply]

Voting

Support Xbypass (talk) 20:07, 10 February 2023 (UTC)[reply]
Support TheAmerikaner (talk) 20:17, 10 February 2023 (UTC)[reply]
Strong support PureTuber (talk) 22:20, 10 February 2023 (UTC)[reply]
Support Skimel (talk) 00:39, 11 February 2023 (UTC)[reply]
Support NMaia (talk) 05:59, 11 February 2023 (UTC)[reply]
Support Shizhao (talk) 13:59, 11 February 2023 (UTC)[reply]
Strong oppose as A) Your goals were too vague and ~~B) language models like GPT 3.5 and LaMDA cannot *know*. They can and will spout out bullshit with utter confidence, because they're not meant as a source for information.~~ QuickQuokka ^{[⁠talk • contribs]} 17:17, 12 February 2023 (UTC)[reply]
The thing here isn't to rely on LLMs for factual accuracy, but to make editing easier. Things such as summarizing sources, detecting vandalism, etc. does not require the LLM to "know", it just need to understand and synthesize new text. I do agree that my goals are too vague and I should've lock in at a specific feature that LLMs can deliver. CactiStaccingCrane (talk) 09:50, 13 February 2023 (UTC)[reply]
Oppose It's quite unclear what the goal here is, other than doing it for the sake of doing it. The proposal speaks vaguely of "fighting vandalism", "writing articles", and "benefits", but with no real focus. Perhaps there is a value in large language models for Wikimedia, but there has to be a plausible goal first. Eiim (talk) 16:44, 13 February 2023 (UTC)[reply]
Support Rodolfo Hermans (talk) 09:11, 14 February 2023 (UTC)[reply]
Oppose per Eiim. --Lion-hearted85 (talk) 12:08, 14 February 2023 (UTC)[reply]
Support Its inevitable anyways, so why not do it now? Meganinja202 (talk) 15:50, 14 February 2023 (UTC)[reply]
Support This would be great to just research information, like answering quick question based on information available on the Wikimedia projects. In the answer the AI could redirect to sources. Also, the bibliographic data in Wikidata could be use to access scientific articles in Open Access and further train the AI. Fvtvr3r (talk) 20:16, 14 February 2023 (UTC)[reply]
Support chatGPT is too much of a blackbox, so please, yes, develop Bert76 (talk) 09:36, 15 February 2023 (UTC)[reply]
Support Qono (talk) 18:06, 15 February 2023 (UTC)[reply]
Support People will use LLMs regardless of what our policies say. We might as well make an LLM available that is specifically trained to recognise sources Wikipedia sees as reliable, and specifically trained on our policies. I doubt any general-purpose LLM will ever be "good" at Wikipedia-specific tasks, without being trained specifically for them. DFlhb (talk) 19:36, 16 February 2023 (UTC)[reply]
Support Vulcan❯❯❯Sphere! 16:39, 18 February 2023 (UTC)[reply]
Weak oppose while it could be useful, the issue is that information coming from an AI obviously cannot be fully trusted. For some of these things like source recommendations, the time it would take to verify the the correctness of the AI's suggestions would be just as long as the time it would take to just fully do it yourself, and for things like vandalism detection, that's not what language models can do. That's not what they're for. It's an interesting idea at the base though--using AI to make lives easier. But putting it that way, isn't that what society as a whole is generally trying to do right now? Snowmanonahoe (talk) 19:36, 18 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:54, 21 February 2023 (UTC)[reply]
Support Thank you, but this MUST be backed up by RSs. Thingofme (talk) 01:56, 23 February 2023 (UTC)[reply]

Implement an offline editor

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: Various reasons, such as power outage, connection errors, and lack of free time or unexpected abandonment of editing. Wikipedia users have the problem of editing large or small articles or even creating them. Since there may be server errors and other errors, they can interrupt users when creating articles.
Proposed solution: Computer software for personal computers and mobile phones can be designed in which users can benefit from all the tools of the visual editor or the code editor. So users could create their articles and improve them on their computers over time offline.
Who would benefit: Wikipedia users and even users of other wikis such as Wikidata, Commons...etc would benefit. Users will have fewer spelling and grammatical errors when uploading articles because the articles will be developed on users' devices by adding references, styles, information...etc.
More comments:
Phabricator tickets:
Proposer: Leonard611 (talk) 10:18, 26 January 2023 (UTC)[reply]

Discussion

I am very sorry for not specifying my language (Spanish)

@Leonard611: ¡Hola! Gracias por presentar esta propuesta. Recibimos esta propuesta. ¿Usted cree que es similar a su propuesta?
Perhaps give a look at w:Visual Studio Code and vscode extension Wikitext? Developed by Chinese Wikipedia contributors, it is somewhat widely used in zhwiki. Milky Defer 03:09, 27 January 2023 (UTC)[reply]
Ideally, this should include a regular expression change facility and a case (upper, lower, sentence, title, toggle) conversion facility. Case conversion should not be limited to ASCII A-Z. --Chatul (talk) 13:17, 22 February 2023 (UTC)[reply]

¿Propuesta Similar?

Problem: Al realizar ediciones más grandes y, en particular, al escribir nuevos artículos, existe la posibilidad de pérdida de datos (posiblemente un valor de algunas horas) debido a::

un corte de energía,
un bloqueo del navegador,
una interrupción de la red (si uno elige obtener una vista previa de sus cambios mientras la red está temporalmente fuera de línea), cierre accidental del navegador.

Es una característica bastante estándar en el software moderno para guardar automáticamente las ediciones del usuario para protegerse contra tales incidentes. El guardado automático es omnipresente en el software basado en la nube, donde tiene el beneficio adicional (o quizás principal) de permitir que el usuario no piense en guardar su trabajo/seguir trabajando en el mismo documento en varias sesiones/a través de múltiples dispositivos. (Podría decirse que sería deseable tenerlo en Wiki por derecho propio). El software "fuera de línea" a menudo también tiene una función de guardado automático, aunque generalmente solo para la recuperación de fallas (por ejemplo, LibreOffice).

El editor de código actualmente no proporciona ningún tipo de funcionalidad de guardado automático, mientras que el Editor visual parece tener algún tipo de guardado automático implementado, o eso deduzco basado en phab: T57370 (Normalmente no uso el Editor visual, así que no puedo decir si realmente está presente; si lo está, entonces parece estar oculto y sin documentar, sin ninguna indicación en la interfaz de usuario de que se está guardando algo, casi tan bueno como si no estuviera allí). Algunas soluciones alternativas que los usuarios, especialmente aquellos que han experimentado pérdida de datos en el pasado, probablemente empleen incluyen:

copiando periódicamente su trabajo del editor Wiki a un programa externo (por ejemplo, el Bloc de notas) y guardándolo localmente;
escribir artículos completos en un programa externo y solo copiarlos en un editor Wiki una vez que estén listos;
escribiendo su artículo en su sandbox y guardando regularmente. Cada uno de estos es inconveniente/requiere mucho tiempo/disminuye la productividad.

Proposed solution: Una funcionalidad confiable de guardado automático que guarda regularmente las ediciones del usuario en segundo plano, que funciona tanto en el editor de código como en el Editor visual, lo que permite restaurar estas ediciones en los 4 casos enumerados anteriormente.

Deseable: un indicador en la interfaz de usuario del editor que le dice al usuario si la página que está editando se guardó por última vez o cuándo, para asegurarle que el guardado automático está realmente presente y funcionando, y por lo tanto no necesita recurrir a ninguno de los las soluciones mencionadas anteriormente. Guardar estas ediciones en línea (en servidores Wiki), para permitir que el usuario continúe trabajando en una página en múltiples sesiones/a través de múltiples dispositivos. (Solo para aclarar: hasta que el usuario las publique, estas ediciones deben permanecer privadas y no visibles para nadie más que el usuario en cuestión).

Who would benefit: Todos los editores, pero en particular: aquellos que escriben artículos más extensos, y dos grupos que, creo, Wikimedia está particularmente interesada en reclutar/retener: editores nuevos, que probablemente se desalienten particularmente si se pierde su arduo trabajo, editores en países , donde se producen con frecuencia cortes de energía/"cortes de carga", que tienen una probabilidad desproporcionada de estar en el Sur Global (como India o Sudáfrica, si se cree en los informes de los medios).

Dejeme saber si piensa que su propuesta es similar o diferente a la propuesta mencionada. HMonroy (WMF) (talk) 23:01, 26 January 2023 (UTC)[reply]

Well, it does look a bit like it. But the difference is that it proposes a different solution to the same problem. The editors you showed me look interesting but I was referring to a code and visual editor at the same time. If it were visual it would be easier for those who are not used to the code editor. I hope you understand, thanks and greetings. Leonard611 (talk) 10:30, 27 January 2023 (UTC)[reply]

I also think that the proposal that I raise has a little more benefits than the previous one. Since articles could be created with the free time of the editors and in fact avoid the many problems that some Internet connections and servers present. (In my case I live in an area with low connection and I use a mobile phone, so if this proposal is accepted, a mobile phone version would be very useful for me. I'm sure it will also be useful for other people) . Thanks and regards Leonard611 (talk) 21:36, 27 January 2023 (UTC)[reply]

Hello guys, I see that my proposal is doing well, however we need to spread it in all the wikis in order for it to be applied and thus increase its popularity. Leonard611 (talk) 06:53, 16 February 2023 (UTC)[reply]

Voting

Support Magnoliasouth (talk) 23:29, 10 February 2023 (UTC)[reply]
Support Skimel (talk) 00:26, 11 February 2023 (UTC)[reply]
Support This is a great idea. Goliv04053 (talk) 06:29, 11 February 2023 (UTC)[reply]
Support Transient-understanding (talk) 08:18, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:33, 11 February 2023 (UTC)[reply]
Support Kekavigi (talk) 09:22, 11 February 2023 (UTC)[reply]
Support Muted Red Tulip (talk) 10:07, 11 February 2023 (UTC)[reply]
Support Plaga med (talk) 11:33, 11 February 2023 (UTC)[reply]
Support Prairie Astronomer (talk) 15:40, 11 February 2023 (UTC)[reply]
Support Baba Gaby (talk) 18:33, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:29, 12 February 2023 (UTC)[reply]
Support Fvtvr3r (talk) 13:54, 12 February 2023 (UTC)[reply]
Support Thomas Kinz (talk) 01:26, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 07:17, 14 February 2023 (UTC)[reply]
Support This would be quite helpful! Mikxth (talk) 11:54, 14 February 2023 (UTC)[reply]
Support This could be of great aid to Wikipedians living in places with poor bandwidth. Ottawajin (talk) 12:14, 14 February 2023 (UTC)[reply]
Support It's a good idea. J. Manolo G. P. (Talk) 10:51, 15 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 09:07, 16 February 2023 (UTC)[reply]
Support JFremd (talk) 16:24, 16 February 2023 (UTC)[reply]
Support -- Ferien (talk) 11:28, 18 February 2023 (UTC)[reply]
Support Lupe (talk) 14:44, 18 February 2023 (UTC)[reply]
Support I edit a lot on my phone on public transport, and the occasional connection interruption is really annoying Trimton (talk) 15:41, 18 February 2023 (UTC)[reply]
Support Jotamide (talk) 16:03, 18 February 2023 (UTC)[reply]
Support Lightoil (talk) 01:56, 20 February 2023 (UTC)[reply]
Support Mbrickn (talk) 03:25, 20 February 2023 (UTC)[reply]
Support Augend (talk) 07:57, 20 February 2023 (UTC)[reply]
Support Qxyz123 (talk) 04:35, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 12:03, 22 February 2023 (UTC)[reply]
Support Chatul (talk) 13:18, 22 February 2023 (UTC)[reply]
Support Morten Haan (talk) 18:55, 22 February 2023 (UTC)[reply]
Support Madacs (talk) 20:51, 22 February 2023 (UTC)[reply]
Support Thingofme (talk) 01:47, 23 February 2023 (UTC)[reply]
Support Althair (talk) 04:11, 23 February 2023 (UTC)[reply]
Support I am aware of users, who have such problems, and it's really annoying to loose several hours of work from relation. Juandev (talk) 11:39, 23 February 2023 (UTC)[reply]
Support منى ناصر ثابت علام حُزين (talk) 16:56, 23 February 2023 (UTC)[reply]

Tool for searching infobox parameter values

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: Some template parameters should have only few values or value types. eg. | foo = <number_only> or | bar = [ABC|DEF|GHI] . For template maintenance should be useful to have list and count of values. Some of this can be done via monitoring categories (see cs.wikisource), but this is suitable for small projects only or with some db query, which is only for few geeks.
Proposed solution: Make some project like petscan or SPARQL, where user can choose template, parameter(s) and type of output. Some example:
- Template:<Infobox - foo>
- Parameter:<state>
- Output:<count|values|regex>
  - Count -> paramter state is used 1234x
  - values - > Albania 5x, Albanie 2x, Andorra 1x.... (table)
  - regex -> 1231x yes, 3x no
After this should be useful If I can search for articles containig specfic value in specific infobox - this can be done via insource, but there are also false positives (have template ffo, but parameter bar is in another template)
Who would benefit: Editors who works on maintenace.
More comments: There was project TemplateTiger, but is more than 5 years out of order. This project made some useful outputs from dumps.
Phabricator tickets: T120767
Proposer: JAn Dudík (talk) 21:25, 26 January 2023 (UTC)[reply]

Discussion

English Wikipedia has something that does a lot (I think) of what you're asking for: Template Parameters. It has some restrictions to reduce processing time (and only runs once a month). No more than 50 values are displayed for any parameter, and for highly used templates (more ~50,000 transclusions), the ability to show exactly which articles contain a particular parameter or value is turned off (but insource regex searches can be used to find a particular value; if I understand, the problem you're having is at least in part not evening knowing what anomalous values might be present in order to search for them). Plantdrew (talk) 23:54, 30 January 2023 (UTC)[reply]

Notably also part of the 2015 wishlist already. —TheDJ (talk • contribs) 13:20, 2 February 2023 (UTC)[reply]
@JAn Dudík: I want to make sure we're understanding the problem, and not focusing as much on the solution. It sounds like the main use-case is for deprecating parameters of template. Is that correct? I see you mention tracking categories, and I wonder why you feel that isn't workable for other projects as well. Tracking categories are used when this situation happens on English Wikipedia, for example en:Category:Deprecated parameters. Template editors can add checks for what parameters and values are passed in, and then categorize accordingly. Are there other use-cases you have that aren't solved by categorization? The proposed solution as currently written would be very complex and likely too large for our team, as it requires preprocessing an entire wiki's template namespace and all transclusions. To do this for every wiki wouldn't seemingly be feasible with the current architecture of MediaWiki. MusikAnimal (WMF) (talk) 21:27, 3 February 2023 (UTC)[reply]
Some example: | parametrer = should be foo, [[Foo]]-Bar Foo, [[Foo]] or [[Bar|Foo]] and I want to know which format is most common and unify it.

Main problem of tracking categories is that some people hates rec categories and creates them even if the are only for few days, and populating this categories takes long time or need bot. JAn Dudík (talk) 19:45, 6 February 2023 (UTC)[reply]
@JAn Dudík Okay, thank you! I think I understand now. This still sounds like a massive project. I had never used the old TemplateTiger tool, but according to the German documentation it took years for it to go through large wikis like English and German Wikipedias. Surely that's not satisfactory.

Did you see the tool that @Plantdrew mentioned above? It has a lot of limitations, but it sounds like it may offer some of what you need. Though, I see it only supports a handful of wikis.

Overall, I think there may be something doable here for our team, but I hate to build yet another difficult-to-maintain external tool that essentially has to go through every transclusion. Better would be to somehow solve this in MediaWiki itself, which is a huge project. So I'm still leaning towards moving this to Larger suggestions. A hacky Toolforge tool doesn't sound like a suitable answer, in my opinion, especially if we know it can't ever run off of recent, live data. MusikAnimal (WMF) (talk) 17:24, 7 February 2023 (UTC)[reply]
I was afraid this is too large. But - some users can give similar outupt from some database query in short time. Maybe some interface for less experienced users should do the same? JAn Dudík (talk) 19:18, 7 February 2023 (UTC)[reply]
@JAn Dudík Can you give an example? I'm not aware of template parameters or their values being stored in the MediaWiki database. MusikAnimal (WMF) (talk) 01:53, 8 February 2023 (UTC)[reply]
I think DBPedia does this, but it only gets updated a few times a year. --Tgr (talk) 05:32, 5 February 2023 (UTC)[reply]
Question: @ MusikAnimal (WMF) I agree about the complication, as we are after database functionality in a wiki, and are maintaining the system using ad hoc maintenance. What about if we bit the bullet and used sql functionality at time of entry and update? and wikidata schemas to validate infoboxes at data entry? OpenStreetMap has some sort of valiation using wikidata, but it's regex based. A SQL structure is far simpler, and would be better suited for dynamic links so that we could get updates from external offical databases. Wakelamp (talk) 04:07, 7 February 2023 (UTC)[reply]
@Wakelamp Something along those lines would be better, yes! I was thinking as far as validation, mw:Extension:TemplateStyles could better handle this, as that's what the community is used to using for specifying each parameter and values. At any rate, I think the project is too big for our team, as much as I'd love to work on it. MusikAnimal (WMF) (talk) 18:29, 7 February 2023 (UTC)[reply]
I misread the original proposal - it's about a dump not live data
But about the other issue - It's sad that it is too big. I was thinking that we may have some hidden constraints with the way we view wikipedia we
everything must be done in wikipedia using wikis

Everyting involving an article should be updated on the article.
Wakelamp (talk) 10:36, 9 February 2023 (UTC)[reply]
@Bamyers99, Hello! How difficult is it to extend this tool (https://bambots.brucemyers.com/TemplateParam.php) to all wikis (or just some of them)? :) Your tool is really cool! Iniquity (talk) 23:10, 8 February 2023 (UTC)[reply]
The tool can be extended to support other wikis (not all). It is hosted on my personal server (long story on why I moved it from Toolforge) so there are data size limitations and processing time constraints. A main purpose of the tool is to find template usage that does not conform to the TemplateData schema defined for a template. Plantdrew is correct about the tools limitations, however, the tool does report all non-conforming template usage even for highly used templates. — The preceding unsigned comment was added by Bamyers99 (talk) 02:05, 10 February 2023 (UTC)[reply]
@Bamyers99, thanks for answer! Where can I request the addition of a new wiki? :) Iniquity (talk) 07:20, 10 February 2023 (UTC)[reply]
@Iniquity: New wiki requests at en:User talk:Bamyers99. --Bamyers99 (talk) 14:43, 10 February 2023 (UTC)[reply]

Voting

Support Matěj Suchánek (talk) 18:40, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:22, 12 February 2023 (UTC)[reply]
Support Betseg (talk) 03:39, 12 February 2023 (UTC)[reply]
Support Libcub (talk) 06:05, 14 February 2023 (UTC)[reply]
Support Hey man im josh (talk) 16:50, 16 February 2023 (UTC)[reply]
Support Jklamo (talk) 12:24, 19 February 2023 (UTC)[reply]
Support — Draceane ^talk_contrib. 12:52, 20 February 2023 (UTC)[reply]
Support Madacs (talk) 20:40, 22 February 2023 (UTC)[reply]
Support Thingofme (talk) 01:48, 23 February 2023 (UTC)[reply]
Support Althair (talk) 04:12, 23 February 2023 (UTC)[reply]
Support Daniel Case (talk) 05:52, 23 February 2023 (UTC)[reply]

Allow changing text written in the "Edit summary" after saving an edit

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: When a user makes an edit, they can use the edit summary (Help:Edit summary) to write something. However, he realizes that he has written something wrong but cannot correct it as he cannot edit the edit summary.
Proposed solution: Allow users to make an edit summary change after saving their edits to correct something they wrote wrong.
Who would benefit: All users would benefit, as they would be able to resolve any information errors in the edit summary. Even administrators could benefit from the proposal, correcting any injustices regarding fallacious accusations in "edit summary" after a more careful analysis of the community on conflicts. I believe that everyone would have the opportunity to redeem themselves for any errors written in the edit summary.
More comments: With the approval of this proposal, it should be implemented in all Wiki projects. I believe that each local project could determine internal rules to avoid possible abuse of the edit summary, so this would be the role of each local community. The MediaWiki developers would initially allow the ability to edit summary without any restrictions.
Phabricator tickets:
Proposer: WikiFer ^msg 13:59, 5 February 2023 (UTC)[reply]

Discussion

Old task for this was T12105. It would be pretty complex, you need an audit trail, a place to put that audit trail (which can't be the page history), a way to see changes, a way to revert, RC / watchlist integration, probably AbuseFilter integration... --Tgr (talk) 23:27, 5 February 2023 (UTC)[reply]

Voting

Support if it is doable. —2dk (talk) 19:48, 10 February 2023 (UTC)[reply]
Strong oppose There are way too many issues with this, specifically the attribution of the edits to the edit summary. This was discussed recently on enWiki but I can't seem to find the thread at the moment. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 23:50, 10 February 2023 (UTC)[reply]
Strong oppose Deeply problematic suggestion. If editors encounter this issue then the solution is null edits to clarify in page history or talk page if necessary. 5225_C (talk • contributions) 03:15, 11 February 2023 (UTC)[reply]
It would require a dummy edit. As a newbie I learned the hard way that edit summaries are not saved on null edits. – Fayenatic London 09:21, 11 February 2023 (UTC)[reply]
There used to be an __END__ magic word you could use to force dummy edits to save, but it was removed a very long time ago... I honestly miss it, lol. —Locke Cole • t • c 09:01, 15 February 2023 (UTC)[reply]
Then all these magical details should be just implemented automatically, giving end users (WP editors) a human-friendly interface to amend their edit summaries. — Mikhail Ryazanov (talk) 01:27, 16 February 2023 (UTC)[reply]
Oppose per above. * Pppery * _{it has begun} 04:08, 11 February 2023 (UTC)[reply]
Support --Crosstor (talk) 13:54, 11 February 2023 (UTC)[reply]
Support OwenBlacker (Talk) 14:43, 11 February 2023 (UTC)[reply]
Support CROIX (talk) 15:20, 11 February 2023 (UTC)[reply]
Oppose could be used to hide what you really meant! Smallbones (talk) 16:33, 11 February 2023 (UTC)[reply]
Oppose There has to be an immutable ground truth of edits at some level of abstraction, and I think it's pretty well conceptualized as things are. I acknowledge the rough edges of the current system, but on balance it's significantly better as-is. NillaGoon (talk) 22:57, 11 February 2023 (UTC)[reply]
Oppose when you write something you have to think about it before saving. or write without logging in. --Blonder1984 (talk) 07:20, 12 February 2023 (UTC)[reply]
Support If this is doable, I'm in favor, as long as the history of edits to the edit summary is preserved. I've often made small errors and wished I could go back and correct them, for the benefit of those who peruse the history of a page. Waldyrious (talk) 07:38, 12 February 2023 (UTC)[reply]
Weak support Sometime i indeed write an incorrect summary edit, generally because i have selected the wrong choice from my browser auto-fill proposals. I wish i could correct them for a correct history. That said, this may be a problem, so maybe restrict this option to be available only a short period, like 1 hour (or even less). Miniwark (talk) 11:28, 13 February 2023 (UTC)[reply]
Support Abuse could be prevented by limiting the time frame in which the edit is possible and by storing the history of the edit summaries. Titore (talk) 14:49, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 06:16, 14 February 2023 (UTC)[reply]
Support As Titore and Miniwark suggested, a very small time frame (even 20 or 30 seconds, or 1 minute) could prevent abuse. Adding a tag that the edit summary has been edited, and the prerequisite that no other edits have been made during this time frame, could avoid confusion. --Lion-hearted85 (talk) 12:37, 14 February 2023 (UTC)[reply]
Support Only once and for short time (eg 30 seconds) after save JAn Dudík (talk) 21:56, 14 February 2023 (UTC)[reply]
Support Given than only certain groups ou users can do so, e.g. admins Ruthven (msg) 15:49, 15 February 2023 (UTC)[reply]
Support Mikhail Ryazanov (talk) 01:23, 16 February 2023 (UTC)[reply]
Oppose If you really need to a different edit summary, then a dummy edit can be used. --Salix alba (talk) 04:16, 16 February 2023 (UTC)[reply]
Support A 60 second window in which to fix a summary would be very useful. Maybe also the option to append a second edit summary to explain a bad edit summary? Dummy edits are ugly. Doktor Züm (talk) 07:38, 16 February 2023 (UTC)[reply]
Support Maybe within a timeframe or before additional edit afterwards. Sometimes you press enter and then realize you had more to say! Dblu9494 (talk) 21:21, 16 February 2023 (UTC)[reply]
Oppose Page can be edited again with another summary. I see no reason to change what has been posted already. Sikander (talk) 22:49, 16 February 2023 (UTC)[reply]
Support I think it’s legitimate to grant the right to change up to, say, two characters within a short time frame. Kays (talk) 00:58, 17 February 2023 (UTC)[reply]
Support Any typo in the wiki must be fixable. Edward Chernenko (talk) 16:24, 17 February 2023 (UTC)[reply]
Support Lightoil (talk) 03:28, 18 February 2023 (UTC)[reply]
Oppose Lupe (talk) 14:24, 18 February 2023 (UTC)[reply]
Oppose unless it is limited to a few seconds (up to 60sec). Being able to change edit summaries could make editors doubt the good faith of other users Trimton (talk) 15:25, 18 February 2023 (UTC)[reply]
Support I support a 60 second window to fix typos or add minor remarks. Jotamide (talk) 15:56, 18 February 2023 (UTC)[reply]
Support As long as it's limited to a 60-sec frame Tutwakhamoe (talk) 23:03, 18 February 2023 (UTC)[reply]
Strong oppose Too much opportunity for gaslighting and other manipulation. I could support a strikethrough of the summary followed by a new summary. Constant314 (talk) 18:25, 19 February 2023 (UTC)[reply]
Strong support Probably should be possible only until another edit is made, like editing a git repo's history. Null/dummy edits clutter up history and make it harder to read. In fact, it should also be possible to submit multiple subsequent changes to the article that are combined into a single edit, like edits are treated on Stack Exchange. — Omegatron (talk) 16:26, 20 February 2023 (UTC)[reply]
Support Serieminou (talk) 23:19, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 11:04, 22 February 2023 (UTC)[reply]
Strong oppose Zero edits is more appropriate, besides being able to change edit summaries at will is too expensive--SunAfterRain 15:00, 22 February 2023 (UTC)[reply]
Oppose This makes way to [widespread] manipulation for an open encyclopaedia — DaxServer (t · m · c) 17:00, 22 February 2023 (UTC)[reply]
Support Open, but should be possible if it is the latest version (Archive links should not be broken, though...) Thingofme (talk) 02:07, 23 February 2023 (UTC)[reply]
Support within a limited time GoingBatty (talk) 03:52, 23 February 2023 (UTC)[reply]

Restore scholarships.wikimedia.org

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: archived without considerations to need of Wikimanias beyond 2021
Proposed solution: restore the website and the software designed specifically for Wikimania Scholarships
Who would benefit: Every Wikimania, and every scholarship application. The review team would be able to review without putting temporary data in google sheets. The WMF and Wikimania teams will be able to obtain consistent statistical data to compare year after year
More comments: This tool has a long history of being being both effective and storing data in a safe way. It doesn't rely on the using third party commercial applications to do the same work.
Phabricator tickets: phab:T243037
Proposer: Gnangarra (talk) 10:49, 4 February 2023 (UTC)[reply]

Discussion

Thanks for the proposal! Unfortunately restoring a project is not something Community Tech can help with. However we're happy to see this through voting in our Larger suggestions category so it gets the visibility it deserves. MusikAnimal (WMF) (talk) 03:55, 6 February 2023 (UTC)[reply]
phab ticket say they cant restore without a software update, that is within the reach of the community tech team Gnangarra (talk) 10:48, 22 February 2023 (UTC)[reply]

Voting

Support Robertsky (talk) 19:55, 10 February 2023 (UTC)[reply]
Support Magnoliasouth (talk) 23:27, 10 February 2023 (UTC)[reply]
Support Քրմապետ (talk) 13:43, 11 February 2023 (UTC)[reply]
Support Novak Watchmen (talk) 17:55, 11 February 2023 (UTC)[reply]
Support Ameisenigel (talk) 09:22, 12 February 2023 (UTC)[reply]
Support Tryvix ^t 13:54, 12 February 2023 (UTC)[reply]
Support Leonry (talk) 15:42, 12 February 2023 (UTC)[reply]
Support Aishik Rehman (talk) 09:03, 16 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 07:52, 18 February 2023 (UTC)[reply]
Support This is like Wikimania scholarships. Thingofme (talk) 01:51, 23 February 2023 (UTC)[reply]
Support cyrfaw (talk) 13:41, 23 February 2023 (UTC)[reply]

Support for major multimedia tools: VideoJS, MediaViewer

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: Now there is a problem, the tools that everyone uses, which everyone sees every day, are completely devoid of support. They have problems with design, functionality, accessibility, code and they are not integrated with each other. All this affects the reader's experience and the overall vision of the style of MediaWiki.
Proposed solution: Select people who would maintain the product
Who would benefit: Readers, Content creators
More comments: https://phabricator.wikimedia.org/tag/videojs_player/, https://phabricator.wikimedia.org/project/view/230/
Phabricator tickets:
Proposer: Iniquity (talk) 11:36, 2 February 2023 (UTC)[reply]

Discussion

@Iniquity: Thank you for submitting this proposal! I see that you provided links to Phabricator boards related to VideoJS and Media Viewer. The survey is meant to highlight specific problems. Are there any particular tasks that you would like to address in this proposal? — The preceding unsigned comment was added by HMonroy (WMF) (talk) 02:01, 8 February 2023 (UTC)[reply]
Hello, yes there is. Main problems with VideoJS: phab:T258584, phab:T311343, phab:T258585. MediaViewer: it needs to rewrite, I think xD Look in the board. And it needs to be integrated with the player Iniquity (talk) 07:57, 8 February 2023 (UTC)[reply]
@Iniquity Could you reword your proposal to be about just one of those problems? Our FAQ goes into more detail as to what we're looking for as far as the scope of proposals. Alternatively, we can move this to our Larger suggestions category to get the attention of leadership, but this would mean it'd be out of scope for Community Tech. As currently written, your proposed solution of "Select people who would maintain the product" would make this a Larger suggestion. Community Tech is not able to assign teams or people to projects.

Unfortunately we have only until sometime tomorrow to get this proposal rewritten, if we want it to be in scope for Community Tech. Sorry to rush you! Thanks and regards, MusikAnimal (WMF) (talk) 18:56, 8 February 2023 (UTC)[reply]
@MusikAnimal, If I rewrite it for a small tasks, it definitely won't get votes. I don't think I will, thanks :) Iniquity (talk) 20:11, 8 February 2023 (UTC)[reply]
Okay. You're probably right, but small tasks can also be picked up at Hackathons (there's one coming up in May, for example). But with your word, let's leave this as-is and move to Larger suggestions. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 21:57, 8 February 2023 (UTC)[reply]
I guess what this is saying is that there should be a Multimedia team (again). --Tgr (talk) 04:12, 11 February 2023 (UTC)[reply]

Voting

Support Strainu (talk) 20:18, 10 February 2023 (UTC)[reply]
Support Tgr (talk) 04:12, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:12, 11 February 2023 (UTC)[reply]
Support Ivario (talk) 22:03, 11 February 2023 (UTC)[reply]
Support --NGC 54 (talk｜contribs) 01:25, 12 February 2023 (UTC)[reply]
Support Mautam (talk) 06:44, 12 February 2023 (UTC)[reply]
Support Mauricio V. Genta (talk) 08:05, 12 February 2023 (UTC)[reply]
Support I agree with Tgr that the entire multimedia story in Wikimedia needs some love. Waldyrious (talk) 08:43, 12 February 2023 (UTC)[reply]
Oppose Completely agree multimedia needs more TLC, but this proposal is too vague and makes no suggestions at all on how to accomplish that. Husky (talk) 21:17, 12 February 2023 (UTC)[reply]
Support Izno (talk) 08:03, 13 February 2023 (UTC)[reply]
Support Libcub (talk) 06:02, 14 February 2023 (UTC)[reply]
Support Lion-hearted85 (talk) 12:12, 14 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:11, 18 February 2023 (UTC)[reply]
Support The entire project definitely needs more dedication towards multimedia. Far beyond keeping the thumbnails and uploads working and some metadata on the side. —TheDJ (talk • contribs) 13:56, 18 February 2023 (UTC)[reply]
Support Vulcan❯❯❯Sphere! 16:40, 18 February 2023 (UTC)[reply]
Support Crainsaw (talk) 11:41, 19 February 2023 (UTC)[reply]
Support Augend (talk) 07:59, 20 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:31, 21 February 2023 (UTC)[reply]
Neutral this proposal doesn't seem to be actually asking for anything. Snowmanonahoe (talk) 14:33, 22 February 2023 (UTC)[reply]
Support Thingofme (talk) 02:07, 23 February 2023 (UTC)[reply]
Support TMg 12:52, 23 February 2023 (UTC)[reply]
Support Patsagorn Y. (Talk) 03:40, 24 February 2023 (UTC)[reply]
Support MichaelSchoenitzer (talk) 11:28, 24 February 2023 (UTC)[reply]

Search in a member's contribution

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: There is no possibility to search not in the whole Wikipedia, but in the contribution of a specific editor
Proposed solution: Add this option
Who would benefit:
More comments: One possibility would be to make it easier to test bypassing the blocking using duck-test
Phabricator tickets:
Proposer: Pessimist (talk) 16:23, 2 February 2023 (UTC)[reply]

Discussion

@Pessimist2006: Could clarify what you mean by searching user contributions, i.e. do you mean searching specifically for the words that have been added or removed by the contributor? I think that providing a few examples would be helpful. DCausse (WMF) (talk) 15:47, 3 February 2023 (UTC)[reply]
Yes, searching specifically for the words that have been added by the contributor.

https://prnt.sc/jxm1hjS-fHq4 Pessimist (talk) 08:59, 5 February 2023 (UTC)[reply]
@Pessimist2006 Thanks for the clarification! I'm not an expert in this field, but I suspect doing arbitrary text searches against a user's contributions is not something that will work quickly enough for it to be usable. Some users have millions of edits. We could however build an external tool, with the caveat that it will run rather slowly. There might already be similar tools now. Does that sound like a good solution to you? MusikAnimal (WMF) (talk) 22:49, 8 February 2023 (UTC)[reply]

Hi Pessimist2006, we're going to move this to the Larger Suggestions section, as implementing this in MediaWiki would likely require significant effort (namely, indexing contributions for search by user) — it's certainly an interesting proposal though, and by keeping it in the larger suggestions category allows us to gauge interest. I hope that makes sense! — TheresNoTime-WMF (talk • they/them) 14:10, 10 February 2023 (UTC)[reply]
OK, it's good idea. Pessimist (talk) 20:14, 10 February 2023 (UTC)[reply]

Voting

Support. DatGuy (talk) 19:23, 10 February 2023 (UTC)[reply]
Support Fallbackintoreality (talk) 20:52, 10 February 2023 (UTC)[reply]
Support Klein Muçi (talk) 00:44, 11 February 2023 (UTC)[reply]
Support Pmsyyz (talk) 01:14, 11 February 2023 (UTC)[reply]
Support * Pppery * _{it has begun} 04:08, 11 February 2023 (UTC)[reply]
Support NMaia (talk) 06:04, 11 February 2023 (UTC)[reply]
Support Arado Ar 196 (talk) 08:32, 11 February 2023 (UTC)[reply]
Support --Jim Hokins (talk) 09:20, 11 February 2023 (UTC)[reply]
Support //Lollipoplollipoplollipop::talk 10:10, 11 February 2023 (UTC)[reply]
Support CaféBuzz (talk) 11:16, 11 February 2023 (UTC)[reply]
Support Guerillero ^{Parlez Moi} 14:03, 11 February 2023 (UTC)[reply]
Support JopkeB (talk) 15:05, 11 February 2023 (UTC)[reply]
Support Prairie Astronomer (talk) 15:39, 11 February 2023 (UTC)[reply]
Oppose For me it looks too dangerous in terms of abuse during the existence of censorship in some states. Lvova (talk) 16:44, 11 February 2023 (UTC)[reply]
Support Ivario (talk) 22:03, 11 February 2023 (UTC)[reply]
Support Gohan 04:53, 12 February 2023 (UTC)[reply]
Support In my opinion, it will be useful German Stimban (talk) 04:10, 13 February 2023 (UTC)[reply]
Support Izno (talk) 08:06, 13 February 2023 (UTC)[reply]
Support SpacedShark (talk) 06:35, 14 February 2023 (UTC)[reply]
Support Labdajiwa (talk) 00:00, 15 February 2023 (UTC)[reply]
Weak support as I do believe that this can be a useful feature, but as User:Lvova mentioned, it can be abused by authoratarian governments and people searching through your edits to defame you. QuickQuokka ^{[⁠talk • contribs]} 20:29, 15 February 2023 (UTC)[reply]
Everything is stored in the database. A authoritarian government absolutely wanting to defame someone doesn't need a nice new feature, they would just employ a computer scientist who knows how to swift through the database. —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:34, 18 February 2023 (UTC)[reply]
No need to help them. Lvova (talk) 12:38, 21 February 2023 (UTC)[reply]
Support Doktor Züm (talk) 07:41, 16 February 2023 (UTC)[reply]
Support ಮಲ್ನಾಡಾಚ್ ಕೊಂಕ್ಣೊ (talk) 17:33, 16 February 2023 (UTC)[reply]
Support —‍(ping on reply)—‍CX Zoom (A/अ/অ) (let's talk|contribs) 08:34, 18 February 2023 (UTC)[reply]
Oppose as User:Lvova mentioned, this can be abused Christian (talk) 20:41, 18 February 2023 (UTC)[reply]
Support Althair (talk) 01:56, 20 February 2023 (UTC)[reply]
Support β₁₆ - (talk) 14:30, 20 February 2023 (UTC)[reply]
Support Tutwakhamoe (talk) 20:02, 20 February 2023 (UTC)[reply]
Support Qxyz123 (talk) 04:30, 21 February 2023 (UTC)[reply]
Support cyrfaw (talk) 18:31, 21 February 2023 (UTC)[reply]
Support This should be useful -- however there is potential for harassment. Thingofme (talk) 01:58, 23 February 2023 (UTC)[reply]

[1] ttps://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2022/03#Pandemie_covidu-19_v_Rakousku_(Q86847911)_is_full_(no,_literally)

[2] ttps://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2022/02#Population:_P1082_or_P4179?

[3] ttps://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2022/11#Tabular_style_data_on_items?

[1]

[2]

[3]