Community Wishlist Survey 2022/Larger suggestions

Larger suggestions
55 proposals, 466 contributors, 1167 support votes
The survey has closed. Thanks for your participation :)




1%

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

  • Problem: The WMF's funding is larger than ever, reaching obscene amounts, and none of that seems to make its way into community support / addressing technical requests. This proposal is simple. Allocate at least 1% of the WMF warchest/yearly budget to the Community Tech team. In 2019–2020, the WMF raised $130M, 1% of that is $1.3M. This is small potatoes for the WMF, but would ACTUALLY FOR ONCE yield tangible impacts on the features the community actually want, rather than on... whatever it is the WMF is spending that money on.
  • Proposed solution: Allocate at least 1% of the WMF yearly budget to the Community Tech team. Hire people. Buy new servers for toolserver. Whatever else needs to be done.
  • Who would benefit: All the community and volunteers, who would finally get the technical support they've been craving for years.
  • More comments:
  • Phabricator tickets:
  • Proposer: Headbomb (talk) 00:30, 11 January 2022 (UTC)

Discussion

  • Hello Headbomb, what is Community Tech team? Thanks, PeterEasthope (talk) 01:02, 11 January 2022 (UTC)
    @PeterEasthope, Community Tech is the team solely responsible for the entire Community Wishlist Survey. SGrabarczuk (WMF) (talk) 02:01, 11 January 2022 (UTC)
    So the proposal is to allocate 1.3 M$ for this survey. What is the current expenditure? How is the number 1% arrived at? Assuming 1.3 M$ is more than currently spent on the survey, what will be added with the larger investment. Thx, PeterEasthope (talk) 02:16, 11 January 2022 (UTC)
    I don't know what the current budget is exactly, but the Community Tech team is apparently 12 people, whom I doubt are assigned full time on this. If we ballpark an average salary of $30/hour, that's roughly $62,500 per full time coder per year, or ballpark $750,000. $1.3M would get us roughly 20 full time coders at that rate. So maybe the proposal should be increase the Community Tech team to 20 full time coders that are specifically assign to deal with community requests. The 1% is symbolic. Headbomb (talk) 02:50, 11 January 2022 (UTC)
    Obviously it’s not as simple as $1.3m equating to 20 F/T employees, there’s other overheads & expenses involved aside from salary. It’d definitely be good to see exactly how much is attributed to the CMTT though to weigh it up. Jcshy (talk) 08:46, 11 January 2022 (UTC)
    Yes, there's overhead, but it's a ballpark figure. Point if you have $130M annual income, more should be spent on things that aren't PR and feel good initiatives. Headbomb (talk) 10:26, 11 January 2022 (UTC)
  • Do we know what the current percentage of the WMF budget given to the team is? {{u|Sdkb}}talk 01:06, 11 January 2022 (UTC)
  • I was actually considering making a proposal like this myself (I did not think about 1% specifically though, and I don't know if it is an adequate number. The point is that the team has to be bigger in several kinds of resources, perhaps at cost of teams that are not working towards direct community requests). --Base (talk) 10:03, 11 January 2022 (UTC)
  • Could this be formulated more diplomatically? I think it's the most important proposal out here, but starting with the word cancer is not the best strategy to get overwhelming support. 1% is quite modest, if you compare this with the back-of-the-envolope estimate of current spending. Would you consider adding an additional medium-to-long term goal of say 2.5%? Femke (talk) 10:44, 11 January 2022 (UTC)
    • +1. Remove the aggressive "cancer", and instead state what the current budgets numbers are for that team, and name their responsabilities or give a link towards those details. How much less than 1% is it? This proposal is basically a signal from the online community to WMF, that transparency/oversight is wanted over what happens to our donations. --Enyavar (talk) 12:13, 11 January 2022 (UTC)
    • +1 on the phrasing change, I can handle being tactful if it makes it more likely to get those who disagree onboard, and +1 on bumping the numbers - let's ask for 2%. Two helpful numbers to include would be the amount spent on knowledge equity and the per/year salary of the new CEO (which, for clarity's sake, I don't think is unreasonable, just a good mark of how small the community tech budget is) Nosebagbear (talk) 12:33, 11 January 2022 (UTC)
    • Maybe it could be changed to something like "from what has been described as cancer-like". I'd also like to note that just increasing spending by itself never helped anything:
the money also has to be actually useful and it should be spent well and efficiently. All of this could tie in with my proposal below to add a banner at the top of all software-development Wikipedia articles to engage developers which would link to a page/system to organize, streamline and facilitate the development such as via selected tutorials&tasks, making it easier to set the development environment up, badges and rankinglists.
-1 on the proposed phrasing changes so far, that term is well-known and I immediately knew the page it was linked to.
I think we should strive to facilitate maximum volunteer development (some of that could for example turn into payed development over time) and maximum usefulness of both payed and volunteer development (such as focusing mainly on high-priority tasks of community wishlist proposals and phabricator tasks that e.g. decrease running costs, are relatively quick to implement, got much support or would save much editors' time).
--Prototyperspective (talk) 12:56, 11 January 2022 (UTC)
  • In light of these comments, I slightly reworded things, but kept the link. Headbomb (talk) 14:47, 11 January 2022 (UTC)
  • An excellent suggestion. We may want to work on the detail but I'd support any of the wordings so far. An organisation as rich as the WMF should not have a resource bottleneck on the thing it was actually created to do. Certes (talk) 14:38, 11 January 2022 (UTC)
  • $30/hour is significantly lower than it should be given the higher than US-average number of staff in the Bay area. It also doesn't factor in the additional costs. I know we are going "you can give more than the 1%", but I reckon they're probably already spending about 0.9% on the Team. Nosebagbear (talk) 15:20, 12 January 2022 (UTC)
  • I don't think there is a shot in hell of the Wishlist Survey determining WMF staffing or budgets. Not that it's a bad idea for more full-time help. Just saying. -- GreenC (talk) 19:23, 12 January 2022 (UTC)
    Not determining perhaps, I would see it more like a petition that can go far to mend the relationship between the community and the WMF. Femke (talk) 20:01, 12 January 2022 (UTC)
  • FWIW, the budget allocated for "Platform Evolution" (defined as "to provide technical systems to support equitable, global growth such as through the addition of a caching center that serves Africa and the Middle East, as well as investing in the technical future of our projects") was increased from US$2.4 million to US$7.9 million in the 2021-2022 WMF Annual Plan. RamzyM (talk) 02:15, 14 January 2022 (UTC)
  • (1) This is out of scope for the Community Tech Team so this is not the right forum. (2) It's also not in the right ballpark. Even at the middle of San Francisco market rates, the annual total cash comp of this team with taxes and benefits would already be well over $1.3M. czar 19:07, 14 January 2022 (UTC)
  • We will not get it, but we should keep asking, to make it clear to the WMF what the community thinks their priorities should be. The amunt specified should be increased, as Czar and others have pointed out--Using Nosebagbear's estimate, and realizing it will take time to increase capacity, we should ask for a doubling of between $2 and $3 million this year, increasing as possible in the future. The bottleneck is managerial priorities, not financial unavailability. DGG (talk) 21:22, 15 January 2022 (UTC) .
    I've made an alternative proposal on talk, asking for a doubling, and in more diplomatic terms. The goal of this is to convince the WMF, and I think this type of wording will give us a larger chance of success. Femke (talk) 11:47, 16 January 2022 (UTC)
  • Agree in principle. I'll echo what some others have said: the framing of the linked essay is antagonistic to the point of being self-defeating. That's not to say it doesn't have a point in there, but if the goal is to be taken seriously, link somewhere else. There's no shortage of "WMF has a ton of money" links. But yeah, I asked about how to get funding increased at a Community Tech Q&A somewhat recently, and don't recall that I got a clear answer (apologies to those who responded if I'm misremembering). I think perhaps this is something we'll need the Movement Charter folks to throw their weight behind (however much that weight is). It's a clear step the foundation could take which would address the widespread belief that not enough of the budget goes to directly support the community. — Rhododendrites talk \\ 15:14, 16 January 2022 (UTC)
  • We absolutely do need much more funding directed at the technical side of the project. Currently the developers are clearly overworked; a lot of the early decisions have proven to be ineffective or simply bad (see our "amazing" parser, for example). Now we are also facing an increasing number of security threats that, again, cannot be eliminated simply because of how the project was built. This is a major tech issue and it is my wish to get more tech workpower so I believe that this submission should stay in the Community Wishlist. Le Loy 04:07, 18 January 2022 (UTC)
    I agree too! This will be very good for WMF! Esaïe Prickett (talk) 00:53, 20 January 2022 (UTC)


The money are not everything. We have the money and job offers. But what are the problems? The error in Wikimedia Mowement and WMF. I think:

  • The normal user don't know about the news in Wikimedia Movement.
  • The normal user don't know about something more about the news on him local wiki, universities, about metawiki, WMF and about the jobs of WMF.
  • Wikimedia Movement and WMF only to wait, wait and wait.
    • I do not read anything about events in the Slovak media in Wikimedia movement. Nothing about job offers.
    • None The day of developers.
    • No promotion in SWAN and him entities.
  • It is the year 2022, none the year 2030. We don't have the Global Council.
  • Nobody is looking for / addressing talents.
  • Money-results: where is the report for the past year? If a person sees that it is useful, he makes an interesting contribution, wants to help or join.
  • IT people are not much.
  • Job offers:
    • None global content search.
    • If I am interested in projects and not programming languages?
    • What is the labor price?
    • None special contact / e-mail.
  • WMF presentation of works is totally like just an institution.
  • Why should I work for WMF? WMF is one of the other organizations why I should work.
  • Nobody investing in talent people.
    • Who needs a detailed knowledge of Wikidata or other languages? In him normal life doesn't need know very detailed. He doesn't generate any complex analyses.
  • Is working for WMF very special? Or can I use knowledge elsewhere?
  • International work can be discouraging.
  • Tech/News – it's Tech news (People can create some small context), or the report with the technical news (Very formal, narrow shot)?

✍️ Dušan Kreheľ (talk) 17:47, 10 February 2022 (UTC)

Voting

  • Support Support * Mustafdesam * very useful 19:08, 8 February 2022 (UTC)
  • Support Support Sounds reasonable. Helps those who support wiki. Johnny0634Cashx (talk) 18:53, 28 January 2022 (UTC)
    @Johnny0634Cashx: Courtesy notice that if you intend to support, you must use the {{support}} template or else it isn't counted. MusikAnimal (WMF) (talk) 20:04, 28 January 2022 (UTC)
  • Support Support Not sure that 1% would be enough, but an expanded community tech team would definitely be a good way forward. Mike Peel (talk) 18:54, 28 January 2022 (UTC)
  • Support Support * Pppery * it has begun 18:58, 28 January 2022 (UTC)
  • Support Support Moral support, even if we should be petitioning for more Femke (talk) 19:44, 28 January 2022 (UTC)
  • Support Support. --Base (talk) 20:08, 28 January 2022 (UTC)
  • Support Support --Arnd (talk) 20:25, 28 January 2022 (UTC)
  • Support Support --Andyrom75 (talk) 20:40, 28 January 2022 (UTC)
  • Support Support See also en:WP:CANCER Qwerfjkl (talk) 21:38, 28 January 2022 (UTC)
  • Support Support Legooverlord11 (talk) 21:39, 28 January 2022 (UTC)
  • Support Support especially if it's combined with the proposed banner for more volunteer development of MediaWiki. I'd support substantially more than 1% of funds (it seems that was a symbolic figure anyway). Prototyperspective (talk) 22:19, 28 January 2022 (UTC)
  • Support Support — Draceane talkcontrib. 22:31, 28 January 2022 (UTC)
  • Support Support More like 3%, but this is in the spirit. Sea Cow (talk) 23:50, 28 January 2022 (UTC)
  • Support Support Hanif Al Husaini (talk) 00:52, 29 January 2022 (UTC)
  • Support Support 1% is nothing like enough but it's a start. Certes (talk) 02:04, 29 January 2022 (UTC)
  • Support Support Betseg (talk) 02:28, 29 January 2022 (UTC)
  • Support Support the spirit of devoting substantially more resources to community support, although I'd like to see more financials on the current situation to understand exactly what 1% would mean. {{u|Sdkb}}talk 03:57, 29 January 2022 (UTC)
  • Support SupportHulged (talk) 07:00, 29 January 2022 (UTC)
  • Support Support JopkeB (talk) 07:19, 29 January 2022 (UTC)
  • Support Support tech team needs to be expanded, tech is our foundation Gnangarra (talk) 07:38, 29 January 2022 (UTC)
  • Support Support SCIdude (talk) 08:01, 29 January 2022 (UTC)
  • Support Support Respublik (talk) 09:07, 29 January 2022 (UTC)
  • Support Support --YodinT 10:12, 29 January 2022 (UTC)
  • Support Support Not sure if 1% is the correct number... but an increased funding for the tech team *does* make sense! Šedý (talk) 11:11, 29 January 2022 (UTC)
  • Support Support Something like 5% is reasonable, but let's start at least somewhere. --TohaomgTohaomg (talk) 11:49, 29 January 2022 (UTC)
  • Support Support More than 1% --Kusurija (talk) 11:55, 29 January 2022 (UTC)
  • Support Support Terber (talk) 12:23, 29 January 2022 (UTC)
  • Support Support Mvuijlst (talk) 14:19, 29 January 2022 (UTC)
  • Support Support BSMIsEditing (talk) 15:20, 29 January 2022 (UTC)
  • Support Support The fact the WMF management aren't investing more into technical and community projects and requests is infuriating especially given how much money there is behind them Ed6767 (talk) 15:39, 29 January 2022 (UTC)
  • Support Support Hemantha (talk) 16:02, 29 January 2022 (UTC)
  • Support Support Aca (talk) 16:04, 29 January 2022 (UTC)
  • Support Support Mbrickn (talk) 16:27, 29 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 17:41, 29 January 2022 (UTC)
  • Support Support Nebotigatreba7 (talk) 17:59, 29 January 2022 (UTC)
  • Support Support —— Eric LiuTalk 18:24, 29 January 2022 (UTC)
  • Support Support Not conviced by the agressive phrasing of the proposal, but I agree we need more investment in technical aspects. — Jules* Talk 18:45, 29 January 2022 (UTC)
  • Support Support KennethSweezy (talk) 19:39, 29 January 2022 (UTC)
  • Support Support and please keep the cancer rethoric, it is on point. --SSneg (talk) 23:54, 29 January 2022 (UTC)
  • Support Support 1% is not enough but I support the sentiment josecurioso ❯❯❯ Tell me! 00:59, 30 January 2022 (UTC)
  • Support Support Agus Damanik (talk) 03:35, 30 January 2022 (UTC)
  • Support Support Ali Imran Awan (talk) 07:22, 30 January 2022 (UTC)
  • Support Support TheInternetGnome (talk) 08:43, 30 January 2022 (UTC)
  • Support Support Fano (talk) 09:12, 30 January 2022 (UTC)
  • Support Support F. Riedelio (talk) 11:17, 30 January 2022 (UTC)
  • Support Support«« Man77 »» [de] 14:03, 30 January 2022 (UTC)
  • Support Support in principle, 1% is too low. MER-C 17:45, 30 January 2022 (UTC)
  • Support Support JPxG (talk) 01:05, 31 January 2022 (UTC)
  • Support Support Libcub (talk) 01:07, 31 January 2022 (UTC)
  • Support Support More money to tech teams is a great idea anywhere. I like WMF in all aspects and I have never been concerned with how donations are managed but I do not deny that every good investment proposal related to this subject is beneficial (benign) for everyone. From here in Brazil, without going into the merits of good financial management or not, I agree! Nishimoto, Gilberto Kiyoshi (talk) 06:58, 31 January 2022 (UTC)
  • Support Support Qazwsx777 (talk) 09:31, 31 January 2022 (UTC)
  • Support Support Needs to be at least 2% Nosebagbear (talk) 12:22, 31 January 2022 (UTC)
  • Support Support — AfroThundr (u · t · c) 13:36, 31 January 2022 (UTC)
  • Support Support FenyMufyd (talk) 17:01, 31 January 2022 (UTC)
  • Support Support Bluerasberry (talk) 17:25, 31 January 2022 (UTC)
  • Support Support Donors EXPECT that their donation goes toward making more quality content, and not PR and obscure "feel good" initiatives Ignacio Rodríguez (talk) 19:29, 31 January 2022 (UTC)
  • Support Support Modest Genius (talk) 20:59, 31 January 2022 (UTC)
  • Support Support IOIOI (talk) 21:09, 31 January 2022 (UTC)
  • Support Support JAn Dudík (talk) 21:40, 31 January 2022 (UTC)
  • Support Support IAmChaos (talk) 21:50, 31 January 2022 (UTC)
  • Support Support Shooterwalker (talk) 22:38, 31 January 2022 (UTC)
  • Support Support. The Community Tech team was created to address serious problems with Foundation's software process and priorities, but it shouldn't exist at all. The Foundation's core job is to maintain and improve our platform, and the Foundation as a whole should be willing or even eager to collaborate with the community in understanding how to do that. If we can't fix that fundamental problem, increasing Community Tech funding is at least constructive. Community Tech was clearly given insufficient resources to handle even the token mission that was promised for it. Alsee (talk) 23:40, 31 January 2022 (UTC)
  • Support Support Dave Braunschweig (talk) 00:10, 1 February 2022 (UTC)
  • Support Support MONUMENTA (talk) 00:29, 1 February 2022 (UTC)
  • Support Support Trey314159 (talk) 00:30, 1 February 2022 (UTC)
  • Support Support Labdajiwa (talk) 04:00, 1 February 2022 (UTC)
  • Support Support Kpgjhpjm (talk) 06:32, 1 February 2022 (UTC)
  • Support Support SCP-2000 08:19, 1 February 2022 (UTC)
  • Support Support Thibaut (talk) 15:59, 1 February 2022 (UTC)
  • Oppose Oppose On principle, it is a really bad idea to hard-code funding allocations. Creates laziness and bureaucracy, and once you have created interests hanging from (what now would be a 1%), these become nigh impossible to revert, even after there is no longer need for whatever was mandated in the very first place. Opposed on principle. XavierItzm (talk) 20:19, 1 February 2022 (UTC)
  • Support Support Agreed. All open source projects have paid developers, and with the funding that WP has at its disposal, adding (more?) paid developers to the staff to accomplish some of the work that volunteers can't/won't do, is needed. Hires an editor (talk) 00:26, 2 February 2022 (UTC)
  • Support Support Browk2512 (talk) 01:21, 2 February 2022 (UTC)
  • Oppose Oppose KingAntenor (talk) 07:09, 2 February 2022 (UTC)
  • Support Support Serg!o (talk) 11:27, 2 February 2022 (UTC)
  • Support Support Stratocaster47 (talk) 12:19, 2 February 2022 (UTC)
  • Support Support for at least 1%. There are tons of favorable tasks lying on phabricator for years that require too much work for a volunteer. WhitePhosphorus (talk) 13:28, 2 February 2022 (UTC)
  • Support Support Financial support for qualified Etymology verifiers and the Wiki Bots as well: in other words; for all that have [thank] after the heading of their edits for the public to thank if they wish. A number of etymology edits are still worrying, as particularly in the diversely semantic proposed links between Proto-Germanic and Proto-Indo-European, as in the cases of the origins of CLOTH and WOOD, et cetera. Werdna Yrneh Yarg (talk) 14:11, 2 February 2022 (UTC)
  • Support Support Mitar (talk) 20:53, 2 February 2022 (UTC)
  • Support Support DannyS712 (talk) 03:13, 3 February 2022 (UTC)
  • Support Support — MrDolomite • Talk 05:14, 3 February 2022 (UTC)
  • Support Support Prof.Flip (talk) 13:58, 3 February 2022 (UTC)
  • Support Support The capabilities and functioning of the platforms must be the primary concern, not PR and parties. Silver hr (talk) 14:22, 3 February 2022 (UTC)
  • Support Support WikiAviator (talk) 16:03, 3 February 2022 (UTC)
  • Support Support Paucabot (talk) 16:14, 3 February 2022 (UTC)
  • Support Support DanCherek (talk) 16:16, 3 February 2022 (UTC)
  • Support Support Reywas92 (talk) 20:19, 3 February 2022 (UTC)
  • Support Support Wutsje (talk) 20:21, 3 February 2022 (UTC)
  • Support Support Xavier Dengra (MESSAGES) 23:34, 3 February 2022 (UTC)
  • Support Support in spirit, even though this is outside the remit of this teams' survey. I do think we are heavily underinvesting in bugfixing and basic quality of the software for the (non-reader) communities and that we should focus much more on their day to day experience. —TheDJ (talkcontribs) 09:08, 4 February 2022 (UTC)
  • Support Support with the understanding that '1%' is a symbolic figure. Headbomb (talk) 15:34, 4 February 2022 (UTC)
  • Support Support MattieTK (talk) 16:12, 4 February 2022 (UTC)
  • Support Support Gonnym (talk) 21:59, 4 February 2022 (UTC)
  • Support Support Pi.1415926535 (talk) 22:17, 4 February 2022 (UTC)
  • Support Support Sir Proxima Centauri (talk) 07:05, 5 February 2022 (UTC)
  • Support Support Donors expect funding to mainly go to server parks and technical development. Tomastvivlaren (talk) 10:00, 5 February 2022 (UTC)
  • Support Support Thingofme (talk) 13:09, 5 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 14:34, 5 February 2022 (UTC)
  • Support Support Ealdgyth (talk) 17:56, 5 February 2022 (UTC)
  • Support Support Exilexi (talk) 18:12, 5 February 2022 (UTC)
  • Support Support Waldyrious (talk) 23:45, 5 February 2022 (UTC)
  • Support Support Steven Sun (talk) 00:37, 6 February 2022 (UTC)
  • Support Support Ynhockey (talk) 01:04, 6 February 2022 (UTC)
  • Support Support --Emaus (talk) 08:14, 6 February 2022 (UTC)
  • Support Support--Vulp❯❯❯here! 09:38, 6 February 2022 (UTC)
  • Support Support Ciencia Al Poder (talk) 11:10, 6 February 2022 (UTC)
  • Support Support I have doubts with this: 1% is not enough. And I wouldn't like to have a %1 for ever. We can have much more. Theklan (talk) 11:19, 6 February 2022 (UTC)
  • Support Support Khairul hazim (talk) 11:51, 6 February 2022 (UTC)
  • Oppose Oppose --Ciao • Bestoernesto 19:04, 6 February 2022 (UTC)
  • Support Support Actorsofiran (talk) 19:09, 6 February 2022 (UTC)
  • Support Support Molestash (talk) 01:15, 7 February 2022 (UTC)
  • Support Support Toadspike (talk) 01:31, 7 February 2022 (UTC)
  • Support Support Ayumu Ozaki (talk) 04:28, 7 February 2022 (UTC)
  • Support Support Good, so good. Pablo131415 (talk) 11:15, 7 February 2022 (UTC)
  • Support Support This proposal is completely unfeasible but the actual number of successfully completed wishes is abysmal and needs to be improved //Lollipoplollipoplollipop::talk 11:36, 7 February 2022 (UTC)
  • Support Support Ryse93 (talk) 12:34, 7 February 2022 (UTC)
  • Support Support the general principle of this particular team getting more money. Not sure whether it should be 1% or more than that, given the analysis done somewhere. ProcrastinatingReader (talk) 16:59, 7 February 2022 (UTC)
  • Support Support Tom Ja (talk) 17:33, 7 February 2022 (UTC)
  • Support Support Daniel Case (talk) 19:22, 7 February 2022 (UTC)
  • Support Support PtolemyXV (talk) 22:48, 7 February 2022 (UTC)
  • Support Support 325 proposals this year; hundreds of hours of volunteer discussion about them all. And...? Nick Moyes (talk) 00:11, 8 February 2022 (UTC)
  • Support Support CrystalBlacksmith (talk) 03:29, 8 February 2022 (UTC)
  • Support Support If your money is too much, give some to the poor. More than 1% is ok too. --Ssr (talk) 12:42, 8 February 2022 (UTC)
  • Support Support Itsfini (talk) 15:12, 8 February 2022 (UTC)
  • Support Support I've seen a small amount of negative comments on social media during annual funding campaigns, specifically about WMF. This, combined with PR/transparency, can make a huge impact, I think, and encourage more people to contribute (and I would imagine, to apply for jobs!). paul2520 (talk) 17:02, 8 February 2022 (UTC)
  • Support Support General Douglas (talk) 19:21, 8 February 2022 (UTC)
  • Support Support As Wikipedia and other Wikimedia projects are growing and getting more and more recognition, we need to be able to protect them from big bugs, hacking, etc. So, yes, more money into this makes sense.--Eunostos (talk) 07:04, 9 February 2022 (UTC)
  • Support Support DontWannaDoThis (talk) 09:19, 9 February 2022 (UTC)
  • Support Support Bop34 (talk) 12:48, 9 February 2022 (UTC)
  • Support Support Ján Kepler (talk) 18:44, 9 February 2022 (UTC)
  • Support Support Tinux (talk) 07:53, 10 February 2022 (UTC)
  • Support Support β16 - (talk) 10:47, 10 February 2022 (UTC)
  • Support Support George6996 (talk) 13:54, 10 February 2022 (UTC)
  • Support Support TheFrog001 (talk) 14:49, 10 February 2022 (UTC)
  • Support SupportDaxServer (t · c) 16:03, 10 February 2022 (UTC)
  • Support Support We desperately need way more resources spent on technical issues and refactoring. Le Loy 02:05, 11 February 2022 (UTC)
  • Support Support Sunpriat (talk) 02:39, 11 February 2022 (UTC)
  • Support Support Marcok (talk) 13:05, 11 February 2022 (UTC)
  • Support Support 1% is not enough. Make it 2% at least. 4nn1l2 (talk) 13:17, 11 February 2022 (UTC)
  • Support Support Our donators invariably want to "Keep Wikipedia Running". As the content is volunteer driven, that translates in my eyes to improving the technology it runs on and making it easier to run. WormTT 13:54, 11 February 2022 (UTC)
  • Support Support Blablubbs (talk) 14:47, 11 February 2022 (UTC)
  • Support Support Grüße vom Sänger ♫(Reden) 16:12, 11 February 2022 (UTC), but rather 5%, at least 10 times as much as is spend on branding.
  • Support Support Maybe this way CommTech can finally deliver on stuff they are obligated (for the lack of better word) to take each year. [With no hard feelings to CommTech people, they are awesome and deserve more funding and more experienced colleagues.] stjn[ru] 17:47, 11 February 2022 (UTC)

50 wishes

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

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

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

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

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

Discussion

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

Voting

  • Oppose Oppose CommTech team are not genies and even for a genie in a bottle this would be cheating. That's not how software engineering works nor how humans can deliver value. I do understand the sentiment behind it but it's like wishing for bag of money falling out of sky. And no, we don't have money for wishes like this. Amir (talk) 18:34, 28 January 2022 (UTC)
    Sorry @Ladsgroup:, but the fact is that we have bags of money falling out of the sky. Yearly. Tons of bags. Theklan (talk) 11:18, 6 February 2022 (UTC)
  • Support Support anything that would improve responsiveness to the huge number of requests that are posted each year. Thanks. Mike Peel (talk) 18:57, 28 January 2022 (UTC)
  • Support Support * Pppery * it has begun 18:59, 28 January 2022 (UTC)
  • Support SupportYahya (talkcontribs.) 19:08, 28 January 2022 (UTC)
  • Support Support The amount raised just from people who mistakenly think they are donating to Wikipedia would fund 500 wishes. Certes (talk) 02:06, 29 January 2022 (UTC)
  • Support Support Work more! -- Флаттершай (talk) 07:17, 29 January 2022 (UTC)
  • Support Support Having a bigger pool of tasks to pick from makes sense. There are some wishes, that are relatively easy to implement, even though they don't make it to the top ten. Šedý (talk) 11:15, 29 January 2022 (UTC)
  • Support Support Waddles 🗩 🖉 21:46, 29 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 02:10, 30 January 2022 (UTC)
  • Support Support«« Man77 »» [de] 14:03, 30 January 2022 (UTC)
  • Support Support Wowzers122 (talk) 22:24, 30 January 2022 (UTC)
  • Support Support scrapping Community Tech and for the Foundation as a whole to improve partnership and respect with the community. On one hand that's such a simple and obvious thing, but on the other hand, after so many years, it feels like I'm wishing for the moon. Alsee (talk) 23:57, 31 January 2022 (UTC)
  • Oppose Oppose KingAntenor (talk) 07:10, 2 February 2022 (UTC)
  • Support Support DannyS712 (talk) 03:14, 3 February 2022 (UTC)
  • Support Support Prof.Flip (talk) 14:04, 3 February 2022 (UTC)
  • Support Support Silver hr (talk) 14:24, 3 February 2022 (UTC)
  • Support Support Unfortunately, it is a shame we are forced to vote for this kind of proposals to be heard and not feel that they play around with this us anymore in this process. The Wishlist has become somehow a fake genius that looks promising and that is not ready to accomplish its most basic tasks. Xavier Dengra (MESSAGES) 23:38, 3 February 2022 (UTC)
  • Support Support Sir Proxima Centauri (talk) 07:12, 5 February 2022 (UTC)
  • Support Support Hanif Al Husaini (talk) 12:08, 5 February 2022 (UTC)
  • Support Support We need to finish the tasks which are not declined and we shouldn't be slow about the schedule. Thingofme (talk) 13:10, 5 February 2022 (UTC)
  • Support Support Because we have money to make it happen. Theklan (talk) 11:19, 6 February 2022 (UTC)
  • Support Support Actorsofiran (talk) 19:10, 6 February 2022 (UTC)
  • Support Support Toadspike (talk) 01:32, 7 February 2022 (UTC)
  • Support Support This proposal is completely unfeasible but the actual number of successfully completed wishes is abysmal and needs to be improved. //Lollipoplollipoplollipop::talk 11:35, 7 February 2022 (UTC)
  • Support Support, even though I wish there was a better solution available… –Tommy Kronkvist (talk), 11:56, 7 February 2022 (UTC).
  • Support Support ChimMAG (talk) 12:34, 7 February 2022 (UTC)
  • BA candidate.svg Weak oppose Having just voted to support the 1% proposal above I think this would actually undermine anything that might accomplish. The 50 most popular might not necessarily be the highest and best fixes we need to do ... there might be small, obscure fixes that if made could make it much easier to fix others, or obviate entirely, the need for many more popular fixes. Or a popular proposal might require so much work as to make all the others go by the boards. Daniel Case (talk) 19:26, 7 February 2022 (UTC)
  • Support Support George6996 (talk) 13:57, 10 February 2022 (UTC)
  • Support Support Some of the wishes on here are rather small and may be easy to implement, it would be nice if they didn’t clog up the bigger issues, but could still be fixed TheFrog001 (talk) 14:53, 10 February 2022 (UTC)
  • Oppose Oppose Rzzor (talk) 20:12, 10 February 2022 (UTC)
  • Support Support Wikimedia is a community, right? So please invest more in what the community wants! Le Loy 02:11, 11 February 2022 (UTC)
  • Support Support Sunpriat (talk) 02:39, 11 February 2022 (UTC)
  • Support Support Gaurav (talk) 02:52, 11 February 2022 (UTC)
  • Support Support It's not easy to churn out 50 wishes worthy of implementation in yearly surveys. 20 is a more sensible number. Make it double. Don't set the bar too high. 4nn1l2 (talk) 13:32, 11 February 2022 (UTC)
  • Support Support Supporting this for the plain reason that the current system is a bit abhorrent. Fighting for scraps that do not get developed because even the team that is developing them is underfunded and understaffed is really weird and capitalistic in the worst ways. The ideal way to solve it would be to fund teams working on all deployed software, not just on some bits and pieces like VisualEditor, Vector etc. stjn[ru] 17:53, 11 February 2022 (UTC)

Dark mode

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

  • Problem: Wikipedia's bright themes/skins are difficult on reader's eyes.
  • Proposed solution: Add a light-on-dark color scheme; toggleable by either the user interface or by the user's browser preference.
  • Who would benefit: The average reader
  • More comments: This was ranked the #2 wish on 2019's Wishlist Survey. While there were internal planning conflicts, hopefully those have resolved in the last two years so that New Vector can get dark mode. The most popular websites, web browsers, and operating systems, offer built-in support for a dark/night mode without hacks or workarounds. This also contributes to site accessibility and user energy savings (on OLED screens).
  • Phabricator tickets: task T26070
  • Proposer: czar 23:32, 10 January 2022 (UTC)

Discussion

  • Community Wishlist Survey/FAQ#Avoid proposals that were declined in the past has Dark Mode as the first example. Procedurally, this proposal should be archived, but I have a hunch too that things have changed in the past two years. People seem to really enjoy mw:Extension:DarkMode and w:Wikipedia:Dark mode (gadget), so the work is nearly done and the popularity among users more or less proven. It just needs some final refinements and being seen through WMF deployment. So instead of archiving, I'm going to move this to our "Larger suggestions" pile, which is a place to for the community to express their desires for the visibility of other product teams and the broader Foundation. Please continue the discussion there and place your votes when the voting phase starts. I do apologize that Community Tech will have to decline this though, as much as we don't want to! MusikAnimal (WMF) (talk) 23:47, 10 January 2022 (UTC)
    @MusikAnimal (WMF), is there any indication that this still conflicts with mw:Desktop Improvements, or that any other team would take up the work? If not, and if it remains a top request two years later, why wouldn't it run in the Reading section for Community Tech consideration with other Reading proposals? If the team overlap conflict from two years ago still exists, so be it and the team can deny it, but isn't this worth checking as long as there is large, long-standing interest and no issue of technical infeasibility? Relegating this to "Larger suggestions" does not seem appropriate here. czar 03:27, 15 January 2022 (UTC)
    @Czar As I understand it, the solution of using the CSS invert filter wasn't approved. Additionally, our Varnish caching meant we couldn't offer the feature to logged out users. Then a different solution was presumably going to be part of Desktop Improvements, or at least things were going to change enough that we wouldn't want to attempt any other solutions because of potential conflicts. Obviously dark mode still isn't here, and I do not know for certain if it is still on the road map for Desktop Improvements (it doesn't appear to be). But either way, Community Tech's attempt at this was rejected. I personally don't really see a workable solution without using the CSS invert filter, in the absence of some other major changes that somehow would allow us to control parser output on desktop without stomping on any community-maintained designs, which would put it much too out of scope for our team, so even then it would still belong here under Larger suggestions. Sorry! I do believe this category will get a lot of attention during voting, if that means anything. The goal here is to give the WMF and broader movement an unfiltered window into the technical desires of the community. I hope this proposal gets the attention it deserves, because believe me when I say if we could have at any point deployed mw:Extension:DarkMode, we would have ;) MusikAnimal (WMF) (talk) 21:37, 15 January 2022 (UTC)
  • My historical concern with "dark mode" proposals was that it's tricky to style on-wiki content for a dark mode. If an official dark mode existed it could add one or more official CSS classes for use with TemplateStyles, making it easy to provide downstream support for a dark mode in templates and such, which sometimes make assumptions that backgrounds are light and text is dark. Having the support be official, rather than relying on ad-hoc gadgets and such, would make a big difference by providing infrastructure for us to build better content-side support for the feature. {{Nihiltres |talk |edits}} 00:27, 11 January 2022 (UTC)
    I agree. Wikipedians seems to be extremely against (if you look a the bug tracker) it which is a bit ridiculous. Lets just fix it. Almost every average user would enjoy it. Mrconter1 (talk) 06:29, 11 January 2022 (UTC)
    I don't think that's a fair assumption @Mrconter1: - it didn't accidentally end up at the top of a previous wishlist because Wikipedians didn't like it, after all! And the usage numbers of the various dark mode CSS etc also suggest we'd like it. Lots of the bug trackers just indicates that making a dark mode that doesn't occasionally either cause significant problems or blind the editors wandering around the less travelled paths onsite is...difficult. Nosebagbear (talk) 14:04, 11 January 2022 (UTC)
    I did not mean every Wikipedian. I am talking about Wikipedians that are responsible/driving the development of the site. Mrconter1 (talk) 14:29, 11 January 2022 (UTC)
    Im with @Mrconter1. Adding on, it would make it easier for everyone that wants to give their eyes a break like me. Rzzor (talk) 21:27, 11 January 2022 (UTC)
    Don't confuse 'against' with 'this is more complicated than ppl make it out to be'. Developers on Phabricator generally discuss the work that needs to be done, not the desire of the feature. —TheDJ (talkcontribs) 10:31, 12 January 2022 (UTC)
  • There is already some infrastructure for the mobile apps that provides dark, black, or even sepia modes. While it struggles with some custom inline css in the content, for the most part it works pretty well. Obviously, it is based on Minerva. So the real and more specific proposal/need here is Dark Mode for (improved) Vector and Minerva in the web browser. --Geraki TL 13:07, 11 January 2022 (UTC)
  • As a frequent reader, but occasional editor, I really want dark mode and don't care if it doesn't work in edit mode. The majority of "content" sites/apps on the net are adopting dark mode for nighttime reading, wikipedia now stands out as an exception. I've installed the extension which mostly works, and am a little mystified why it wouldn't be a priority for wikipedia. Its by far the most obvious problem with WP as a reader.—The preceding unsigned comment was added by Aaron Lawrence (talk) 03:29, 13 January 2022‎ (UTC)
    Yes, dark mode is important and Wikimedia is left behind. Leaving all of the technical limitations, we should have dark mode for dark reading at night. Thingofme (talk) 14:41, 6 February 2022 (UTC)
  • concider:some Smartphone userer using night mode, so wiki have to kow, wich mode the user is curentlyusing--JanEhlebrecht (talk) 12:37, 16 January 2022 (UTC)
  • +1, this would definitely make the list of "most popular QoL improvements". It would reduce the amount of energy currently being wasted on developing + trying to maintain other gadgets and extensions, and as Nihil notes help others build better content-side support. –SJ talk  23:35, 23 January 2022 (UTC)
    • It would also reduce the amount of electrical energy consumed by displays! Rich Farmbrough 21:26 29 January 2022 (UTC)


Where is the problem? Where is the problem to have the native dart mode? Dark mode is not extra new thing in world. WMF (owner of MediaWiki) have the money. Tools? We have the Less or another's, create some preprocessor. Missed people? WMF, You find the people found on the project or buy a solution from another company. Or, can create the comunity create the dark theme? Does the idea / solution open the door in the main stream? If yes, community, make a collection. The ways exist, so, do we want to have that? If yes, so, stop me compliance and moan. ✍️ Dušan Kreheľ (talk) 19:09, 10 February 2022 (UTC)


I found an existing dark‐mode project https://www.mediawiki.org/wiki/Skin:Timeless-DarkCSS/timeless-dark.css based on the Timeless skin and I used it as a base of my own: https://meta.wikimedia.org/wiki/User:Ratajs/global.css You can use it for inspiration… Ratajs (talk)

Voting

  • Support Support --Nachtbold (talk) 18:29, 28 January 2022 (UTC)
  • Support Support Amir (talk) 18:36, 28 January 2022 (UTC)
  • Support Support It is specialy annoying when you have to edit articles for hours. Your eyes really start to burn, specially at night. Athosmera (talk) 18:47, 28 January 2022 (UTC)
  • Support Support Would also save battery. Johnny0634Cashx (talk) 18:55, 28 January 2022 (UTC)
  • Support Support Pretty standard on modern websites Bristledidiot (talk) 19:05, 28 January 2022 (UTC)
  • Support Support My eyes are hurting right now! Rzzor (talk) 19:47, 28 January 2022 (UTC)
  • Support Support CrystalLemonade (talk) 19:52, 28 January 2022 (UTC)
  • Support Support Marshal 10000 (talk) 20:20, 28 January 2022 (UTC)
  • Support Support: it's astonishing that the WMF failed to implement this simple functionality, but the need has not decreased. — Bilorv (talk) 20:24, 28 January 2022 (UTC)
  • Support Support --MSY-07 (talk) 20:25, 28 January 2022 (UTC)
  • Support Support --Arnd (talk) 20:26, 28 January 2022 (UTC)
  • Support Support Bischnu (talk) 20:29, 28 January 2022 (UTC)
  • Support Support USI2020 (talk) 20:54, 28 January 2022 (UTC)
  • extremly Support Support it, although I suppose its difficult due to the existing Inline-CSS, but absolutely needed. -- DerFussi 23:11, 28 January 2022 (UTC)
  • Support Support --Guerillero Parlez Moi 23:12, 28 January 2022 (UTC)
  • Support Support Sea Cow (talk) 23:51, 28 January 2022 (UTC)
  • Support Support --𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 00:12, 29 January 2022 (UTC)
  • Support Support Fazart (talk) 00:48, 29 January 2022 (UTC)
  • Support Support DonBarredora (talk) 00:55, 29 January 2022 (UTC)
  • Support Support I use a browser add-on for most sites but feel obliged to edit Wikipedia as readers see it. It's hard on my eyes, especially after sunset. Certes (talk) 02:07, 29 January 2022 (UTC)
  • Support Support Betseg (talk) 02:28, 29 January 2022 (UTC)
  • Support Support War (talk) 03:45, 29 January 2022 (UTC)
  • Support Support Johro77 (talk) 04:58, 29 January 2022 (UTC)
  • Support Support Jake The Great 908 (talk) 06:32, 29 January 2022 (UTC)
  • Support Support Steven Sun (talk) 06:44, 29 January 2022 (UTC)
  • Support Support --Флаттершай (talk) 07:18, 29 January 2022 (UTC)
  • Support Support Crt 07:46, 29 January 2022 (UTC)
  • Support Support Bretwa (talk) 08:20, 29 January 2022 (UTC)
  • Support Support This, that and the other (talk) 08:50, 29 January 2022 (UTC)
  • Support Support //Lollipoplollipoplollipop::talk 09:49, 29 January 2022 (UTC)
  • Support Support THainaut (talk) 10:48, 29 January 2022 (UTC)
  • Support Support "All this time?" "Always." (cit.) Sannita - not just another it.wiki sysop 10:54, 29 January 2022 (UTC)
  • Support Support Tranhaian130809 (talk) 11:08, 29 January 2022 (UTC)
  • Support Support Lion-hearted85 (talk) 11:27, 29 January 2022 (UTC)
  • Support Support --Spiros71 (talk) 13:20, 29 January 2022 (UTC)
  • Support Support please. -sasha- (talk) 13:44, 29 January 2022 (UTC)
  • Support Support ACortellari (talk) 14:25, 29 January 2022 (UTC)
  • Support Support BSMIsEditing (talk) 15:20, 29 January 2022 (UTC)
  • Support Support Aca (talk) 16:05, 29 January 2022 (UTC)
  • Support Support Marwin H.H. (talk) 16:28, 29 January 2022 (UTC)
  • Support Support Mbrickn (talk) 16:28, 29 January 2022 (UTC)
  • Support Support Mohammad ebz (talk) 18:09, 29 January 2022 (UTC)
  • Support Support —— Eric LiuTalk 18:21, 29 January 2022 (UTC)
  • Support Support — Jules* Talk 18:45, 29 January 2022 (UTC)
  • Support Support Douglasfugazi (talk) 21:22, 29 January 2022 (UTC)
  • Support Support Rich Farmbrough 21:27 29 January 2022 (UTC)
  • Support Support Waddles 🗩 🖉 21:45, 29 January 2022 (UTC)
  • Support Support --NGC 54 (talkcontribs) 23:14, 29 January 2022 (UTC)
  • Support Support josecurioso ❯❯❯ Tell me! 00:59, 30 January 2022 (UTC)
  • Support Support Veilure (talk) 01:43, 30 January 2022 (UTC)
  • Support SupportSHEIKH (Talk) 02:09, 30 January 2022 (UTC)
  • Support Support Juan90264 (talk) 07:02, 30 January 2022 (UTC)
  • Support Support Christian Alexis Arroyo Ortiz (talk) 08:49, 30 January 2022 (UTC)
  • Support Support OwenBlacker (Talk) 11:49, 30 January 2022 (UTC)
  • Support Support«« Man77 »» [de] 14:03, 30 January 2022 (UTC)
  • Support Support Amir.h7 (talk) 14:10, 30 January 2022 (UTC)
  • Support Support HynekJanac (talk) 17:24, 30 January 2022 (UTC)
  • Support Support Maro mich (talk) 21:59, 30 January 2022 (UTC)
  • Support Support Bailo26 (talk) 22:19, 30 January 2022 (UTC)
  • Support Support My eyes could kiss you! Wowzers122 (talk) 22:21, 30 January 2022 (UTC)
  • Support Support Elekhh (talk) 00:08, 31 January 2022 (UTC)
  • Support Support Libcub (talk) 01:09, 31 January 2022 (UTC)
  • Support Support ··· 🌸 Rachmat04 · 03:09, 31 January 2022 (UTC)
  • Support Support daSupremo Diversity icon red.svg 04:25, 31 January 2022 (UTC)
  • Support Support It would require a function that allows article editors to identify alternate image files for cases where one image is optimal on a white screen but a different image is better (or even necessary) on a dark screen. CdnMCG (talk) 05:27, 31 January 2022 (UTC)
  • Support Support Info-farmer (talk) 09:35, 31 January 2022 (UTC)
  • Support Support Most dark mode gadgets I've tried are not great, a formal version would enable improvement over time. Personally, I propose modelling off Discord's Nosebagbear (talk) 12:04, 31 January 2022 (UTC)
  • Support Support This would also require adding supporting classes for templates (via TemplateStyles). — AfroThundr (u · t · c) 13:40, 31 January 2022 (UTC)
  • Support Support Trizek from FR 13:50, 31 January 2022 (UTC)
  • Support Support Lrkrol (talk) 15:00, 31 January 2022 (UTC)
  • Support Support Bluerasberry (talk) 17:26, 31 January 2022 (UTC)
  • Support Support Aoba47 (talk) 20:45, 31 January 2022 (UTC)
  • Support Support Forcing readers to use black text on a white background is becoming increasingly anachronistic. Most major websites, mobile apps, operating systems, office applications etc. have a dark mode these days. Modest Genius (talk) 21:02, 31 January 2022 (UTC)
  • Support Support Something that isnt the black and green option I stumbled upon recently. (no offense to whomever created that) IAmChaos (talk) 21:52, 31 January 2022 (UTC)
  • Support Support Dave Braunschweig (talk) 00:11, 1 February 2022 (UTC)
  • Support Support MONUMENTA (talk) 00:47, 1 February 2022 (UTC)
  • Support Support Alpaca the Wizard (talk) 00:47, 1 February 2022 (UTC)
  • Support Support Labdajiwa (talk) 04:00, 1 February 2022 (UTC)
  • Support Support HarryAllen64 (talk) 04:13, 1 February 2022 (UTC)
  • Support Support Kpgjhpjm 06:36, 1 February 2022 (UTC)
  • Support Support SCP-2000 08:21, 1 February 2022 (UTC)
  • Support Support --Alaa :)..! 08:33, 1 February 2022 (UTC)
  • Support Support TechLich (talk) 11:04, 1 February 2022 (UTC)
  • Support Support Szymonel (talk) 13:39, 1 February 2022 (UTC)
  • Support Support Cabayi (talk) 14:52, 1 February 2022 (UTC)
  • Support Support Thibaut (talk) 16:00, 1 February 2022 (UTC)
  • Support Support mw:Skin:DarkVector exists. Flounder ceo (talk) 18:48, 1 February 2022 (UTC)
  • Support Support GNUtoo (talk) 16:21, 1 February 2022 (UTC)
  • Support Support Mustafa_MVC (talk) 20:25, 2 February 2022 (UTC)
  • Support Support Imagine not having dark mode in 2022 WhitePhosphorus (talk) 13:31, 2 February 2022 (UTC)
  • Oppose Oppose I think there are more important things to work on. Mitar (talk) 20:54, 2 February 2022 (UTC)
  • Support Support Prof.Flip (talk) 14:04, 3 February 2022 (UTC)
  • Support Support Giacomo Alessandroni let's talk! asd 15:00, 3 February 2022 (UTC)
  • Support Support WikiAviator (talk) 16:03, 3 February 2022 (UTC)
  • Support Support DanCherek (talk) 16:17, 3 February 2022 (UTC)
  • Support Support It would be great! Mixedtomatoes (talk) 16:24, 3 February 2022 (UTC)
  • Support Support ZaidhaanH (talk) 22:23, 3 February 2022 (UTC)
  • Support Support Xavier Dengra (MESSAGES) 23:39, 3 February 2022 (UTC)
  • Support Support Taxs1 (talk) 02:34, 4 February 2022 (UTC)
  • Support Support it is disappointing that Wikipedia as a popular website has not just a simple dark mode. Farrokh.A (talk) 15:55, 4 February 2022 (UTC)
  • Support Support Ninepointturn (talk) 16:27, 4 February 2022 (UTC)
  • Support Support Yeeno (talk) 20:18, 4 February 2022 (UTC)
  • Support Support --ToprakM 01:15, 5 February 2022 (UTC)
  • Support Support Sir Proxima Centauri (talk) 07:20, 5 February 2022 (UTC)
  • Support Support Dark mode is currently possible with browser plug-ins, but that's a very imperfect solution. As one example, the plug-in Dark Reader works,but table borders and certain images turn invisible. Fandom already beat us to this, so it's definitely possible. JDspeeder1 (talk) 09:08, 5 February 2022 (UTC)
  • Support SupportKPFC💬 11:03, 5 February 2022 (UTC)
  • Support Support Thepuglover (talk) 11:20, 5 February 2022 (UTC)
  • Support Support Hanif Al Husaini (talk) 12:09, 5 February 2022 (UTC)
  • Support Support Urgently! Thingofme (talk) 13:10, 5 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 14:44, 5 February 2022 (UTC)
  • Support Support Arturo Angeles (talk) 15:03, 5 February 2022 (UTC)
  • Support Support Oliveleaf4 (talk) 18:03, 5 February 2022 (UTC)
  • Support Support Exilexi (talk) 18:13, 5 February 2022 (UTC)
  • Support Support Yzelf (talk) 20:58, 5 February 2022 (UTC)
  • Support SupportThanks for the fish! talkcontrib (he/him) 22:23, 5 February 2022 (UTC)
  • Support Support --Tinker Bell 05:17, 6 February 2022 (UTC)
  • Support Support Even as an avid Dark Reader user, Vulp would appreciate a native dark mode solution for Wikimedia sites--Vulp❯❯❯here! 09:38, 6 February 2022 (UTC)
  • Oppose Oppose --Ciao • Bestoernesto 19:07, 6 February 2022 (UTC)
  • Support Support Molestash (talk) 01:16, 7 February 2022 (UTC)
  • Support Support Ryse93 (talk) 12:36, 7 February 2022 (UTC)
  • Support Support Tom Ja (talk) 17:34, 7 February 2022 (UTC)
  • Support Support Daniel Case (talk) 19:26, 7 February 2022 (UTC)
  • Support Support Arvelius (talk) 20:34, 7 February 2022 (UTC)
  • Support Support Captainroz (talk) 06:34, 8 February 2022 (UTC)
  • Support Support "Easy" (says the person not contributing to the code) win that I think would generate a lot of positive attention. Especially if there was an intuitive way for users to enable even if not logged-in (like a lightbulb, toggle, etc.). paul2520 (talk) 17:05, 8 February 2022 (UTC)
  • Support Support BugWarp (talk) 13:54, 9 February 2022 (UTC)
  • Support Support Prawdziwy Mikołajek (talk) 17:50, 9 February 2022 (UTC)
  • Support Support Tinux (talk) 07:55, 10 February 2022 (UTC)
  • Support Support β16 - (talk) 10:48, 10 February 2022 (UTC)
  • Support Support George6996 (talk) 13:58, 10 February 2022 (UTC)
  • Support Support Frequent on many pages of the web, and has already been implemented in the iOS app TheFrog001 (talk) 14:54, 10 February 2022 (UTC)
  • Support Support Km415 (talk) 15:52, 10 February 2022 (UTC)
  • Support SupportDaxServer (t · c) 16:06, 10 February 2022 (UTC)
  • Support Support ZellmerLP (talk) 18:39, 10 February 2022 (UTC)
  • Support Support Sunpriat (talk) 02:39, 11 February 2022 (UTC)
  • Support Support Betateschter (talk) 07:13, 11 February 2022 (UTC)
  • Support Support Kaicarver (talk) 08:38, 11 February 2022 (UTC)
  • Support Support Jl sg (talk) 08:52, 11 February 2022 (UTC)
  • Support Support It's a shame that dark mode for Wikipedia is still a wish in 2022. Hope you don't make us wait until 2030! 4nn1l2 (talk) 13:34, 11 February 2022 (UTC)
  • Support Support Blablubbs (talk) 14:45, 11 February 2022 (UTC)
  • Support Support Forrestkirby (talk) 15:31, 11 February 2022 (UTC)
  • Support Support Vddbert (talk) 15:32, 11 February 2022 (UTC)
  • Support Support --evrifaessa (talk) 16:29, 11 February 2022 (UTC)
  • Support Support Valerio Bozzolan (talk) 16:37, 11 February 2022 (UTC)
  • Support Support Ziko (talk) 18:55, 12 May 2022 (UTC)
  • Support Support And there should be a gadget for it here - the English Wikipedia script seems to work well enough. GreenReaper (talk) 08:22, 10 November 2022 (UTC)

Make SecurePoll accessible through local wikis

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

  • Problem: To vote in a SecurePoll election, you need to be redirected to votewiki (vote.wikimedia.org). This leads to potential vulnerabilities (see phab:T298849) and it also requires the interface language of votewiki to be changed based on the language of the local wikis who are running an election there at each given time.
  • Proposed solution: Refactor the code of SecurePoll to properly use CentralAuth and SUL, so that users don't have to leave their local wiki at all to vote.
  • Who would benefit: Wikis that hold elections using SecurePoll (currently enwiki and fawiki, soon to include zhwiki and more).
  • More comments:
  • Phabricator tickets: phab:T298849 (it is private for security reasons)
  • Proposer: Huji (talk) 01:03, 11 January 2022 (UTC)

Discussion

  • What is forcing this in to the "larger suggestions" pile? — xaosflux Talk 02:25, 11 January 2022 (UTC)
May be "Refactor the code"? I wonder if it is possible to simply make voters to login into votewiki through CentralAuth. --Steven Sun (talk) 03:46, 11 January 2022 (UTC)
No, more likely the privacy/security aspects of it. That's gonna make this a really big task. Also steers it outside of the expertise of the community tech team a bit I think as they would have to consult lots of other teams. —TheDJ (talkcontribs) 13:42, 11 January 2022 (UTC)
By the way, what is the purpose of local Special:SecurePoll page? You still need to go to an external wiki to vote anyway. Hope one day it could be uesd as a standalone local voting portal. —— Eric LiuTalk 16:41, 11 January 2022 (UTC)
It seems to be a fix for earlier days without SUL, but now, as we have it, it seems better to host elections locally (unless there's CU concern). 1233 T / C 16:29, 19 January 2022 (UTC)

Voting

A banner on software-related Wikipedia articles to increase MediaWiki development and get Wishlist proposals implemented

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

  • Problem: We're having these surveys every year but only a very small fraction gets implemented.
There's also a large backlog of code issues on phabricator, and many even very basic features haven't been implemented so far.
This is despite of the code issues not including many existing and potential proposals.
Often code issues, if implemented at all, take over 5 years from creation to implementation. There could be much more development.
  • Proposed solution: Add a banner asking developers to help with MediaWiki development.
The banner is only displayed at the top of all software-related articles (at least all software development related ones). Alternatively it could also be displayed on all pages.
  • Who would benefit: Wikipedia as a whole and all existing and potential sites using MediaWiki software.
  • More comments: It could be further improved by setting up e.g. a competition-like leaderboard of volunteer developers who helped the most on the page the banner links to. Maybe there could also be functionality to donate to teams/people who implement Wishlist proposals to fund their implementation. However, I think it would be best if the first time such a campaign is run, only volunteer development gets facilitated, especially because it may be difficult to design this in a way that's fair and well-functioning if that's possible at all (I think it could be fairly simple).

    Engineering would be required to put the banner only on software development related pages. This could be done by using categories. It would also be required for things like rankinglists and badges. The badges could be rewarded for certain tasks like closing a difficult issue or a number of issues and would get certified. Users could then use these badges on their userpages and even outside of Wikipedia. Moreover, engineering could help ensure that people can get started with the development well and quickly and that efforts are streamlined in a way that ensures contributions are constructive. Further details and additional ways could be worked out later or get added to this proposal (via edits and comments).


This proposal also got substantial support on reddit on multiple subreddits.
It seems like at the talk page Ayack Otourly Stryn and Sänger expressed discontempt with how Wishlists have been implemented so far.

Wikipedia runs on MediaWiki software as its core and most proposals here are about this software. It is this page or a similar page, that the page of the banner should link to or whose information the page should contain.

Note that many proposals are not yet code issues. For example, I have many proposals I never published so far because I'm still waiting for more important issues to get solved first (like a button on the Watchlist to see all changes since last visit per page which could save a lot of editors' time).

I also think that more of the WMF's financial resources should be dedicated to software development of the Wishlist proposals and phabricator tasks (this also got substantial support on reddit). However, this proposal here is "only" about the banner (and everything directly related to it on the landing page etc). I think that regardless of what's decided related to the use of funds and funding-mechanisms, we should strive to maximize volunteer MediaWiki-related development.

Note that visibility, feedback and being part of a campaign (roughly described), rather than an unfacilitated strive to help out by interested individuals, can substantially increase motivation. This could also be the idea behind #1lib1ref.

I don't think that such a campaign would draw substantial human resources (or time, expertise, effort) away from other important software development. In particular, away from open source software development/maintenance of important packages.

Discussion

  • @Prototyperspective: how would you want the banner to know if any specific page would be a target to show said banner? For example: a list of pages, a cateogry, a wikidata category, etc? — xaosflux Talk 19:09, 10 January 2022 (UTC)
A category for example. --Prototyperspective (talk) 20:31, 10 January 2022 (UTC)
How many experienced developers would be reading the Wikipedia articles for those languages in question? Wouldn't just having a global banner be much more appropriate with a wider reach? Ed6767 (talk) 22:33, 10 January 2022 (UTC)
  • Proposals should require engineering work; this one doesn't really do so. The only somehow engineering-related part of the proposal is to identify "software-related Wikipedia articles", so the proposal could be reduced to "create software that automatically identifies software-related Wikipedia articles and provides a list of them for displaying banners"… I don't really see how this is an improvement to be made by the Tech Team. Mostly, the page you're looking for seems to be CentralNotice/Request. ToBeFree (talk) 19:09, 10 January 2022 (UTC)
Yes, it's that simple that it doesn't really require any engineering work of significance, so it's really just the decision(-making / willingness) of the WMF that causes this to not get implemented. However, it still requires a minor effort of engineering, which Xaosflux asked about above: how to identify said pages. Moreover, if a rankinglist and things like that are added these would also require engineering work. --Prototyperspective (talk) 20:31, 10 January 2022 (UTC)
  • You've listed this as something for "admins and patrollers" - is this something you'd only see showing for such groups - or is this something you want to target general readers of projects? — xaosflux Talk 19:10, 10 January 2022 (UTC)
General readers. It was the best fit of the available categories of the Wishlist Survey. --Prototyperspective (talk) 20:31, 10 January 2022 (UTC)
  • Per User:ToBeFree, this does not require any engineering resources. It sounds like CentralNotice/Request is indeed the only place you need to go. I'm going to archive this proposal. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 19:42, 10 January 2022 (UTC)
Please unarchive it: see the answer above, it does require engineering work. It's also a wishlist proposal. --Prototyperspective (talk) 20:31, 10 January 2022 (UTC)
  • @Prototyperspective, this has been archived but I was originally writing a comment regarding this proposal.
    I think your proposal and Reddit post is pretty inaccurate and outdated, and ignores so many points - you mention "intransparency" in the WMF despite literally everything being logged and your only citation being an opinion on a talk page? You mention the WMF is "unwilling to facilitate volunteer developers to help with the thousands of already-existing code issues", despite the fact the WMF provides Wikitech, Wikimedia Cloud Services, technology grants, hackathons, and so much more. You also said "basically nothing could be done about it", which is a very pessimistic view. I could go on, especially with your irrelevant raising of log4j and heartbleed. You have to remember too that there is a big difference as many MediaWiki features are implemented through extensions and gadgets - these are the things that often go unmaintained and become neglected - adding a feature to MediaWiki itself isn't necessarily as simple as you'd think.
    You also seemed to ignore that moving from Gerrit to GitLab is already planned and timelined?
    I just don't feel you've done the adequate amount of research required for a proposal like this. You do raise some good and well known issues however, and there are many more valid criticisms regarding the current developer situation that could be made, but you completely missed the point here with weak rationale. It is true that development is lacking and not many people know they can and/or want to contribute to MediaWiki development and how current resources and developer support isn't advertised or promoted as much as it should be. My advice is you should go back and rework your proposal and come up with a plan for how developers from outside the Wikimedia community would feel more welcomed and have more resources available to them, then submit it through the appropriate venues, rather than the community wishlist. Ed6767 (talk) 20:10, 10 January 2022 (UTC)
    See also mediawikiwiki:Bug management/Development prioritization Ed6767 (talk) 20:16, 10 January 2022 (UTC)
Provide proof of your claims (which are wrong). I removed the largely irrelevant mention of log4j etc. With this unwillingness I was referring to the blockade to add such a banner. I already knew and discussed the GitLab switch before making the post. Your points basically all misunderstood my points and aren't about the proposal. The Wishlist is a perfectly suitable place to propose this. I already read that page. I reworked the proposal to remove the log4j side note. --Prototyperspective (talk) 20:57, 10 January 2022 (UTC)
@Prototyperspective, I'm not a fan of your dismissive attitude, but sure:
> With this unwillingness I was referring to the blockade to add such a banner
This was not clear, but if you have a solid proposal all you need is consensus through the appropriate venue, the community wishlist is for engineering proposals, the infrastructure for global notices is already in place. I was also responding to some of the points made in your Reddit post.
I'm not saying I'm opposed to this, onboarding more developers from the wider public would be a great thing - however, I'm saying you need better planning and better rationale. Onboarding too many developers at once may create a massive influx that would need planning in place, not to mention the responsibilities that would be in place for security, reviewing and setting up each proposal and documenting it. Simply throwing as many developers as we can at the wall and seeing who sticks isn't the best strategy and would, in my opinion, make things even more disorganised. Ed6767 (talk) 22:13, 10 January 2022 (UTC)
I wanted to keep it short on purpose. (Other than that, it's not like I've never discussed related things before.)
The annual plan is what I linked to because it does not show exactly where the money goes. I mean I could be wrong but so far I can only find very large composite expenses for whole areas of expenses like Programmatic (and some other users have expressed similar concerns). Basically, the only main reason for why I didn't link to it directly but a Talk page is because it obviously gives the reader another impression.
The technology-related efforts are great and all and I wasn't saying there was nothing going on there at all, I mean one would reasonably expect there to be efforts. I was referring to the banner only and related facilitation of volunteer development like larger, more visible hackathons, rankinglists, badges, outreach, and so on. I just don't think the banner is an "only" – it would be the starting point of larger things, basically a requirement to get the development capacities and do whatever else you'd like to do to improve the Wikipedia software (including facilitating more development).
> but if you have a solid proposal all you need is consensus through the appropriate venue, the community wishlist is for engineering proposals, the infrastructure for global notices is already in place
This proposal is appropriate here in three ways: it fits the description "community wish/proposal" and "platform improvement", it's about Community Wishlists in a meta way, and engineering is required to make it work. The infrastructure for global notices already being in place makes it even easier to implement, making it more strange that it hasn't been done before. But that's not all the engineering that would go into this, especially depending on how well it's implemented (the better the more engineering would go into it...even though the survey isn't called "Community's Engineering Wishlist").
The linked reddit post was not meant to be a major point, it was just to show that externally there is considerable support for doing so – reddit is not the Wikipedia/Wikimedia community so it has not a significance as large as you may have thought I'm suggesting it to be.
> Onboarding too many developers at once may create a massive influx that would need planning in place, not to mention the responsibilities that would be in place for security, reviewing and setting up each proposal and documenting it.
See? These things would require engineering. However, it would be about implementing proposals, not about creating more proposals. Maybe I should also add more details about that (including streamlining and onboarding) beyond badges which would also require engineering.
Having such a large wall of text under "Discussion" is a problem though so maybe it should be wrapped in a collapsed template one can expand.
--Prototyperspective (talk) 00:20, 11 January 2022 (UTC)
It seems that as I've critiqued your idea you've clarified and developed your idea, but in a contradictory way - and what I said is more than engineering, but would require policy, funding and planning. These are some great ideas to increase onboarding, and I think having a much larger hackathon event that is publicly advertised to an audience wider than the general community is a brilliant idea that should be developed, but there needs to be much more in depth planning as for a project as large as MediaWiki, it's not trivial. Not to mention some of your comments disregarding the WMFs software engineering team [1][2][3] and arguing with people on Phabricator seem, in my opinion, quite disrespectful towards their continued hard work, especially as a developer I have worked on and benefitted from their work and support, along with many others.
Ignoring that we're swerving vastly off topic, I still don't think this is appropriate for the wishlist:
  • Overlaps with another team: see mediawikiwiki:Developer Advocacy (you may want to open a phab ticket with a more developed suggestion there for their consideration)
  • You still haven't proven that this needs engineering work (i.e. development of a new tool/tech/etc.) - the tech exists, policy page and program development is different and would require further discussion at a more appropriate venue
  • This isn't just one problem that needs solving, but rather something that should be developed into deeper proposals in a different venue - this is not what the community wishlist is for
Of course, it goes without saying that the quickest way to get what you want in FOSS is to aim to fix things yourself so that you can also contribute and help the community, and it may also help with giving your perspective for developing future proposals. Ed6767 (talk) 02:04, 11 January 2022 (UTC)
You said it didn't require engineering work. I certainly don't oppose related efforts of "policy, funding" (and planning) which you think are required for this.
I'm very grateful for the developers. I was saying there should be more development. And not even once were my concerns addressed in my arguments there even though I repeated them about 10 times, trying to make them ever clearer than before. I always remained respectful, not sure why you're suggesting I wasn't. Other than that, I think there ought to be certain humility when using donated money.
I don't think that "we're swerving vastly off topic" – you've done that by causing a large a wall of text beneath this proposal that's largely not about the proposal at all.
It's not about FOSS but about Wikipedia/Wikimedia and it's a very due platform improvement proposal which does require engineering (lots of it if you do it very well). --Prototyperspective (talk) 11:24, 11 January 2022 (UTC)

Voting

  • Support Support TheInternetGnome (talk) 08:45, 30 January 2022 (UTC)
  • Support Support JPxG (talk) 01:07, 31 January 2022 (UTC)
  • Support Support Vukky (talk) 08:22, 2 February 2022 (UTC)
  • Support Support However it gets done, I agree Wikipedia could use more volunteer developers Ph03n1x77 (talk) 07:03, 5 February 2022 (UTC)
  • Support Support Thingofme (talk) 13:11, 5 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 14:55, 5 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 19:08, 6 February 2022 (UTC)
  • Support Support Sounds like a great idea to pique the interest of students, casual coders, and full-time SEs with free time. I'm very much in favor of anything that can be done to encourage open source contributions. paul2520 (talk) 17:11, 8 February 2022 (UTC)
  • Support Support Gaurav (talk) 02:55, 11 February 2022 (UTC)
  • Support Support If this will be shown instead of donation banners, YES. Valerio Bozzolan (talk) 16:39, 11 February 2022 (UTC)

Less embellishment

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

  • Problem: Embellishmentosis
  • Proposed solution: Less embellishment.
  • Who would benefit: Everyone reading a Wikimedia page with a Web browser.
  • More comments: Example: "edit source" suffices; remove "edit".
  • Phabricator tickets:
  • Proposer: PeterEasthope (talk) 01:21, 11 January 2022 (UTC)

Discussion

  • Hello PeterEasthope, thanks for adding a proposal. Could you provide more examples of the Embellishmentosis? We need to know the specifics of what you mean by the label you use. Perhaps this piece of documentation could be useful. Thanks! SGrabarczuk (WMF) (talk) 01:58, 11 January 2022 (UTC)
    In accord to the documentation.
    > Pick one specific problem and describe it in detail
    Here are two. No charge for the 2nd. =8~)
    (1) Two links are presented to edit a page or section thereof. "edit source" allows editing the markup text which is translated to create the HTML of the page. "edit" allows visual editing.
    "edit" is slow to load and restricts capabilities. "edit source" loads quickly and allows all editing. Visual editing is relatively recent. Before it was added there was only source editing.
    (2) Multiple "skins" are offered. Consider this principle of the Web: the server presents content with minimal imposition of presentation; the client has as much freedom in presentation as feasible. Imposition of skins is unnecessary. Focus on content.
    > Don't worry about finding the solution
    Here are my proposed solutions. Again, no charge. =8~)
    (1) Drop visual editing. Keep source editing.
    (2) Drop the skins. Impose as little style as feasible. If you want to help readers with presentation, offer style sheets which a reader can use according to taste. Ref. https://support.mozilla.org/en-US/questions/1271227 =8~)
    Regards, ... PeterEasthope (talk) 02:57, 11 January 2022 (UTC)
    "Two links are presented to edit a page or section thereof. "edit source" allows editing the markup text which is translated to create the HTML of the page. "edit" allows visual editing." is a result of your preference/configuration. You can change that in your personal preference according to my understanding. C933103 (talk) 08:23, 17 January 2022 (UTC)
    In Preferences I found the switch and shut off visual editing. The wording suggests it's temporary for beta. I'd rather it be permanent. Thx, ... PeterEasthope (talk) 05:17, 21 January 2022 (UTC)
    • The VisualEditor has been worked on for years. It was created to make it easier for users who are not used to working with wikimarkup to be able to edit a page with relative ease. It will definitely not be removed. If the "Edit" button is bothering you, you can simply remove it through a userscript. Xxmarijnw (talk) 18:54, 11 January 2022 (UTC)
      Write a script to eliminate a distraction? Seriously? ... PeterEasthope (talk) 05:19, 21 January 2022 (UTC)
Inescapable question: the work on the visual editor was by volunteers or by paid Wikimedia staff or by paid contractors? Thanks, ... PeterEasthope (talk) 17:04, 21 January 2022 (UTC)
  • -1. Curmudgeonosis. –SJ talk  23:47, 23 January 2022 (UTC)
Accidentally clicking the "edit" link for the visual editor results in a delay while editing is set up. =8~( If the visual editor is permanent, then the configuration switch to turn off the edit link should also be permanent.
Dismissing legitimate concerns as curmudgeonly will only discourage some capable and well meaning people from contributing. Look at what's happened with the Web. Many pages aiming to present simple information are severely burdened with JavaScript. Consequently a bus schedule which might be presented efficiently as a table in HTML5, is bogged with JavaScript. No problem for a contemporary iPhone or Android phone containing a JavaScript ASIC. Yes problem for reading the schedule with an old computer and Dillo. Try Dillo on a desktop machine. If possible an older generic machine. Immediately you'll notice how quickly Dillo opens compared to Firefox. Not a criticism of Firefox. Rather an illustration of the pervasive imposition of JavaScript. The endless push to more complex and resource consuming systems is a grave problem for the biosphere.
Climate change
Environmental degradation
We don't have to play into the hands of mega-corporations. Of all people, Wikimedians should exercise principled autonomy and initiative. Regards, ... PeterEasthope (talk) 16:33, 27 January 2022 (UTC)
I mean isn't it already possible to disable the visual editing at Special:GlobalPreferences#mw-prefsection-betafeatures?
Currently, yes, in Wikibooks I disabled visual. I hope the personal configuration option isn't dropped. Regards, ... PeterEasthope (talk) 17:53, 27 January 2022 (UTC)
I recall having to make some special config to get multiple edit buttons? C933103 (talk) 17:27, 27 January 2022 (UTC)
In Wikibooks, my default was "edit" and "edit source". In Preferences, I switched off "edit". Here I have only "edit" (= edit source). Apparently visual editing isn't available here.
This discussion is itself an example of why I advocate for simplicity. This morning I've spent at least an hour here which could have been spent on editing and writing. Exactly my concern. When a technology becomes established, focus shifts to embellishment with unnecessary complexity. Consequently some of the original value is lost. Illustrated by the Web as noted above. At some point people should recognize success and stop. Regards, ... PeterEasthope (talk) 18:26, 27 January 2022 (UTC)
Thanks for elaborating, Peter. Of course we should focus on simplicity, a minimum of JS bloat, and the like. It was your final comment about the "inescapable question" that struck me as unhelpful. The visual editor has increased the # of people I've successfully gotten to edit many times over, and was the most-requested feature by non-editors in the years leading up to it. –SJ talk  03:24, 28 January 2022 (UTC)
'... most-requested feature by non-editors ...'
Fair enough but please leave a permanent option for visual vs. source editing preference. As mentioned, inadvertently choosing visual wastes time. Might be only 20 seconds but a distraction nevertheless and seconds add up. The principle of "user centered interface", familiar to Mac users, is significant. A user should be presented with only pertinent and significant information. If a user uses only one of the two edit interfaces, there is no need for two edit links. It's a matter of psychology. Less can be more.
'...comment about the "inescapable question"...'
Accountability may be embarrassing but is necessary where a cooperative effort is aimed to a result. Without accountability efforts go astray. A harsh reality.
Regards, ... PeterEasthope (talk) 15:34, 28 January 2022 (UTC)

┌─────────────────────────────────┘
After writing the preceding sentence I happened to the read the "Wikipedia has Cancer" essay by Guy Macon. Disturbingly congruent to my concerns. Any donor should be seriously concerned about the noted refusals for financial accounting. The scenario of bankrupcy and acquisition by a mega-corporation is gravely disturbing. Exactly the fate of Mountain Equipment Coop, started in Vancouver by a group of outdoor enthusiasts. For several decades a wonderful success. Then it began to grow like a mushroom, opening stores across the country. Opposition to the growth was met with stonewalling. =8~| No problem for a few years. Then the economy shifted. MEC became bankrupt and was forced to sell assets to a private interest. I really don't want Wikimedia to fall to the same fate but, without accountability, that might be inevitable. =8~( Regards, ... PeterEasthope (talk) 15:42, 29 January 2022 (UTC)

  • Comment Comment Please invest more than 1 minute in writing a good proposal. The world is watching this conversation. --Valerio Bozzolan (talk) 16:40, 11 February 2022 (UTC)
Valerio Bozzolan> Comment "Please invest more than 1 minute in writing a good proposal."
Before I attempt to rewrite the proposal please make one specific criticism or ask one specific question. The meaning of "less embellishment" is clear. I gave two examples. An alternative statement in one word: simplify. Sorry to resort to a flippant cliche but what part of simplify is not understood?
> "The world is watching this conversation."
Encouraging although authorization of a change and implementation are controlled by a few people. If the authority doesn't support a proposal, it won't progress. Hypothetically, the board of directors has ultimate authority. The board can advance an interest or delegate to paid staff, few of which will support a proposal limiting employment. In any case there is risk of benefit to interests of a relatively small group of people on a relatively small time span. As noted above, the analogy to MEC is frightful. =8~(
Incidentally, the absence of an answer to my "inescapable question" suggests exactly one explanation: the answer is too embarrassing to state.
Regards, ... PeterEasthope (talk) 15:50, 13 February 2022 (UTC)
A third simplification, additional to the two above.
(3) For some links to articles, hovering the mouse pointer on the link gives a small preview of the article. I question the worth of the preview. In a page containing a high density of links, just moving the pointer across the screen can produce several unwanted activations. Every unwanted activation is a distraction and delay. Rather than use computational resources for preview, simply open the full article with a click. In absence of a click, do nothing. If previewing must remain, make it optional; provide a option to shut it off. Wirth's dictum again: resouces needn't be consumed merely because consumption is possible. PeterEasthope (talk) 16:57, 13 February 2022 (UTC)
@PeterEasthope: I'm on your side, but if the proposal is poorly written, the proposal readers (lot of people) invest too much time to understand how to help and sustain you, resulting in no one being able to support you. If you think that «Embellishmentosis - Example: "edit source" suffices; remove "edit".» is a good proposal, I thank the six people who put +1 understanding what you wanted. I didn't get it. Valerio Bozzolan (talk) 09:45, 14 February 2022 (UTC)
Another question which might help: what fraction of readers in Wikipedia adjust their Preferences? Thanks, ... PeterEasthope (talk) 15:33, 15 February 2022 (UTC)

Voting

  • Support Support This is a real warning suggestion. Every organisation tend to extend beyond its core goal, which makes its grow more exponential, and finally causes implosion. Havang(nl) (talk) 10:18, 1 February 2022 (UTC)
  • Support Support KingAntenor (talk) 07:13, 2 February 2022 (UTC)
  • Support Support Prof.Flip (talk) 14:05, 3 February 2022 (UTC)
  • Support Support Thingofme (talk) 13:12, 5 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 19:09, 6 February 2022 (UTC)
  • Support Support --Liuxinyu970226 (talk) 01:33, 9 February 2022 (UTC)

Identity protection for functionaries

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

  • Problem: Functionaries get doxxed on and off Wikimedia projects, and receive threats of harm and have had things happen to them in real life. Many countries, including the United States, do not have proper legal protections regarding publication of private information, and county and state records including birth certificate and property deed information wind up on data sharing sites.
  • Proposed solution: For functionaries, provide an identity protection service like DeleteMe and/or general identity theft protection (plenty of companies do this in the US). Provide equivalent services in other countries. Also write up a guide as to basic identity protection practices (there are plenty out there for high-risk journalists, for example).
  • Who would benefit: Functionaries, and users served by those functionaries.
  • More comments: It might be possible to convince companies to provide this service as a gesture of goodwill and charity.
  • Phabricator tickets:
  • Proposer: Rschen7754 02:07, 14 January 2022 (UTC)

Discussion

  • See en:Wikipedia:Functionaries to learn that "functionary" is a technical term in Wikipedia....
  • so... this deleteme service basically files "Right to be forgotten" requests with google and makes things disappear from google and other search engines ? —TheDJ (talkcontribs) 09:17, 14 January 2022 (UTC)
    • Not Google, but data brokers like Spokeo and Intellius. [4] --Rschen7754 19:02, 14 January 2022 (UTC)
      • Well I'm seeing as an immediate issue, the fact that the Foundation has formally stated its opposition to the concept of "right to be forgotten" and suchlike. I can't imagine they'd be in favour of backing this, even though they are, of course, against the editors being doxxed. Nosebagbear (talk) 15:46, 18 January 2022 (UTC)
        • I'm not sure how relevant that is - we talk about people who are notable, but then we don't go and publish celebrity home addresses on Wikipedia. --Rschen7754 19:03, 18 January 2022 (UTC)

Voting

  • Support Support I doubt this would turn out to be worthwhile but it's an important enough problem to merit official investigation of the proposal, IMO. Tgr (talk) 00:46, 30 January 2022 (UTC)
  • Support Support JPxG (talk) 01:08, 31 January 2022 (UTC)
  • Support Support Libcub (talk) 01:11, 31 January 2022 (UTC)
  • Support Support Novak Watchmen (talk) 17:40, 31 January 2022 (UTC)
  • Oppose Oppose The underlying issue is important but I don't see why it should be limited to functionaries or how companies providing "identity protection services" would help here. For instance if you're part of a group of people that is persecuted (either by states or other groups of people), having your identity revealed can be really problematic in any case. For instance if you're homosexual, in some countries you can be killed for that (https://en.wikipedia.org/wiki/Capital_punishment_for_homosexuality), and contributing to articles on the topic. For instance [[LGBTQI+ rights in <country where homosexuality is illegal>]]) can get you in trouble. The same issue applies to some political topics in many countries. The consequence is that repression against people directly affect the neutral point of view of Wikimedia projects like Wikipedia. To fix that, the Wikimedia projects themselves should rather be proactive in protecting contributors identity rather than trying to fix it when it's too late and not fixable anymore. Wikipedia pages (including the history) can be archived for instance. Nowadays:
What we could do to improve the situation is probably to find what prevents people from contributing to projects like Wikipedia in these situations and fix it. For instance before writing this reply, I wasn't aware of the policies, and I assumed that it was not possible to create additional accounts to avoid political persecution. Though I do edit Wikipedia through Tor and for that I had to request an exemption. Though sometimes even if I'm logged, I've to use a new route to edit as I'm somehow blocked even with the exemption, but after very few retries it usually works. Without the exemption I don't think I could do any editions at all from Tor. Another area of work would be to have guides to help persecuted people contribute to projects like Wikipedia and still stay safe. Using the tor-browser (with or without bridges depending on the country and the political situation), avoiding being identified through Stylometry, etc could probably help too. The issue here would be to find people persecuted people that are willing to explain why they don't contribute. The Tor and the Tails projects already interviewed people anonymously to understand better the needs of their users, so they also have experience with that. In addition they have to distribute bridges in countries where you could get in trouble for that, so some people involved probably have some experience with helping people facing persecution in ways that don't backfire. GNUtoo (talk) 21:25, 1 February 2022 (UTC)
  • Support Support KingAntenor (talk) 07:16, 2 February 2022 (UTC)
  • Oppose Oppose Xavier Dengra (MESSAGES) 23:42, 3 February 2022 (UTC)
  • Support Support This is important to not harass or bribe the functionaries (Checkusers, oversighters, stewards). Also we can give the global bureaucrat permission (some are not comfortable to sign the confidentiality agreement) Thingofme (talk) 13:14, 5 February 2022 (UTC)
  • Support SupportThanks for the fish! talkcontrib (he/him) 22:24, 5 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 19:10, 6 February 2022 (UTC)
  • Oppose Oppose already too powerful and well-protected. 4nn1l2 (talk) 13:39, 11 February 2022 (UTC)

Wikipedia kids app

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

  • Problem: Children cannot easily consume Wikimedia content.
  • Proposed solution: Create a Wikipedia mobile app for kids with features like:
    • Articles derived from Simple Wikipedia.
    • By default the app has no censorship, however, parents can set censorship filters if wanted.
    • Daily fun facts
    • Kid-friendly topic portals
    • Image-based informational storybooks/slideshows (Wikistories)
    • Games
    • Maybe early-education Wikiversity courses?
  • Who would benefit: Children
  • More comments:
    • Maybe this could turn into a completely new Wikimedia project with a website? Who knows?!
    • Please comment below other features you think this could have!
    • See the Basque Wikipedia's kids portal: eu:Txikipedia:Azala
  • Phabricator tickets:
  • Proposer: Sea Cow (talk) 06:25, 13 January 2022 (UTC)

Discussion

  • Building an entire new app AND what is essentially a new 'wiki', seems a bit outside of the scope of the wishlist. I mean i'd love to see it too, but.... Anyway, I think this could be easily prototyped by someone as a website, which pulls from different parts of our wiki eco system. Projects like these need people who are personally invested into making them succeed I think. Better one dedicated volunteer with a vision and some tech skills, then a group of random developers. —TheDJ (talkcontribs) 10:09, 13 January 2022 (UTC)
    Oh, and I think that what you proposed in term of engagement etc. is actually better than lots of the 'wikikids'-wiki proposals I've seen out there. Also makes sense to do that on mobile, the kids I know seem to only use iPads/phones, I've only seen them use Chromebooks for school when they become 12yo or something. —TheDJ (talkcontribs) 10:12, 13 January 2022 (UTC)
  • Apparently out of TechCom's scope. Creating another app is something to be decided by WMF and its Board of Directors. Right? George Ho (talk) 08:28, 14 January 2022 (UTC)
  • I think what is needed is to cut down the scope of this proposal heavily in order to fit into community tech wish list. I see the proposal can be cut down to only "Adding children mode into the existing wikipedia app" with main features needed including "sensitive content filter", "access time limitation", "article reading history report", as well as "random DYK articles". But even just these aspects are already quite complicated by community tech standard. C933103 (talk) 22:36, 15 January 2022 (UTC)
  • OOS per George Ho, can someone please move this to Community Wishlist Survey 2022/Archive? --Liuxinyu970226 (talk) 01:42, 17 January 2022 (UTC)
  • Hello and thanks for taking the time to write this proposal. Echoing what folks said here, this is definitely out of scope for our team but an idea that's valid nonetheless. I am therefore moving it to the Larger Suggestions Category. Thanks again! Regards, NRodriguez (WMF) (talk) 17:49, 17 January 2022 (UTC)
  • Simple English Wikipedia is constantly short of editors; for this reason, things like "Portals" don't really exist. The "Fun facts" take at least a month to compile; of course Wikipedia isn't censored, so the "access restrictions" will be difficult to implement there. As long as there are not more editors on SEWP, this is not realistic.-Eptalon (talk) 22:34, 17 January 2022 (UTC)
    @Eptalon Ya I see this too. The creation of this app might encourage editors to contribute. Though, I don't think we should build something when the content isn't even there to support it yet. We're going to have to find a better way to encourage contributions to Simple or come up with some other way to deliver simplified content. Lectrician1 (talk) 11:16, 19 January 2022 (UTC)
  • FYI, Txikipedia exists in Basque, this is something you can do without asking the WMF to. There's also an app for Txikipedia (links in the main page). -Theklan (talk) 08:10, 24 January 2022 (UTC)

Voting

  • Support Support Sounds lovely- would really encourage learning + provide an app for those parents that somehow maintain the insane belief that Wikipedia is unreliable Bristledidiot (talk) 19:07, 28 January 2022 (UTC)
  • Support Support Maybe we could replace some words with other easier to understand ones Rzzor (talk) 19:49, 28 January 2022 (UTC)
  • Support Support (As creator) Sea Cow (talk) 23:52, 28 January 2022 (UTC)
  • Support Support Lectrician1 (talk) 00:10, 29 January 2022 (UTC)
  • Support Support This would need to have a team dedicated to it, but could be incredibly valuable to new generations. "no censorship by default"; I would say is a little broad. I would think the app would censor what is shown by default. People could tag articles as "safe for children" or "not safe for children" and parents could enable or disable, etc.. Fazart (talk) 00:52, 29 January 2022 (UTC)
    The problem with this is the following: at least internally, you need two users, one or more users 'Parent1..n' who could set the information of what is acceptable for user child to see. Then perhaps 2-3 different "levels of settings":
    1) Age group: (3-5,)5-7, 7-9, 9-11,11-15,15-18
    2) Different "Knowledge groups": Animals, Geography, People, Customs,...
    3) Perhaps a negative list: no nudity, no atheism, no new religious movements, only christianity-related articles about religion.
    etc.
    No first of all: all these groupings need to be done using manual (or more likely: automatic) filtering. If your girl searches for bikini, do you want her to also be able to see information about 'micro bikinis' (they were developed by nudists in the US, because some states outlawed nudism), or pasties (even more minimal?). Or just information about the Bikini atoll (where nuklear tests were done, in the late 1940s-1980s, and local population was chased away, and some islands won't be habitable for a long time, see the dome they bulit on Runit island where they pur 'radioactive material')? - Note that the way the Wiki is built, there can be links from any article to any other article. So if your kid can see bikinis but not micro-bikinis, how would you make it obvious for them that 'micro-bikini' is off limits?
    Note: no matter how it is implemenzed, the 'permissible-content-selction' needs to be done in the Application, and not on any of the Wikipedia projects. It might be difficult/ewrror prone to implement. Eptalon (talk) 20:53, 30 January 2022 (UTC)
  • Support Support Klein Muçi (talk) 01:22, 29 January 2022 (UTC)
  • Support Support Hanif Al Husaini (talk) 01:40, 29 January 2022 (UTC)
  • Support Support War (talk) 03:54, 29 January 2022 (UTC)
  • Support Support Ottawajin (talk) 05:47, 29 January 2022 (UTC)
  • Support Support Tranhaian130809 (talk) 11:09, 29 January 2022 (UTC)
  • Support Support Veilure (talk) 01:43, 30 January 2022 (UTC)
  • Symbol oppose vote oversat.svg Strong oppose - While the content may be there (for English), I do not see enough editors willing to contribute (as editors). In addition, the idea of 'customizable-content-selection' is non-trivial to implement, and I currently do not see the manpower available. As noted above: In my opinion, 'content-selection'/'censorship' needs to be implemented off-wiki (that is: in the app).-Eptalon (talk) 21:04, 30 January 2022 (UTC)
  • Support Support Libcub (talk) 01:11, 31 January 2022 (UTC)
  • Support Support daSupremo Diversity icon red.svg 04:27, 31 January 2022 (UTC)
  • Support Support Ignacio Rodríguez (talk) 19:34, 31 January 2022 (UTC)
  • Oppose Oppose KingAntenor (talk) 07:16, 2 February 2022 (UTC)
  • Oppose Oppose --Serg!o (talk) 11:29, 2 February 2022 (UTC)
  • Support Support Syced (talk) 10:50, 4 February 2022 (UTC)
  • Support Support Wikipedia Kids (or euwiki has tikipedia) can be a learning material for children at school. Thingofme (talk) 13:14, 5 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 19:12, 6 February 2022 (UTC)
  • Support Support Daniel Case (talk) 19:28, 7 February 2022 (UTC)
  • Support Support ChhTJ096 (talk) 19:42, 8 February 2022 (UTC)

Identifying Lobby Teams

Light bulb iconB 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 how to prevent corporate (not individual) sock-puppets - where teams of employed (or conflict of interest) editors collude to steer a narrative. While Wikipedia has a strong ability to moderate and manage those efforts by individuals to distort, rewrite, or promote a particular viewpoint, it is not at all as strong when dealing with large corporate interests, especially when pushing a narrative that, at face value, may appear to be robust and peer-reviewed, but is actually politically or financially motivated. As one of the most visited websites in the world, where people come to find out 'the truth', there is an increasing responsibility to prevent political/financially motivated agendas.
  • Proposed solution: This behaviour could be identified using modern graph analysis tools based on edit and comment behaviours. Current sock-puppet approaches use tools such as stylometric conformance analysis, but I believe that additional tools could be implemented that look at cross-user behaviours, especially where comments and edits are often shared, following patterns of behaviour that indicate focus on specialised content. This is particularly noticeable where there are a group of editors who are aggressively defensive in their given subject area.

    For example, of a potential positive hit, it is not unusual, given any area of expertise, for editors to agree most of the time - however, when they agree all of the time, then their relationship becomes suspect.

  • Who would benefit: Everyone who matters benefits from increased vigilance.
  • More comments:
  • Phabricator tickets:
  • Proposer: 20040302 (talk) 20:37, 10 January 2022

Discussion

  • I don't know if I'm at liberty to discuss it here, but this already exists. I'm going to archive this proposal. Thanks for participating in the survey! MusikAnimal (WMF) (talk) 20:44, 10 January 2022 (UTC)
    See mw:User:Ladsgroup/masz * Pppery * it has begun 23:59, 10 January 2022 (UTC)
    The example you showed only indicates sockpuppet identification through stylometric conformance. What I am suggesting is different, and involves co-ordinated efforts being made by separate editors who are working for the same lobbying organisation. 20040302 (talk) 11:19, 11 January 2022 (UTC)
    @20040302 Thanks for clarifying, and for Pppery for mentioning Masz which I wasn't sure was public knowledge :) Anyway, I worry this project might be too big for Community Tech, but now knowing that Masz isn't what you're looking for, I will unarchive this proposal for the time being. Later when Community Tech reviews the proposals we may or may not deem this one too large, but if it is, we'll be sure to move it to our Larger suggestions category so it doesn't get lost here in the archives. Best, MusikAnimal (WMF) (talk) 16:44, 11 January 2022 (UTC)
    Upon further investigation I think it's clear this is out of scope for our team, but it's otherwise a fine proposal so I'm going to move it to the Larger suggestions category. Regards, MusikAnimal (WMF) (talk) 23:27, 17 January 2022 (UTC)
  • Yeah, I don't think this is in the pile of things the team has time for, and it would need significant fleshing out. --Izno (talk) 00:19, 17 January 2022 (UTC)
  • A big task, perhaps better suited for its own persistent team. But I would say this is one problem we will eventually have to solve (or shut down). The # of editors who primarily edit because they are paid by syndicates or as editing consultants has been rising even as total editors slowly declines. In some smaller wikis and some topic areas these may already be dominant forces. –SJ talk  23:45, 23 January 2022 (UTC)
  • I'm no expert but I wouldn't have expected detection to be the main COI/PAID/SOCK issue, but enforcement. We need WMF Legal to start sending scary letters to the corporations and individuals blatantly in violation of our Terms of Service, as proud declarations on their websites of their "services" to clients make abundantly clear. — Bilorv (talk) 20:31, 28 January 2022 (UTC)

Voting

  • Oppose Oppose I think we should evaluate content on accuracy & relevance, not on motivation of an editor. Libcub (talk) 01:16, 31 January 2022 (UTC)
  • Oppose Oppose I already have significant concerns with the morality of @Ladsgroup:'s process - the community can't judge its accuracy for itself, we don't know its error margin, how much of the review (in the sense of "this is how confident we are in the closeness") is done by the CUs and how much is automated and just told to them, and knowledge of its existence is generally pretty low (I knew prior to it being posted here, but only because I was told about it by a CU). More relevantly, the comment above is absolutely right, we don't need better mapping tech, we either need Legal to become significantly more aggressive on dealing with them or a public relations campaign to see if we can impose pressure that way...and I think the latter would only help them. Nosebagbear (talk) 10:08, 1 February 2022 (UTC)
  • Support Support Oh, yes, this is desperately needed. Strongly support. XavierItzm (talk) 20:22, 1 February 2022 (UTC)
  • Oppose Oppose KingAntenor (talk) 07:17, 2 February 2022 (UTC)
  • Oppose Oppose Potential witch hunting tool. - Darwin Ahoy! 02:05, 5 February 2022 (UTC)
  • Oppose Oppose oppose votes because of confident in detecting collab socks (block real users) Thingofme (talk) 13:16, 5 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 19:12, 6 February 2022 (UTC)

Fix parsing inside references

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

  • Problem: Currently, inside <ref>, template substitution (subst:) and link shortcut ([[w:likethis|]]) doesn't work.
  • Proposed solution: Make the same parsing inside <ref> as outside. There should be no difference (except recursive <ref>).
  • Who would benefit: All contributors wanting to avoid hitting template inclusion limit, and avoid typing text for link.
  • More comments:
  • Phabricator tickets: T4700
  • Proposer:  ◄ David L • talk ► 23:19, 16 January 2022 (UTC)

Discussion

Hello there, we looked at the discussion inside T4700 and decided that from an engineering perspective, this would be too large for our team. We are moving it to Larger Suggestions because we still think it should get visibility. Thanks for understanding, regards NRodriguez (WMF) (talk) 01:18, 18 January 2022 (UTC)

FWIW, in the English Wikipedia we have a very powerful referencing template {{R}}, which allows to define and invoke citations and footnotes. At its core it is a wrapper around MediaWiki's Extension:Cite, therefore it is fully compatible with references using <ref> tags, and both styles can be mixed on the same page as inline references or list-defined references. It is also compatible with any other citation templates typically used inside <ref> tags to format references (including the suite of CS1/CS2 citation templates).

Due to the way it works, the pipe trick, substitution, and nesting all work when defining references through template {{R}}.

I agree that MediaWiki's parser should be improved to support these features directly, but for those who don't want to wait for this, using {{R}} might be a workaround. --Matthiaspaul (talk) 22:01, 28 January 2022 (UTC)

Using {{R}} is, however, annoying for users who edit using the visual editor, because it has very poor support for references created inside templates (see e.g. T52474). A technical solution that avoids such templates would be nice. Matma Rex (talk) 22:10, 28 January 2022 (UTC)
I would phrase that rather differently. The purpose of {{R}} is not to be a workaround to the problem stated by the OP, it exists (like other templates on top of Extension:Cite) because it provides many desirable features of a citation system in its own right - it just happens to also work around the OP's problem and therefore could be conveniently used for this purpose as well.
Yes, this still makes it desirable to have an improved MediaWiki parser so that the mentioned features work also inside of <ref> tags. One does not rule out the other.
But, no, suggesting that references in templates should be avoided (or even technically forbidden) is setting the priorities wrong. If VE does not cope well with references in templates, the problem is VE (implementation-wise or even conceptually), not references in templates. VE is a non-essential convenience extension for beginners, whereas the possibility to use references anywhere in an article (including inside of templates) belongs into the group of essential features to lay the foundation to properly referenced encyclopedic articles, the very reason of why we are here. So, if VE can't cope with it, VE (or the framework around it) should be improved, not other much more important functions put down. But not the topic of this thread... ;-)
--Matthiaspaul (talk) 15:20, 29 January 2022 (UTC)

Voting

  • Support Support * Pppery * it has begun 18:59, 28 January 2022 (UTC)
  • Support Support Qwerfjkl (talk) 21:46, 28 January 2022 (UTC)
  • Support Support — Draceane talkcontrib. 22:34, 28 January 2022 (UTC)
  • Support Support Tol (talk | contribs) @ 23:01, 28 January 2022 (UTC)
  • Support Support NguoiDungKhongDinhDanh 15:21, 29 January 2022 (UTC)
  • Support Support —— Eric LiuTalk 18:25, 29 January 2022 (UTC)
  • Support Support OwenBlacker (Talk) 11:51, 30 January 2022 (UTC)
  • Support Support I realise Community Tech probably can't do anything about this, but want to express my support for someone at least looking into it. It's a totally counter-intuitive bit of behaviour, just look how many duplicates of the bug have been filed over the years. the wub "?!" 15:13, 31 January 2022 (UTC)
  • Support Support Matma Rex (talk) 16:33, 31 January 2022 (UTC)
  • Support Support JAn Dudík (talk) 21:41, 31 January 2022 (UTC)
  • Support Support Thingofme (talk) 13:16, 5 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 14:53, 5 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 19:13, 6 February 2022 (UTC)
  • Support Support Krzysiek 123456789 (talk) 15:37, 7 February 2022 (UTC)

Long Term Abuse tracking

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

  • Problem: The current system for tracking Long Term Abuse (LTA) is barely functional. LTA case pages are often abandoned or jammed with IPs from a decade ago. Self-made lists (e.g., en:User:EvergreenFir/socks, en:User:NinjaRobotPirate/Socks) can be helpful but are idiosyncratic and incomplete.
  • Proposed solution: Create a system like Sockpuppet Investigations (SPI) where cases are filed, reviewed, and archived. Adding reporting abilities to Twinkle would be a huge help.
  • Who would benefit: Admins, vandal fighters
  • More comments: Having CheckUsers be able to confirm would be helpful (like SPI) but I imagine this being much more about behavior and geolocation. Maybe a subsection in SPI itself could work.
  • Phabricator tickets:
  • Proposer: EvergreenFir (talk) 06:04, 18 January 2022 (UTC)

Discussion

See IP Editing: Privacy Enhancement and Abuse Mitigation/Improving tools#3. A database for documenting long-term abusers. It will be an cross-wiki LTA database. There are several LTA lists allready, one on english wikipedia (en:WP:LTA), one on dutch, and so on.--Snævar (talk) 08:33, 18 January 2022 (UTC)

  • Comment Comment @Zeleni, TheInternetGnome, Kcomerfo, and Thibaut:, pinging supporters. Since this was moved to larger suggestions there’s no guarantee of it passing but especially if you add the low support compared to other suggestions. I suggest to create a user group in meta for long term abuser monitoring, move all the databases from Wikipedia to meta, and this user group will be in charge of maintaining it. It’s possible to ping users monitoring their own lta databases. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 07:53, 4 February 2022 (UTC)
@Snævar and EvergreenFir:, pinging commenter and proposer. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 10:51, 4 February 2022 (UTC)
As I said, merging to one central LTA list will happen with the "IP editing" project (linked above). Creating an meta list could speed up the proccess, as it has been decided that the "IP editing" central list will be merged by the communities. Just be aware the list will not necessarily remain on meta, although it still will be central. Snævar (talk) 18:06, 4 February 2022 (UTC)
@Snævar: Is Talk:IP Editing: Privacy Enhancement and Abuse Mitigation/Improving tools the place to discuss this? Also please ping me in your reply. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 19:50, 4 February 2022 (UTC)
@Gifnk dlm 2020: Yes and no. The technical aspect needs to be communicated with the "IP editing" team, but merging and maintaining it is entirely upto the community, so the RFC below is good for that. We need to know what format the "IP editing" team wants for the list. Snævar (talk) 00:18, 9 February 2022 (UTC)
  • @Thibaut120094: wring pinging above. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 20:23, 4 February 2022 (UTC)
    • Wrong. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 20:24, 4 February 2022 (UTC)
      For LTA list, we should have a database, SRCU, and links between globally banned users (their editing behavior) and list of socks (to help coping with SRG which has a lot of requests). Also we can have an alternative way of SRG - a page similar to GSR or WP:AIV in enwiki, just to report socks of blocked users to lock and record. Thingofme (talk) 13:20, 5 February 2022 (UTC)

Voting

  • Support Support Zeleni (talk) 18:45, 29 January 2022 (UTC)
  • Support Support there are already such lists across different wikis. Just move all the content in multiple languages to one list on meta. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 20:01, 29 January 2022 (UTC)
  • Support Support TheInternetGnome (talk) 08:47, 30 January 2022 (UTC)
  • Support Support Kcomerfo (talk) 14:51, 31 January 2022 (UTC)
  • Support Support Thibaut (talk) 16:01, 1 February 2022 (UTC)
  • Support Support Create a Long-term abuse page in Metawiki, containing crosswiki socks and local links; globally banned users and their appearance, behavior (link to the home wiki) Thingofme (talk) 13:17, 5 February 2022 (UTC)
  • Support Support - Darwin Ahoy! 14:58, 5 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 19:14, 6 February 2022 (UTC)
  • Support Support Daniel Case (talk) 03:26, 8 February 2022 (UTC)
  • Support Support TheFrog001 (talk) 14:49, 10 February 2022 (UTC)

Votewiki/SecurePoll are not fit for service

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

  • Problem: Votewiki & Securepoll (V&S) are currently failing to meet several key requirements of communities demanding secure electoral capacity. Worse, yet, they are even less well suited to the impending increase in demand (such as new Arbcoms being encouraged into being by the Universal Code of Conduct) and variability in electoral methods (potentially the U4C, likely the Global Council, etc etc). Example issues include, but are not limited to: inability to handle simultaneous elections in different languages; extreme user-unfriendliness for Single Transferable Vote with more than a few candidates; lack of a tied-candidate mechanism for the STV option; difficulties in adding additional voting systems; the system is also technically fragile, with major bugs impacting elections requiring WMF staff activity to resolve.
  • Proposed solution: There have been discussed interim solutions (Such as creating a second vote-wiki to allow for two simultaneous elections), but they are just that, interim. A significant scoping work and re-development across the board would be needed, rendering this well beyond the Wishlist team's capacity.
  • Who would benefit: Every community that has non on-wiki elections, but especially every voter and every candidate
  • More comments: Everyone should feel free to add phab tickets below, as appropriate. I've not directly added the issue of struggling to find trusted/qualified individuals to scrutinise elections as that's not strictly a system issue.
  • Phabricator tickets:
  • Proposer: Nosebagbear (talk) 15:14, 18 January 2022 (UTC)

Discussion

  • Firstly, given the movement-charter adjacent nature of this proposal, just to confirm that this proposal is solely from me, without prior discussion with the MCDC and is not intended to indicate their opinion on the proposal. Nosebagbear (talk) 15:14, 18 January 2022 (UTC)
  • Though not what I proposed, in Community Wishlist Survey 2022/Miscellaneous/Improvement of private vote systems I mentioned a possibility to replace SecurePoll with another rewritten extension.--GZWDer (talk) 07:14, 20 January 2022 (UTC)
    • So I think that proposal would make an excellent interim solution, especially if twinned with making the current system somewhat more stable, but ultimately it's still going to prove insufficient for needs (and thus makes a good more practicable suggestion vs the issue raising this more is, for now) Nosebagbear (talk) 10:19, 20 January 2022 (UTC)

Voting

Improve pageviews to show which parts of the article the user is reading

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

  • Problem: The current pageview analytics are not specific enough to direct an editor's attention to the portion of an article that is most in need of being improved.
  • Proposed solution: The proposed solution is analogous to the YouTube engagement analytic that shows, statistically, at what time in a video viewers are leaving. However, the proposed solution for a Wikipedia article needs to account for multiple entry points into the article, as opposed to YouTube viewing which usually starts at the beginning of the video. Therefore, the proposed solution is to provide article editors with data showing how much time readers spend on each rendered section of the article, starting at the reader's entry point into the article.
  • Who would benefit: The article editors would benefit from the feedback and the article readers would benefit from articles that have had their worst parts improved.
  • More comments:
  • Phabricator tickets:
  • Proposer: Gj7 (talk) 00:52, 16 January 2022 (UTC)

Discussion

  • Good idea. Such analytics might also give an idea of which parts of an article can be deleted! Similar to the grammar-check proposal. In general Wikipedia needs to get with the times and make more use of automated tools. They represent free productivity, there for the taking. That should be a priority for a project built on volunteer labor. --Rollo (talk) 19:17, 16 January 2022 (UTC)
  • I agree that it could help with deletions. I think deletions are the most difficult edits because of the risk of discouraging volunteers from making future contributions. However, deletions often improve the article and having some data to help rationalize deletions would make deletions a little less difficult. --Gj7 (talk) 15:34, 17 January 2022 (UTC)
  • This is very much out of scope for Community Tech, but we're going to put in with our Larger suggestions category so it can still get some attention. Without having ran this by the Analytics team (who maintains the pageviews pipeline), I suspect there are many concerns with this. One is that we'd basically be monitoring what parts of the page the reader is viewing, which is something perhaps not everyone is comfortable with (even if anonymized). It could also be of performance concern for mobile readers, given we'd have to continually make roundtrips to the server even though the user hasn't done anything beyond scrolling. It also would be subject to many false positives and could send editors the wrong signal. For instance, a reader may view the table of contents for an article on a music artist and jump straight to the Discography section. This doesn't mean there's anything wrong with the content in between; they just want the discography and nothing else. In my opinion an encyclopedic article isn't that comparable to a YouTube video in this regard. MusikAnimal (WMF) (talk) 23:45, 18 January 2022 (UTC)
  • The rewording of the wish changed its nature. The original wish was not to track a reader's movement through an article as the current wording suggests. The problem, as I see it, is that article editors are blind to the statistical patterns of reader access: including time and order. In the case of your example, if 90% of the readers of that article on a music artist jump straight to the discography section, would that not be useful information for article editors to help reorganize the article, for example by putting the discography section first?

Voting

  • Support Support Meditating (talk) 19:14, 28 January 2022 (UTC)
  • Oppose Oppose: this information would be both informative and motivating to many editors in many situations, but this is outweighed by privacy (and possibly performance) concerns. We should be proud about not collecting this sort of intrusive analytic data. — Bilorv (talk) 20:35, 28 January 2022 (UTC)
  • Oppose Oppose: There would be a performance hit from such analytics. Wikipedia doesn't need this anyway - let's strive to have excellent articles, not just excellent sections. --Šedý (talk) 11:24, 29 January 2022 (UTC)
  • Support Support Zeleni (talk) 18:46, 29 January 2022 (UTC)
  • Oppose Oppose telemetry C933103 (talk) 06:52, 2 February 2022 (UTC)
  • Oppose Oppose KingAntenor (talk) 07:18, 2 February 2022 (UTC)
  • Support Support Prof.Flip (talk) 14:07, 3 February 2022 (UTC)
  • Support Support Obviously it would need to be implemented in a privacy-conscious way, but I think more information could help with article decisions Ph03n1x77 (talk) 07:07, 5 February 2022 (UTC)
  • Oppose Oppose We already have that idea Thingofme (talk) 13:21, 5 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 19:16, 6 February 2022 (UTC)
  • Support Support ZellmerLP (talk) 18:50, 10 February 2022 (UTC)
  • Oppose Oppose Encyclopaedia, not blog — DaxServer (t · c) 12:22, 11 February 2022 (UTC)
  • Oppose Oppose Nice to have if I was a product manager but since I'm an user, I oppose to user-tracking. --Valerio Bozzolan (talk) 16:45, 11 February 2022 (UTC)

Chat client

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

  • Problem: Communicating about smaller things or conversations that require frequent back-and-forth are time-intensive and annoying to conduct on Talk pages. As a result, communities have been set up on other platforms like Discord and Telegram to conduct these types of conversations. All wiki conversations should conducted and centralized on their wiki for openness and collaborative efficiency, but because of the current lack of communication methods they are not and have moved to different platforms.
  • Proposed solution:
    • A chat client that can be accessed on any wiki page through a button at the upper right by your profile icon that opens a chat dialog box where you can access all of the chats you are subscribed to. The client will also have its own dedicated page so that you can keep it open in a separate tab. Realtime notifications could be enabled.
    • Chats will be derived from containers present on talk pages. For example, a talk page will have a normal Wikitext container and then a chat container (maybe one after the other or side-by-side?). The chat container will house a custom client that shows a list of active and previous chats for that page and allows users to start a new chat about a topic or subscribe to one just like current talk pages. Once created or subscribed-to, these chats will be realtime/live-updating and able to be accessed from the chat client when you are away from the talk page.
    • Chats will be structured in a thread-like format. Every response to the last message sent by another user will be by-default considered a reply to that message or series of messages unless a specific message or series of messages is selected to be replied to. This way, chats can be converted into Wikitext conversations if-wanted and vice-versa. If the topic changes from what was originally being discussed, a message can be marked as the starting point for a new chat. That message will create a new chat on its page (or could even be moved to another) to indicate to other editors it is a new topic, but will still remain a continuation of the chat it was derived from.
    • Chats would primarily be enabled on personal and community talk pages like User, WikiProject, and wiki-encompassing talk pages, but not article pages.
    • Chats will not replace Wikitext conversations. Wikitext conversations are beneficial for topics that require the attention and input of an entire community that would see a talk page. They act as a permanent notice and community forum, rather than a chat where points mentioned by users in a conversation can quickly disappear. For example, discussions about changing something fundamental about a WikiProject would be appropriate for a Wikitext conversation.
    • Continuous non-thread-like-chats may want to be created to provide a fun off-topic place for editors to converse. That way we don't have to rely on Discord for that either.
  • Who would benefit: All editors.
  • More comments: See also Wikimedia Social Suite. This is a set of communication services hosted by Wikimedia itself including chat services like Mattermost, Rocketchat, and Zulip. This proposal is different in that it seeks to build an on-wiki centralized chat service.
  • Phabricator tickets:
  • Proposer: Lectrician1 (talk) 07:56, 11 January 2022 (UTC)

Discussion

It seems like this would require a lot of Wikipedia's resources (making a bespokse chat client is hardly a small task) for something that is already solved by users using Discord or Telegram. I don't think an additional on-site chat client will stop users prefering to use Discord and Telegram either. --//Lollipoplollipoplollipop::talk 09:39, 11 January 2022 (UTC)
The convenience of having a chat on-site and accessible while editing would be extremely convenient. New users wouldn't even have to search for if a Discord server exists for a Wiki because an available chat client would be right there and you could easily connect with any Wiki user you want to, without having to worry whether they are on Discord or not. Therefore, I think users would totally use this over Discord and Telegram, even if it wasn't as feature-rich.
This would require quite a bit of resources to implement, however tools similar to this like Structured Discussions can be used as a baseline technologies for demonstrating that non-wikitext thread-like chats can work and exist. Really, the key infrastructure that will require work will be connecting users live and connecting of them in groups. Lectrician1 (talk) 13:14, 11 January 2022 (UTC)
  • Some ideas for this are at Wikimedia Social Suite. Blue Rasberry (talk) 21:35, 11 January 2022 (UTC)
    Even more information is at Live Chat System which I ran across doing research for something else. –MJLTalk 20:14, 13 January 2022 (UTC)
  • Does the existing web client for IRC already resolve this mostly? Example: #wikimediaconnectxaosflux Talk 14:20, 12 January 2022 (UTC)
    Would normally be in another browser tab, but certain browsers have the ability to "float" a tab and make it "on top" of other things. — xaosflux Talk 14:21, 12 January 2022 (UTC)
    @Xaosflux IRC can't conveniently work because it is not linked to Wikimedia account. Lectrician1 (talk) 18:54, 13 January 2022 (UTC)
    @Lectrician1: why not? (1)IRC doesn't require registration to use at all, (2) Most Wikimedia projects don't require "an account" at all either. — xaosflux Talk 19:03, 13 January 2022 (UTC)
    @Xaosflux The problem is that you cannot directly identify users. Also, IRC would not allow for people to create new chat topics for a page like I described in the proposal since IRC only has channels (unless you want to set up a server for every page that has a chat container). You also don't have the ability to create threads or ping users. It would be much better to create a MediaWiki-based chat extension that gives us the ability to implement and have full control over such features. Lectrician1 (talk) 19:34, 13 January 2022 (UTC)
    "threads", "ping users" - this doesn't sound like "chat" anymore - this sounds like a discussion page! — xaosflux Talk 19:49, 13 January 2022 (UTC)
    Pinging users came after IRC did, as did wiki use of the term 'threads' from forum boards, email, and Usenet. ;) Izno (talk) 22:20, 18 January 2022 (UTC)
  • This would be particularly useful for adding interactive sessions to Wikiversity. In a traditional classroom setting students ask the instructor questions, and discussions among students are often held as part of the class. This is an important learning mode that is absent from Wikiversity. If a chat room was readily available to students, linked from a specific course that would be helpful. Additional features that could allow a discussion leader to announce a time and place for a discussion session or seminar would make this even more useful. Thanks! --Lbeaumont (talk) 15:00, 12 January 2022 (UTC)
  • If adding a chat, it would be a good idea to use an existing standardized protocol for such a chat, like IRC, XMPP or Matrix. --Tengwar (talk) 01:00, 13 January 2022 (UTC)
+1--Max schwalbe (talk) 10:04, 23 January 2022 (UTC)
  • @User:Redrose64 you might be interested in this based on your views about Discord. Lectrician1 (talk) 05:26, 13 January 2022 (UTC)
  • I think this is very useful and will benefit everyone. Especially the commment about wikiversity is a compelling argument imo. -Gifnk dlm 2020 Happy New Year 🎄❄️⛄️🎇 (talk) 17:48, 13 January 2022 (UTC)
  • Could be implemented by running a Mattermost or Rocket.Chat instance (and setting up authentication against Wikimedia OAuth or equivalent). There also is Phabricator Cohpherence live chat, T127640, "we use Zulip for GSoC and Outreachy participants." --Gryllida 20:55, 13 January 2022 (UTC)
    @Gryllida We actually already have those chat service instances running. See Wikimedia Social Suite.
    This proposal seeks to establish an on-wiki chat system as a centralized and more-convenient solution. Lectrician1 (talk) 04:10, 14 January 2022 (UTC)

What's so terrible about w:Wikipedia:Discord? A lot of folks are in this server, and there's (optional) verification via OAuth -FASTILY 08:08, 14 January 2022 (UTC)

@Fastily I love the Discord too, but wouldn't a chat on-wiki that would be faster to use, public and available to everyone, and allow you contact anyone with a wiki account be a better solution? I don't think anyone thinks that the community being fragmented in communication among the various chat platforms and talk pages is a good thing. If a MediaWiki extension was made, all Wikimedia projects and all MediaWiki wikis could utilize it too. Lectrician1 (talk) 13:04, 14 January 2022 (UTC)
Getting DMs via MediaWiki while editing feels oddly invasive, and it's certainly not something I'd want enabled by default. "Fragmentation", which I'm still not convinced is an actual issue, could be remedied by simply declaring Discord to the be the official platform for chat. -FASTILY 23:27, 14 January 2022 (UTC)

I'm in general against a chat feature. User A: "In chat, user B has called me a stupid idiot. Block them!" WM projects are not chat rooms and I consider these being out of scope. New projects enwikichat, dewikichat, frwikichat, eswikichat? No, IRC as is now is sufficient. --Achim55 (talk) 19:44, 17 January 2022 (UTC)

@Achim55

User A: "In chat, user B has called me a stupid idiot. Block them!"

Judging by how this rarely happens on any of the chat platforms currently used by the community or talk pages, I doubt this would happen. People tend to communicate more respectfully when everything they say is public. Though, I do understand the concern - I just don't think it will manifest itself.

WM projects are not chat rooms and I consider these being out of scope. New projects enwikichat, dewikichat, frwikichat, eswikichat? No, IRC as is now is sufficient.

If IRC was sufficient, everyone would use it. Barely anyone does on the English Wikipedia compared to the Discord server. There's clearly a demand for a chat service. Making it centralized on-wiki will mean people won't "miss out" and everyone can see what everyone is talking about. Also, new projects "enwikichat, dewikichat, frwikichat, eswikichat" is not how this will work. Please read the proposal above. Lectrician1 (talk) 21:10, 18 January 2022 (UTC)
Existing chat platforms aren't advertised widely. You're proposing to put this in a prominent location for every person who views/edits the website. Izno (talk) 22:22, 18 January 2022 (UTC)

Hey everyone, thanks for taking the time to write this wish and for the discussion! Adding chat functionality would be out of scope for our team due to technical and design complexity. There are strong cases to be made for including chat and for not including that functionality. We are moving this wish to Larger Suggestions instead of the Archive since we still believe there is value in voicing this as an idea and letting the conversation grow accordingly. Thanks and regards, NRodriguez (WMF) (talk) 00:58, 19 January 2022 (UTC)

I think a reasonable alternative (as the Wikimedia movement trying to develop its own chat client would be an immense waste of resources) would be to integrate an existing chat system so that you can interact with it from a wiki page (maybe from a messenger popup, similar to e.g. Intercom; maybe from a container that can be embedded in the content). I have been looking into that lately and I think Matrix provides a solid foundation for it, with an open and fairly flexible community-stewarded protocol, the ability to provide our own identity services while being connected to a global network, and some existing (not great but functional) web integrations (like the ones used here or here). --Tgr (talk) 21:52, 23 January 2022 (UTC)

  • Modding this would be completely implausible - the Discord (where I am a mod) has a vastly higher dominance of experienced editors than the general project would. Additionally, we don't use IRC because it's not user-friendly enough for our purposes. I consider it unlikely that the WMF is going to make a client that viably competes with Discord on those grounds. Nosebagbear (talk) 11:32, 24 January 2022 (UTC)

I could imagine finding this useful, but I wouldn't make it a priority. In particular, I hang out on a smaller Wikipedia where we haven't yet been overwhelmed with the amount of discussion on talk pages. A. Mahoney (talk) 18:53, 31 January 2022 (UTC)

Voting

  • Very Strong support Strong support will be very useful to be able to have instant chats. Someone has suggested they can be used to have lessons for wikiversity courses. I agree with this compelling argument, it will be possible to set a scheduled 90 min chat as a lesson, and it’s content will be archived for people in the future willing to learn that lesson. In Israel, there are groups in WhatsApp with scheduled lessons and a teacher for high school students and it’s useful and works, so there’s no reason such an idea won’t. Also the creator of the course will be able to verify his identity easily because it will be using the same account system. There’s no reason modding this will be different from modding talk pages, actually it will be easier because users won’t be able to vandalise other comments, and their comments will be signed automatically. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 18:17, 28 January 2022 (UTC)
    • Before someone asks, using the proposed client for lessons will be better than WhatsApp or discord chat since the archive is in wikiversity and can be linked in the course main page. Users will be able to learn from the questions of previous people. In order to avoid abuse, only users with a special permission will be able to schedule chats. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 18:32, 28 January 2022 (UTC)
      • If approved it will be able to do something previously impossible with courses in wikiversity. This definitely can’t be done with regular talk pages so previously the only way was to use other platforms. With this proposal, it will be possible to have lessons on wikiversity and then the lessons will have a public archive in wikiversity for people in the future to learn from the questions of people in the past. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 19:15, 28 January 2022 (UTC)
        • Not to mention how useful it will be for user groups that will not have to use external platforms anymore. -Gifnk dlm 2020 From Middle English Wikipedia 📜📖💻 (talk) 21:57, 1 February 2022 (UTC)
  • Support Support Would be useful to be able to chat on-wiki, rather than having to install third-party tools to do so. Ideally should include public logging to the talk page afterwards. Telegram seems to have become particularly popular this last year, sadly, even though it's completely closed and non-transparent. Thanks. Mike Peel (talk) 18:59, 28 January 2022 (UTC)
  • Oppose Oppose Wikimedia is not a social network. * Pppery * it has begun 19:00, 28 January 2022 (UTC)
  • Support Support Bristledidiot (talk) 19:07, 28 January 2022 (UTC)
  • Support Support Finally I can chat with people to coordinate edits or permission to edit specific pages in which otherwise I would be unable to edit. Rzzor (talk) 19:52, 28 January 2022 (UTC)
  • Oppose Oppose A can of worms. Xn00bit (talk) 20:15, 28 January 2022 (UTC)
  • Support Support Sea Cow (talk) 23:53, 28 January 2022 (UTC)
  • Support Support Izno (talk) 00:17, 29 January 2022 (UTC)
  • Oppose Oppose per my previous comment --//Lollipoplollipoplollipop::talk 09:53, 29 January 2022 (UTC)
  • Oppose OpposeElioPrrl (talk) 15:34, 29 January 2022 (UTC)
  • Support Support daSupremo Diversity icon red.svg 04:30, 31 January 2022 (UTC)
  • Support Support Ajshul (talk) 22:40, 31 January 2022 (UTC)
  • Support Support Amirh123 (talk) 12:37, 1 February 2022 (UTC)
  • Oppose Oppose KingAntenor (talk) 07:19, 2 February 2022 (UTC)
  • Neutral Neutral Wikipedia is not a web host, social media. However Wikipedia has some IRC discussion channels, and we have Convenient Discussions by Jack who built the house: c:User:JWBTH/CD Thingofme (talk) 13:22, 5 February 2022 (UTC)
  • Support Support Some people still have not understood that Wikipedia is also a social network since it's inception. That's how it initially developed, and a significant part of new users come precisely from the social network part of it (either on Telegram, Facebook, wherever. It would be really great to have a native platform to chat with each other, instead of relying in 3rd-party stuff. - Darwin Ahoy! 15:01, 5 February 2022 (UTC)
  • Support Support MaksOttoVonStirlitz (talk) 03:41, 6 February 2022 (UTC)
  • Support Support Actorsofiran (talk) 19:09, 6 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 19:17, 6 February 2022 (UTC)
  • Oppose Oppose First, a chat client would lead more people to use it for purely social purposes. The temptation is always there. Second, I have always been proud of our insistence that we make people write and memoralize what they say in on-wiki discussions so that there is a record of decisionmaking for anyone to examine. It may be cumbersome by today's standards but it keeps us honest at a time when we need to be. Daniel Case (talk) 03:29, 8 February 2022 (UTC)
  • Oppose Oppose Wikimedia is not a social media. Veracious (talk) 06:50, 9 February 2022 (UTC)
  • Support Support ZellmerLP (talk) 19:00, 10 February 2022 (UTC)
  • Support Support Jl sg (talk) 08:55, 11 February 2022 (UTC)
  • Oppose Oppose Encyclopaedia, not social media. There's a Special:Email which you one can use — DaxServer (t · c) 12:44, 11 February 2022 (UTC)
  • BA candidate.svg Weak oppose OpenStreetMap has a very nice way of recommending nearby communities (chats, mailing lists, local groups) when you are in edit mode. I think that could be a generic solution. --Valerio Bozzolan (talk) 16:52, 11 February 2022 (UTC)

Show Abusefilter changes in watchlists

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

  • Problem: Currently, there is no way to monitor for changes to specific AbuseFilters without going directly to the filter itself and viewing the history of changes. They cannot be not shown in watchlists like other pages can.
  • Proposed solution: Show the Special:AbuseFilter/history on the user's Special:Watchlist like deletion, page move, etc.
  • Who would benefit: AbuseFilter managers
  • More comments:
  • Phabricator tickets: phab:T62588 (declined), phab:T227595
  • Proposer: aokomoriuta (talk) 01:45, 12 January 2022 (UTC)

Discussion

Voting

Page merge and fork

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

  • Problem: MediaWiki doesn't allow page merge and fork. Editors have to copy-paste content manually, edit history is lost. Edit history can be merged via deleting, but it leads to unreadable mess.
  • Proposed solution: Extension to enable merge and fork features like a version control system.
  • Who would benefit: editors
  • More comments:
  • Phabricator tickets: T113004
  • Proposer: Abiyoyo (talk) 23:44, 18 January 2022 (UTC)

Discussion

  • This is probably too large for the team. --Izno (talk) 05:09, 20 January 2022 (UTC)
  • Most likely, but I'll share my thoughts anyway: it seemingly wouldn't be too hard to have a Special:ForkPage for instance that simply copies the revisions to a new page. However they would of course be new revision IDs, and that brings up the question of what to do about timestamps. Do we use the original timestamps? That seems weird because those edits to the new page weren't actually made at the same times as the original edits. Finally, this feature could be abused. How bad does it make me look if you forked edits I made and put them under some inappropriate title? Food for thought.
  • Judging by the size of phab:T113004, I'm definitely going to say this is out of scope for us, but I will move it to our Larger suggestions category so the idea doesn't get suppressed in the archives. Best, MusikAnimal (WMF) (talk) 23:27, 20 January 2022 (UTC)
  • Forking involves some copyright concerns. Allowing page history to be a DAG instead of strictly linear seems not super hard in terms of backend implementation, but how do you display merges and forks to the user? It would be a massive project (although potentially quite valuable to support offline editing and FlaggedRevs style functionality where contributions can be on a "side branch" until they get reviewed; of course there are many ways that could go wrong). Tgr (talk) 21:59, 23 January 2022 (UTC)
    I don't think there are actually copyright concerns :) Just interface clarity concerns. –SJ talk  23:56, 23 January 2022 (UTC)
    Well, if you "continue" the page history in the forked page in some way, there are copyright issues to deal with. If you duplicate the page history, there aren't, but then there will be duplicated edits in user contributions, inflated edit counts etc. Tgr (talk) 02:35, 24 January 2022 (UTC)
  • A full merge/fork tool is hard. But an interface for the current process (single-edit fork or merge, appropriate defaults for the edit summary) seems possible. I don't think you need to copy any revisions at all, just provide an interface that makes it easy to see them all in one history page or to compare revisions across the different article titles [something already possible if you know both article-revision-IDs]. –SJ talk  23:56, 23 January 2022 (UTC)

Voting

  • Support Support Izno (talk) 00:17, 29 January 2022 (UTC)
  • Support Support Shizhao (talk) 04:09, 29 January 2022 (UTC)
  • Support Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:39, 29 January 2022 (UTC)
  • Support Support Hemantha (talk) 16:06, 29 January 2022 (UTC)
  • Support Support Aca (talk) 16:13, 29 January 2022 (UTC)
  • Support Support —— Eric LiuTalk 18:27, 29 January 2022 (UTC)
  • Support Support Jklamo (talk) 19:24, 29 January 2022 (UTC)
  • Support Support Douglasfugazi (talk) 21:23, 29 January 2022 (UTC)
  • Support Support Gusfriend (talk) 00:06, 30 January 2022 (UTC)
  • Support Support A1 (talk) 09:00, 30 January 2022 (UTC)
  • Support Support Titore (talk) 19:20, 30 January 2022 (UTC)
  • Support Support Maro mich (talk) 22:00, 30 January 2022 (UTC)
  • Support Support Libcub (talk) 01:17, 31 January 2022 (UTC)
  • Support Support daSupremo Diversity icon red.svg 04:32, 31 January 2022 (UTC)
  • Support Support JAn Dudík (talk) 21:42, 31 January 2022 (UTC)
  • Support Support KingAntenor (talk) 07:19, 2 February 2022 (UTC)
  • Support SupportMarcoAurelio (talk) 16:00, 2 February 2022 (UTC)
  • Support Support YBG (talk) 07:44, 3 February 2022 (UTC)
  • Support Support WikiAviator (talk) 16:07, 3 February 2022 (UTC)
  • Support Support Betseg (talk) 08:38, 4 February 2022 (UTC)
  • Support Support Gonnym (talk) 22:00, 4 February 2022 (UTC)
  • Support Support Thingofme (talk) 14:00, 5 February 2022 (UTC)
  • Support Support Lectrician1 (talk) 05:26, 6 February 2022 (UTC)
  • Support Support Uanfala (talk) 22:45, 9 February 2022 (UTC)
  • Support Support Glerium (talk) 00:00, 10 February 2022 (UTC)
  • Support Support β16 - (talk) 10:49, 10 February 2022 (UTC)
  • Support Support Great idea, but might be impossible to implement. TheFrog001 (talk) 14:59, 10 February 2022 (UTC)
  • Support Support Marcok (talk) 13:08, 11 February 2022 (UTC)
  • Support Support Nice to have to create new sandboxes. Maybe as user gadget. This would help in respecting copyrights, since most of the time an user just copy-pasta the content without leaving any information in the destination subject entry (so no way to go back to the original permalink or to the original page or to the original history). Valerio Bozzolan (talk) 16:57, 11 February 2022 (UTC)

Show navbox templates on mobile

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

  • Problem: When I use the mobile version I can't see the navigation templates, such as en:Template:Theatres in London.
  • Proposed solution: Show a compact version of navigation templates on mobile pages.
  • Who would benefit: It would make it easier to reach other pages, in particular when someone is not sure about the title of the page.
  • More comments:
  • Phabricator tickets: phab:T124168
  • Proposer: Esc0fans (talk) 06:50, 11 January 2022 (UTC)

Discussion

  • The blockers for this are well understood. 1. Navboxes are too large. they are very verbose and are huge contributors to pagesize. This is a solvable problem with lazy loading, but that does require significant engineering. 2. Navboxes are tables that don't work nicely on mobile devices, the UI concept needs work 3. Navboxes are mostly used by editors, not by readers (so lots of burden to benefit just a few). I would however love to see the design department simply EXPLORE this topic, come up with interaction ideas for people with this content. We really need a vision for this stuff, not just someone to flip a toggle and make these things visible on mobile. —TheDJ (talkcontribs) 10:17, 13 January 2022 (UTC)
    • TheDJ, Please clarify lazy loading, Does it mean only loading when actually needed, like if you click on expand? Cheers, · · · Peter (Southwood) (talk): 08:44, 14 January 2022 (UTC)
      Yes it means only downloading the content after engaging with some part of the UI to indicate you want the content. (not like expand now, because that shows you something that was already downloaded). —TheDJ (talkcontribs) 09:09, 14 January 2022 (UTC)
      Most navboxes are text-only. The larger ones with more complex styles might be a few dozen KB large but I doubt they would be as large as a single image, in term of data needed to be transfer. If those few KBs are of concern then I think a check box for user to opt out of such feature would already be sufficient. C933103 (talk) 08:00, 16 January 2022 (UTC)
      The Covid 19 navboxes were 2MB at some point. On most covid pages, they were half the page load and for some smaller articles the covid navboxes were more bytes than the entire article. Of course that is a pretty extreme example, but navboxes are much larger than ppl think (because they are collapsed ppl don't really think about them). Regardless, MediaWiki has to take extreme cases as the default. If it can happen, it will happen, because its user generate content. —TheDJ (talkcontribs) 10:08, 19 January 2022 (UTC)
    I think many readers also use navbox. Like even when I am not in a mode or mood of editing Wikipedia, I would still frequently use the navbox to check out what are some other related pages or topics that could contain information I might want to see or need to find. This definitely benefit readers. And I think a simple table is enough, as long as the table can be allowed to scroll horizontally. C933103 (talk) 22:41, 15 January 2022 (UTC)
  • I fully support adding navboxes on mobile web and apps. They are an important part of Wikipedia and the reading experience is impoverished without them. Do you have any empirical evidence, like from usage studies, for the claim that "Navboxes are mostly used by editors, not by readers"? It seems highly dubious to me. --Albany NY (talk) 04:49, 16 January 2022 (UTC)
    If we want to talk about dubious, that navboxes are used at all by any significant proportion of anyone is dubious. :) --Izno (talk) 06:12, 18 January 2022 (UTC)
All I know is that I use them frequently and find them a helpful way to learn about a topic. But I don't think it's wise for any of us to make claims about how people in general use Wikipedia without evidence from usage studies. --Albany NY (talk) 19:44, 18 January 2022 (UTC)
There definitely are some studies on this, I've seen them at Wikimania in the past. But finding them back is really hard. the search terms are so common... If anyone can find them, I'd love it. —TheDJ (talkcontribs) 10:23, 19 January 2022 (UTC)
  • phab:T124168 goes into all the detail, but in short: there are many concerns about blanket-enabling all navboxes on mobile. They can potentially contains enormous amounts of markup and visually consume a lot of space, which is problematic for mobile users. This is proposal is certainly out of scope for the Community Tech team, but we know it's a long-desired feature for some, so we will move it to our Larger suggestions category so it can be discussed further with the community. Thanks for participating in the survey, MusikAnimal (WMF) (talk) 23:54, 20 January 2022 (UTC)

Voting

  • Support Support * Pppery * it has begun 19:00, 28 January 2022 (UTC)
  • Support Support Long overdue. Thanks. Mike Peel (talk) 19:02, 28 January 2022 (UTC)
  • Support Support --MSY-07 (talk) 20:29, 28 January 2022 (UTC)
  • Support Support. Thryduulf (talk: meta · en.wp · wikidata) 20:37, 28 January 2022 (UTC)
  • Support Support , particularly in the sense TheDJ mentioned of providing a vision. We need this to help make editorial decisions, like whether or not to discourage see also links that are also in a navbox. If we don't know what Wikipedia in 2030 will be like, we can't plan to build it. {{u|Sdkb}}talk 04:09, 29 January 2022 (UTC)
  • Support Support 𝑇𝑚𝑣 (𝑡𝑎𝑙𝑘) 07:39, 29 January 2022 (UTC)
  • Support Support per Sdkb. Some half-solution like only loading navboxes of < n kB would likely be a 95%+ fix to this problem. — Bilorv (talk) 16:08, 29 January 2022 (UTC)
  • Support Support Aca (talk) 16:13, 29 January 2022 (UTC)
  • Support Support —— Eric LiuTalk 18:27, 29 January 2022 (UTC)
  • Support Support Zeleni (talk) 18:50, 29 January 2022 (UTC)
  • Support Support --NGC 54 (talkcontribs) 23:14, 29 January 2022 (UTC)
  • Support Support Titore (talk) 19:21, 30 January 2022 (UTC)
  • Support Support JPxG (talk) 01:09, 31 January 2022 (UTC)
  • Strong support Strong support Long overdue. PorkchopGMX (on the go) (talk) 18:28, 31 January 2022 (UTC)
  • Support Support Mbkv717 (talk) 20:15, 31 January 2022 (UTC)
  • Support Support Malarz pl (talk) 21:11, 31 January 2022 (UTC)
  • Support Support JAn Dudík (talk) 21:45, 31 January 2022 (UTC)
  • Support Support Szymonel (talk) 13:40, 1 February 2022 (UTC)
  • Support Support Msz2001 (talk) 14:31, 1 February 2022 (UTC)
  • Support Support Serg!o (talk) 11:33, 2 February 2022 (UTC)
  • Support Support — MrDolomite • Talk 05:27, 3 February 2022 (UTC)
  • Support Support YBG (talk) 07:44, 3 February 2022 (UTC)
  • Support Support Betseg (talk) 08:38, 4 February 2022 (UTC)
  • Support Support Ninepointturn (talk) 16:48, 4 February 2022 (UTC)
  • Support Support Valid concerns in the comments, but a great feature to be explored Ph03n1x77 (talk) 07:09, 5 February 2022 (UTC)
  • Support Support Thingofme (talk) 14:07, 5 February 2022 (UTC)
  • Support Support --Tinker Bell 05:54, 6 February 2022 (UTC)
  • Support Support Daniel Case (talk) 03:30, 8 February 2022 (UTC)
  • Support Support  dima_st_bk 11:16, 8 February 2022 (UTC)
  • Support Support Uanfala (talk) 22:51, 9 February 2022 (UTC)
  • Support Support --evrifaessa (talk) 16:33, 11 February 2022 (UTC)

Add more real-time features to MediaWiki

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

  • Problem: Other than the Watchlist which supports live updates, MediaWiki is severely in lacking AJAX-based real-time features, making it rather painful to participate in discussions where new comments are being made in quick succession, among other issues.
  • Proposed solution:
    • Echo alerts and notifications should automatically refresh without a reload/navigation being required – so that users are notified in real-time when discussions they are following have new messages, or when they are pinged. (phab:T34284)
    • Browser-based push notifications should be implemented for Echo alerts and notifications – so that users are notified even if they just have Wikipedia open in one tab but are working on something else. (phab:T113125 / phab:T276409)
    • On talk pages, visual indicators like "There are x new comments in this section. Click to reload" could be added (this is currently provided by Convenient Discussions gadget, but could be made more broadly available)
    • Page history could show an indicator if new edits are made to the page while user is viewing. (phab:T298419)
    • While viewing the latest diff or permalink of a page, if a new edit is made, there could be a indicator that the content is no longer current. (phab:T295225)
    • Create an abstraction (such as via polling or EventStreams or WebSockets) that can be used to implement all of the above. It will also empower extension developers to integrate similar features. (phab:T146032?)
  • Who would benefit: All MediaWiki users
  • More comments:
  • Phabricator tickets:
  • Proposer: SD0001 (talk) 07:01, 11 January 2022 (UTC)

Discussion

  • I general, broad proposals like these are good for support votes, but in my experience will get rejected as too big/unspecific by the team. I'd just split it in these individual features you gave as an example. —TheDJ (talkcontribs) 13:04, 12 January 2022 (UTC)
    This approach was suggested by @Trizek (WMF) in phab:T294382#7474807. The main part would be coming up with a generic framework for real-time notifications, after which the implementation of specific use-cases mentioned above could be left for other teams or volunteers. SD0001 (talk) 03:44, 13 January 2022 (UTC)
    @SD0001 THAT is the line you should start that proposal with, in my opinion. Not just all the features that it will (eventually) unblock (because those are not all gonna be delivered within a single wishlist project, not possible). —TheDJ (talkcontribs) 11:01, 13 January 2022 (UTC)
    FYI, I wasn't aware of the scope of this year's survey when I wrote my comment on Phabricator. Trizek (WMF) (talk) 12:30, 13 January 2022 (UTC)
    Hello there, and thanks for your proposal! As TheDJ mentioned (Thank you @TheDJ!) this is a larger ask in nature, and unfortunately while it's a collection of sound ideas, they're too big for our team. We still believe in the importance of letting other participants indicate the extent to which they support this. We are therefore moving this to Larger Suggestions rather than the Archive. Thanks, NRodriguez (WMF) (talk) 13:00, 21 January 2022 (UTC)
  • Have you tried UpdateNotifications and livenotifications? NguoiDungKhongDinhDanh 16:09, 26 January 2022 (UTC)

Voting

Add support for making some templates directly "visually editable" in VisualEditor

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

  • Problem: In VisualEditor, editing templates such as an infoboxes or an episode table of a series, etc., can be more tedious than it appears. In order to change the values of the template, you have to first open the template editing dialog. It would be easier if the infobox was directly editable visually, without the need for a dialog.
  • Proposed solution: Add support for making some templates directly "visually editable" as if they were tables
  • Who would benefit: Editors who use VisualEditor
  • More comments:
  • Phabricator tickets: task T52182
  • Proposer: Mohammad ebz (talk) 15:09, 11 January 2022 (UTC)

Discussion

  • @Mohammad ebz: Could you link to some example templates you believe are not supported? I highly suspect all that's missing is the TemplateData. This is what instructs VE and TemplateWizard what fields are available and what kinds of values they accept. Only the community can implement this. It's pretty easy though; just go to the documentation page for the template and hit edit, then you should see a "Manage TemplateData" button at the top-left. MusikAnimal (WMF) (talk) 20:03, 11 January 2022 (UTC)
    @MusikAnimal (WMF): I mean, do not open another page and edit it in the same way as regular text that is edited in Visual Editor mode. In fact, the idea is to edit the text and template information directly and visually, without the need to enter information in the window that opens. Mohammad ebz (talk) 04:42, 12 January 2022 (UTC)
    @Mohammad ebz Okay, I think I may be on to you now: You're saying some templates are transcluded on a page, and you have to go to that template page to edit it, when you'd rather be able to edit it directly from the article. Is that right? It would be still be helpful if you could give an example. Link to a specific article with this problem, and let us know which template you're unable to edit. (or whatever the issue is, if I'm still misunderstanding you :) MusikAnimal (WMF) (talk) 04:46, 12 January 2022 (UTC)
    @MusikAnimal (WMF): You still do not understand what I mean, let me give you an example: Suppose you want to modify an actor's infobox on his Wikipedia page. To do this, click on the word "edit" at the top of the article, then select Visual Editor mode and then click the actor's infobox, Now a floating page opens, I mean this page; If the last step is removed and the template contents are edited completely Visual like the original text of the article, the editing speed will be much faster. Mohammad ebz (talk) 05:08, 12 January 2022 (UTC)
    Yes! That explains it perfectly, thank you :) I might recommend using what you just wrote as the problem statement. Your proposal says …has the problem of opening additional pages and is the same as a source editor which made it sound like you meant opening new pages in a separate tab. This "page" is what we would call a dialog or modal window.
    Anyway, I'm afraid what you're after may not feasible. Without having done any sort of technical investigation, a few issues that come to mind:
    • Templates can have logic in them that make them appear differently based on values you give them. This would offer a very weird experience, say if the value of one field is supposed to make other fields disappear. That would be confusing if this happened in real time. This is the same reason you may notice sometimes that after applying your changes to a template, there's a brief time where it's still "loading" (in the processing of applying them). This is the parser doing its thing.

      You did mention specifically "commonly" used templates, which are generally more predictable, but there's still no guarantee their behaviour won't ever change in a way we could reliably predict in VisualEditor.

    • What if you want to add or remove parameter to the template?
    • What about templates that pull their data from Wikidata?
    Honestly, I think our upcoming Real Time Preview for Wikitext feature might help you in this situation. Yes, it's for wikitext (not VisualEditor), but it solves your problem of having to edit both visually and in wikitext. With Real Time Preview, you see what you're going to get when you save (just like VisualEditor). If you're like me and love VisualEditor, the current template editing dialog that is shown may be what you have to get used to. I personally find it better because it also allows the parameters to be documented and ensure the editor knows what each field is intended for, etc. (what they call TempalteData).
    You also mentioned tables. Some tables are built using a template, but any raw wikitext table such as in this example should be editable directly with VisualEditor.
    That's my opinion, and at the very least I would say this is out of scope for Community Tech. Let's see what others have to say. MusikAnimal (WMF) (talk) 05:47, 12 January 2022 (UTC)
    @Mohammad ebz Our team has concluded this wish is out of scope for us. However we're happy to promote it in the Larger suggestions category, which is intended to promote ideas to other WMF teams and the broader Foundation, rather than it being buried in our archives of rejected proposals.
    However I think the proposal could be reworded better to describe what you're after. Now I understand what you're after, would you mind if I reword your proposal some? Then after you approve, I will move it to Larger suggestions. Thanks, MusikAnimal (WMF) (talk) 04:08, 18 January 2022 (UTC)
    In my opinion, no problem, do your best to get a better result, my only suggestion was to improve the editing on Wikipedia; In any case, thank you for your attention Mohammad ebz (talk) 07:23, 18 January 2022 (UTC)
    Okay, thanks for clarifying! I will move this to Larger suggestions. I have also tweaked the wording to make the proposal more clear. Hope this okay! Thanks, MusikAnimal (WMF) (talk) 23:10, 20 January 2022 (UTC)
  • By Community Tech scale, it would be too much to do so in one year. This is a very big proposal, which means it could change all the items and how VisualEditor works. But I think it would make VE more friendly. Thingofme (talk) 13:13, 12 January 2022 (UTC)

Voting

  • Support Support * Pppery * it has begun 19:00, 28 January 2022 (UTC)
  • Support Support Iamthinking2202 (talk) 21:54, 28 January 2022 (UTC)
  • Support Support Izno (talk) 00:18, 29 January 2022 (UTC)
  • Support Support Helpful for those users who use mobile devices to edit Wikipedia. SSG123 (talk) 06:13, 29 January 2022 (UTC)
  • Support Support Aca (talk) 16:14, 29 January 2022 (UTC)
  • Support Support: VE is hugely inadequate in this area. — Bilorv (talk) 16:33, 29 January 2022 (UTC)
  • Support Support —— Eric LiuTalk 18:28, 29 January 2022 (UTC)
  • Support Support --NGC 54 (talkcontribs) 23:15, 29 January 2022 (UTC)
  • Support Support Tgr (talk) 00:50, 30 January 2022 (UTC)
  • Support Support Libcub (talk) 01:19, 31 January 2022 (UTC)
  • Support Support Trizek from FR 13:52, 31 January 2022 (UTC)
  • Support Support Lectrician1 (talk) 16:07, 31 January 2022 (UTC)
  • Support Support Browk2512 (talk) 01:24, 2 February 2022 (UTC)
  • Support Support Prof.Flip (talk) 14:02, 3 February 2022 (UTC)
  • Support Support WikiAviator (talk) 16:07, 3 February 2022 (UTC)
  • Support Support First of all, VisualEditor need to be implemented to documentation page and other testcases (TemplateData needs to be fixed) Thingofme (talk) 14:09, 5 February 2022 (UTC)
  • Support Support --Ciao • Bestoernesto 19:23, 6 February 2022 (UTC)
  • Support Support PtolemyXV (talk) 22:49, 7 February 2022 (UTC)
  • Support Support Daniel Case (talk) 03:31, 8 February 2022 (UTC)
  • Support Support TheFrog001 (talk) 15:00, 10 February 2022 (UTC)
  • Support Support Wikiusuarios (talk) 20:25, 10 February 2022 (UTC)
  • Support Support 4nn1l2 (talk) 14:15, 11 February 2022 (UTC)

Adapt MediaWiki to the needs of Wiktionaries

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

  • Problem: MediaWiki hasn’t been designed to make dictionaries or thesauri, to manage a distributed multilingual content, to interface lexicographical and semantics data and “sentence-plain” contents. The only improvement made to fix that point is Cognate extension, whereas many ones are needed so Wiktionaries can address their goals.
  • Proposed solution: Create a dedicated team, including a project manager to coordinate these efforts, a product owner in liaison with communities, a UI/UX engineer to design some propositions and to test them with readers and editors, developers to implement chosen improvements, a communication manager to cover this work and to assist the transformation of practices.
  • Who would benefit: All Wiktionary editors and readers, from all language communities.
  • More comments:
  • Phabricator tickets:
  • Proposer: Noé (talk) 15:50, 11 January 2022 (UTC)

Discussion

  • Clearly out of scope of Community Tech team. However, keeping only UX side, Community Tech could work on skin improvements and JavaScript features to redesign Wiktionary reading (facilitate browsing through sections — languages and subsections). The problem it would fix would be “It is hard for Wiktionary readers to find the information they look for in right language when they are on the right page.” --Pols12 (talk) 20:24, 11 January 2022 (UTC)
    Thanks for the translation. I'll keep it as such because the need is clear and broader than a reading issue. Moreover, your proposal is neat, it could be another wish. Noé (talk) 10:50, 12 January 2022 (UTC)