Wikimedia Meta-Wiki

Community Wishlist Survey 2023/Larger suggestions

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



Fix unified login to Wikidata and Commons

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

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

Discussion

Voting

Add semantics of processes

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

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

Discussion

Voting

Finalize Gadgets 2.0

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

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

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

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

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

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

Dismantling of the annual Wishlist Survey system

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

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

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]
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:
  1. We can aknowledge that the wishlist system was a good idea, but it have failed to deliver. We can create a relate in which every year the team makes something, but the reality is hard, and numbers are numbers. Only 7 of the most voted 35 wishes were awarded in the last 4 years, and some of them in a sum-optimal way, with tools that only work in some very specific conditions. The system is not working, and is not going to work better in the future, so creating scarcity and promotig a wishlist that is not going to work is not the best idea. The WMF can't spend more money on this, and solving issues should be done by the community. This would need a better path for volunteers in order to make such contributions.
  2. We can aknowledge that the wishlist system is a good idea, it have failed to deliver, but changes can be made to fulfill the wishes and make our product better. This would need a team, probably larger than what we have, more money to invest on hiring people with coding skills and more time for this functions, eventually having a full-time dedicated team unblocking the huge tech debt, and making our product the best one... before 2030. This will create other problems with the community, because hiring more people is not always welcome, and some of the new products will have opposition.
Is up to the leadership to decide which path is better. Theklan (talk) 16:32, 2 February 2023 (UTC)[reply]
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.

  1. Google Knowledge panels
  2. Google auto translate tool
  3. The 803 Wikis .The vast majority of these are very small, have many outdated auto-translated articles, and have very few active editors. It is interesting to see how few articles are organically created there (especially by editors who only edit in that wiki), and what types of articles. Many of these wikis do not have the volunteer resources to paper over the wikimedia software and process limitation, to be a community, to detect scammers, and to remove bias. It is difficult for a reader to know which wikipedia the text was sourced from, so that cultural/political bias can be taken into account.
  4. Wikidata was going to allow translation of core data between Wikipedias to create unbiased articles, and fill info boxes. enWIkipedia is reluctant to use it because of missing references, reliability of sources, no update link with source data (single source of truth), and what happens when different wikipedias have different field values. I believe this also feeds into google knowledge panels. Wakelamp (talk) 07:48, 3 February 2023 (UTC)[reply]
Hi SDeckelmann-WMF. Thanks so much for assigning software resources based on open letters (PageTriage, Commons), and for engaging with the communities on talk pages by making statements like you did in this section. These are both great steps towards improving community relations. I think you and the current executive team are good faith contributors and are doing great work. Please keep it up.
Here's a possible roadmap for CommTech and the wishlist:
  1. Refocus to getting the top 10 wishes worked on. The community spends a lot of energy lobbying for and voting on wishes. This energy gets us a fairly accurate picture of what the community wants. Comments on this talk page about top 10 wishes barely getting worked on are alarming, and should be taken seriously. It possibly indicates a broken process when folks can spend a month of bureaucratic energy prioritizing stuff, and then those priorities are not closely followed.
  2. Assign more developers to CommTech. I'd suggest double or triple, and following the spirit of the wish Community Wishlist Survey 2022/Larger suggestions/1%.
  3. Once 1 and 2 are fixed, it should become possible to run the wishlist more often. Perhaps every 6 months. It is important to find ways to shorten the amount of time between the community requesting software and the community receiving software. Both the Annual Plan and the Wishlist seem to take over a year. This cycle should ideally be shortened.
Hope this helps. Happy editing. –Novem Linguae (talk) 18:26, 13 February 2023 (UTC)[reply]
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

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

Future of the Wishlist Update – January 2024

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

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

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

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

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

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

Updates

Community Wishlist Survey is now Community Wishlist

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

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

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

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

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

​​​​​​​​​​​​​​​​​​​​​​​ Pinging more discussants. ––


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

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

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

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

Renaming of Wishlist – May 21, 2024

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

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

Updates on Wishlist Redesign – 18 May 2024

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

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

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

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

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

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

Thank you! –– STei (WMF) (talk) 15:07, 13 March 2024 (UTC) [reply]

Wikinews mobile app

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

  • 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

Voting

Allow for searching for the start and end of a string

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

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

Discussion

Voting

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.

  • 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

Voting

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.

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

Discussion

Voting

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.

  • 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

Voting

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

  • 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

Voting

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.

  • 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.
  1. ↑ https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2022/03#Pandemie_covidu-19_v_Rakousku_(Q86847911)_is_full_(no,_literally)
  2. ↑ https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2022/02#Population:_P1082_or_P4179?
  3. ↑ https://www.wikidata.org/wiki/Wikidata:Project_chat/Archive/2022/11#Tabular_style_data_on_items?
  • 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.

Discussion

Voting

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.

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

Voting

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.

  • 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:
  1. 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.
  2. Conceal the actual time of each edit on "Recent changes", "History", "Watchlist" and similar pages in that date and order would be sufficient.
  3. 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 "#".
  4. 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.
  5. Refactor links, elements and code that may reveal the actual time of edits.
  6. Reframe and disguise data traffic of Wikimedia sites, especially uploads.
  7. 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.
  8. 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

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.

  • 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

Voting

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.

  • 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

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.

  • 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

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.

  • 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

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.

  • 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

Related: WMDE Technical Wishes/Book referencing. --Matěj Suchánek (talk) 13:16, 25 January 2023 (UTC)[reply]

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

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.

  • 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

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.

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

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

  • 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

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.

  • 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

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.

  • 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

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.

  • 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)

¿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::
  1. un corte de energía,
  2. un bloqueo del navegador,
  3. 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]

Please consider the following as a probable solution to the problem for Windows users: Offline MediaWiki Code Editor Tonygarfume (talk) 03:32, 25 May 2024 (UTC)[reply]

Voting

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.

  • 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
    1. everything must be done in wikipedia using wikis
    2. 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

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.

  • 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

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.

  • 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


Voting

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.

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

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.

  • 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

Voting

Retrieved from "https://meta.wikimedia.org/w/index.php?title=Community_Wishlist_Survey_2023/Larger_suggestions&oldid=24644505"