Wikipedia:Village pump (proposals)/Archive 176

English Wikipedia's 20th anniversary
Hello, January 15 is in two days. I see that 20 just has a redirect to Meta. Are there any plans to celebrate it here? --NaBUru38 (talk) 20:36, 13 January 2021 (UTC)
 * There was some talk on changing the logo for the day but they never gained much traction and ultimately fell through. Besides that, not much chatter has been going on about it on-wiki. — Wug·a·po·des​ 21:43, 13 January 2021 (UTC)
 * We should at least do something... ~ HAL  333  22:20, 13 January 2021 (UTC)
 * Well then, let's hope it snows. — Wug·a·po·des​ 22:40, 13 January 2021 (UTC)


 * Thanks for starting the RfC below. I wonder, will people clicking the logo on that date expect to be taken somewhere other than the main page? If so, do we have a decent target? WP:About certainly isn't ready, alas, but it'd be nice if we could use some of the buzz around this to direct readers toward trying out editing. Another thought is having a banner notice, or tying in the billionth edit. We're on a short timeline, though. &#123;{u&#124;  Sdkb  }&#125;  talk 23:32, 13 January 2021 (UTC)
 * Maybe History of Wikipedia? I don't know if it is written well enough to be "featured"... ~ HAL  333  23:42, 13 January 2021 (UTC)
 * Given that it's had a "needs update" banner at the top since 2018, prob. not. Maybe we could have it go to the Main page as normal, but put a variant of one of the banners like File:Wikipedia 20 cover confetti blue.png on the Main page. But that'd still leave the question of where, if anywhere, to point people who click on the banner. Maybe I'm just biased in favor of my own work, but I can't really think of any intro-esque project page other than Help:Introduction to Wikipedia that'd really be ready. &#123;{u&#124; Sdkb  }&#125;  talk 00:31, 14 January 2021 (UTC)
 * That would do too. ~ HAL  333  01:12, 14 January 2021 (UTC)
 * I like your suggestion of linking to a version of the main page with an anniversary banner, but would this be too technical to pull off in time? I'm not convinced about Help:Introduction to Wikipedia, as it's really for people who are already interested in contributing. Just toying with an idea here, but I've always been a fan of the 'Impact of Wikipedia' video, which provides an accessible, inspiring overview, if it could be somehow linked to. If none of these suggestions are practical then I think the normal main page link is best. Jr8825  •  Talk  12:02, 14 January 2021 (UTC)
 * , a main page banner wouldn't be that hard technically; I think the harder issue would be just garnering consensus. I like that video as well, and I'd be fine linking to it from the banner. Ideally we'd want it to autoplay, but alas that might not be possible. Give me a few minutes to experiment... &#123;{u&#124; Sdkb  }&#125;  talk 13:17, 14 January 2021 (UTC)
 * Does User:Sdkb/sandbox/Wikipedia:20th anniversary look something like what you envision? (It'd need attention from a CSS expert to get mobile display fully working.) To spell it out, we'd put a banner on the main page something like this, and clicking on it would lead to the page. &#123;{u&#124; Sdkb  }&#125;  talk 14:29, 14 January 2021 (UTC)
 * Since we're on such a short timeframe, I went ahead and made a section below. We'll see what folks think; it'll be nice if it succeeds, and worst case scenario we just get stuck with the normal main page. &#123;{u&#124; Sdkb  }&#125;  talk 15:25, 14 January 2021 (UTC)

Well, it seems as though there's quite a lot of active participation down below. Whatever the logo chosen, I believe it should stay for more than just one day - keep it for a week. Wilhelm Tell DCCXLVI converse &#124; fings wot i hav dun 02:03, 14 January 2021 (UTC)
 * I would support that. I remember the 6 million articles banner logo lingering for a week or so. ~ HAL  333  02:20, 14 January 2021 (UTC)


 * Lingering longer than a day sounds fine to me. &#123;{u&#124; Sdkb  }&#125;  talk 15:02, 14 January 2021 (UTC)
 * I'd be fine with up to a month. — xaosflux  Talk 15:44, 14 January 2021 (UTC)
 * A week or two sounds good to me. A month might get tired with the flashier option (D). —  The Earwig   talk 19:21, 14 January 2021 (UTC)
 * Two weeks would work well. ~ HAL  333  23:08, 14 January 2021 (UTC)


 * The WMF has a nice site set up at I'm spread incredibly thin at the moment, but you might want to check it out and see if that's a worthwhile target for the banner. — Wug·a·po·des​ 23:13, 14 January 2021 (UTC)
 * , oh wow, I feel silly for assuming that Wikipedia 20 was all there was and not thinking to check the foundation site. That's much more professional than anything we could create (my only quibble being that, alas as expected, it's more focused on getting you to donate than to edit, with the only path toward the latter being a tiny link to the Teahouse). The discussion below is unfortunately running into some disagreement about what the banner should look like, which at this late hour is probably going to result in there being nothing at all, but if we somehow find a way to get past that, pointing to the WMF page seems the way to go. &#123;{u&#124; Sdkb  }&#125;  talk 23:37, 14 January 2021 (UTC)
 * I'm trying to obtain the new video so we can switch to using that at WP:20th, but the WMF extremely frustratingly doesn't appear to have put it on Commons yet. &#123;{u&#124; Sdkb  }&#125;  talk 02:04, 15 January 2021 (UTC)

Proposal to change logo for 20th anniversary
Should we temporarily change our logo in celebration of Wikipedia's 20th anniversary? — Wug·a·po·des​ 22:40, 13 January 2021 (UTC)

Because of the short time frame, this RfC will only run for 24 hours. To ensure adequate participation in the reduced time frame, notices have been left at the administrators' noticeboard, the centralized discussion notice, and the village pumps.
 * RfC Format

The original RfC proposed File:WP20 EnWiki20 SimplifiedLogo.svg. Due to editor interest, other options have been added below and are labeled by letters. Please rank your preferences from most to least, and do not list options which you oppose.

Details can be found at mw:Manual:FAQ. Ideally a server admin can update the server configuration, but the change can also be achieved through edits to MediaWiki:Common.css
 * Implementation


 * Survey
 * Support as proposer. — Wug·a·po·des​ 22:40, 13 January 2021 (UTC)
 * Support no brainer. Levivich harass/hound 22:41, 13 January 2021 (UTC)
 * (Thanks for the ping, !) My preferences are A, C, B, D in that order. Levivich harass/hound 23:22, 13 January 2021 (UTC)
 * Support why not? M Imtiaz (talk · contribs) 22:52, 13 January 2021 (UTC)
 * A is my vote. M Imtiaz (talk · contribs) 00:06, 14 January 2021 (UTC)
 * Support, sure, why not. Vanamonde (Talk) 22:53, 13 January 2021 (UTC)
 * No objections to any of the images, support in the order D > C > B > A. Vanamonde (Talk) 23:28, 13 January 2021 (UTC)
 * Support Option C, it's time. Enjoyer of World — Talk 22:53, 13 January 2021 (UTC)
 * Conditional support options since added if there are no other proposals. I'd prefer something bolder than that (which looks like it'll barely be noticeable), but I'll take it over nothing, certainly. Can we have some other proposals? &#123;{u&#124; Sdkb  }&#125;  talk 22:55, 13 January 2021 (UTC)
 * Support - Sure, why not? Beyond My Ken (talk) 22:56, 13 January 2021 (UTC)
 * Follow up: Of these choices, I still prefer the originally posted one, Option A. The remainder are too gaudy, or amateurish-looking, or take up too much space.  I prefer the understatement of the original, which is clean and professional-looking.  Wikipedia has outgrown its amateurish roots, and we should present ourselves for what we are now, the premiere source of immediate information on the Internet. Beyond My Ken (talk) 01:19, 14 January 2021 (UTC)
 * Conditional support, same reasoning as Sdkb. Tayi Arajakate  Talk 22:57, 13 January 2021 (UTC)
 * Conditional support, same as Sdkb. davidwr/  (talk)/(contribs)  22:58, 13 January 2021 (UTC) Option A is better than the rest, but anything is better than nothing.  davidwr/  (talk)/(contribs)  23:28, 13 January 2021 (UTC)
 * Note working on getting the other options set up since there's interest. Gimme a sec. — Wug·a·po·des​ 23:00, 13 January 2021 (UTC)
 * Support A - I prefer the fact that it is not too showy or gaudy. A nice commemoration of two decades of building the 'pedia. MarnetteD&#124;Talk 23:01, 13 January 2021 (UTC)
 * Support If we celebrated 6 million articles, why not 20 years? ~ HAL  333  23:03, 13 January 2021 (UTC)
 * Support I want a flashing Wikipedia logo with a comic sans 20 in the middle of it and animated fireworks (preferably yellow and red, green isn't my thing) in the background. Make it happen. -- qedk ( t  愛  c ) 23:03, 13 January 2021 (UTC)
 * Conditional support per Sdkb. YorkshireLad ✿  (talk) 23:04, 13 January 2021 (UTC)
 * Support --Enos733 (talk) 23:09, 13 January 2021 (UTC)
 * Logo preference is Option A followed by option D. The logo should be changed for the anniversary. --Enos733 (talk) 17:58, 14 January 2021 (UTC)


 * Follow-up The RfC has changed since these first comments. Those indicating support were commenting only on option A. — Wug·a·po·des​ 23:12, 13 January 2021 (UTC)
 * Since we only have 24 hours for the RFC, am pinging the users above who commented before options were added: Aza24 (talk) 23:19, 13 January 2021 (UTC)
 * Option D. It's the most vibrant, but still looks professional. &#123;{u&#124; Sdkb  }&#125;  talk 23:21, 13 January 2021 (UTC)
 * Option D As Sdkb says: Vibrant yet professional. Followed by: B, C, A. A is hardly noticeable. B is...okay but a bit hard to see what it says. C seems a bit hokey. CaptainEek  Edits Ho Cap'n!⚓ 23:26, 13 January 2021 (UTC)
 * Option A makes the point in a consistent and elegant style. B and D seem too cartoony and garish. And C risks being quite inaccurate as it supposes that the readership is just like the contributors when their demographics may be quite different. Andrew🐉(talk) 23:29, 13 January 2021 (UTC)
 * Option D, then B, C, A. A seems too subtle, C perhaps too in-your-face. Thanks for the ping, ! YorkshireLad  ✿  (talk) 23:31, 13 January 2021 (UTC)
 * Option D. Option A is also better than nothing.  I oppose C - it looks like a Cards Against Humanity card; it's too big and the black background isn't good. power~enwiki ( π,  ν ) 23:32, 13 January 2021 (UTC)
 * Option D: Here is a mockup on Vector. I thought it might be too busy/colorful, but it seeing it in context – it works, I think. Fits the branding for other 20th anniversary content. Second choice: A, then B. Not C; it looks like we're protesting something or someone died. — The Earwig   talk  23:34, 13 January 2021 (UTC)
 * Interesting mock. Maybe we need to increase the spacing between image and text a bit? ProcrastinatingReader (talk) 08:09, 14 January 2021 (UTC)
 * Yes, I think you might be right. Pad a bit more to match how the current logo looks and possibly give us enough space to properly center "20 years of"? Unfortunately we're running out of time. Ping Wugapodes. —  The Earwig   talk 19:16, 14 January 2021 (UTC)
 * Working on the final designs of A and D (since those seem the only real candidates) as we speak. Should have them posted by 20:00 UTC — Wug·a·po·des​ 19:48, 14 January 2021 (UTC)
 * D C B A ~ ToBeFree (talk) 23:38, 13 January 2021 (UTC)
 * Option B Then D, C, A. I like the design of B and D, but D is just too busy. ~ HAL  333  23:39, 13 January 2021 (UTC)
 * D all the way 's vector changed my mind. ~ HAL  333  23:44, 13 January 2021 (UTC)


 * Option D – followed by C, I've loved the style of D since I first saw it at some WMF page; it should draw attention, worried that the others won't. A and B seem a little too bland for a celebration or anniversary imo. Aza24 (talk) 23:40, 13 January 2021 (UTC)
 * Option A: maybe option B. C is horrible. D is messy — GhostInTheMachine talk to me 23:43, 13 January 2021 (UTC)
 * Option C, unorthodox opinion sure. In your face, yes. But it brings attention to the fact that anyone can become a contributor which is something we need more awareness of and I like its aesthetics... Tayi Arajakate  Talk 23:50, 13 January 2021 (UTC)
 * Option A or C, please not the cartoony B or D. --Yair rand (talk) 23:52, 13 January 2021 (UTC)
 * A, then D. Not B or C. —  xaosflux  Talk 00:05, 14 January 2021 (UTC)
 * Option D - F ASTILY   00:25, 14 January 2021 (UTC)
 * Option D then Option A. But wondering whether a logo would mention we reached one billion edits. "20 years, 1 billion edits" sounds even more grandiose. Ovinus (talk) 00:30, 14 January 2021 (UTC)
 * Prefer A, then C, but any of these would be better than doing nothing.- gadfium 00:37, 14 January 2021 (UTC)
 * Option D (then A). I wouldn't want this around for any length of time, but it's nice and punchy (but friendly) for a day. -- Elmidae (talk · contribs) 00:40, 14 January 2021 (UTC)
 * I really love Ovinus' suggestion of "20 years, 1 Billion edits" CaptainEek  Edits Ho Cap'n!⚓ 01:10, 14 January 2021 (UTC)
 * Could someone with some photoshop skills modify Option D - the clear frontrunner - so that it reads that beneath the artwork? ~ HAL  333
 * Here it is for Option A, though I think the portion could be moved up a tad. Ovinus (talk) 02:35, 14 January 2021 (UTC)
 * I'm away from inkscape at the moment, but if we're going to have both 20 years and 1 billion edits, I would suggest they go under the Wikipedia textmark instead of over. Essentially, replaing "The Free Encyclopedia" part with something like "Wikipedia\n20 years and 1 billion edits". Another option is to keep "20 years of" above the mark and have "Over 1,000,000,000 edits" below in small caps. — Wug·a·po·des​ 02:46, 14 January 2021 (UTC)
 * Good idea! I've put something similar on the right, though I admit I have no background in graphic design so the spacing may not be optimal. Maybe someone can make one using the "The Free Encyclopedia" font. Ovinus (talk) 03:02, 14 January 2021 (UTC) Wikipedia logo one billion edits v2.svg
 * Having the text above "Wikipedia" looks much better imo. ~ HAL  333  03:18, 14 January 2021 (UTC)

A bit busy at the moment, so maybe someone else can create the analogous things for other options/Wugapodes's second idea. Ovinus (talk) 04:09, 14 January 2021 (UTC)
 * I mocked up the text mark. It's at right or here. This can just be dropped into whatever logo gets chosen except C but that one's a long shot anyway. — Wug·a·po·des​ 04:23, 14 January 2021 (UTC) EnWikipedia 20 years billion edits text mark.png


 * Support A or C, preferring A. The B option has a bizarre number "2" that looks like a 5 that fell over. Both the B and D options do not match any of the look of Wikipedia or the other Wikimedia projects, so unless there is a complete rebrand everywhere, they are too strange. – Jonesey95 (talk) 01:13, 14 January 2021 (UTC)
 * D > C > A > B > nothing. – Teratix ₵ 01:20, 14 January 2021 (UTC)
 * D, C: Currently support D, with C coming a close second. C has the best message to deliver, and it looks really classy, but it's too solemn - maybe have some 50% opacity glyphs, or splashes of colour, on the black background to make it look less like a banner for a memorial service for a recently deceased person. Wilhelm Tell DCCXLVI converse &#124; fings wot i hav dun 01:32, 14 January 2021 (UTC)
 * Comment: As Ovinus suggested, we have to mention the thing about the billion edits. How can we not? It's a milestone as great as any other, and the billionth edit itself was by Ser Amantio di Nicolao, rather than just some vandal... Wilhelm Tell DCCXLVI converse &#124; fings wot i hav dun 02:12, 14 January 2021 (UTC)


 * Support A or D. My only strong opposition is for option C, which is too big and might be disruptive. If we can't all agree, I suggest just going for A because it's so minimal many won't even notice. 20 years is a long time... I feel like we have to advertise this milestone in some way! &mdash; MusikAnimal  talk  01:56, 14 January 2021 (UTC)
 * Support A'. Yes, 20 years is a benchmark that should be acknowledged, but I do not think that a dramatic celebratory change is appropriate at this moment in world history. Cullen328  Let's discuss it  02:30, 14 January 2021 (UTC)
 * Celebration is fun, and the whole world's beginning to look brighter every day. Vaccines are out, and economies are slowly beginning to pick up pace again. Twenty years in pursuit of excellence and a billion edits definitely call for celebration. Wilhelm Tell DCCXLVI converse &#124; fings wot i hav dun 05:01, 14 January 2021 (UTC)


 * Support generally, first choice being Option A, second choice Option D. No objection to other options presented, though. BD2412  T 02:59, 14 January 2021 (UTC)
 * Support D though A is fine. I also support the 20 years 1 billion edits wording. Opposed to the other two. Best, Barkeep49 (talk) 03:19, 14 January 2021 (UTC)
 * Support A, minimalism is best here. - The Bushranger One ping only 03:40, 14 January 2021 (UTC)
 * Support A, per the Bushranger. Also support mentioning the billion edits, of course. Double sharp (talk) 04:16, 14 January 2021 (UTC)
 * Support to A or D. &#8208;&#8208;1997kB (talk) 04:56, 14 January 2021 (UTC)
 * First choice is Wugapodes' suggestion, second is option A, third is D and B. --pandakekok9 (talk) 05:02, 14 January 2021 (UTC)
 * Support D rest look meh. Oppose B and C. A looks way too bland, unlikely to even be noticed tbh. D is exciting, whilst not messy. ProcrastinatingReader (talk) 05:55, 14 January 2021 (UTC)
 * Support D, which I thought would be too messy at first but looks great in the vector. A as backup. Vaticidalprophet (talk) 05:58, 14 January 2021 (UTC)
 * Support D followed by A. signed,Rosguill talk 06:00, 14 January 2021 (UTC)
 * Support A D followed by D A. Also support the 20 years 1 billion edits wording  Asartea  Talk  undefined  Contribs  07:51, 14 January 2021 (UTC)
 * Support any: A, B, C, D. Just do something.   GenQuest  "scribble" 07:59, 14 January 2021 (UTC)
 * Support any, but A as first pick. -- a lad insane  (channel two)  08:11, 14 January 2021 (UTC)
 * Support option D —Th e DJ (talk • contribs) 09:06, 14 January 2021 (UTC)
 * Comment: I think many option A !voters are missing how extraordinarily subtle that change would be. It's one thing to see the extra line when you're looking at it oversized in the context of a discussion you know will be about changing it; it's quite another to be browsing Wikipedia for something totally unrelated. If we want anyone other than ourselves to notice (and I think we do for an anniversary this significant), we should choose a bolder option. &#123;{u&#124; Sdkb  }&#125;  talk 09:30, 14 January 2021 (UTC)
 * Support C, followed by A As C doesn't seem to be getting much love, please consider A my !vote if that wouldn't win. I prefer the non-cartoony options, 20 years in, Wikipedia is into its adulting phase ;) Nosebagbear (talk) 10:18, 14 January 2021 (UTC)
 * Support D, followed by A. The D looks quite cool.  Mario Jump  83!  11:16, 14 January 2021 (UTC)
 * Support D, then A. Jr8825  •  Talk  11:31, 14 January 2021 (UTC)
 * Support. Preferences: D or B. A is too easy to miss. –&#8239;Joe (talk) 11:59, 14 January 2021 (UTC)
 * Support A D looks a bit cluttered and cartoonish, and I like the more simple, minimalistic form of A. B looks ugly, and C is just text.
 * Support A is the most professional looking one..lets steer clear of child like cartoons on the main page...or any page for that matter.-- Moxy 🍁 14:20, 14 January 2021 (UTC)
 * Support D Option D looks cool in my opinion, better than the rest. Danloud (talk) 15:03, 14 January 2021 (UTC)
 * support A though it should not be temporary, it should be an alternate to main logo for a few weeks...IMO--Ozzie10aaaa (talk) 16:38, 14 January 2021 (UTC)
 * Support D - Compared to the other options, actually feels celebratory. D reminds of a vibrant mural on the street. Altamel (talk) 16:51, 14 January 2021 (UTC)
 * support A, then C – B and D look amateurish. Dhtwiki (talk) 19:47, 14 January 2021 (UTC)
 * Strong support choosing any of the proposals (though that seems to have consensus now) and I'd like C, D, B and A in that order. C is simple but thought-provoking and could inspire people to think about joining, D is beautiful and hopefully would also get people to reflect a bit on how they use Wikipedia and why, B looks nice and grabs attention and A is similar to banner themes we've used in the past and uncontroversial. — Bilorv ( talk ) 19:56, 14 January 2021 (UTC)
 * Just to emphasise: that's a strong support of D over A (since those look like frontrunners). Support mentioning 1 bn edits too. — Bilorv ( talk ) 22:04, 14 January 2021 (UTC)
 * I support C, D, B, A, in that order. We've done bolder logos for arguably less important events, and I think C looks really good for WP 20. Best, KevinL ( alt of L235 · t · c) 20:22, 14 January 2021 (UTC)
 * Oppose, but if you must, then A looks OK. Don't forget to keep the 'The Free Encyclopedia' bit. Thanks. Mike Peel (talk) 20:27, 14 January 2021 (UTC)
 * I thought all this was discussed and dismissed weeks ago. I agree with Mike Peel, oppose a change, but if there is to be one, A looks best.--Wehwalt (talk) 20:43, 14 January 2021 (UTC)
 * A only. Agreed that the professionalism on the other two is lacking. Especially if we leave this to linger for longer than the day. --Izno (talk) 20:44, 14 January 2021 (UTC)
 * Support any. This is a milestone worth recognizing. I would also support a "1 billion edits" message as part of the logo. — python coder (talk &#124; contribs) 21:23, 14 January 2021 (UTC)
 * Support the proposal: Not voting for anything specificially. Like pythoncoder I also ensorse the proposal in general. Let's do it. --Titodutta (talk) 22:16, 14 January 2021 (UTC)

Main page banner
There is some discussion above about having a banner on the main page leading to a page with some additional information and encouragement to try editing. I've put together a rough mockup of what that could look like. It needs some technical attention to get the width working properly, so apologies for not having something more refined, but I want to put it out here because we're on such a short timeframe. The main page would be changed to add a banner like this, which would lead to this page with a video and further reading/learning links (again, it still needs a few technical tweaks, and it'd of course be moved to 20th anniversary if adopted). Is there general support for doing something like this? &#123;{u&#124; Sdkb  }&#125;  talk 15:22, 14 January 2021 (UTC)
 * I think that banner is way to big, would rather something less intrusive like we did for 6MM articles (example). Keep in mind there is already also a huge CN banner for the New York area at the top of the page, landing on Meetup/NYC/Wikipedia_Day_2021. — xaosflux  Talk 15:48, 14 January 2021 (UTC)
 * , While the banner could be slightly smaller this is wikipedia's 20th anniversary and I think something big would be appropriate  Asartea  Talk  undefined  Contribs  15:52, 14 January 2021 (UTC)
 * I'm assuming this would be in addition to already styling the logo special as well - that's why I'm suggesting not making it so large in addition. — xaosflux  Talk 16:06, 14 January 2021 (UTC)
 * Support mainpage banner and the page  Asartea  Talk  undefined  Contribs  15:53, 14 January 2021 (UTC)
 * Support Good idea ....but could we incorporate a few more options like above. Just not sure a cartoonish look is apprioate during a world wide pandemic...should look more academic in my view.-- Moxy 🍁 16:01, 14 January 2021 (UTC)
 * , considering my quick reading of the Logo seems to indicate D will win this banner would be in the same kind of style. A more academic banner might clash with the logo otherwise.  Asartea  Talk  undefined  Contribs  16:08, 14 January 2021 (UTC)
 * Agree D will win.... the one that looks like the stickers on my granddaughters baby monitor ...sad face. Can we get color blind friendly version at least.-- Moxy 🍁 00:08, 15 January 2021 (UTC)


 * Note: There is a banner campaign planned in support of WP20 in place of the usual WMF fundraising thank you campaign and will follow a similar format to that run in previous major anniversary. Seddon talk 18:21, 14 January 2021 (UTC)
 * , that's good to know. I'm not sure it'd interfere with this unless it's being planned to launch tomorrow. The aim is also different if it's fundraising vs. seeking editors. &#123;{u&#124; Sdkb  }&#125;  talk 18:32, 14 January 2021 (UTC)


 * Support ~ HAL  333  19:37, 14 January 2021 (UTC)
 * I do not support the proposed banners. I do support our usual banner like at 6m articles. Something like "Wikipedia celebrates its 20th birthday with 1 billion edits" or something. --Izno (talk) 20:46, 14 January 2021 (UTC)
 * I agree with Izno, let's do the usual Main Page banner style like at the n-millionth article celebrations. Mz7 (talk) 23:18, 14 January 2021 (UTC)
 * I should clarify by saying I think something is better than nothing, and I merely prefer the usual banner style, but I don’t want to prevent there from being any banner at all. Mz7 (talk) 00:00, 15 January 2021 (UTC)


 * Support, it's a bit odd to have the page icon and not a banner. As for the format of this, I'm not really sure on what would be appropriate but do support a graphical style one.
 * ✨ Ed  talk!  ✨ 23:48, 14 January 2021 (UTC)


 * There seems to be the least resistance so far to do "something" over nothing-- going off the styling at Template:Main_Page_banner - can we settle on some text, including a single bolded call to action that has a specific landing page? — xaosflux  Talk 00:57, 15 January 2021 (UTC)
 * , Would it be simplest to just use a modified version of the "x million articles" message? For instance, The English-language Wikipedia is celebrating its 20th birthday! Learn how you can take part in the encyclopedia's continued improvement. Sam-2727 (talk) 01:07, 15 January 2021 (UTC)


 * I've added the plain-ish banner via Template:Main Page banner; the landing page is 20th anniversary. I'm at least slightly involved in this preference, but "anything is better than nothing" seems to be prudent initially - discussion on further improvements to the banner are more than welcome to continue here and any admin is welcome to revert me if they think this is out of line without more discussion. —  xaosflux  Talk 02:33, 15 January 2021 (UTC)
 * , I'm glad we managed to get something up. No one has addressed the technical stuff I mentioned above, though, so it currently works terribly on mobile or screens with an unusual resolution. Could we get someone good at CSS to address those things as soon as possible? &#123;{u&#124; Sdkb  }&#125;  talk 12:33, 15 January 2021 (UTC)
 * can you be a bit more specific? The banner seems to be displaying at least as well as any of the other page content to me at very small and very large resolutions, in vector/monobook/minerva/timeless, also via the minerva on the mobile site (en.m.wikipeida).  Are you referring to the banner itself or the landing page (20th anniversary) itself (I think that one certainly could use some work but I didn't have anything to do with that page). —  xaosflux  Talk 18:02, 15 January 2021 (UTC)
 * , I was referring to the landing page. swooped in and fixed the issue, so we're set now. (Not the first time he's helped fix a CSS issue for mobile; many thanks!) &#123;{u&#124;  Sdkb  }&#125;  talk 18:05, 15 January 2021 (UTC)

Banner text
The text of the banner current says The English-language Wikipedia is celebrating its 20th birthday! I think we should change it to Wikipedia is celebrating its 20th birthday! The founding of English Wikipedia and Wikipedia were the same, and founding Wikipedia as a whole is the bigger event, so that's what we're celebrating. Plus it's just cleaner. And I don't think we need the wikilink when this banner is appearing directly below the permanent banner which already includes a wikilink to Wikipedia. &#123;{u&#124; Sdkb  }&#125;  talk 12:42, 15 January 2021 (UTC)
 * , courtesy pinging you on this since you implemented; would you be willing to switch the language? &#123;{u&#124; Sdkb  }&#125;  talk 18:07, 15 January 2021 (UTC)
 * ✅ trimmed Template:Main Page banner. — xaosflux  Talk 18:15, 15 January 2021 (UTC)

Banner for IPs?
When I go to a page logged out, I see a banner with the rather silly tagline "celebrating 20 years human", linking to the WMF page. There doesn't seem to be anything on it at CentralNotice; does anyone know where this is coming from? &#123;{u&#124; Sdkb  }&#125;  talk 01:07, 16 January 2021 (UTC)
 * I'm not seeing that one, just the CN notice with "Thank you for making 20 year..." that has a javascript easteregg to the foundation site (sigh....). Can you inspect that element you are seeing and provide more info?  Also is this on desktop, mobile, or mobile app? —  xaosflux  Talk 01:55, 16 January 2021 (UTC)
 * OK those seem to be coming from CN's as well (e.g. in pages like meta:MediaWiki:Centralnotice-template-WP20 test1 Cake20 I see the text) - think these are all being managed by User:Seddon (WMF). — xaosflux  Talk 02:02, 16 January 2021 (UTC)
 * Main page 20 banner (original variant).PNG
 * Main page 20 banner.PNG
 * , when I just tried reloading the page, it changed the text, so we're seeing the same thing now. Attaching screenshots. If you'd like to know anything about the source code, just tell me what to look for when I inspect the element.
 * The main issue is that these duplicate our banner on the main page, creating some redundancy. Not a super urgent issue, but not totally ideal either. &#123;{u&#124; Sdkb  }&#125;  talk 02:09, 16 January 2021 (UTC)
 * think they have a few CN's that will cycle and they also have impression diets that make them not always show, and they show on every page not just MP - don't think we should remove our MP banner just because of that. — xaosflux  Talk 02:13, 16 January 2021 (UTC)
 * Yeah, sounds fine. It might be nice to suppress the CN banner on the Main Page to get rid of the duplication, but I don't feel strongly. &#123;{u&#124; Sdkb  }&#125;  talk 02:21, 16 January 2021 (UTC)
 * Yeah, sounds fine. It might be nice to suppress the CN banner on the Main Page to get rid of the duplication, but I don't feel strongly. &#123;{u&#124; Sdkb  }&#125;  talk 02:21, 16 January 2021 (UTC)

Banner duration
This type of banner isn't really designed to be long-term, suggest taking it back down either (A) when changing to the more subtle site logo soon or (B) in about 2 weeks when we revert to the standard site logo. Any feelings one way or the other? — xaosflux  Talk 19:48, 20 January 2021 (UTC)
 * Barring any objections, I'll stand this down whenever A occurs (see other section for progress on that). — xaosflux  Talk 11:20, 22 January 2021 (UTC)
 * Removed from Template:Main Page banner. — xaosflux  Talk 16:21, 22 January 2021 (UTC)`

What about launching a campaign to candidate the Wikimedia Foudation for the Peace Nobel Prize?
Candidates for the Nobel Prize will be examined as from February 1st, there's still some time and this might be a favourable momentum! Lichinga (talk) 15:47, 14 January 2021 (UTC)
 * Something like that would have to be thoroughly planned and considered. There's no chance of us being ready to launch by tomorrow. &#123;{u&#124; Sdkb  }&#125;  talk 16:16, 14 January 2021 (UTC)
 * I agree w/ Lichinga--Ozzie10aaaa (talk) 17:57, 14 January 2021 (UTC)
 * This is something that would need considering in great depth, researching thoroughly and a very strong and detailed nomination prepared if there is going to be any hope of it getting past even the first sift. Another consideration is that only certain people can make a nomination and still there are around 200 different nominees a year from a much higher number of nominators. So in short, not this year. Thryduulf (talk) 22:36, 14 January 2021 (UTC)
 * Given that we're not going to win it this year, I think the nomination would be harmless. Certainly we can't prevent any eligible nominator from nominating us if they wish. BD2412  T 23:33, 14 January 2021 (UTC)

On other projects
Just wanted to note plans I've noticed at other projects. FrWikipedia are discussing the same options (except our option C) at w:fr:Wikipédia:Le Bistro du jour. CsWikipedia chose a logo in the same art style as B and D at w:cs:Wikipedie:Pod lípou. Probably too late to take this into consideration, but if people are interested in being consistent with other projects, it's worth looking at. — Wug·a·po·des​ 20:04, 14 January 2021 (UTC)

Finalizing images
Given the discussion, the main candidates are A and D (the eventual closer will need to figure out which has consensus) and there's interest in memorializing the one billion edit milestone. In prep for deployment, I've finalized these two images based on the feedback. Let me know if there are any other issues that should be fixed before midnight UTC. — Wug·a·po·des​ 20:14, 14 January 2021 (UTC)
 * Given that there’s only a few hours till midnight, Wug, and also the last deployment window before Monday, do you have someone ready who can close this? And it may be worth contacting a sysadmin on IRC to have them (or someone else CR) look over the patch to make sure it, and the asset, looks okay, since there’s not much slack room I suppose. ProcrastinatingReader (talk) 20:21, 14 January 2021 (UTC)
 * Chatted up #wikimedia-operations and that seems ready when the time comes. Based on feedback, it seems the deployment window isn't as tight as I first thought so we we've got a bit of wiggle room (but not a ton). said on IRC that they're willing to close. — Wug·a·po·des​ 21:06, 14 January 2021 (UTC)
 * The "20 years of" text needs to be properly centred under the puzzle-globe, it looks totally slapped on and unprofessional being slightly too much to the right. --  AxG /  ✉  21:28, 14 January 2021 (UTC)
 * I uploaded an example here, but imo it doesn't look much better. It leaves more white space between the small-cap letters and the italic text and still looks somewhat off-center because of the asymmetric width of the "W" and "A". — Wug·a·po·des​ 21:50, 14 January 2021 (UTC)
 * The centered text looks slightly better to me. &#123;{u&#124; Sdkb  }&#125;  talk 23:42, 14 January 2021 (UTC)
 * I disagree. The non-centered text doesn't bother me. ~ HAL  333  22:43, 14 January 2021 (UTC)
 * Wug·a·po·des​, the final deployed logo is cut-off at the bottom on MonoBook. See comments at Talk:Main page. Fences  &amp;  Windows  23:33, 14 January 2021 (UTC)
 * Yep, we're working on it with on IRC as we speak. I'll leave a message there as well. — Wug·a·po·des​ 23:35, 14 January 2021 (UTC)

Duration

 * Thanks for the close. Do we have any conclusions on the preferred duration? Up above there seems to be desire for it to be longer than a single day, but no firm consensus on exactly how long. &#123;{u&#124; Sdkb  }&#125;  talk 22:37, 14 January 2021 (UTC)
 * Unfortunately, the discussion above only focused on which logo to use, so there aren't any conclusions on the preferred duration. I would say "do what you think is right", but if you want a definitive answer, then more discussion is needed. Mz7 (talk) 22:40, 14 January 2021 (UTC)
 * I was expecting we might have another "24-hour RfC" on when to remove when it seemed the mood was for changing it back, but perhaps starting an RfC now on duration might be best, closing ad hoc when it's been almost the period of time that has the most agreement. (I'd like a week but I am but one mortal.) — Bilorv ( talk ) 22:47, 14 January 2021 (UTC)
 * FYI, per our normal deployment procedure, there shouldn't be any deploys until Tuesday, at the earliest (Monday is a US holiday so few people are around). Jdforrester (WMF) (talk) 23:26, 14 January 2021 (UTC)
 * This doesn't happen that often, I'm good for anything up to a month. — xaosflux  Talk 00:54, 15 January 2021 (UTC)
 * Two weeks would be reasonable imo. ~ HAL  333  01:26, 15 January 2021 (UTC)
 * I also support using option A for a much longer duration (up to a year) afterwards. It's subtle enough. ~ HAL  333  02:54, 16 January 2021 (UTC)
 * one month since this is a unique achievement perhaps it should stay like this one year(however I'd switch to option A)--Ozzie10aaaa (talk) 02:22, 15 January 2021 (UTC)
 * It shouldn't go beyond the 15th unless it is changed to a variant of the original logo. We had a rushed RfC that installed a hideously tacky logo that barely fits with Wikipedia branding, regardless if these were picked by Wikimedia. Nihlus  02:24, 15 January 2021 (UTC)
 * Two weeks to a month sounds reasonable. I absolutely opposes 24 hours. <b style="color: #0000FF;">OhanaUnited</b><b style="color: green;">Talk page</b> 03:00, 15 January 2021 (UTC)
 * IMHO, the current logo (option D) is too distracting and loud to be used for a whole month. On the other hand, I'd be okay with having the logo up for a whole month if one of the more subtle options (e.g., option A) were used after the first 24 hours. 72.209.60.95 (talk) 03:15, 15 January 2021 (UTC)
 * I agree with the IP above that the current logo (D) is not suitable for long-term use, and with Nihlus that the 15th (or soon after) would be long enough. Two weks or a month would be too long.  I wouldn't object to Option A (the original choice) replacing it for the remainder of 2021, though, since it's only a small adjustment from our regular logo.  We'd then go back to the normal logo in 2022. Beyond My Ken (talk) 04:31, 15 January 2021 (UTC)
 * I have a slightly radical suggestion - keep option D for anywhere between three days to one week, and then keep option A for one year, till 15 January 2022. Wilhelm Tell DCCXLVI converse &#124; fings wot i hav dun 04:52, 15 January 2021 (UTC)
 * I preferred Option D, then Option A in order - as the Option D is way cooler than Option A, but I didn't realize how ugly it was until today. I agree that Option D should be used for a short while, then Option A for the rest of the year until 2022.  Mario Jump  83!  04:57, 15 January 2021 (UTC)


 * 20 days for 20 years. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[ᴛ] 05:02, 15 January 2021 (UTC)
 * I agree that option D is probably not a great option for a long term logo, though I do like the idea of switching to option A for the rest of our 20th year. It shouldn't be hard to implement either as long as we can find someone to do the deployment. We've probably got this one through the weekend though. — Wug·a·po·des​ 05:12, 15 January 2021 (UTC)
 * D only for a day as a nice joke...use A for the month.-- Moxy 🍁 05:25, 15 January 2021 (UTC)
 * I'm also liking the idea to switch to A after a bit. I don't think we need to keep D for more than a few days to a week at the most. Switch to A for the remainder of the month, or longer. —  The Earwig   talk 05:57, 15 January 2021 (UTC)
 * ~20 hours should be enough: with all these colours and everything there's hardly a need to keep it longer, people will have understood that we do indeed care a lot about this occasion. The logo File:WP20 EnWiki20 SimplifiedLogo.svg would be ok for longer periods. Nemo 06:58, 15 January 2021 (UTC)
 * No more than a week of Option D; I don't know how long celebrations will be going but they should be done by then. power~enwiki ( π, ν ) 07:00, 15 January 2021 (UTC)
 * 20 days sound good. —Th e DJ (talk • contribs) 09:18, 15 January 2021 (UTC)
 * No more than a week of our painfully bright logo (fine for big splash, not a good long-runner), 72 hours would be better. Against just 1 day. Like some of the above, I'd be happy with 2-4 weeks of the calmer "A" logo. Nosebagbear (talk) 09:50, 15 January 2021 (UTC)
 * 20 days sounds good. imo keep D for the entire duration. No opinion on whether to revert to original logo, or option A, for some period afterwards. ProcrastinatingReader (talk) 10:25, 15 January 2021 (UTC)
 * Only 1 day seems good to me, if you must keep it longer then changing to (A) would be better for the rest of the time. Also, can we go back to 'The Free Encyclopedia' please? We're still about a factor of 1,000 from 1 billion edits, we're only at around 1000 million. Thanks. Mike Peel (talk) 10:54, 15 January 2021 (UTC)
 * There is more than one definition of a billion. See our article. Britmax (talk) 11:17, 15 January 2021 (UTC)
 * Exactly, that's why it's best to avoid using the word. Thanks. Mike Peel (talk) 11:37, 15 January 2021 (UTC)
 * Good point. Britmax (talk) 11:39, 15 January 2021 (UTC)
 * One million million as a billion is supposed to be the English variant, but my English self has never heard a single person use it that way IRL, and that's not what the news, books etc. use. I'm sure it's different in different countries but I think it's predominant enough to use here. At some point you have to make a regional choice. No-one has yet suggested "100 crore", which millions (rather: tens of lakhs) of our readers would find most natural. — Bilorv ( talk ) 15:16, 15 January 2021 (UTC)
 * I'm from the UK, but whenever I hear 'billion' I have to double-check what is actually meant... Good examples with crore/lakh. Why not avoid the whole issue by either just giving it as a number, or going back to the standard tagline? Thanks. Mike Peel (talk) 18:05, 15 January 2021 (UTC)
 * Then I suspect that you, Bilorv, are rather younger than me. When I was at school in England in the 1960s and 1970s "billion" very definitely meant a million million in British English, but by the time my children went to school in the 1990s the more common meaning had become a thousand million. Some of us old codgers are still alive and reading an online encyclopedia so ambiguity should be avoided if at all possible. Phil Bridger (talk) 18:47, 18 January 2021 (UTC)
 * Of course, the "correct" understanding of the term billion is indeed one million million. We do all know this. Sadly, we in the homeland are over-influenced by the usage of our ex-colonies and so tend to use their understanding of a billion to be a thousand million. We know that they are wrong, but the usage is spreading all over the place. Hence "billion" is likely to be a confused term for some people. I suspect though, that in this case, most people will not internalise the word billion to be a real number and will just accept that Wikipedia has done "lots" of edits. That is enough really. We have done lots, are justifiable happy about that and that is a Good Thing — GhostInTheMachine talk to me 20:32, 18 January 2021 (UTC)
 * One to a few days, I think it tends to confuse users about whether they are at the correct site. Alanscottwalker (talk) 13:12, 15 January 2021 (UTC)
 * 1 week seems reasonable to me. My rough sense is that most people visit Wikipedia at least that often, so keeping around for that long will give everyone a chance to see it. Anything beyond that and it just gets tired. &#123;{u&#124; Sdkb  }&#125;  talk 13:32, 15 January 2021 (UTC)
 * I wouldn't mind it being used on a permanent basis going forward. It adds some new color the site and breaks the monotony of gray and white. -- Calidum  15:35, 15 January 2021 (UTC)
 * As briefly as humanly possible. Imho this is an abomination, and I came to this page to say as much. Put the number 20 in a wreath or something if you want to celebrate "20 years", when I saw this, my first thought was that Wikimedia has finally sold out to Google. This "Silicon Valley" art style is ugly aesthetically as it is soulless. Maybe it is only fitting that Wikimedia finally wears this style on its sleeve, but it doesn't suggest a celebratory mood, at least to me. --dab (𒁳) 19:18, 15 January 2021 (UTC)
 * The instituted icon should be up for minimal time. I think rest-of-the-month-to-20-days is a reasonable time for option A, since several seem to be suggesting that. --Izno (talk) 19:45, 15 January 2021 (UTC)
 * Leave D up over the weekend, switch to A on Monday. Mjroots (talk) 20:15, 15 January 2021 (UTC)
 * Option D should only stay up until the end of the day today (24 hours from when it was implemented, whenever that is). Option A is much better, in my opinion, and I am willing to see it for up to two weeks. A whole month seems silly to me, and a year even more so. — Goszei (talk) 21:30, 15 January 2021 (UTC)
 * Switch to A as soon as possible. D is ugly, off-brand and (to many non-American liberals) it also features a symbol of female oppression. Crazy. Rollo (talk) 22:10, 15 January 2021 (UTC)
 * 1 day sitewide / 1 week main page. Switch to A if long-term. This is a good compromise for both the celebrators and the let's-get-back-to-work people. Cordially,  History DMZ  ( talk )+( ping )  00:22, 16 January 2021 (UTC)
 * I hope this won't last long. Yes, I missed my chance on !voting for another option, though I probably wouldn't have voted for any. Honestly, I first thought this was a feature letting me click on one of the four images (which are in fact one) depending on what device I was using (phone, desktop, tablet, other). As dab pointed out, these cutesy-primary-colors aesthetics don't quite cut it. ---Sluzzelin talk  00:31, 16 January 2021 (UTC)
 * I'd say 2 days for option D, then switch to option A and let it stay that way for 20 days. pandakekok9 (talk) 03:21, 16 January 2021 (UTC)
 * comment there are about 8 editors that both would agree to change to option A and leave for a year (there are several more indicating at least a month; also one gets the feeling from reading the above posts that the majority prefer option A)...Ozzie10aaaa (talk) 01:29, 17 January 2021 (UTC)
 * Wikipedia is for readers. Most readers couldn't care less that it's an anniversary, and the anniversary logo's visual heft is distracting. Wikipedia is for its contributors. Its contributors have spent years contributing to a site with a playful puzzle ball. Count this as another vote for "as soon as possible." (Option A is fine, but consider that many readers won't know what "one billion edits" even means. Yes, the process by which Wikipedia is made is something to celebrate, but at the end of the day, people only care if the information they're looking for is here, and whether it's right.) --  Zanimum (talk) 15:32, 17 January 2021 (UTC)
 * If it's going to be for longer than today, we need a much wider discussion. I predict a vote of 10–1 against the current banner. To me this is a cautionary lesson about making site-wide changes without a fully representative discussion.  DGG ( talk ) 18:42, 17 January 2021 (UTC)
 * It was first proposed something like seven weeks ago, on this very page. -- Red rose64 &#x1f339; (talk) 21:23, 17 January 2021 (UTC)
 * Switch to Option A starting 0:00 UTC January 19 and keep Option A for the remainder of the month. Some1 (talk) 23:55, 17 January 2021 (UTC)
 * It's time to take it down, in my opinion. ~48 hours (the time period in which it was Wikipedia's birthday in at least one time zone) would have been long enough. --Yair rand (talk) 00:02, 18 January 2021 (UTC)
 * I would say take it down at 0000 tomorrow. That's enough.--Wehwalt (talk) 01:41, 18 January 2021 (UTC)


 * Option D is horrible (accepted by a mere 1 vote "majority"), the sooner it is gone, the better (yesterday was too late). Pavlor (talk) 06:16, 18 January 2021 (UTC)
 * Remove immediately I've been puzzling over the elements of the image.
 * strike 1: The four pictures are supposed to come from the official resources but only 3 of them do so – the mobile phone at bottom left is not part of that set, which has this instead to represent mobile usage.
 * strike 2: The top left image is supposed to symbolise Wikiversity, not Wikipedia. Using an icon intended for a different project seems quite erroneous.
 * strike 3: None of the icons created to symbolise the point of the occasion have been included – no cake, fireworks or even the number 20.
 * Andrew🐉(talk) 11:36, 18 January 2021 (UTC)
 * Switch to A ASAP. Leave A for 2 more weeks — GhostInTheMachine talk to me 11:48, 18 January 2021 (UTC)


 * Switch to A or Remove I !voted for D on the assumption that it was running for one day, it was unsubtle enough to (hopefully) be noticed by site visitors.  Agreed that's it's too flashy to stay medium- or long-term. <b style="color:#049">YorkshireLad</b>  ✿  <b style="color:#052">(talk)</b> 12:02, 18 January 2021 (UTC)
 * D has been on for long enough Switch to A sooner rather than later, or go back to the original. Not particularly concerned if A stays on for a month or so. &middot; &middot; &middot; Peter Southwood (talk): 15:52, 18 January 2021 (UTC)


 * Switch to A I'm OK if option A stays for a while (month to year). --Enos733 (talk) 16:14, 18 January 2021 (UTC)
 * Switch to A asap. The current logo is nice as a special for up to a week, but if we want to do something long term, then go to A or original. — Preceding unsigned comment added by JackFromReedsburg (talk • contribs) 00:52, 19 January 2021 (UTC)
 * I also think the current logo has run for long enough that we should switch to A. KevinL ( aka L235 · t · c) 09:03, 19 January 2021 (UTC)
 * I don't edit here much anymore, but I feel like one month is long enough for a celebration like this. I'm one of the few that actually like Option D as it is a special occasion, but I'm fine with Option A if consensus reaches that conclusion.  —   Gestrid  ( talk ) 14:29, 19 January 2021 (UTC)
 * Keep D until tomorrow (21st) and then switch to A and keep it until 15th April. -- <b style="color:black">CptViraj</b> (talk) 14:02, 20 January 2021 (UTC)

Duration next steps
I voted above, so need someone else to review next steps on the duration - seems like this is moving towards at least a "Change to special Logo A" soon (possibly during this weeks deployment) - though there were some concerns in another sections about the ambiguity of "billion" that may need to be addressed if we want that in the logo as well. So long as this is the next step, we've got time to determine how long "option A" will stay up once it is there, so determining that shouldn't block the switch to it if that is going to be the next step. — xaosflux  Talk 16:18, 18 January 2021 (UTC)
 * would agree w/ above editor as to next step (option A asap), as seems to be the majority of editors above...(as to duration 8 editors have indicated a year, and several others about a month; since this is an achievement which will not happen again, 1 Billion, why not keep it up between a few months to a year, I guess we can vote only on duration)--Ozzie10aaaa (talk) 18:37, 18 January 2021 (UTC)
 * Huh? Option D is still here. What's going on? ---Sluzzelin talk  01:03, 19 January 2021 (UTC)
 * GET OPTION A UP, Pronto! Mjroots (talk) 08:50, 19 January 2021 (UTC)
 * Nearly everyone working on this is a volunteer, and speaking for myself I can't exactly take another day off work to wrangle all of the stakeholders again. If swapping the logo immediately is important to you, be bold and do it; nothing I did required advanced permissions. Log on to #wikimedia-operations and ask someone to deploy option A, and if it helps point them to change 656268, patch set 1, which has option A prepped already. You can also ask an interface administrator to temporarily deploy option A using css (see MediaWiki manual) while waiting for ops to deploy the config change. — Wug·a·po·des​ 23:14, 19 January 2021 (UTC)
 * I don't think there is any "pressing need" to rush the change - and also until someone actually closes the RfC above we should be blocked on community consensus. — xaosflux  Talk 01:07, 20 January 2021 (UTC)


 * If this is going to be "Change D to (anything but the default)" please make a subtask of T272108 to track these together. — xaosflux  Talk 15:07, 19 January 2021 (UTC)
 * I've closed the discussion above and opened a subtask here: T272526. Mz7 (talk) 19:07, 20 January 2021 (UTC)
 * two weeks? (per pure math of the above 'duration' per editor it would seem at the least a month, if not more?)...update 'option D' is still up after two days??(22/1/21)--Ozzie10aaaa (talk) 19:36, 20 January 2021 (UTC)


 * FYI, there have been some technical issues with this, workarounds being looked in to at WP:IANB in the meantime. — xaosflux  Talk 14:52, 22 January 2021 (UTC)
 * I've now put this up. Please holler if anything looks busted or needs tweaking. ~ Amory <small style="color:#555"> (u • t • c) 16:09, 22 January 2021 (UTC)

margin overlap problem (resolved)
Guys, right now this looks like this on my main page: "" is cut off, and "Navigation" overlaps. It's like this on other pages also. Please fix. Cheers! BD2412 T 23:44, 14 January 2021 (UTC)
 * I see this has already been raised above. BD2412  T 23:47, 14 January 2021 (UTC)


 * this should be all patched in now, let us know if it isn't working for you please. — xaosflux  Talk 00:50, 15 January 2021 (UTC)
 * It's good enough. The overlap is gone, and the "" is all there, although it seems a bit sharp at the bottom. BD2412  T 00:53, 15 January 2021 (UTC)

image text accessibility problem
Can we fix the color combination in the 4th image....as of now not visible to color blind readers.-- Moxy 🍁 00:02, 15 January 2021 (UTC)
 * We can try. What color combination would look better for color blind users? You can see the palate at Wikipedia 20/Resources but feel free to pick whatever colors you think look best. — Wug·a·po·des​ 05:47, 15 January 2021 (UTC)


 * Accessible Colour Contrast.-- Moxy 🍁 06:04, 15 January 2021 (UTC)
 * this seems stalled, someone will have to want to work on this before the "duration" discussion decides to remove it -- feel free to mock up a new logo if you would like, but it's not a matter of just uploading it to deploy it to code either. — xaosflux  Talk 00:04, 16 January 2021 (UTC)

New image feedback
Take this for what it's worth to you, coming from an editor who mostly just does drive-by edits here and there and who's not really part of the "meta-community"... but the new temporary image is so garish it actually motivated me to try and find a place to discuss it. :) I find the colors distract from the article texts, and the overall "aesthetic" sort of reminds me of K-12 sites from 20 years ago. The drawings themselves are competently-executed, it's just really out of place in what has traditionally been a greyscale, unobtrusive area. I appreciate that someone put some time and energy into it and that at least several people seem to have figured it was okay enough to win the above vote, but... man... oof. Anyway, feel free to refactor or move this to wherever people are discussing the image post-implementation, not calling for anyone's head here, just felt like I had to speak out! WonnE66 (talk) 01:23, 15 January 2021 (UTC)
 * I concur with the above. It's really distracting when trying to read articles. 72.209.60.95 (talk) 01:29, 15 January 2021 (UTC)
 * I feel that going off-script is warranted for celebrating 20 years. I'm glad you found your way here to share your opinion though. To 20 more years! Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[ᴛ] 03:35, 15 January 2021 (UTC)
 * I am sorry to say that the new image -- which I dearly hope is only temporary -- is truly, truly  awful . I'm afraid this is one of those times when consensus really wasn't the best method to arrive at a good result. Beyond My Ken (talk) 03:54, 15 January 2021 (UTC)
 * yes, temporary above is discussing how temporary. —  xaosflux  Talk 04:21, 15 January 2021 (UTC)
 * Yes, it looks like clip art from Windows 95. Ceoil  (talk) 15:34, 15 January 2021 (UTC)
 * Question: Is it a known issue that when you go to "page information pages" (e.g. for the main page) it still shows the old logo? ( or other user with technical knowledge) Sam-2727 (talk) 05:53, 15 January 2021 (UTC)
 * , your cache has likely not updated. You can try purging your browser cache to fix it. Nihlus  06:07, 15 January 2021 (UTC)
 * , Thanks that worked Sam-2727 (talk) 14:28, 15 January 2021 (UTC)
 * Comment It should read "more than 1 billion edits" not "over one billion edits".  Lugnuts  Fire Walk with Me 09:18, 15 January 2021 (UTC)
 * , I agree ("more than" is better grammar, and I think "1" looks cleaner). I thought about bringing it up earlier but decided not to since I didn't want to risk derailing anything. &#123;{u&#124; Sdkb  }&#125;  talk 12:37, 15 January 2021 (UTC)
 * (Also, is anyone else super reminded of the McDonalds tagline haha?) &#123;{u&#124; Sdkb  }&#125;  talk 12:44, 15 January 2021 (UTC)
 * It seems symbolic not of 20 years ago, but 40: it brought back a memory of CGA graphics.  DGG ( talk ) 18:12, 17 January 2021 (UTC)
 * I never thought I would be so motivated to go out of my way to complain about a new (albeit temporary) logo, but here I am. I agree with BMK; it really is dreadful.--WaltCip- (talk)  20:40, 17 January 2021 (UTC)

Improve tooltip for red links
If a red link is supposed to indicate that an article on that subject is needed, and is not supposed to be used for anything else, and should be removed if misused, why is the only thing you see when you place the cursor over that word "the article does not exist". Why doesn't it say "article needed"? Imagine being a living person whose name is red-linked and all you see is "the article does not exist"! Wikipedia can be so confusing when it comes to living people. Sometimes we really care about how they are treated. Could we get that tooltip (cursor message) changed?

Proposal: Change the red link tooltip to read "Article needed". --SergeWoodzing (talk) 17:22, 14 January 2021 (UTC)
 * Hmm, interesting suggestion. Two questions that come to mind are: (1) Would we be concerned about erroneous overuse of red links (which, like it or not, happens) leading to the software encouraging the creation of non-notable articles? (2) Is there potential for confusion by moving away from the straightforward "page does not exist" to something else? Also, we'd need to refine a bit, since redlinks exist beyond just mainspace; for instance, I'm looking at a red link to Template:Editnotices/Group/Wikipedia:Village pump (proposals) from my current edit window, an example of a page that doesn't exist and probably shouldn't exist. We'd have to handle circumstances like that before moving forward with this sort of proposal. &#123;{u&#124; Sdkb  }&#125;  talk 17:37, 14 January 2021 (UTC)

Comment: the tooltip adds (page does not exist) to the name. Page, not article. CapnZapp (talk) 18:58, 14 January 2021 (UTC)

I think the description should remain literal, rather than assuming that every dangling link indicates a page is needed. isaacl (talk) 19:00, 14 January 2021 (UTC)
 * Much less that every red link is for an "article". — xaosflux  Talk 19:05, 14 January 2021 (UTC)

"Imagine being a living person whose name is red-linked and all you see is "the article does not exist"!" Okay, I'm imagining it. My reaction? So? It simply means that no one has written about me at this time. Is that supposed to bother me? --Khajidha (talk) 01:23, 15 January 2021 (UTC)

To add on to what others are saying, I've occasionally seen red links for articles that have been AfDed. Needless to say, those are almost definitely not needed.- <span class="nowrap" style="font-weight:700;font-size:85%;transform:rotate(358deg);display: inline-block;">Novov T  C  08:07, 15 January 2021 (UTC)
 * in practice, ti appears whenever the article is not there for any reason: this may be because the article is needed, but it an also appear because the article has never been &should never be written  because it would be inappropriate to do so for any one of a variety of reasons, or   because of a typographical difference or mis-spelling. In the first case, the correct way to deal with it is to write the article; in the second, to either leave it alone or remove the link, in the third case to make a redirect if it's likely to be more than just idiosyncratic. Perhaps might do well to have more specificity--but considering the possibility of misuse and confusion, we might do just a swell to let things be, and leave it to the judgment of the editor encountering the link.   DGG ( talk ) 11:06, 17 January 2021 (UTC)
 * Red links, ugh. They're even using them in citations. What would it hurt to simply do away with them? If you're taking time to redlink, just create the article. We've got enough delegators on WP as it is when coupled with format tagging, etc. <span style="text-shadow:#F8F8FF 0.2em 0.2em 0.2em,#F4BBFF -0.2em -0.2em 0.2em,#BFFF00 0.4em 0.4em 0.5em;color:#A2006D"> Atsme 💬 📧 15:50, 17 January 2021 (UTC)
 * Back in the day, there was actually a rule that when creating an article, you should deliberately and obviously leave something unfinished. The idea was that it was an invitation to others to join in.  I don't think anyone saw it as an attempt to boss people around. WhatamIdoing (talk) 20:11, 22 January 2021 (UTC)

RFC at WP:POLITICS
See here for RFC on US party nominee succession boxes in US political bios. GoodDay (talk) 21:02, 23 January 2021 (UTC)

Replace hyphen with en-dash in Wikipedia browser tab name – MediaWiki:Pagetitle
HTML tag &lt;title&gt; defines the text, which web browsers usually use to label tabs. The &lt;title&gt; tag on English Wikipedia is controlled through the page MediaWiki:Pagetitle (see mw:Manual:Interface/Pagetitle for details). English Wikipedia uses the default $1 -, where $1 is replaced by the full page name, magic word {{SITENAME}} is substituted to "Wikipedia", and they are separated by a spaced hyphen. For example, this page has Wikipedia:Village pump (proposals) - Wikipedia. Different wikis use different separators. Examples (note that wiki-local internationalization preferences affect the page title—use incognito/private tab to see actual tab name): I propose replacing the hyphen at English Wikipedia's MediaWiki:Pagetitle with an en-dash, which is a more appropriate separator—see MOS:ENDASH. —⁠andrybak (talk) 16:29, 3 November 2020 (UTC)


 * I don't think this is necessary, and keep in mind would only change for users with the English interface language set (everyone else will still get the system default). —  xaosflux  Talk 18:29, 3 November 2020 (UTC)
 * Support per MOS:ENDASH. This seems like a pretty simple grammar fix (albeit with a huge scale), so I'm not sure it needs a giant discussion here, but I'm also not sure where else the discussion would've been hosted, so I can see why you brought it here. To speak to Xaosflux's point, this shouldn't be something that only applies to English, so if we can figure out how to apply it to all languages, that'd be even better. &#123;{u&#124; Sdkb  }&#125;  talk 22:56, 3 November 2020 (UTC)
 * Shouldn't the punctuation on each project conform to its own language and MOS? The MOS on enwiki would certainly indicate that an en dash, not a hyphen, should be used here, but an em dash or hyphen may be correct in other languages. A centralized discussion on Meta would be a good place to confirm that each project's tab punctuation adheres to its own MOS. Armadillo  pteryx  00:46, 4 November 2020 (UTC)
 * Meh for en.wiki; they're all just horizontal lines. 99% of users have never noticed, and of that 1%, 96% won't care. None of our business for all other wikis.  I assume I'm misunderstanding Sdkb's comment; you aren't suggesting that the result of a discussion here should affect all other wikis? --Floquenbeam (talk) 23:29, 3 November 2020 (UTC)
 * From what Xaosflux said above, it seems that a fix might only apply to the English Wikipedia with the English language interface set, not all language interfaces. We control all language interfaces on English Wikipedia. As for other Wikipedias, it might be nice to standardize among those, but that discussion would probably have to be held somewhere on Meta. &#123;{u&#124; Sdkb  }&#125;  talk 23:35, 3 November 2020 (UTC)
 * It's very likely you know more than me about this. But "We control all language interfaces on English Wikipedia" doesn't sound right at all.  I think I must be missing a subtlety or distinction or term of art?  Anyway, it isn't important that I understand.  As long as you're not saying we should make changes for, say, es.wiki or Commons too - which it looks like you're not saying - then we're good. --Floquenbeam (talk) 23:42, 3 November 2020 (UTC)
 * In Special:Preferences you can set your language. If unset or set to a language that doesn't have a locally created MediaWiki page, there is a default MediaWiki page used. Killiondude (talk) 00:19, 4 November 2020 (UTC)
 * MediaWiki has a framework to support translations into different languages in its own user interface messages, as described by Killiondude, which is what Sdkb is describing regarding having control over all language interfaces on English Wikipedia. It has been long recommended for users not to change their preferences to another language, though, as a lot (most? all?) of customized messages have not been translated (and as I recall, even specifying a country-specific English variant, like en-uk, will cause a fallback to the default message, thereby losing the customization). isaacl (talk) 00:36, 4 November 2020 (UTC)
 * actually it seems that if a custom message is set but not translated, the custom message is used. At least in the sidebar - go to https://en.wikipedia.org/wiki/Earth?uselang=de (an en.wp page but with the interface language set to German). The second item in the "contribute"/"Mitmachen" section is the custom English "Learn to edit" in both English and German interfaces rather than the default "Introduction" / "Einführung". Thryduulf (talk) 01:41, 4 November 2020 (UTC)
 * You can see what impact changing the interface language would have by appending  (where xx is the language code you want to use) to the URL (or   if the URL already contains a ?). For example go to https://en.wikipedia.org/wiki/Earth?uselang=de to see an English Wikipedia article with the interface language in German. The article text remains in English, but all the tabs, sidebar links, etc. are in German. Thryduulf (talk) 01:41, 4 November 2020 (UTC)
 * It took you all more effort than it was probably worth, but I finally understand. Thanks everyone for the patient explanations, sorry everyone for being technologically incompetent, and sorry User:Sdkb for momentarily implying you might have been saying something crazy. --Floquenbeam (talk) 16:26, 4 November 2020 (UTC)
 * No worries at all! &#123;{u&#124; Sdkb  }&#125;  talk 19:31, 4 November 2020 (UTC)
 * Support this change on enwiki (and other English-language projects) per MOS:ENDASH; projects in other languages should make sure the dash (or hyphen) used conforms to their own MOS. Armadillo  pteryx  00:46, 4 November 2020 (UTC)
 * previous relevant discussion: . —⁠andrybak (talk) 01:08, 4 November 2020 (UTC)
 * Support, hyphens are not used for this purpose, WP:NDASH. <b style="border:1px solid #0800aa"> Nixinova </b> <b style="border:1px solid #006eff"> T </b> <b style="border:1px solid #00a1ff"> C </b> 02:23, 4 November 2020 (UTC)


 * Support. It's a tiny, tiny thing...but honestly, I would be happy to see it happen.—Neil Shah-Quinn (talk) 15:11, 6 November 2020 (UTC)
 * Support on enwiki per Armadillopteryx. &#12296; Forbes72 &#124; Talk &#12297; 16:28, 6 November 2020 (UTC)
 * should an RFC be opened to gather more feedback? —⁠andrybak (talk) 16:01, 8 November 2020 (UTC)
 * Support – It shouldn't be a question that our interface should generally conform to the MOS absent any reason to the contrary. 207.161.86.162 (talk) 03:26, 9 November 2020 (UTC)
 *  Tentative support , but I am wonder whether there is a technical reason that hyphens in page titles are so common, even for sites with strict style manuals. For example, both the New York Times and the BBC have hyphens in their page titles. Indeed, it looks like every site in my browser bookmarks that has equivalent punctuation has a hyphen (except that my university's Blackboard Learn site has both a hyphen and an en dash in the title, which looks quite ugly now that I have noticed it). Any thoughts about why that might be? blameless  21:01, 9 November 2020 (UTC)
 * Withdrawing my support per the below and continued investigation. It was said above that "hyphens are not used for this purpose"--I am certainly a descriptivist, and I would say that hyphens are used for this purpose for purely internet-based instances of language (such as browser tabs) that are entirely separate from prose content, for the sake of consistency and reliability across browsers and character sets. Neutral. blameless  19:26, 26 November 2020 (UTC)
 * Oppose or replace with pipe. Browser tabs have limited horizontal space, and the only effect of this proposal is to waste a bit more of it. Perhaps this is why it is so common to use a hyphen or a pipe rather than an en-dash or em-dash. ST47 (talk) 21:29, 9 November 2020 (UTC)
 * , I'd have thought that the pipe would take up less space than an endash. I've tested in Firefox and Chromium in Ubuntu. In Firefox the pipe takes up more space than endash (font Noto Sans 10pt). In Chromium both take up the same amount of space (I couldn't figure out which font is used). —⁠andrybak (talk) 23:06, 9 November 2020 (UTC)
 * My browser (Firefox on Debian) follows our page title (and every other page title) with " - Mozilla Firefox" so using a dash or pipe would make my browser title look weird. Is that enough to oppose? I don't know, but clearly hyphens are pretty standard separators in how browsers display page titles. Additionally, it's probably better that our page titles are ASCII-compliant, and this change would move us away from that. This could affect page downloads or distribution on offline hardware. My main concern is that we gain pretty much no benefit, but there might be hidden problems it introduces. — Wug·a·po·des​ 23:55, 9 November 2020 (UTC)
 * Meh Not worth the trouble for all the reasons Wugapodes mentioned. Probably nothing will break, but the benefit is so small it's not worth doing. The hyphen-minus is also the standard window title element separator on every non-Apple platform. An en/em dash will take up more space, which is undesirable. Switching to pipes would change the visual style, and I'm not a fan of that idea either (the hyphen-minus is the most common separator anyway. --AntiCompositeNumber (talk) 00:27, 10 November 2020 (UTC)
 * Oppose Browser has limited space. Also, the proposal text doesn't clearly say which Hyphen is currently used. Hyphen-minus is ASCII. If it currently is ASCII, then stay with ASCII for less interference with third party systems. TerraCyprus (talk) 23:26, 10 November 2020 (UTC)
 * Sticking to ASCII is about 3 decades out of date, and is in general too limiting, even for English. Dicklyon (talk) 21:56, 10 December 2020 (UTC)
 * , regarding If it currently is ASCII, then stay with ASCII for less interference with third party systems. tag &lt;title&gt; already contains dashes and much more of the Unicode. E.g. Ágústa Þorsteinsdóttir, 燒酒. —⁠andrybak (talk) 16:59, 31 December 2020 (UTC)
 * Meh (Is Meh a valid voting option?) The title is also used for bookmarks, and so the site suffix has some value there, but I generally edit the titles to make sense to me and normally remove the suffix. Most of the time the tab is too narrow to display all of the article title, so the "- Wikipedia" site suffix is lost anyway. Personally, I would delete the site suffix from the titles as the icon at the start is enough to identify the tab, but I do suspect that would be seen as a step too far — GhostInTheMachine talk to me 11:59, 14 November 2020 (UTC)
 * Meh because I'm not sure I'll ever encounter a Wikipedia debate that warrants "meh" as much as this one. I'm sympathetic to both sides, but would probably favor the character that can be entered with one tap of the keystroke and is easily identified by non-native English speakers who don't even know what an en- or em-dash is. On the other hand no one's really going to be typing this on their own. Also, what were French and Russian Wikipedias thinking when they instituted the em-dash? -- Fuzheado &#124; Talk 20:46, 16 November 2020 (UTC)
 * , Russian Wikipedia's MOS is based mostly on current Russian grammar and typography practices. Same is probably true for the French Wikipedia. —⁠andrybak (talk) 07:49, 23 January 2021 (UTC)
 * I have requested closure of this discussion at WP:ANRFC. —⁠andrybak (talk) 18:25, 23 November 2020 (UTC)
 * Support. The use of the hyphen here is an old "lazyism" from pre-MOS:DASH days. Should have been corrected a long time ago.  — SMcCandlish ☏ ¢ 😼  03:49, 8 December 2020 (UTC)
 * Support –definitely. It's professional English, and apart from being in accordance with the major style guides (including ours), it's slightly easier to read. I don't care if other languages want to stick with their shabby little hyphens. <b style="color:darkgreen">Tony</b> (talk)  09:34, 8 December 2020 (UTC)
 * Yes, Support the hyphen is a lazy substitute for the intended punctuation, a dash of some sort. The spaced en dash is a good choice. Those who won't notice the difference won't be bothered. Dicklyon (talk) 06:58, 9 December 2020 (UTC)
 * Support. It's a very minor thing, but we may as well follow proper professional usage. Alkari (?), 10 December 2020, 04:29 UTC
 * Oppose Pretty much what Floq said. I don't have a real "side" as far as the actual issue, because, like most people, to me the distinction is essentially meaningless. (Please, please don't feel compelled to explain to me how very important it is) So, the only concern here is "will this break anything?" And it seems that a few people here are concerned that it might. So, very, very little benefit (arguably none at all) and some risk, so that's a no for me. Beeblebrox (talk) 00:04, 19 December 2020 (UTC)
 * Support. I found myself on both sides while writing this comment, but settled in support. The MOS is clear that an en-dash is preferred over a hyphen as a separator here. The most cogent objection is that the en-dash may cause certain technical issues, and there's a lesser point that it takes up more space. However, this same reasoning would apply to our many articles that are titled with – or — instead of -, or indeed any other non-ASCII characters, which all show up in the tag. And yet, MOS:DASH has been in place for article titles for many, many years with no apparent problems. The fact that dewiki, frwiki, and ruwiki all use some form of dash also supports this point. We can always revert the change if we find out about some unexpected side effect. —  The Earwig   talk 06:11, 27 December 2020 (UTC)
 * Oppose If it works, don't fix it. Andrew🐉(talk) 13:00, 28 December 2020 (UTC)
 * Oppose Why so many people have this thing for a character that's not standard and cannot be typed is beyond me. It's constantly forced down our throats for no reason. - The Bushranger One ping only 07:20, 31 December 2020 (UTC)
 * , regarding a character that's [...] cannot be typed. On Windows, it can be typed using the Win menu (under Ω tab), on macOS it is Option, on most Linux distributions it is Alt (via XCompose feature), on Android and iOS most keyboard apps support it on long press of the hyphen -. On Wikipedia, the en-dash can be inserted using both the editor toolbar (Special Characters > Symbols) and CharInsert extension (first character in the "Insert" group)—both UIs are enabled by default. Also, there is HTML entity . —⁠andrybak (talk) 16:44, 31 December 2020 (UTC)
 * And it doesn't matter anyway in this context. Bushranger's "utility" argument is inapplicable to something that is simply part of the interface display.  — SMcCandlish ☏ ¢ 😼  22:50, 1 January 2021 (UTC)
 * Support per MOS:ENDASH resp. Sdkb and particularly 207.161.86.162 and SMcCandlish, who both expressed my view very succinctly. Similar to The Earwig, I was wavering for some of the same reasons, but above all because of GhostInTheMachine's statement. However, my support was strenghened when I saw that a significant portion of the Oppose votes were because of a fear that something could break, which is absurd IMO given andrybak's point that the title already often contains non-ascii characters. ◅ Sebastian 20:38, 1 January 2021 (UTC)
 * Support. It's small change but conforms better to English style guides. I don't see how typing it is such a problem. This is not a change that implies the need of manually entering the character, and MOS:ENDASH already mandates it for a lot of content. --MarioGom (talk) 14:25, 4 January 2021 (UTC)
 * Support, per the MOS & correct punctuation. Cavalryman (talk) 04:23, 6 January 2021 (UTC).
 * Support it's hard to take a side here, and indeed I don't take either with much confidence. But as a small change that better conforms with MOS and standard English, I think we may as well. Aza24 (talk) 01:39, 8 January 2021 (UTC)
 * Don't think MOS applies to page titles. Most sites - massive, big, and small - use a hyphen in page titles. English Wikipedia would be sticking out like a sore thumb. Keep the hyphen. ProcrastinatingReader (talk) 16:40, 13 January 2021 (UTC)
 * Support. MOS:ENDASH. Personally, I was quite getting used to this.  Mario Jump  83!  04:32, 15 January 2021 (UTC)

Proposal: Adding more links in the sidebar in mobile view
I think that the mobile view should have more links directing users to appropriate places. I think one link that should be added is a help link and tutorial. I will create specific sections to try to propose and hopefully get community support for the idea. I am now editing in mobile view more than desktop view now and hopefully these changes will help Wikipedia become a more user-friendly site in the future. Interstellarity (talk) 16:57, 24 January 2021 (UTC)

Add a help link in the sidebar linking to Help:Contents

 * 1) Support as proposer. Interstellarity (talk) 16:57, 24 January 2021 (UTC)

Add a tutorial link linking to Help:Introduction

 * 1) Support as proposer. Interstellarity (talk) 16:57, 24 January 2021 (UTC)
 * Question....I don't see any sidebar in mobile view..do you mean the top banner? Also is the tutorial accessible to you in mobile view? -- Moxy 🍁 17:09, 24 January 2021 (UTC)
 * I’m talking the hamburger menu in mobile view to clarify. Interstellarity (talk) 17:24, 24 January 2021 (UTC)
 * Oh and I forgot to answer your second question. I had no problems with viewing tutorial on my mobile device. Interstellarity (talk) 18:44, 24 January 2021 (UTC)

General discussion
I find mobile extremely complex, since there's not just one mobile version—there's the mobile web browser, the mobile web browser in advanced mode, the Android app, the iPhone app, and possibly others I'm forgetting. I agree that it'd be good to have some discussion about which links from the desktop left sidebar to include on the mobile version, but without knowing exactly what's currently there for the different mobile versions or what the space/design considerations are, it's hard to make judgements about specific changes. &#123;{u&#124; Sdkb  }&#125;  talk 03:08, 26 January 2021 (UTC)

RfC: Should we have Support/Oppose/etc. survey convenience templates?
Should we have survey convenience templates? Mike Peel (talk) 22:07, 1 January 2021 (UTC)

While WP:NOTVOTE is really important, we have a lot of discussions/debates (like this one) that people Support/Oppose and comment on. A lot of the Wikimedia projects use templates like Support, Oppose etc. to help with this, often also including a symbol. These templates were deleted here back in 2005, mostly because people objected to the inclusion of the symbol.

In this RfC I propose restoring these templates but without the symbol. This would mean that editors could use  rather than , but it would look the same. It would not be compulsory to use one or the other, and of course the !vote should be accompanied by a rationale regardless. The templates would simply be a convenience for editors that are used to using the other syntax, and would avoid a lot of follow-up edits to fix formatting after trying to use the templates instead of the bold formatting (which I at least frequently do, either after saving or in preview!). Their use would have negligible impact on server load (another concern from 2005), but could easily be bot-substituted (by batches every day/week/month) if that really is still a concern.

(These templates have been frequently recreated since their deletion, to the extent that it is a perennial request (the difference with this !vote is that it's to meet cross-wiki expectations, and I'm not proposing to use icons). I originally took this to WP:DRV last month as per the latest deletion/protection edit summaries, but an RfC was recommended instead.)

Thanks. Mike Peel (talk) 22:07, 1 January 2021 (UTC)

Survey (survey convenience templates)

 * Support as proposer. Thanks. Mike Peel (talk) 22:07, 1 January 2021 (UTC)
 * Oppose As I would typically say in TfD, insufficient complexity of markup to warrant a template. I completely fail to see the point of creating a template whose content is its name with three apostrophes prepended and appended, when that is only two characters longer than typing the wikitext out in the first place. * Pppery * <sub style="color:#800000">it has begun... 22:27, 1 January 2021 (UTC)

Notified: Wikipedia talk:Templates for discussion. * Pppery * <sub style="color:#800000">it has begun... 22:31, 1 January 2021 (UTC)


 * It's not about the number of characters, it's about the time it takes to remember the syntax, and that the syntax shouldn't depend on which Wikimedia project you are using. The human cost is much more than the syntax cost. It's the same as tq vs. this alternative way of writing it. Thanks. Mike Peel (talk) 22:38, 1 January 2021 (UTC)


 * I would prefer to type “ ” rather than “ Support ” because the “'” character is not on the iPad keyboard.  could be made to auto-subst.  Oppose cut or gaudy pictures. —SmokeyJoe (talk) 23:05, 1 January 2021 (UTC)
 * my iPad allows me to type a '. Switch the keyboard to punctuation, then press and hold the ‘ key. The pop up menu offers you 4 differs types of quote symbol — GhostInTheMachine talk to me 23:36, 1 January 2021 (UTC)
 * That was a nice trick to learn! Thank you.  Unfortunately, it is very tedious to do the six times. --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)
 * or just type Oppose, select the word and click the B on the editing toolbar — GhostInTheMachine talk to me 23:48, 1 January 2021 (UTC)
 * Yeah that works. Unfortunately, the toolbar is above the fold.  I wish it could be moved to below the editing window.  --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)
 * Or you could just try convincing people using words instead of syntax. —Cryptic 06:39, 2 January 2021 (UTC)
 * I like the simple bold of the lede word of the !vote. Do you dislike that low level of syntax?  This !vote bolding culture underlies the working of https://afdstats.toolforge.org/, which is sometimes a nice tool.  --SmokeyJoe (talk) 07:00, 2 January 2021 (UTC)
 * One possible work around is to use iOS's text replacement feature (Settings -> General -> Keyboard -> Text replacement). You can choose any sequence of characters to be replaced by another. For example, you could choose bqq to turn into ''' (three single quotes.) isaacl (talk) 20:23, 9 January 2021 (UTC)
 * Oppose Sorry but no. I understand that moving between projects is a mental pain (I struggle with the equivalent of xxx at Commons) but hiding simple syntax does not help the project. Some projects appear more focused on a vote count, and that idea should not be encouraged here. Johnuniq (talk) 23:08, 1 January 2021 (UTC)
 * Oppose per Johnuniq's comments, especially about hiding syntax. We should not be encouraging anything that gives the impression that votes are more important than the rationale accompanying them. Thryduulf (talk) 23:14, 1 January 2021 (UTC)
 * How exactly does the existance of a convenience template give that impression, please? Thanks. Mike Peel (talk) 21:07, 3 January 2021 (UTC)
 * the existence of a template, regardless of the formatting it outputs, elevates the importance of that output - if it wasn't important then why would anybody make a template for it? Why would any template be kept if it wasn't adding something of value? Experienced editors will unlikely gain this impression, but that is not necessarily true of those who are new to Wikipedia or who have a limited understanding of how XfD discussions work (if there wasn't an impression they are votes then we wouldn't need boilerplates like ). Thryduulf (talk) 23:57, 3 January 2021 (UTC)
 * I disagree with that thinking, I don't think having the template would give any more weight to a new user's thinking that they can !vote than seeing a list of bold-formatted support/oppose votes that they could copy/paste would. Thanks. Mike Peel (talk) 09:30, 4 January 2021 (UTC)
 * Oppose what would the Support template expand to, other than Support in bold? — GhostInTheMachine talk to me 23:45, 1 January 2021 (UTC)
 * I would have the string auto-change and substitute to Support .  I would find it useful, for the same end result.  --SmokeyJoe (talk) 04:34, 2 January 2021 (UTC)
 * weak support I don't think it unreasonable request--no reason to make anyone's editing harder and it sounds like there are a few people it would help. That said, the help is minor and the worries about a slippery slope to voting aren't utterly trivial. So a small thing that helps people now vs. a very unlikely thing (but not impossible) that might hurt the culture down the road? I'm gently leaning toward the short-term gains being worth the improbable long-term risk. Hobit (talk) 04:32, 2 January 2021 (UTC)
 * Oppose per Johnuniq ~ HAL  333  04:45, 2 January 2021 (UTC)
 * weak Support If we can have Agree and Disagree why not Support or Oppose? RudolfRed (talk) 05:03, 2 January 2021 (UTC)
 * Like this: ✅ →  ✅.  Now, how to lose the gaudy green tick?  --SmokeyJoe (talk) 06:55, 2 January 2021 (UTC)
 * strong?  →  .  --SmokeyJoe (talk) 07:06, 2 January 2021 (UTC)
 * Does it substitute?  Support →  <strong     >Support .  --SmokeyJoe (talk) 07:46, 2 January 2021 (UTC)
 * <strong    >Support .  Oh dear, that's a mess of wikimarkup, isn't it.  --SmokeyJoe (talk) 07:48, 2 January 2021 (UTC)
 * Usually I eschew starting my comment with a bolded word, precisely to place emphasis on discussion over voting. Assuming the community is truly dedicated to making decisions through discussion, I do not favour having templates that give more prominence to votes. isaacl (talk) 07:18, 2 January 2021 (UTC)
 * the opposite is that there are so many words in a section that prefacing the section with a bold helps you know what to expect, especially in confusingly worded arguments you know better what they're trying to get at. eg when closing RfCs I don't necessarily close based on vote, but knowing a binary yes/no before a comment helps follow the comment and get a general feel of where the discussion lies. ProcrastinatingReader (talk) 19:20, 2 January 2021 (UTC)
 * I wrote something similar once about how knowing where an argument is heading can help provide context and thus improve understanding. Nonetheless, it can be done with a thesis sentence, rather than a single bolded word. I appreciate many people like starting with a single bolded word. I believe, though, that it puts more emphasis on voting and tabulation of votes versus discussion. isaacl (talk) 19:28, 2 January 2021 (UTC)
 * User:Isaacl, you are assuming that others find it as easy to read or write a thesis sentence as you do. E.g. people with dyslexia, ESL, inexperience with writing topic sentences) I personally struggle to summarise positions into a sentence for many reasons. It was also helpful to me as a new editor that there's a format which people are generally using to help me feel able to engage with discussions. --Xurizuri (talk) 11:33, 12 January 2021 (UTC)
 * If someone can't, that's OK. Starting with "I support the proposal," is fine. If we're trying to encourage discussion amongst those who have opted to contribute to a writing project, though, I think it's reasonable to aspire for participants to craft a concise explanation of their viewpoint. Though it'll likely remain an ideal, it's a good target to aim for. isaacl (talk) 17:00, 12 January 2021 (UTC)
 * The practice became widespread because editors felt it worked best. It has persisted because editors continue to feel it works best (for the most part, although many surely do it because they see others doing it). To my mind, there is no higher principle than that, and there is something to be said for consistency in formatting (some handle the variation better than others, and I'm in the latter group). But whether to use a bolded first word and whether to create templates for it are separate and independent questions. &#8213; Mandruss  &#9742;  18:42, 12 January 2021 (UTC)
 * Yes, as I said, I appreciate many people like to start their response with a bolded word. isaacl (talk) 01:01, 13 January 2021 (UTC)
 * I'll support such templates, not because I'd use them myself, but I see no justification for preventing other people from using them. When instructions are given for how to participate in XFD discussions, a summary word in bold is suggested. On the rare occasions when I take part in such discussions on other wikis I have to go round searching other people's comments for the appropriate syntax so I can sympathise with the difficulties of occasional !voters here. Thincat (talk) 09:48, 2 January 2021 (UTC)
 * Oppose. This is a good example of the failure to understand the cost of complexity in terms of barrier to entry. Multiple ways to accomplish the same thing is unnecessary complexity, unjustified by the perceived need to let every editor "have it their way" (apparently because they are unpaid). Anyway, the template syntax is no less prone to typing error than the markup. In the worst case the editor can omit the bolding and it may be fixed by another editor per TPO. To the extent that is not done, a few very rare cases of unbolded !votes are not a significant problem. &#8213; Mandruss  &#9742;  11:29, 2 January 2021 (UTC)
 * OPPOSE - The goal is simply to highlight what your opinion is. There are lots of ways to do this. As demonstrated here, ALL-CAPS works too. Blueboar (talk) 14:16, 2 January 2021 (UTC)
 * To disincentivise plain voting, we could adopt these templates, but ensure they only output an empty string :) – Uanfala (talk) 16:56, 2 January 2021 (UTC)
 * Oppose This is NOT a problem. No SOLUTION is necessary.  GenQuest  "scribble" 22:02, 2 January 2021 (UTC)
 * Oppose - per User:GenQuest and User:Mandruss (and probably a few others that I agree with for other points). Or, if you wish for greater detail, why would we decrease inconsistency between multiple projects by increasing inconsistency in one project? Having the same method for producing bold "oppose" and "support" as is used for making other things bold throughout Wikipedia is beneficial to the general run of users on Wikipedia.--Khajidha (talk) 00:33, 3 January 2021 (UTC)
 * Support. Minimal implementation cost, minimal burden on other users, and well-defined use case. Thincat put it well. I understand the instinctual "no voting templates!" response, but there's no icon and no emphasis on the opinion. It would be a good idea to brainstorm ways to enforce current community norms around !voting if these templates are created, though. Enterprisey (talk!) 00:52, 3 January 2021 (UTC)
 * Sure. If there are no icons, Support and Oppose become shortcuts for wiki markup. As with SmokeyJoe I use an iPad to edit Wikipedia, and typing would be slightly better for me than Support . I also agree on what Thincat and Enterprisey said. <b style="background:#000;color:#FFF;padding:1px;">GMX</b> (on the go) 16:00, 3 January 2021 (UTC)
 * Support The cognitive dissonance of people typing  in this discussion is remarkable.  Andy Mabbett ( Pigsonthewing ); Talk to Andy; Andy's edits 16:19, 3 January 2021 (UTC)
 * As one of the several people who have explained why a template producing the same output as  is not desirable I find this ad hominem to be in rather bad taste. Thryduulf (talk) 20:40, 3 January 2021 (UTC)
 * Andy has a point here about how people comment regardless of the existence of the template, it's not an ad hominem. Thanks. Mike Peel (talk) 21:07, 3 January 2021 (UTC)
 * Effectively calling everyone idiots, without explaining why they're being called idiots, sort of looks like an ad hominem, doesn't it? – Uanfala (talk) 21:45, 3 January 2021 (UTC)
 * if Andy has a point other than insulting the intelligence of people with a different opinion on these templates to him then I am at a loss as to what it is. I can't prove it, obviously, but the impression I get is that he has read only the bolded words (which would be rather ironic for this discussion). Thryduulf (talk) 23:57, 3 January 2021 (UTC)
 * Competent editors can see that Andy's comment was 100% insult and 0% argument, and therefore a "not-not-vote" of no consequence. A competent closer, if there is a closer, would simply discard it. &#8213; Mandruss  &#9742;  16:10, 4 January 2021 (UTC)
 * weak support I would not use it, but why not have such a template if it makes it easier for some? Graeme Bartlett (talk) 02:52, 4 January 2021 (UTC)
 * Oppose. Tends to encourage voting rather than discussion aimed at generating a consensus. Solution looking for a problem. Stifle (talk) 09:56, 4 January 2021 (UTC)
 * OPPOSE per Thryduulf, isaacl and Stifle. Those who can't write bold should use the workarounds mentioned above, address their shortcomings (which would help in a far wider range of applicability) or simply write all caps, as Blueboar suggested. ◅ Sebastian 11:17, 4 January 2021 (UTC)
 * Oppose per Johnuniq, Mandruss and GenQuest - This really is a solution looking for a problem. I appreciate Commons etc use Support however we're not Commons, Every project has their own way of doings things and " Support " is our way of doing things. Personally I use " Support " on all projects as it's what I'm used too (unless it looks out of place which I then change it after (ie with RFAs etc)). – Davey 2010 Talk 11:30, 4 January 2021 (UTC)
 * Support: trivial implementation, no disruption of previous practices, no migration cost, aligns well with other Wikimedia projects, probably slightly less chance of unbalanced markers (e.g. 2x2 vs 3x3). --MarioGom (talk) 14:06, 4 January 2021 (UTC)
 * As much as I myself mostly start comments with a bold oppose text, I don't think this a template necessary. Firstly, per there being a wide range of commonly used !vote strings and having a template for each is a massive overkill. Will we be needing for Option 2 or something? This proposal fails to list (even as example) the actual templates, there are surely more than the two mentioned. And having only a few of these will just create extra differences in markup. I would want to see some statistics of the commonly bolded terms in discussion first. Furthermore, the non-existent complexity of the output does not warrant a template, it is unnecessarily convoluting what is a simple text message, nor is having (even more) templates in text helpful when it's literally default bold syntax. Then there's grammar -- what if I want it lowercase or add other words that need bolding? These just feel like ballot checkboxes rather than a summary of the opinion to follow. Finally, pretty sure this will just make using visual editor way more complicated needing to insert a template when one could have clicked/tapped bold like is standard in every other text editor. —  HELL KNOWZ   ▎TALK 14:39, 4 January 2021 (UTC)
 * This is a good point - the common recommendations at current discussions are: "allow recreation", "containerize"/"containerise", "convert to an article"/"write an article", "delete", "disambiguate", "draftify", "dual merge", "endorse", "keep", "listfy", "merge", "move", "oppose", "overturn", "purge", "redirect", "refine", "relist", "rename", "rename", "restore", "retarget", "reverse merge", "revert", "setindexify", "soft redirect", "split", "subst", "support", "upmerge", "userfy", "wrap"/"wrapperify" and "wrong venue". Then you have modifiers like "all", "don't", "for now", "in principle", "leaning", "speedy", "strong", "weak" and "without prejudice" and non-recommendation bolds like "comment", "note", "question" and "update". Covering all these would need between 40 and 50 templates. Thryduulf (talk) 13:09, 5 January 2021 (UTC)
 * We're only talking about the most common uses of such templates, which are also used on other wikis, like those mentioned in the proposal. There's a latin phrase you could use to explain your comment if you want, though. Thanks. Mike Peel (talk) 22:04, 5 January 2021 (UTC)
 * These are the the recommendations used multiple times in a current discussion and/or in multiple current discussions on en.wp (AfD, RfD, CfD, TfD, MfD, DRV, MRV and RM; although there were none exclusive to MfD). To be useful to editors at en.wp they will need to cover the !votes they will commonly make otherwise they will frequently have to use the standard ''' markup which negates the whole point of having templates in the first place. What other wikis do is not relevant to discussions on the English Wikipedia. Thryduulf (talk) 00:43, 6 January 2021 (UTC)
 * Why not I would never use them, but that doesn't mean that others wouldn't find them useful. Most of the oppose votes are people who have no personal use for them.  Why is this even a vote?  The OP could have saved themselves some trouble by just creating them.  I am struggling to figure out why we needed to even have this discussion/vote.  -- Jayron <b style="color:#090">32</b> 15:43, 4 January 2021 (UTC)
 * No trouble would have been saved by doing that, because (a) the templates are salted and (b) I would have tagged than as db-g4 if I had noticed them being recreated. We would have ended up here anyway after a few more rounds of bureaucracy. * Pppery * <sub style="color:#800000">it has begun... 15:47, 4 January 2021 (UTC)
 * It's quite apparent that this is controversial. Sure, people often slip in new templates that would be controversial if discussed beforehand, but I don't consider that good faith practice. Editors are less likely to challenge by WP:TFD because it's such a hassle (and, for some, because they aren't aware of TfD or don't have the time to learn how to use it correctly). If the creation of a template were as easily challenged as an ordinary edit, standard BRD process would work fine, but that is unfortunately not the case. I commend the proposer for "discussing first" in this case, despite the fact that it likely would have been easier to get forgiveness than permission. &#8213; Mandruss  &#9742;  16:38, 4 January 2021 (UTC)
 * My primary concern is that templates (in general) too often shift from being “optional” to being “preferred” ... and then to “expected” and finally to essentially “mandatory”. I know this is not the intent here, but I have seen this shift occur too many times with other templates to be comfortable with it now. Blueboar (talk) 17:03, 4 January 2021 (UTC)
 * Definitely not the intent here. I can't say that this won't happen, but if it does, then presumably it would be accompanied by discussions that you and others (including myself) could object to. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
 * My experience with “template creep” is that there often isn’t any discussion in which to state an objection. So I am objecting NOW, while I have a chance to do so. Blueboar (talk) 22:25, 5 January 2021 (UTC)


 * can we have "Strong Meh" as well? But really we already have Template:Done/See_also and we also don't have a problem with people actually typing "Support" so I really don't care if a template does it as well, however I don't want to see a proliferation of media like File:Symbol confirmed.svg on every discussion, less concerned if it is stylized text (even check marks that are not image files). —  xaosflux  Talk 17:22, 4 January 2021 (UTC)
 * Sadly meh already exists as . We would probably want weak meh as well — GhostInTheMachine talk to me 10:17, 6 January 2021 (UTC)
 * Even without images, we can still run into problems with a page's transclusion limit which could end up breaking the village pumps or ANI where there are lots of proposals with lots of bolded !votes. Not worth the trouble just to save two keystrokes. I'm also worried about what Blueboar points out with templates going from "optional"->"preferred"->"required" over time. In this case, it would threaten to undermine the already weak "discussion-not-vote" consensus process which worries me per WP:NOTAVOTE and VotingIsEvil. — Wug·a·po·des​ 22:20, 4 January 2021 (UTC)
 * We could always have a bot auto-subst them (although it would clutter the page history). Enterprisey (talk!) 08:54, 5 January 2021 (UTC)
 * I suggested that in the proposal. I could code up a bot to do so if needed. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
 * I left it vague, but to be clear, I think that's a worse idea for precisely the reason Enterprisey hints at. The last thing I want is a WP:COSMETICBOT roaming around making non-visible changes to markup and cluttering discussion diffs just to help powerusers save 2 keystrokes. It would probably also make people think they themselves ought to be substituting it which actually costs them 4 keystrokes compared to just using bare markup. — Wug·a·po·des​ 02:23, 6 January 2021 (UTC)
 * Support without the icon and with substitution to avoid transclusion limit. As other projects have implemented it, I have found myself trying the template before realize that here doesn't work. Alexcalamaro (talk) 23:59, 4 January 2021 (UTC)
 * O - or a bold S is simple enough or better yet, separate the sections like we do at RfA. <span style="text-shadow:#F8F8FF 0.2em 0.2em 0.2em,#F4BBFF -0.2em -0.2em 0.2em,#BFFF00 0.4em 0.4em 0.5em;color:#A2006D"> Atsme 💬 📧 15:30, 5 January 2021 (UTC)
 * Great, let's support more options for commenting, like this proposed template? Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
 * Oppose: or alternatively doing it properly, Hell no. I despise bolded words as a substitute to discussion and the lack of nuance of just going support or oppose is not to be encouraged. Spartaz Humbug! 19:58, 5 January 2021 (UTC)
 * But you just used bold words in your comment? This proposal is for a convenience template to make it easier for other editors to comment, not a substitute. Thanks. Mike Peel (talk) 21:58, 5 January 2021 (UTC)
 * Oppose. The convenience factor does not outweigh the barrier to newcomer participation created by use of excessive templates in simple discussions.  --SmokeyJoe (talk) 00:19, 7 January 2021 (UTC)
 * Support I support anyone making and using almost any template, and the creation of templates rarely requires a vote or discussion. I must be misunderstanding something here. As noted above, we already have agree and meh which are similar templates that people can use or ignore. Why the opposition? No one is proposing to force or require the use of this template, so most people would either not know it exists or not care. Other Wikimedia projects like Commons use these templates, so it is understandable to me that if some people want to use it, then they might look for it across projects. In 2005 the template was deleted for use of images, but no one is proposing that right now. To a typical reader they would not know a template is being used at all.
 * I think the point of this discussion is that this template has been deleted ~10 times since 2005 because of prior use of images, but I see no harm or cost in having the template available for those who want to use it now.  Blue Rasberry   (talk)  16:25, 7 January 2021 (UTC)


 * Majavah (talk!) 18:51, 7 January 2021 (UTC)
 * Oppose: (1) It's not that hard to type the non-templated equivalent (2) It encourages !voting without !vote rationale, (3) It only increases the number of templates transcluded on discussion pages. Thanks! Plastikspork <sub style="font-size: 60%">―Œ <sup style="margin-left:-3ex">(talk)  20:03, 7 January 2021 (UTC)
 * @Plastikspork, you don't ever edit from a smartphone, right? We have editors above who say that it actually is "that hard" for them to type straight apostrophes (').  I think we can trust them that they struggle with this. WhatamIdoing (talk) 23:21, 8 January 2021 (UTC)
 * Then type in all caps (as suggested above), which is even easier than finding the {} symbols. Thanks! Plastikspork <sub style="font-size: 60%">―Œ <sup style="margin-left:-3ex">(talk)  23:30, 8 January 2021 (UTC)
 * That's a good point. On my bog-standard Android keyboard ' is on the first page of symbols, { and } are on the second page. Additionally, when editing using the Wikipedia Android app there is a single button that automatically inserts the markup for bold text, there is no equivalent for templates. Unless iOS works very differently (I own no Apple products so can't check) then it seems very likely that templates being easier to insert than bold markup for smartphone users looks fallacious. Thryduulf (talk) 14:01, 9 January 2021 (UTC)
 * Checking on an iphone (in a text application not in a Wikipedia app), ' is on the first page and { is on the second, but if I enter ' then the characters go back to the alphabet, while if I enter { then it stays on the second page, so it's easier to add a second {. Does android behave the same? Thanks. Mike Peel (talk) 17:31, 9 January 2021 (UTC)
 * I just tried editing in the Wikipedia app on iPhone, and I see the same keyboard behavior there. Thanks. Mike Peel (talk) 17:33, 9 January 2021 (UTC)
 * If there is a consensus to try to make it easier to enter bold or italic text without using a straight single quote, then I'd prefer it be done in a generic way for all text, not just specific words. Let's extend wikitext markup in some way, for example. Maybe something like @&lsquo;&rsquo;&rsquo;, @&rsquo;&rsquo;&rsquo; , and other combinations of typographical quotes can be supported. isaacl (talk) 17:01, 9 January 2021 (UTC)
 * This is a textbook example of a solution looking for a problem. – Teratix ₵ 14:23, 10 January 2021 (UTC)
 * Agreed. It's quite sad to see the amount of attention this is getting, while much more significant issues get crickets. &#123;{u&#124; Sdkb  }&#125;  talk 15:21, 10 January 2021 (UTC)
 * It's a simple solution to a problem I and others encounter regularly. I know others don't have this problem, but I am surprised at how many have gone out of their way to oppose this. Thanks. Mike Peel (talk) 16:06, 10 January 2021 (UTC)
 * Mike Peel, perhaps we are not simply going out of our way, but instead many more people than expected felt strongly about this. (Similarly, User:Sdkb perhaps what you feel is significant is not the same as for others.) That does however not mean that its not a real problem, but perhaps instead that this is not the best solution. Personally, I wish I could have a panel of formatting/template shortcuts that I could customise to address a related problem I have with often forgetting specific template names (even if I use them regularly). --Xurizuri (talk) 11:33, 12 January 2021 (UTC)
 * , significance is not some wishy-washy subjective value. Yes, assessments differ, but there are objectively things that have a big impact on readers and things that don't. The size of this discussion is perfectly indicative of our worst navel-gazey tendencies. &#123;{u&#124; Sdkb  }&#125;  talk 12:37, 12 January 2021 (UTC)
 * Oppose per above. Likely to encourage voting behavior which would not harmonize well with enwp's consensus-based culture. -  F ASTILY   01:04, 12 January 2021 (UTC)
 * Oppose because this method of bolding is very simple. As someone that recently began editing, the vast numbers of templates have frankly been barriers to me engaging with some parts of WP thus far, particularly when there's no immediately obvious consistency in when people use one method or the other. And trying to remember all the templates and their parameters, and type them out correctly, is one of the biggest barriers from editing resulting from my ADHD that I've had. I would greatly prefer to not have more of either of those issues. The bolding and italicising are, to me, the simplest/easiest type of formatting we've got and making that more confusing is frankly not worth it. --Xurizuri (talk) 11:33, 12 January 2021 (UTC)
 * If the arguments about how very difficult it is to type straight apostrophes with a smartphone were being made in good faith, this would be a discussion about undeleting Template:Bold. —Cryptic 15:54, 12 January 2021 (UTC)
 * (Restored from archive as the RfC is still active. Thanks. Mike Peel (talk) 12:57, 22 January 2021 (UTC))
 * Oppose as a solution in search of a problem, and seconding Cryptic on the matter of bolding templates. Vaticidalprophet (talk) 04:59, 23 January 2021 (UTC)
 * Support per 's comments. On Apple mobile devices such as iPhones or iPads, it defaults to ‘, and a good half-second press is needed for ', which is very tedious and seemingly time consuming, much more than typing – . This would solve all the mistakes when mobile editors try to bold text. Using  isn't any better, as you would need to switch from the default keyboard to the symbols keyboard for the "<", then go back to the default for "b", then go back for ">", then back to default for text, then rinse and repeat with an additional "/". D🐶ggy54321 (let's chat!) 04:25, 1 February 2021 (UTC)

Delete Gadget and Gadget Definition namespaces
The Gadget and Gadget Definition namespaces are unused, have never been used, and have confusing documentation at Gadget due to having never been used. Apparently, all relevant gadgets are in MediaWiki-space (for example, MediaWiki:Gadget-Twinkle.js). Considering this, there is no reason to keep the namespaces around.

Somewhat relevant:
 * Phab tasks for Gadgets-2.0, which would supposedly use this namespace
 * Previous post at the technical village pump about Gadgetspace

If after five years nothing has happened, I doubt anything will happen with the namespace in the future. Elliot321 (talk &#124; contribs) 20:25, 15 January 2021 (UTC)
 * Support unless there is a realistic plan to use them within a year. They take up space and confuse in many namespace selections like Special:Search, Special:WhatLinksHere, Special:PrefixIndex, Special:AllPages, Special:RecentChanges, Special:Watchlist, Special:MovePage and so on. The main reader facing is probably Special:Search. We could remove them there right away with the below in MediaWiki:Common.css. PrimeHunter (talk) 20:56, 15 January 2021 (UTC)
 * Strong support, especially gadget definition, which is literally comprised in a single page: MediaWiki:Gadgets-definition. JJP...MASTER![talk to] JJP... master? 21:12, 15 January 2021 (UTC)
 * I'm not sure what you mean by this. That page is where the current gadgets are defined, so would be unaffected by this change.  What would be removed are the namespaces above, which are currently entirely unused, but in theory would be by the future gadget reorganization. ~ Amory <small style="color:#555"> (u • t • c) 22:44, 17 January 2021 (UTC)
 * , what I mean is that the gadget definition namespace is entirely useless, because what it would be supposed to contain is in that single page. JJP...MASTER![talk to] JJP... master? 18:19, 18 January 2021 (UTC)
 * Please note that I requested gadgets improvements, including parts of Gadgets 2.0, in the most recent community wishlist, see m:Community Wishlist Survey 2021/Bots and gadgets/Gadgets improvements. This may be addressed by the community tech team in the coming year. --DannyS712 (talk) 05:22, 16 January 2021 (UTC)
 * I'll withdraw this proposal if there's actual work on gadgets. I don't have a gripe with the namespace, I just didn't get the impression it was ever going to be used at this point. Elliot321 (talk &#124; contribs) 07:56, 16 January 2021 (UTC)
 * I’m still yet to see many valid usages of this namespace as an article title, other than one popular redirect example, possibly two. ProcrastinatingReader (talk) 08:15, 16 January 2021 (UTC)
 * I see it has been added to the RfC list. Can someone clarify if it within the domain of community consensus to even remove the namespace / gadget, and if so is it even a good idea if that Wishlist proposal will happen? If no to either, then RfC is likely a waste of time. ProcrastinatingReader (talk) 18:41, 16 January 2021 (UTC)
 * I think it falls under WP:CONEXCEPT. --Izno (talk) 19:32, 16 January 2021 (UTC)
 * As I understand it, adding or removing a namespace is something that only developers can implement, and they will (again AIUI) only do so in two circumstances (1) where it is (no longer) required for a new (or removed) software feature, or (2) clear community consensus. Regarding the Wishlist proposal, it is almost impossible to predict which of the proposals will be actually be worked on beyond investigating in more detail what that work would entail and what resource is required. If there is no clear indication on Phabricator after about 3 months then I'd say to ask for an update, but before that point it's unlikely to be worthwhile even asking. Thryduulf (talk) 03:45, 17 January 2021 (UTC)
 * Support* *unless there's work on the namespace, as indicted might be coming.  ~Gwennie &#128008;  &#xFF5F;💬 📋&#xFF60; 22:00, 16 January 2021 (UTC)
 * Notified: Template:Centralized discussion. &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 17:29, 17 January 2021 (UTC)
 * I'm not clear on what the point of this RfC is. There's only one page in any of these namespaces (i.e. Gadget:Invention, Travel, & Adventure), and AFAIK, it cannot be modified or deleted by anyone on enwiki without at least steward--if not sysadmin--intervention (which itself is why it exists, as a one-off hack). Is the intent to establish a consensus first, and then open a phab ticket or something to ask for the removal of the namespace by developers, using this RfC as evidence of consensus? I think that would be a platform-wide change, wouldn't it? If so, wouldn't we need more than just enwiki to agree with that before the devs would even begin to listen? I ask because we've been here before, last year, and nothing came of it, and I'm not sure what this RfC would change about that. Writ Keeper &#9863;&#9812; 17:42, 19 January 2021 (UTC)
 * , if that's the case then should this be a Meta RfC? JJP...MASTER![talk to] JJP... master? 23:06, 19 January 2021 (UTC)
 * I don't think that removing these namespaces would be a platform-wide change given that different wikis can have different namespaces, although it's possible it might be. If it is possible, the developers will not remove the namespace here without evidence of consensus to do so. If it isn't consensus to remove it only on en.wp would be evidence of a good reason to start a discussion on meta. Thryduulf (talk) 12:05, 21 January 2021 (UTC)
 * @Thryduulf: Generally speaking, yes different wikis can have different namespaces. But my understanding--which is limited for sure--is that these aren't just extra namespaces the way Draft is. The Gadget: and Gadget definition: namespaces are reserved by the Gadgets 2.0 extension, so I think removing the namespaces would require a code change for that extension, which would impact all wikis.
 * My point isn't ultimately about whether this should be here or on Meta, although that is a pending question. My point is that--again, based on my limited knowledge and unlike a normal modification of namespaces--this is a non-trivial code change that will impact all wikis, not just enwiki, and it's one that the devs have already repeatedly refused to do. (Why we even have a half-finished extension on a production site is another question entirely, but...) I don't think this RfC is formulated in a way that people know what they're asking for, and as such, I don't think it'll go anywhere, even if we get a consensus. Writ Keeper &#9863;&#9812; 14:41, 21 January 2021 (UTC)
 * Support Never used, only use I have seen is Gadget:Invention, Travel, & Adventure, which is only in that namespace because of the format of the subject title. <b style="color:#090">Semi</b><i style="color:#099">Hyper</i><u style="color:#009">cube 13:44, 20 January 2021 (UTC)
 * Support. Having this sort of thing around contributes to complexity and confusion and, as mentioned, this namespace is only used once. I have always wondered what the point of this namespace was / is and can see now others are in the same boat. With respect to our jurisprudence I think it's perfectly fine to indicate that locally on EN WP we don't see this namespace being useful, and further discussion can happen at a larger venue. Many such technical changes have arisen from discussions locally that indicate the feeling of editors, even if there may need to be other discussions elsewhere. --Tom (LT) (talk) 07:03, 21 January 2021 (UTC)
 * Strong Support, not a single page in those namespaces other than Gadget:Invention, Travel, & Adventure and the talk page, which isn't even a real gadget. All gadgets, as far as I know, are, in fact, in the MediaWiki namespace. 54nd60x (talk) 07:55, 26 January 2021 (UTC)
 * Additional comment: Unlike the Education Program namespace, which had talk pages (why it was installed back in 2018,) there are no real gadget (definition) talk pages on this wiki, which is another reason why I think it should be deleted. 54nd60x (talk) 09:21, 26 January 2021 (UTC)
 * See User:54nd60x/common.css, add that to your common.css if you want to hide the gadget/gadget definition namespaces. 54nd60x (talk) 09:21, 26 January 2021 (UTC)
 * The current version only hides it at Special:Search. This hides it in some other places but not all, and maybe not in all browsers:   PrimeHunter (talk) 14:11, 26 January 2021 (UTC)
 * Support. It has been several years, and there do not seem to be any concrete plans to do the work which would use this namespace. If there are plans, I'm happy to keep it, but otherwise there's no sense in the extra complexity and confusion it causes by having it appear in every namespace selector. the wub "?!"  18:15, 30 January 2021 (UTC)
 * Question — How much is the namespace costing us? — GhostInTheMachine talk to me 22:10, 30 January 2021 (UTC)
 * Nothing. Writ Keeper &#9863;&#9812; 22:26, 30 January 2021 (UTC)
 * Not true. This namespace has caused a lot of drama over the years, mainly due to conflicts involving the name of the visual novel Gadget Invention, Travel, & Adventure. Some examples are Village pump (technical)/Archive 139, User talk:MaxSem/Archives/August 2015, Talk:Gadget Invention, Travel, & Adventure, Gadget talk:Invention, Travel, & Adventure, Steward requests/Miscellaneous/2019-04, and Administrators' noticeboard/Archive311, Administrators' noticeboard/Archive326. * Pppery * <sub style="color:#800000">it has begun... 23:14, 30 January 2021 (UTC)
 * I was assuming that the question was about the monetary cost of hosting the Gadgets namespace, which is $0. Writ Keeper &#9863;&#9812; 17:32, 31 January 2021 (UTC)
 * Support As I wrote in the last of the above list of links, the movement to use the gadget namespace has been stalled with no sign of progress for over 4 years, so there's no reason to expect it to happen [...] in the near future. This namespace's existence is causing periodic problems, for no apparent benefit. * Pppery * <sub style="color:#800000">it has begun... 23:14, 30 January 2021 (UTC)
 * How often do we need to create articles whose names begin with the seven characters "Gadget:"? There's one documented instance, mentioned above. So, that one aside, which other potential articles is this causing problems for? -- Red rose64 &#x1f339; (talk) 08:46, 31 January 2021 (UTC)
 * Okay, here's my hat: oppose. This namespace is not harming anything, the periodic discussions notwithstanding. The discussions themselves take more time than the actual namespace takes from anyone else. A single page hanging out in the wrong place also isn't breaking the wiki. That we're having this conversation when this is basically a WP:CONEXCEPT question is asinine. Go home, live with it, wait until the namespace is actually used. It's not hard to ignore it, people. Put something on WP:Namespace if it isn't there. --Izno (talk) 07:25, 31 January 2021 (UTC)
 * It's unclear to me whether this is proposal to temporarily remove these namespaces until Gadgets 2.0 is ready or a request to permanently remove them. If it's the latter, that's a non-starter, if it's the former then I'd ask exactly what the issue is in having them around, albeit unused, given that they will be used...eventually. For context, I was one of the most recent people (like 4-5 years ago) working on Gadgets 2.0 whenever we could find time (usually once a year at the Wikimania hackathon). I do believe that every editor actually wants Gadgets 2.0 to happen, though most won't care and won't notice. Gadgets will be slightly faster and gadget authors will get access to more features. So...if the problem is that these namespaces are sitting unused, I think the best solution/use of time is to find some more technically minded folks who would be interested in contributing to the Gadgets extension and work towards getting 2.0 ready for users, so we can populate those namespaces. Legoktm (talk) 08:00, 31 January 2021 (UTC)
 * I think moving away from Gerrit will be a boon for code contributions. Moving the code into GitHub would’ve probably helped too, though I guess that’s a non-starter. But there’s still the issue of getting code reviews. ProcrastinatingReader (talk) 10:46, 31 January 2021 (UTC)
 * If code review is what's stopping people or getting set up with Gerrit I'm always happy to help with that. Legoktm (talk) 00:02, 2 February 2021 (UTC)
 * When I originally opened this, I was unaware that there was still work being done on Gadgets 2.0. I'm obviously not opposed to that - I was under the impression that these namespaces were long-abandoned. Elliot321 (talk &#124; contribs) 17:26, 31 January 2021 (UTC)
 * To be clear, no one is currently working on Gadgets 2.0 as far as I know. But eventually, I hope. (I won't make any promises or even suggestions because I already told people we'd have Gadgets 2.0 by 2017 and well, here we are.) Legoktm (talk) 00:02, 2 February 2021 (UTC)
 * Strong support: Have never been used, unlikely to be used in the future. If there’s no benefit of this namespace and it’s causing problems for any page, I think the namespaces should very well be deleted. 54nd60x (talk) 01:35, 1 February 2021 (UTC)
 * Oppose any en-wiki specific development hacks to remove namespaces 2300-2303. That would just result in some barely/un-supported technical debt that will likely break down in the future. Strong Oppose any display hacks to try to "hide" this locally, that will certainly break down and be inconsistent across platforms/browsers/etc.  Neutral on if the results of this are just to petition the devs to globally remove these namespaces from all/all-wmf projects. —  xaosflux  Talk 13:58, 2 February 2021 (UTC)
 * What do you mean by "some barely/un-supported technical debt that will likely break down in the future?" These namespaces have never been used on this wiki, aren't likely to be used in the future, and cause too many problems for the page Gadget:Invention, Travel, & Adventure. There are no archives to keep - unlike the Education Program namespace. I don't see any benefit in keeping these namespaces as they are currently unused and have never been used, and cause so many problems for every edit request to Gadget:Invention, Travel, & Adventure. I know that one page hanging out in the wrong place may not be that big of deal, but that's not the only problem readers face. There are problems in Special:Search as well. 54nd60x (talk) 14:29, 3 February 2021 (UTC)
 * these namespaces are deployed to the 700+ WMF integrated projects, so making some special one-off configuration that is only for the English Wikipedia would mean an exception that has to be cared for indefinitely by the developers. — xaosflux  Talk 15:08, 3 February 2021 (UTC)


 * Oppose, if it wasn't clear. The request is a non-starter; it's something we as a community can't do, and the people who can won't. Given that there is a sum total of one page across the entire enwiki that's affected by it (a redirect that does not require ongoing editing or maintenance), I don't see the benefit in a massive effort to change their minds. This is by far too much effort for not enough payoff for the wiki; I'd almost call it a solution in search of a problem. Writ Keeper &#9863;&#9812; 14:50, 3 February 2021 (UTC)
 * Amusing how all this discussion and still the only repeated example above is one article, this gadget movie, not a particularly popular article by any metric either, nor do I think any readers care. I’m getting the feel that people just have an axe to grind with WMF/dev actions, tbh. There are far bigger problems, community caused, that nobody seems to care about doing anything about. ProcrastinatingReader (talk) 15:56, 3 February 2021 (UTC)
 * If my opinion wasn't clear enough, the reason I want to delete these namespaces isn't because of that one article, but because they have never been used and won't likely to be used in the future. So there's no use in keeping these namespaces if they are not used and won't be used. But was right, that the gadget and gadget definition namespaces are used on just about every wiki, so uninstalling those namespaces on enwiki would mean that an exception would have to be cared for indefinitely by the developers. Only Wikimedia Vote Wiki and Wikimedia Login Wiki I know of don't have these namespaces. 54nd60x (talk) 01:15, 4 February 2021 (UTC)

New template (a new way) to track how many times an article is listed at Portal:Current events
So Wikipedia has a template that is able to track daily page views and that template can be placed on any article when it is relevant or wanted by the community. I am proposing to create a template that can track the number of times and/or the dates when an article is listed on the Portal:Current events.

This would allow people to know when an article was relevant in the international/national news and this would also allow for people to know when an article most likely had a major update of content.

For example, Biden–Ukraine conspiracy theory was created during the first set of allegations. The article saw a massive spike in the number of views and number of edits. The number of edits/vandalism was so big that active arbitration remedies were placed on the article. After about a week, the articles edits died to almost none and a 23 day long request for a copy-edit took place. During those 23 days, only 4 edits were made to the article. About two weeks later, the article was back in the US national news, so the article had tons of new content being added.

Another example is the Sandy Hook Elementary School shooting happened in 2012. Of course it was a major thing in the international news, so it saw major content for the week or two that it was in the news. The article was slowly updated, but on December 12, 2019, the article was in the news against due to a trial. The article had 8 edits during that week alone, when it was getting maybe 4 edits a month.

Some articles never see the Portal:Current events, and some may only see it once. For example, 2019 Bagram Airfield attack only saw the portal 1 time and that was on the day of the attack.

If this is added, people could fairly easily find the dates when the article had new content added. It would also allow people to know how many times (or how many days in a row) the article was of importance in the world (or national importance).

Elijahandskip (talk) 15:11, 28 January 2021 (UTC)


 * That'd be good, providing it's easy to use & clear to understand.
 * Some major events which should be on CE never are, although I don't know how to solve that problem. Jim Michael (talk) 15:37, 28 January 2021 (UTC)
 * My mind is thinking of a copy/paste type template with some fill in spots that the editor adds, so it would be easy to use. Elijahandskip (talk) 17:37, 28 January 2021 (UTC)
 * I think this is a great idea. 🌀 𝕾𝖚𝖕𝖊𝖗 𝕮𝖞𝖈𝖑𝖔𝖓𝖎𝖈 𝕾𝖙𝖔𝖗𝖒 𝕮𝖔𝖗𝖔𝖓𝖆 🌀 17:58, 28 January 2021 (UTC)
 * This is just more talk page cruft. When there are multiple discussions elsewhere about reducing how much Stuff is at the top of talk pages, this is not a socially-feasible proposal. Certainly not as its own template. Going beyond that, I doubt Portal:Current events drives much if any traffic at all. --Izno (talk) 20:41, 28 January 2021 (UTC)
 * according to that daily page views, it gets about 60,000 views daily.Elijahandskip (talk) 21:03, 28 January 2021 (UTC)
 * "Drives" is a key word in context. --Izno (talk) 21:12, 28 January 2021 (UTC)
 * Why wouldn't it drive traffic? Many people read what's happened recently & click on the links to find out more. Jim Michael (talk) 22:48, 28 January 2021 (UTC)
 * But compared to the number of people coming in via Google, social media etc. it's likely insignificant. We need fewer templates cluttering up talk pages, not more. If for some reason you want to check when something was on the portal, it's easy to do via Special:WhatLinksHere/Biden–Ukraine_conspiracy_theory and filter to the Portal namespace. the wub "?!"  23:07, 28 January 2021 (UTC)
 * Being very honest, I am a 2 year Wikipedia editor and I have never seen that before. Highly unlikely 99% of that 60,000 even know what that is.  But I would guess maybe 75% of them would click on the articles and maybe 30% of them would click the talk page of that article.  That is at least a few thousand up to 10k.  Elijahandskip (talk) 23:30, 28 January 2021 (UTC)
 * Besides 75% click-through from the portal being very unlikely, you're significantly overestimating readers' interest in talk pages as well. The number of views of the talk page is about 2% that of the article |Talk:Biden%E2%80%93Ukraine_conspiracy_theory. the wub "?!"  00:59, 29 January 2021 (UTC)
 * The featured article two days ago, The Holocaust in Slovakia, had a gracious 60k views. That's 1 in 100 clickthroughs from the main page, which gets 6-7 million (which is fairly high for recent TFAs). Let's assume that a secondary portal, though linked prominently with its own 60k pageviews, has a similar clickthrough. That's 600 pageviews a day from the one page.
 * No thank you to a new template. --Izno (talk) 06:40, 29 January 2021 (UTC)
 * A stronger argument is not that it drives traffic, but correlates with it—as in the examples given by the OP. It could still be useful for someone trying to work out what made the pageviews/edits spike. But I think this would be better as a tool of some kind than a talk page banner (even one minimized by default). "Track when page X was linked on page Y" would work for this use case (Y = Portal:Current events) and might plausibly be useful in other situations too. — Bilorv ( talk ) 20:55, 4 February 2021 (UTC)

An idea is to make it similar to how the ITN recognition that is placed on talk pages. Elijahandskip (talk) 22:21, 28 January 2021 (UTC)

Some countries aren't even protected!
While I was searching about Burma, I then went to Israel. It was "Extended-Confirmed". Then I went to the Malta page and it didn't have any protection! There should be a policy that all countries MUST have at least some protection on their articles.

Avishai11 (talk) 23:59, 4 February 2021 (UTC)
 * , articles are protected only when it's truly necessary. You can learn more at WP:PP. Schazjmd   (talk)  00:04, 5 February 2021 (UTC)
 * We do not pre-emptively protect pages; we apply protection when it is necessary to do so - persistent vandalism, for example. What kind of edits are you thinking of that protection would have prevented? -- Red rose64 &#x1f339; (talk) 00:08, 5 February 2021 (UTC)
 * , like most Israel-Palestine related articles, the Israel article has Extended confirmed protection because of ArbCom enforcement. You can read about that here - WP:A/I/PIA. As for other country articles, they can be protected individually if they have persistent disruption. Otherwise it is not necessary.  AVS malnad 77  talk  05:35, 5 February 2021 (UTC)

Should Cewbot remove interlanguage link templates once local articles exist?
This task ([]) destroys the information about which other wikis have relevant articles about the subject. For instance, if the article is created, and then one week later is deleted again, the ill link is gone and the work of the editor who originally placed it there is lost.

The reason for this odd behavior has been that the bot is computationally intensive. Now, the bot was recently given the ability to bypass this load. The idea is that an editor adds force to the Interlanguage link when the English article exists. The template will then render as a regular blue link but retain the information about other wikis, so if that article is deleted, an editor can simply turn off the display parameter again. Of course, the bot itself should be this editor.

Another reason brought up is that ill create clutter in the editing window, but I see nothing worse than when you have a load of references interspersed in running text.

One argument is also that Cewbot waits one week before removing the ill links. But articles quite often take more than one week to go through PROD or AfD.

So should Cewbot remove interlanguage link templates once local articles exist?

I say there's gotta be a better solution that doesn't destroy the work of editors. CapnZapp (talk) 10:47, 22 January 2021 (UTC)
 * I should add that I brought this up at the bot's talk page but was shut down twice and told the Bot Noticeboard was a more appropriate place to have this discussion. Then that discussion was shut down and I was told to go to the Village Pump. So far I've complied, but this is the end of the line.
 * User talk:Kanashimi/Archive 1
 * Bots/Noticeboard
 * CapnZapp (talk) 10:51, 22 January 2021 (UTC)


 * To answer the question in the headline, absolutely. --Izno (talk) 19:25, 22 January 2021 (UTC)
 * I wonder whether the conversion could be logged somewhere. Maybe a note on the edited article's talk page ("I changed  to Local" – please revert if Local gets deleted)?  Maybe a note on the possibly-to-be-deleted article's talk page ("If you delete this, please go revert this edit by the bot")?  Maybe a central log, which any interested editors could scan it for red links later?  WhatamIdoing (talk) 20:38, 22 January 2021 (UTC)
 * Forum shopping is not OK. That said, perhaps the bot could run this task every month rather than every week to reduce the chances of article creations being subsequently deleted. Or better, the deleting admins could restore the interlanguage links while they are deleting the article. In general, it's better to link to a local language article where it exists, though. Thanks. Mike Peel (talk) 21:13, 22 January 2021 (UTC)
 * , CapnZapp was directed here by the BAG. No one at WP:BOTN supported stopping Cewbot, because no one saw any consensus to stop it. This RFC is a legitimate attempt as checking if C has C'd. There's also the possibility that while Cewbot still has a general consensus to do its task, the community finds its preferable to tweak certain behaviour. &#32; Headbomb {t · c · p · b} 05:18, 23 January 2021 (UTC)
 * Thanks for the background, I've struck that part of my comment. It still sounds like waiting a bit longer, or perhaps checking for deletion tags in the article to be linked to, would be an improvement. Thanks. Mike Peel (talk) 18:54, 23 January 2021 (UTC)
 * Yes it should. I also don't see any reason to change its one week delay, especially if it removal of ill is halted during an ongoing AFD/PROD discussion. Having logs could be a good idea though. &#32; Headbomb {t · c · p · b} 05:18, 23 January 2021 (UTC)
 * What does especially if it removal of ill is halted mean, Headbomb? It can very easily be more than just a week before an article even starts the PROD or AfD process, so arguing the bot respects that process (if indeed that is the case?) seems insufficient... CapnZapp (talk) 11:01, 25 January 2021 (UTC)
 * Articles may be deleted at any point, from seconds, to days, to weeks, to years after their creation. That something might potentially be deleted is not a valid argument against suspending basic maintenance tasks. &#32; Headbomb {t · c · p · b} 16:17, 25 January 2021 (UTC)


 * Yes Pointless wikitext makes editing the article more difficult. Having in some articles but plain wikilinks in others invites hapless gnomes to go  round "fixing" one or the other. I don't think logs are warranted: just another unloved maintenance page to be ignored. All that is needed is an edit summary spelling out what was done (not each link) so it could be found in article history or the bot's contributions. Perhaps the bot could wait longer than a week from page creation. Johnuniq (talk) 06:06, 23 January 2021 (UTC)
 * I'm arguing the wikitext isn't pointless. It was useful info added before the local article was created and this usefulness is exactly the same after it gets deleted. Having in some articles but plain wikilinks in others is just a hypothetical I'm having trouble taking in good faith. What has your conspiracies against "wiki gnomes" to do with my question and my arguments, Johnuniq? What do you mean by "plain wikilinks" in this context (I haven't mentioned any)? All that is needed is an edit summary spelling out what was done (not each link) so it could be found in article history or the bot's contributions. You appear to miss one step of reasoning - why would anyone think to check the edit summaries when the bot leaves no trace of anything to find - unless there's say, an editor comment of some kind: "here was once useful interlanguage links, check the page history for details"? I will note I haven't asked for any logs, so we're in agreement there. As of yet I haven't seen a single editor arguing why the bot should wait such a desperately short time, so, yes, waiting more than a week seems like one easy step to take, whatever else we agree on. CapnZapp (talk) 11:09, 25 January 2021 (UTC)
 * One article might have a plain link such as Example while another has Example . Johnuniq (talk) 00:27, 26 January 2021 (UTC)
 * Yes As per the comment above, pointless wikitext should be removed. Editing is difficult enough already for new editors. What would be the point of a log? How would it advance the project? Peter coxhead (talk) 07:33, 23 January 2021 (UTC)
 * No, that comment doesn't explain or justify why the wikitext is "pointless". (I invite you to be the first to actually start the argument, Peter coxhead) Personally, I don't find ill templates more difficult than a jumble of references/citations where it can be quite tricky to find the actual article text among the sea of reference parameters, and you don't see any bots obsessively messing around with them... I am not asking for a log, I am asking for a discussion wherein we don't just take cewbot for granted, but arrive at alternatives that don't erase information volunteered by editors. Cheers CapnZapp (talk) 11:13, 25 January 2021 (UTC)
 * if there's no article here, then ill is of some value. Once there is an article here, it isn't. The links to other language wikis are then provided via Wikidata. Yes, full references in text are also confusing, especially to new editors, which is why I always prefer the list-defined approach with the minimum reference in the text. But the argument that X is confusing so it doesn't matter if Y is as well isn't, in my view, convincing. We should remove as much complexity as possible. Peter coxhead (talk) 11:30, 25 January 2021 (UTC)


 * Yes. I struggle to think of a situation in which we'd need to retain an ill when a local article exists. If the article in the other language is better, just tag the English page with Expand language, which is plenty enough of a signal to readers that they might want to just use Google Translate. And if the article in English is created and then deleted as not notable, then it shouldn't have an ill as an ill is just a type of redlink and non-notable pages shouldn't be redlinked. &#123;{u&#124; Sdkb  }&#125;  talk 16:40, 23 January 2021 (UTC)
 * To ease your struggle, I started the very first talk section with If an article is created, but later deleted (perhaps a person article that's deemed not notable enough), the ill link is lost and we have a red link instead. saying the bot actually destroys input added by editors (the existence of the foreign-language wiki article). Regards, CapnZapp (talk) 11:21, 25 January 2021 (UTC)

Let me respond to Mike Peel in a more prominent place since this is important. It has been very hard indeed to actually get a discussion started where people look at the bot's job critically and were we discuss alternatives that still accomplish what the bot set out to do but in a way that does not actively destroy the work of editors. I have mainly had to battle editors who focus solely not just on shunting the discussion elsewhere like a hot potato but actively shutting it down before arguments were even considered. Here seems to be the only place where there's nowhere else to point, so I look forward to an open-minded discussion which does not avoid the greater issue. With that in mind, thank you for striking that part of your comment, and thanks to Headbomb for highlighting the struggle to even start the discussion. CapnZapp (talk) 11:27, 25 January 2021 (UTC)
 * Yes The question contains an unstated supposition that "the work of editors" is somehow sacrosanct and "destroying" it is axiomatically a "bad thing". I don't believe this idea has any merit at all. In any case an "ill" link is intended to only be a temporary "patch" to cover a supposed hole in the 'pedia. Roger (Dodger67) (talk) 17:10, 25 January 2021 (UTC)
 * Yes. Removing an obsolete ILL, is helpful, and deletion of the article is not the expected/common path. The week delay should cover almost all speedy deletes, and that delay could be increased if we want to catch a higher number of AFD/PRODs. However we should not halt this useful work and obviously not permanently retain ILLs, just because an article might eventually be deleted. Alsee (talk) 02:20, 26 January 2021 (UTC)
 * Yes – good idea and would certainly be an example of a bot doing helpful "edits that would be extremely tedious to do manually". Can see no reason why we'd want the ill links to stick around. Aza24 (talk) 07:18, 26 January 2021 (UTC)

Two takeaways: 1. If the bot updates wikidata thereby retaining the information otherwise lost, that'd be sufficient. 2. Several posters have qualified their response by saying a longer waiting time could be useful. What would then be a more reasonable length of time for the bot to wait? Three months? More? Less? CapnZapp (talk) 09:22, 1 February 2021 (UTC)


 * Question. If and Example both result in Exemplum/Example.. then isn't this a cosmetic bot task? &#8211;<span style="font-family:CG Times, times"> MJL &thinsp;‐Talk‐☖ 03:57, 5 February 2021 (UTC)
 * With the parameters in your example, incurs the cost of one "expensive parser function" since it checks for the existence of the Example page on the English Wikipedia.  davidwr/  (talk)/(contribs)  04:05, 5 February 2021 (UTC)
 * A cosmetic bot task is one that makes a change which has no effect on reader-facing aspects of the encyclopaedia. So, yes, this is cosmetic. Thryduulf (talk) 11:15, 5 February 2021 (UTC)
 * Ah, but it does have an effect on reader-facing aspects of Wikipedia if removing an expensive parser function call will cause the formerly-501st expensive parser function call on that page to succeed instead of "failing because it was the 501st" and produce different output to the user. Therefore, it is not necessarily a cosmetic bot when used on pages that are already over the limit.  davidwr/  (talk)/(contribs)  19:54, 5 February 2021 (UTC)
 * Also, it is effectively not a cosmetic change if it removes Template:Interlanguage link then the en-wiki page is deleted or changed into a redirect. Had the bot NOT run, the interlanguage link template would've shown a link to the other-language page as soon as the en-wiki target was deleted or changed into a redirect.  So, I guess technically it's a cosmetic change at the time the bot is run, but it is effectively a non-cosmetic change in that if the bot runs AFTER the en-wiki link is deleted or changed into a redirect, the bot will skip it and the end result will be different for the reader.  davidwr/  (talk)/(contribs)  19:58, 5 February 2021 (UTC)

Bot to remove year of birth/death categories when the claim is removed from the article body
This proposal is related to an open bot approval request (BattyBot 53). AWB, as part of its current genfixes, will add birth/death categories (like Category:1980 births) to biographies that contain a birth/death statement in the article body (either the lead sentence or the infobox, I think). However, it seems no process exists to remove the categories if the corresponding statement is later removed from the article. An example of this problem is at Advaitha (actress): adds an uncited date of birth,  (automated) adds the corresponding category, and  removes the date of birth as unsourced, but misses the category and it is left unsupported by the article, until manually removed by me much later.

I'm wondering if there is support for a bot to automatically remove these categories in this type of situation. Some additional thoughts, open questions, and potential objections:


 * The bot should only remove the category if a birth/death claim formerly existed in the article and was removed, not if the category was added without a corresponding claim ever being present. (This would lead to the bot directly reverting a manual edit, which is not my intention.)
 * To prevent edit warring, the bot should not remove a category from the same article multiple times, and could wait for some grace period (a day? a week?) before removing in case the removal of the claim itself was mistaken/vandalism.
 * Should the bot replace the category with Category:Year of birth missing or a related category, or just remove it?
 * "This would just result in multiple bot edits when there could be none. My watchlist and I hate bots with a passion." Yes, fair. The current situation, though, appears to be that these categories get added and are not always maintained. It is also possible that the category was originally added by a human, so this is not always a case of "bots reverting bots", but a bot cleaning up something a human missed.
 * "Not a good bot task, too situational." Perhaps. The bot could log these issues and not directly action them. Would anyone bother to check the log? Part of the justification for this proposal is to avoid unsourced BLP information, on which I believe we should err on the side of removal.
 * "The category should be automatically handled by the infobox/Wikidata, so there aren't multiple places to maintain this information." Maybe? This is a very different proposal. Not every article has an infobox, and not every Infobox person is in the lead section of a biography. There is frequent opposition to using Wikidata for this due to lack of review/quality sourcing.
 * "The category system is terrible." Yes, but this is a non sequitur. The category system exists and we must maintain it, particularly for BLPs.

Thanks. —  The  Earwig ⟨talk⟩ 16:29, 4 February 2021 (UTC)
 * My first thought is that this is a good idea, but as you say it needs workshopping a bit before implementation. For example, how will it cope if a duplicate year of birth/death statement is added and then removed, or the statement is changed without being removed (e.g. Born 1986 changed to Born 1987)? If it adds any categories it should be ones that are flagged as needing human review (perhaps "year of birth possibly missing" or something) - especially for deaths (we don't want living people in year of death missing cats). The bot will need to cope with people changing e.g. "born 1930" to "1930–2021" in a variety of formats. How will it cope with the year of birth/death being removed from the prose or infobox but not both? Maybe an edit filer for year of birth/death removed would be a good first and/or additional step? Thryduulf (talk) 02:30, 5 February 2021 (UTC)
 * Thanks Thryduulf, this is helpful. My original idea was to simply check whether the claimed year of birth/death is present in the page text or infobox at all, except for the category itself. It would be prone to false negatives, but seemed like a safe starting point for detecting situations where the category is completely unsupported. Of course, you are right to bring up the case where the year changes; I would be less comfortable about a bot doing something in that situation, but removing the category wouldn't be strictly improper? (I don't think I'd want the bot to change the category to the new birth year without human review.) Your comment on adding categories makes me think that it would be best to not add any due to uncertainty—a "year of birth possibly missing" category does not seem especially useful. I know there has been some prior discussion about the (lack of) utility of these. An edit filter is a good suggestion, but it might be difficult to build a useful one. I will think more about this. —  The  Earwig ⟨talk⟩ 08:44, 7 February 2021 (UTC)

Warn new editors before putting in a date-of-birth less than 18 years ago
Lately I've found and reported more than a handful of minors posting their own year-of-birth or that of a family member, or people creating drafts about non-notable teenagers complete with real name and date-of-birth.

I propose an edit filter for non-(auto)confirmed editors that that would throw up a warning recommending that the editor read On privacy, confidentiality and discretion, Guidance for younger editors, and WP:AUTOBIOGRAPHY before publishing anything that looked like a date of birth 5-17 years ago. This wouldn't prevent publication, but it would at least put some "friction" in the process giving the editor a chance to think about it. For obvious reasons, the filter should be set to "private" and edits that are saved anyway should be flagged for review by someone with visibility to that edit filter, as a fair number of them would likely need to be immediately WP:REVDELed away and referred to WP:OVERSIGHT.

I wanted to get feedback on the idea here before making a more formal proposal on Village pump (technical) or Edit_filter/Requested in case there's some good reason NOT to proceed.

It's not part of this proposal (first things first) but a similar proposal to flag new editors putting up email addresses or social-media links on user- and draft- pages and new-ish pages in other namespaces would also help cut down on naive users posting things that have to be cleaned up later. davidwr/ (talk)/(contribs)  03:06, 27 January 2021 (UTC)
 * ... in what context? Edit filters are not magical. --Izno (talk) 04:41, 27 January 2021 (UTC)
 * Moreover, this seems better for WP:VPI since you don't know what you want exactly. --Izno (talk) 04:43, 27 January 2021 (UTC)
 * I suppose we could flag new articles with Category:2004 births or later, but I doubt that editors unsophisticated enough to attempt to make articles on themselves or their family members of that age are adding birth categories. BD2412  T 06:20, 27 January 2021 (UTC)
 * It's impossible to make an edit filter totally private. The username and page title will always be visible. Are you sure you want to make a handy list of minor editors? Suffusion of Yellow (talk) 06:25, 27 January 2021 (UTC)
 * I'm sure I do NOT want such a list, at least not one that is visible to the public or unprivileged editors. I had forgotten about the limitations of the privacy features of the edit filter log. From re-reading the edit filter documentation, it looks like this is not currently possible in en-wiki.  That said, in principle it looks like the edit filter extension could be "cloned" so there could be two independent groups of edit filters, one that is very locked-down to the point that its logs were invisible to most editors.  That said, it's not the simple undertaking I envisioned, which makes my suggestion impractical at least in the short term.  davidwr/  (talk)/(contribs)  19:15, 27 January 2021 (UTC)
 * Yes, please move this to VPI. &#123;{u&#124; Sdkb  }&#125;  talk 14:53, 30 January 2021 (UTC)

Many non-notable people (most of them young) have created articles about themselves or non-notable people whom they personally know. Even more have added their births to year and day articles. I can't work out a way to prevent this while not preventing articles & additions being made which are useful & justified. Jim Michael (talk) 15:40, 28 January 2021 (UTC)


 * The birthdatescammers!

Proof https://i.pinimg.com/originals/87/86/66/878666a2074787830017c0981de58e10.jpg --2A01:C23:7033:1D00:115B:35E7:3490:2E47 (talk) 13:02, 7 February 2021 (UTC)

Proposal: Add notable people when browsing Wikipedia in the WP:Contents page such as in WP:Contents/Overviews
All of the links in the contents seem to cover every part of the encyclopedia. The only part that seems to be missing is listing notable people like Jesus, Albert Einstein, Isaac Newton, Leonardo da Vinci, and Aristotle. All of the links with the exeption of meta's articles every Wikipedia should have and the vital articles list notable people. Please let me know what your thoughts are regarding this. I want to help improve browsing Wikipedia for people who prefer not to do a search. Interstellarity (talk) 19:16, 9 February 2021 (UTC)
 * Who says that someone's historical impact or fame (which I can only assume is the basis for the five figures you list) correlates with what people want to read on Wikipedia? Look at the page views for Trump compared these people |Leonardo_da_Vinci|Aristotle|Albert_Einstein|Isaac_Newton|Donald_Trump last year; I doubt he would be included in the list of Jesus, Leonardo, Aristotle etc. yet he receives significantly more attention from readers. I could understand having a most viewed articles section for the day or week (mobile already has something like this) but trying to create a list of people we're guessing readers consider the most "notable" seems impossibly arbitrary and serves no real purpose. Aza24 (talk) 23:46, 9 February 2021 (UTC)

Wikipedia as fact-checker
Hey, my name is Joey.

I think Wikipedia is great and would like to try to contribute to its success in the future.

Wikipedia is full of facts, making it a great place for research. It is also highly monitored, making it trustworthy. I think Wikipedia could fill another, in my opinion much needed, position in our modern society. Nowadays people have the option to post whatever they please on social media. I feel like a fact-checker, like the one Twitter recently implemented, is highly needed. I think Wikipedia could fill that role. The digital engineers behind the site could develop a system that would be able to check videos, text and images for how factually true it is. Then Wikipedia could strive to have a fact-check button implemented on every social media platform.

I think this is something that is indefinitely going to happen in the future and I think that Wikipedia would be the perfect organization to make it happen.

Thanks for listening to my idea. Greetings, Joey — Preceding unsigned comment added by 2001:1c04:3f14:6d00:5091:fa99:3bbc:f338 (talk • contribs) 13:09, 4 February 2021 (UTC)
 * Joey, please read about how Wikipedia is not a reliable source, or in other words, not trustworthy. We don't deal in truth, but in what can be verified. 331dot (talk) 08:03, 7 February 2021 (UTC)


 * The problem is that a fact checking system like twitter’s would likely violate our WP:No original research policy.
 * All we can do is ensure that our information is accurate, based on what reliable sources tell us. And sometimes, the reliable sources disagree. When this happens, our WP:Neutral point of view policy says we can not choose between them, but must present what the various reliable sources say (even if we, as individuals, think one side of the disagreement may be wrong). Blueboar (talk) 14:31, 7 February 2021 (UTC)
 * The English Wikipedia is already being used as a source of ground truth for fact checkers (including automated systems). If you are interested this subject, see Diego's talk at mw:Wikimedia Research/Showcase#December 2020. Whatamidoing (WMF) (talk) 05:18, 10 February 2021 (UTC)

logo
Recently the logo was temporarily changed to.....see image at right. In this case I'm proposing adding back 'The Free Encyclopedia' however with '20 Years over one Billion edits' the idea is that it is a milestone and hence would give even more credibility to the movement as its indicating how many years its been helping readers, and how many edits have been done--Ozzie10aaaa (talk) 19:15, 4 February 2021 (UTC)
 * who have very recent feedback on this on Talk:Main Page that I'm going to point to here. — xaosflux  Talk 19:45, 4 February 2021 (UTC)
 * thank you(it could be 'more than')--Ozzie10aaaa (talk) 19:49, 4 February 2021 (UTC)


 * Support as proposer--Ozzie10aaaa (talk) 16:47, 5 February 2021 (UTC)
 * Oppose. Pretty much every reader knows that Wikipedia is a very popular and well-established website, so we don't need to use up the most valuable space in our layout (since people begin reading at upper left) to remind them of that fact. I'd rather we keep using the official tagline ("the free encyclopedia"), which at least says something about our editorial philosophy. &#123;{u&#124; Sdkb  }&#125;  talk 05:10, 5 February 2021 (UTC)
 * what I propose is this same logo with "The Free Encyclopedia" as usual on it--Ozzie10aaaa (talk) 15:51, 5 February 2021 (UTC)
 * , if you're proposing a logo change at VPR, it's preferable to have an actual logo file in hand, so that this sort of confusion doesn't happen. You could request that at the WP:Graphics lab if you don't know how to make it yourself. Without knowing where exactly you'd want to place each piece of text, I have to continue to oppose, although if you came back with a file and it looks better than I expect it to, there's a slight chance I'd change my mind. &#123;{u&#124; Sdkb  }&#125;  talk 07:28, 7 February 2021 (UTC)
 * ok its hereModified_logo.png (Im not very good at images but you get the general idea)--Ozzie10aaaa (talk) 13:26, 7 February 2021 (UTC)


 * Support Until February 15th and then bring back the normal logo in march unless the WMF opposes this idea and wants us to keep using the normal logo before the 15th 🌸 1.Ayana 🌸 (talk) 11:27, 5 February 2021 (UTC)
 * Oppose We should stick with this one for a while more. Pretty notable milestone. Someone should really ping all of the editors who contributed to the previous discussion on this. ~ HAL  333  02:54, 6 February 2021 (UTC)
 * did you vote 'oppose' if your saying We should stick with this one for a while more. Pretty notable milestone....--Ozzie10aaaa (talk) 20:28, 8 February 2021 (UTC)


 * The back and forth logo changes are probably confusing to the average reader who notices. Though, I guess that is quite representative of Wikipedia’s consensus building process, so perhaps a good thing to showcase. ProcrastinatingReader (talk) 08:59, 7 February 2021 (UTC)


 * note this discussion was closed too soon as what was being discussed was merging to a new logo for a non-specific time..."the logo has been changed back" is not a valid reason to close as there are ongoing discussions on the matter(as seen above)...IMO--Ozzie10aaaa (talk) 18:11, 10 February 2021 (UTC)

mergers @ AfD (yes, again)
Yes, I know it's a perennial proposal, and yes I've read over quite a few discussions in the past and yes I do feel times are different now. Mergers often stay open exorbitantly long times. This is not practical, and the system of proposed mergers is clearly struggling with low participation and interest (not to suggest that other areas aren't). It is more effective and efficient to nominate an article for deletion if you want it to be merged. Like it or not, that would seem to be a fact at this point based on my highly unscientific day-to-day life. See, for instance, 1 and 2, where unanimous consensuses were reached in a week-- this would usually take months to a year or more if you followed the 'correct' way of proposing a merge. Currently, some users will !vote "keep: a merger should be discussed elsewhere" and I'd argue that more often than not no discussion happens elsewhere.I'm not suggesting completely folding PROPMERGE into AfD and I'm not suggesting necessarily renaming AfD to articles for discussion, I just think it past time that we seriously consider making 'merge' a valid option to start an AfD for. Is AfD exactly booming with participants? no, but I'd argue it's higher visibility than proposing a merger, the format works just as well better, and I highly doubt the number of new merges would overwhelm the system. We could always do a trial for X months and reassess... Cheers, Eddie891 Talk Work 23:22, 25 January 2021 (UTC)
 * To clarify I'm suggesting that we make merge an acceptable proposal to suggest when opening an AfD, but leave Proposed mergers as a functional place where people can still file proposals if they either feel that system would work better (perhaps for a sufficiently high traffic article) or if the AfD is closed as no consensus (but, of course, not 'keep' or 'delete). This would allow most merger suggestions to get more discussion (because of higher visibility) and closed faster (time limit of AfD) and may also have the benefit of more controversial Proposed mergers getting more attention because there are more manageable amounts. Eddie891 Talk Work 23:38, 25 January 2021 (UTC)
 * , I agree (as I hope everyone does) that the merge proposal system is clearly broken and needs some sort of reform. I'll leave it to others more familiar to decide whether folding it into AfD is the best approach, but I'm down to try something, and worst case scenario it fails and we return to the status quo.
 * Since this is a developed, actionable proposal, you might want to move it to WP:VPR, as the idea lab isn't a place for !voting. &#123;{u&#124; Sdkb  }&#125;  talk 03:18, 26 January 2021 (UTC)
 * I think we should redirect RMergers to AFD and be done with it. (Regardless of that opinion, we should also make it doubly clear somewhere on WP:Deletion policy and/or WP:ATA and/or WP:AFD/AI that not-votes like "AFD is not for merging" get kicked to the curb.) --Izno (talk) 03:58, 26 January 2021 (UTC)
 * Unless someone provides a good reason for the bureaucracy that is having completely separate and non-overlapping (by policy, if not practice) procedures for merging versus deletion versus draftication versus etc of articles, I agree completely that AfD should serve as a central point of discussion for any article that people feel should not be an article - be that "it should be a redirect" or "it should be merged" or "it's too soon so draftify". -bɜ:ʳkənhɪmez (User/say hi!) 04:09, 26 January 2021 (UTC)
 * I have concerns about the actual execution as well as diluting AfD participation with large numbers of merge articles. While the discussion and closing don't take too long, merging requires a lot of execution effort. I don't do AfDs that have a merge close likely result since I don't want to merge them, and without someone agreeing to do it (say, the nom), it risks the close of discussions without actual merging being carried out on a reasonable timescale. Nosebagbear (talk) 10:15, 27 January 2021 (UTC)
 * Even in that scenario though, you still get a decision and anyone can act without sitting in ambiguity. And that decision is timely, and it's visible on the article that the article is long in the tooth. RFM is like AFC except it can be years rather than months before you know. --Izno (talk) 18:28, 27 January 2021 (UTC)
 * What plays the biggest role in diluting AFD is when users go on large nominating sprees of 20+ articles in a single day. So far in january there have been 200 proposed mergers, or about seven a day. I don't see adding those to the 100+ AFDs regularly nominated each day as holding the potential for overwhelming that process. Eddie891 Talk Work 18:35, 27 January 2021 (UTC)
 * I wouldn't say that reasoning is entirely cast-iron. You'd like this change because it would make it easier to get merges to happen, presumably encouraging more. That would logically bump up the figures far more than the 7/day (which would be notable, but certainly tolerable). If it didn't bump it up, then the change would probably not be worth making. Nosebagbear (talk) 10:35, 29 January 2021 (UTC)
 * I have been editing WP since 2006... and I didn’t know a separate Merger process even existed! It certainly was not advertised widely (When was it created?)  I have no problem dealing with contentious merger proposals through AFD. Why do we need two separate bureaucracies? Blueboar (talk) 13:19, 27 January 2021 (UTC)
 * Probably because it's listed somewhere in PEREN. :^) --Izno (talk) 18:28, 27 January 2021 (UTC)
 * It seems unlikely that any experienced editor has not seen and attended a merge discussion such as this or that. I am reminded of M. Jourdain who is surprised to learn that he has been speaking prose all his life, without knowing it! Andrew🐉(talk) 09:37, 30 January 2021 (UTC)
 * It seems unlikely that any experienced editor has not seen and attended a merge discussion such as this or that. I am reminded of M. Jourdain who is surprised to learn that he has been speaking prose all his life, without knowing it! Andrew🐉(talk) 09:37, 30 January 2021 (UTC)


 * Comment: The general Articles to be Merged backlog is now below 12 months (this used to be 2.5+ years), and the AfD resulting in Decision to Merge backlog is again below 90 days and rapidly being reduced.  Just so you know.  Anyone who wishes to help out, you now have the links to do so. SMirC-grin.svg  Regards,  GenQuest  "scribble" 18:50, 27 January 2021 (UTC)
 * Comment, I have similar concerns to Nosebagbear but I see merit in the idea that likely contested nominations could be nominated at AfD with the nominator proposing a merger. I would however oppose anything that would prevent editors from conducting bold mergers/redirects (obviously bold deletion is unavailable to most of us, for good reason), if contested they could then be formally nominated (as is currently the case). Cavalryman (talk) 11:50, 29 January 2021 (UTC).
 * I've never really understood why they're separate. If anyone wishes to only watch for deletion discussions or only watch for merger proposals, that can be handled via one of the several ways we already organize AfDs. AfDs don't get lost in talk page archives, are more centralized, and have a structure that can already result in merger. I say take this opportunity to reduce our number of complicated processes. Or perhaps try it out for a while? &mdash; Rhododendrites  <sup style="font-size:80%;">talk \\ 02:42, 30 January 2021 (UTC)
 * Oppose Let us count the ways:
 * 1) Mergers are inherently unproductive because they just move content from one page to another with low value-added
 * 2) Mergers can mostly be done by anyone using ordinary editing tools, just as anyone can add, remove or move a section in an article
 * 3) Deletion however is a specially restricted function because it makes the content inaccessible and is not easy to revert
 * 4) AfD exists primarily for deletion, providing the clear consensus required for admins to use this specially restricted function
 * 5) AfD is moribund too because it's no fun looking at junk
 * 6) The longer the AfD list, the less likely that people will look through it and so participation will decline further
 * 7) Already we see lots of AfD discussions being relisted again and again for lack of participation
 * 8) AfD tends to attract zealots who tend to vote delete as a knee-jerk reflex, without regard to the merits of the topic and its potential
 * 9) The proposal therefore risks turning mergers into deletions and content will be lost
 * 10) There are technical limits on the size of the daily AfD logs due to their heavy use of templates
 * 11) The AfD process doesn't scale - neither technically nor in its human factors
 * 12) The proper place to get attention for mergers would be projects staffed by subject-matter experts
 * 13) But projects are dying too
 * 14) The main reason that everything is dying is excessive assholery, battleground behaviour, busywork and conflict
 * 15) We need to focus on fostering collaboration, cooperation and content creation rather than finding new and better ways to annoy each other
 * Andrew🐉(talk) 08:21, 30 January 2021 (UTC)


 * I agree with merging merges into AFD. One place to discuss what happens to a stand alone page (delete, draftify, merge, etc) seems to make the most sense and will avoid the duplication of effort and dilution of attention that happens now with multiple processes. Levivich harass/hound 15:15, 4 February 2021 (UTC)
 * Support folding it into AfD Didn't even know WP:PROPMERGE existed (note, most merge discussions I've closed on WP:ANRFC didn't use such a process either but were just regular talk page discussions). Looks like a useless process to me. Personally I'd have taken "blank-and-redirect" type merges into AfD anyway. It's a centralised venue which achieves conclusive outcomes, whereas many talk page discussions take far more weeks and still end up with minimal participation. I dislike that some admins refuse to acknowledge merge consensus imo, with the rationale that AfD isn't for merges, even if the AfD reached a consensus for merge. That part seems to be dependent on the closing admin (some allow it, others don't and say "can be discussed elsewhere", from what I've seen). ProcrastinatingReader (talk) 16:06, 4 February 2021 (UTC)
 * Support The only place where such a discussion will get any attention at all is AfD--though participation is lower than it should be, it's still the best-attended of such processes. Since merge has in the past been used as a surreptitious method of deletion by calling it a merge, but not actually merging anything substantial, it makes sense. We should probably specify that the action in such discussions if there is no participation is not the soft delete we use for articles, but merge, as undisputed. Both are easily reversible if challenged. As  says, the virtue of AfD is that if disputed, it comes to a conclusion. Yes, AfD tends to attract people who try to find reasons to vote delete, but it also attracts those who seek every possibility for keep. Those in each party have always been sure they were a struggling minority. I'm not sure how that would translate into merges--each side sometimes suggests it to find a compromise solution. Merges are not unconstructive--they move the information, but they remove the often extensive duplication and all the overhead associated with being a separate article.
 * No, AfD often does not come to a conclusion. Many times, AfDs are closed as no consensus.  Or a supposed consensus doesn't stick.  For example, today I closed an AfD.  Notice that there had been 8 previous discussions!  And notice that no-one suggested merger of the subject into Kennedy family, even though this was an obvious alternative.  AfD encourages the adversial extremism of Keep/Delete rather than more complicated compromises. Andrew🐉(talk) 23:47, 11 February 2021 (UTC)
 * , As a regular at AfD, I have no problem with a merge result, nor with a nominator proposing merge as one of the alternatives. And you are right that merge discussions are much slower. However, we should not just convert merges into AfD discussions as obviously the process is for deletions, not merges. What we need instead is an AfD like process, where merges are listed in a central directory, sorted, and gain more visibility than they do currently. <sub style="border:1px solid #228B22;padding:1px;">Piotr Konieczny aka Prokonsul Piotrus&#124; reply here 11:57, 12 February 2021 (UTC)


 * I don't understand why we have so many policies for merging, AFD, Prod it is just mad. New users find it difficult, and I have been on and off Wikipedia for several years and still finding stuff because it's not the easiest of layouts. I stated on a previous AFD policy that I think Prod should be done away with, and Merger should be integrated into the AFD policy and process, making it simpler for users to find and discuss. I know Andrew has commented about poor quality of some mergers, but this should be made part of AFD process i.e. If editors decide a concensus to merge, then it should be then left open to discuss level of merger. Davidstewartharvey (talk) 16:03, 14 February 2021 (UTC)

Color code http and https links differently
Should we indicate by color code whether a link to a website has an SSL certificate? For example, Wikipedia shows a box/arrow that is blue. That's good because it is https. However, a site like CI, which has no SSL certificate and connects as http has the same color (blue) box/arrow. I suggest we turn that red. Charles Juvon (talk) 00:19, 11 February 2021 (UTC)


 * I think they could be coded to display a lock to show it is a secure connection. I remember seeing this on FANDOM. Aasim (talk) 04:27, 11 February 2021 (UTC)
 * I don't know what you two are talking about; I'm using Firefox 52 (yeah, I know) on Vista (can't help it) with the Modern skin, and I see a yellow lock next to the blue link for Wikipedia, and a blue box with an arrow coming out of it next to the blue link for CI. If I saw a red link, it would make me think a wiki target didn't exist, so it'd be confusing. IOW, for me, the "problem" is already solved. Ergo, no, we don't need to add an unexpected color to our hyperlinks. &mdash; JohnFromPinckney (talk) 06:29, 11 February 2021 (UTC)
 * JohnFromPinckney, Modern is not a maintained skin beyond what it takes for it to function from a PHP perspective. Don't use it if you want to have a good representation of what most people see today. (I am minded to hunt down the relevant CSS and have it removed if it still displays as such.) --Izno (talk) 15:29, 11 February 2021 (UTC)
 * Thanks for the tip, Izno. But: how am I supposed to know that? I was using Vector, but several things (Alerts, Notifications, show/hide on collapsed items) stopped working, so I tried one of the four other skins in my Preferences list. Modern didn't exhibit any of those problems, so I thought I was up to date. And besides: "Modern". IYKWIM.
 * And now, it seems that my obsolete skin is more functional (in terms of http/https icons) that what other WP users use. So I'm totally confused. &mdash; JohnFromPinckney (talk) 15:49, 11 February 2021 (UTC)
 * JohnFromPinckney, to answer the question in your edit summary, Modern has been a skin for at least a decade and offhand I believe it predates Vector. The name "Modern" is just a 'pretty' name. --Izno (talk) 15:59, 11 February 2021 (UTC)
 * I'm calling my lawyer to see about suing for false advertising. I require a remedy for the mental anguish I've endured... &mdash; JohnFromPinckney (talk) 16:03, 11 February 2021 (UTC)
 * Oh rats, here I was hoping I wouldn't need to block you for using Firefox 52 on Vista. C'est la vie. --Izno (talk) 16:08, 11 February 2021 (UTC)
 * Don't block me for using Vista; it's not my fault and, trust me, I'm suffering enough. You should block me for WP:THREAT. ;-) &mdash; JohnFromPinckney (talk) 16:20, 11 February 2021 (UTC)
 * Enforcing actual policy? Sounds like bologna. --Izno (talk) 16:29, 11 February 2021 (UTC)
 * I do not anticipate a change here. The previous differentiating "lock" for HTTPS was removed because they had become noise to most people (most sites were migrating or had been migrated to HTTPS by that time). They were removed in 1.23/1.24, nearly 7 years ago. It would be just as noisy for us to add something to unsecured links. Moreover, some websites do not keep up their actual certificates, so at best we are linking to something with HTTPS in the scheme but which we can only guess as being secured. Bad idea overall.--Izno (talk) 15:29, 11 February 2021 (UTC)
 * You can change it for yourself only. This is the CSS rule to put in Special:MyPage/common.css:  With this rule, links to https: sites will get a blue padlock, links to http: sites will retain the arrow-out-of-box icon. -- Red rose64 &#x1f339; (talk) 16:39, 11 February 2021 (UTC)
 * We should prefer HTTPS links, but it's not important enough to the average reader to justify the extra visual clutter. It would be better to have some sort of bot or userscript that can change/highlight HTTP links for editors who opt-in (if it doesn't already exist). –&#8239;Joe (talk) 16:46, 11 February 2021 (UTC)
 * For most common/big sites, MediaWiki does an automatic transform of HTTP to HTTPS since a year or two ago. There is additionally a bot for that to change the wikitext. RR above provides the perhaps-desired CSS for indicating which are secure; one could change it trivially for the reverse case. --Izno (talk) 17:10, 11 February 2021 (UTC)
 * Thank you all for considering my proposal and discussing it in such an informed manner. Special thanks to  for the CSS rule.  I remain concerned about our readership.  Most know not to click a link in spam email, but they might not expect WP to send them off to a bad site.  There is another issue:  Recently, I obtained an SSL certificate for my personal website. I had to remove every single http link in my site to obtain a certificate.  So, I assume, there is an exception for large well known sites like WP.  Is that correct? Charles Juvon (talk) 17:32, 11 February 2021 (UTC)
 * That's not a requirement to get an SSL/TLS certificate for anyone... where did you get it from? How could it possibly be enforced? Anyway, something like 10% of major websites still use HTTP, so it's not intrinsically dangerous to follow a link to one. Wikipedia itself has enforced HTTPS for years and I don't think it's our responsibility to point out that other websites don't; most people using a modern browser will already see a warning. –&#8239;Joe (talk) 10:42, 12 February 2021 (UTC)
 * Agree with Joe. No need for Wikipedia to provide this clutter. This is a problem for browsers. Lack of TLS isn't inherently dangerous anyway. ProcrastinatingReader (talk) 00:18, 13 February 2021 (UTC)
 * I am not at SSL expert, but I definitely had to remove all http links from a Yahoo Business website as per their policy. Our own article on TLS is rather complicated, and it references many sources including this.  Perhaps one can conclude that individual web hosting services are setting policy. Charles Juvon (talk) 17:45, 13 February 2021 (UTC)
 * nothing in the document you linked to says anything about need to remove HTTP links to obtain a certificate. It says nothing about the requirements to obtain a certificate at all. All it says is that if you use HTTP resources on your site, browsers and other tools may warn that your site is insecure or has mixed content. Note that despite some confusing wording, this refers to resources only i.e. files that need to be loaded to render the page e.g. images (with or whatever), fonts, scripts. It doesn't refer to hyperlinks ( etc) on a website to other pages or websites. (I.E. Other sites or pages that may be loaded by the end user clicking on them, but which aren't loaded to render page.) Also, the very fact they mention this means it's possible to obtain a certificate even with insecure resources, let alone links. Otherwise you could never have a mixed content site. Nil Einne (talk) 17:23, 14 February 2021 (UTC)

Topic blocks to complement topic bans
Now that we have the capability of blocking editors from editing specific articles, is there a way that we can bundle together all articles within a specific topic area (e.g. post-1992 American politics, COVID-19, Beyoncé) so that an editor who has been topic-banned from editing in those areas could in fact be blocked from editing pages deemed to fall within those areas? BD2412 T 21:19, 8 February 2021 (UTC)


 * Thought about this before, and imo it seems to be technically infeasible. There's no special way to determine whether an article is really within the AP2 editing area. There are talk page DS notices (Ds/talk notice), but anyone can place that so relying on it would be problematic (eg I'd be able to place that notice on a random article to block people from editing it. highly likely to be abused). Of course, this assumes that the page blocking functionality could work with categories or templates, which it can't. ProcrastinatingReader (talk) 21:26, 8 February 2021 (UTC)
 * Another problem is articles that include both content under the ban and content not under the ban. For example, the article for any year since 1992 is going to include both AP2 and non-AP2 content. signed,Rosguill talk 21:30, 8 February 2021 (UTC)
 * I had two thoughts for specific approaches. One would be by the category tree where the Tban is specific to something like a country or a musical artist. The other would be to manually construct a list on a protected page in project space and reference it. An actual block on editing would likely only apply to pages squarely within the Tban. BD2412  T 22:18, 8 February 2021 (UTC)
 * I don't think the DS notice is an issue - if someone places those maliciously, it just gets reverted (obviously if someone topic-banned hit an invalid one they would immediately raise the issue on WP:ANI or WP:AE or wherever is appropriate) and the user who placed it sanctioned if the maliciousness is self-evident. It's generally clear-cut so it wouldn't be an issue.  The issue with articles that contain things both inside and outside the topic area is harder to deal with, though. --Aquillion (talk) 21:52, 15 February 2021 (UTC)


 * I believe there was an RFc before pblocks were implemented discussing this and "category" style pblocks being too easy to game... CUPIDICAE💕 22:31, 8 February 2021 (UTC)
 * See Community health initiative/Partial blocks for more information about that approach. Whatamidoing (WMF) (talk) 05:47, 10 February 2021 (UTC)
 * The issue with category blocks is really twofold. Anyone can add them, anyone can remove them. Which de facto gives anyone the ability to block certain users (eg I can add American Politics to this page. It might be quickly reverted, but still). The third issue is that the idea of a protected page / admin list may be infeasible. I’m not sure admins could really maintain their own list. Maybe they could get a category list at a given time, skim check it over and then add it to the protected page, which will at least be mostly complete. But mostly I’m not sure this is a problem. I mean, topic ban evasion isn’t hard to identify. People are usually quick to report each other to AE for even the slightest violations. ProcrastinatingReader (talk) 06:39, 10 February 2021 (UTC)
 * As touched on above, this is a nice idea on paper but would just create more issues. ~ HAL  333  22:18, 10 February 2021 (UTC)
 * It would need to be done on a case-by-case basis and would require a code change, but it is do-able. One way to do it would be to get rid of the low limit on page blocks, which I think is 10 or something like that. If this were a very high number - say 5000 - then in most cases it would be easy enough to generate a "snapshot in time" list of pages from categories, manually filter out the obvious "false positives," then page-block the person from all of those pages.  This would make for very long block logs though, but it is do-able.  It won't work for "mixed content" pages though, where the topic-ban, even "broadly construed," only covers part but nowhere near all of the content of a given page.  I don't see any easy way to enforce that in software without over-kill.  It also would do nothing about pages that aren't properly categorized or which don't exist yet, but which are covered by the topic-ban.  Bottom line:  I think it's a good idea, if you accept the limits involved and don't consider it a magic bullet to enforce topic-bans.  davidwr/  (talk)/(contribs)  22:29, 10 February 2021 (UTC)
 * I haven't been directly involved in any of the partial-block work, but from what I've overheard, being able to partial-block someone from 5,000 pages is unlikely to be acceptable to Ops for performance/database reasons. Whatamidoing (WMF) (talk) 21:40, 15 February 2021 (UTC)

Adding a reply button on all talk pages.
I believe this will help many beginner editors. When you click it you just type a message and then it automatically puts your signature. SoyokoAnis 19:21, 12 February 2021 (UTC)


 * This is part of the WP:Talk pages project. There's an ongoing discussion about experiences using the tool here. ProcrastinatingReader (talk) 19:23, 12 February 2021 (UTC)
 * It's an excellent suggestion that everybody wants. In addition to the Talk pages project tool linked to above, there is a script, User:Enterprisey/reply-link, that you can install. Levivich harass/hound 21:13, 12 February 2021 (UTC)
 * Which doesn't allow an edit summary, so I don't use it. Doug Weller  talk 19:58, 13 February 2021 (UTC)
 * It can be configured to allow an edit summary to be entered. isaacl (talk) 23:06, 13 February 2021 (UTC)
 * Almost nobody actually types meaningful manual edit summaries on talk page edits, and even the editors who use the edit summary option the most on talk pages will use pointless edit summaries such as  (meaning "comment") on occasion. Whatamidoing (WMF) (talk) 21:50, 15 February 2021 (UTC)
 * Sure; I was just addressing Doug Weller's issue. Looking at that editor's contributions made me think that admins are probably more likely to use edit summaries on user talk pages in order to explain their actions. isaacl (talk) 22:33, 15 February 2021 (UTC)

Adding more information in templates
Dear editors and others of Wikipedia. Forgive me for I am new to this site. I have enjoyed using Wikipedia for as long as I can remember. However, after visiting the site so many times, I feel that somethings are missing. For those who don't have time to read every single piece of information on some historical or current leader. politician, etc, etc. They don't know how to get this information. I propose a couple of ideas for the templates.

Ideas

What I am proposing is this.

Tenet: Progressive, Neutral or Conservative

With this, users and those visiting the site can learn what their favorite historical or current leaders' tenet is.

For example. These are just a couple of historical individuals to give you an idea.

Progressive: Oda Nobunaga, Qin Shi Huang, Date Masamune and Cao Cao.

Those who wish to move forward towards a better future and life.

Neutral: Sun Quan, Sanada Yukimura, Zhang Liao, Minamoto no Yoshitsune and Tokugawa Ieyasu.

Those who wish to join neither side whether it be a conflict, war, religious matter, etc, etc.

Conservative: Adolf Hitler, Takeda Shingen, Liu Bei and Zhuge Liang.

Those who wish to stay in the past and protect old traditions.

Ideals: Ambition, Fame, Talent, Family, Determination, Mastery, Greed, or Justice.

Fame: Those who wish to obtain as much glory and status as possible.

Ambition: Those who have big ideas for the future and the world.

Talent: Those who wish to show their talent and make themselves known.

Greed: Those who wish to achieve everything they want by any means.

Determination: Those who wish to achieve their goals with any opportunity that comes or is available.

Family: Those who goals are solely to ensure that their family, clan, business, etc, etc, stays strong and endures.

Justice: Those who wish to make sure evil does not prevail and to protect those whom they love.

Mastery: Those who wish to continue to prefect their craft whether they are a swordsman, priest, blacksmith, merchant, etc, etc.

With this, users and those visiting the site can learn what their favorite historical or current leaders ideals are.

Fame: Shimazu Yoshihiro and Minamoto no Yoshitsune

Talent: Toyotomi Hideyoshi and Kuroda Yoshitaka.

Greed: Dong Zhuo, Tokugawa Ieyasu, Matsunaga Hisahide and Lu Bu.

Justice: Sanada Yukimura, Hosokawa Tadaoki, Liu Bei, Zhuge Liang and Zhao Yun.

This give you an idea.

Tier: C, B, A or S.

With this, users and those visiting the site can learn what their favorite historical or current leaders tier.

S: Cao Cao, Oda Nobunaga, Zhang Liao, Imagawa Yoshimoto, Zhuge Liang, Qin Shi Huang, Minamoto no Yoshitsune and Toyotomi Hideyoshi.

A: Kuroda Yoshitaka, Miyoshi Nagayoshi, Hosokawa Tadaoki, Akechi Mitsuhide and Shimazu Iehisa.

This gives you an idea.

Rebellious: 1 ~ 15

14: Date Masamune and Ōtomo Sōrin.

13: Miyoshi Nagayoshi.

12: Oda Nobunaga, Toyotomi Hideyoshi and Kuroda Yoshitaka.

11: Imagawa Yoshimoto.

This gives you an idea.

If these ideas are added to templates, it should help users and newcomers learn must faster and more efficiently on what or who they wish to learn about. It doesn't have to just apply on people, but policies, groups, organizations or whatever it can be applied to.

This is what I propose to help Wikipedia help those who want to known this type of information is essential to any avid leader or newcomer. Like with everything, Wikipedia must move forward. If not, those who do not are doomed to fail. That is all I have to propose at the moment. — Preceding unsigned comment added by Azuchi1579 (talk • contribs) 10:34, 26 February 2021 (UTC)
 * Why would need this? There's a search bar. And what templates are you talking about? Lettlerhello • contribs 20:56, 27 February 2021 (UTC)
 * It would be a gargantuan task to class all article subjects according to their ideals without violating WP:NPOV; managing the inevitable editwarring and POV-pushing would require ten times more effort, to say nothing of the complaints and lawsuits from article subjects angry that they've been classified as "greedy" or put in the same tier as Hitler. I couldn't think of a better way to drive Wikipedia into the ground. – Teratix ₵ 04:52, 28 February 2021 (UTC)
 * I'll do my best not to bite here– but Wikipedia can't appeal to the lowest common denominator. Our apologies if you can't read the whole article, but usually, if the political beliefs of someone are notable, they'll be included in the lead or a relevant section. Also, this would be impossible to do without violating WP:NPOV. theleekycauldron (talk • contribs) (they/them) 23:41, 1 March 2021 (UTC)

Notification of an RFC
Users may be interested in the RFC at. Thanks, -- DannyS712 (talk) 23:29, 18 February 2021 (UTC)

Science Photo Competition 2021 Russia targeting CentralNotice banner
On Marth 1, the «Science Photo Competition 2021» started, traditionally the photo marathon is being held jointly with the Nauka television channel, it will be interesting. We invite everyone who is interested in science and who is able to hold a camera in their hands. The rules of the contest are very simple, prizes have a place to be! Colleagues, to attract external participants, we proposed a banner of the competition through CentralNotice. JukoFF (talk) 11:43, 21 February 2021 (UTC)

New speedy delete criterion (Not for Wikipedia)
This AfD could have been resolved earlier if there was this criterion. It was clearly not for Wikipedia, and it was a WP:SNOW anyway. The text should read as follows:

'Ax''. Not for Wikipedia.'''

Pages which qualify under Not for Wikipedia as not for Wikipedia. (templates)

-or something to that effect. This should be numbered A12. Please consider this, as it will help avoid future unnecessary AfDs like that. AnotherEditor144talk contribs 21:56, 14 February 2021 (UTC)
 * Just let the process work out. It will be gone within a week. --Malcolmxl5 (talk) 22:18, 14 February 2021 (UTC)
 * Clearly not for Wikipedia is far too broad and subjective for a speedy deletion criteria. I'm a little more sympathetic to AFD snow as a speedy deletion criteria, except for the issue that sometimes it can be a while before someone comes along and does the legwork to find spources and save an article.  Ϣere Spiel  Chequers  22:45, 14 February 2021 (UTC)


 * I of course also agree that "not for Wikipedia" is much too broad and subjective for CSD. As for SNOW, it can't be a CSD because then future iterations of the article wouldn't be G4-eligible. Perhaps a better idea would be to create some sort of "requested SNOW closure" category (perhaps populated via a template) to notify administrators that a SNOW close had been requested. Extraordinary Writ (talk) 22:59, 14 February 2021 (UTC)
 * Wouldn't that require making WP:SNOW a guideline first? Adam9007 (talk) 23:09, 14 February 2021 (UTC)
 * Snowball closes are authorized by WP:XFD, which is a guideline. I thus think that a requested SNOW close category would be valid, although the details would probably still need to be fleshed out. (WP:SNOW probably should be a guideline, for what it's worth, although I don't think it's necessary for our purposes.) Extraordinary Writ (talk) 23:25, 14 February 2021 (UTC)
 * Ok. Let's go to Wikipedia talk:Criteria for speedy deletion and sort this out. AnotherEditor144talk contribs 07:33, 15 February 2021 (UTC)
 * This is a frequently suggested criterion for speedy deletion, indeed so much that it is point one at WP:NOTCSD. Also, for future reference, the correct location to proposed speedy deletion criteria is Wikipedia talk:Criteria for speedy deletion. Thryduulf (talk) 23:01, 14 February 2021 (UTC)
 * Ok. AnotherEditor144talk contribs 07:28, 15 February 2021 (UTC)
 * So should this maybe be moved to the talk for the CSD page? Foxnpichu (talk) 14:22, 15 February 2021 (UTC)
 * Only if someone has a proposal for something different to what has been suggested and rejected countless times before. Also don't bother unless it meets all four of the criteria at WP:NEWCSD. Thryduulf (talk) 15:14, 15 February 2021 (UTC)
 * I wonder whether what's needed is actually to change CSD's name, from "speedy deletion" – everyone wants bad articles to be removed quickly, so if CSD doesn't have the right criteria to fit the page I want to get rid of, then we should just expand the list some more – to something like "undiscussed deletion". WhatamIdoing (talk) 06:42, 16 February 2021 (UTC)
 * Interesting idea. Ideally a new name would include something to indicate that it is an exception to the standard process for exceptional situations not something that's just for "things one or more editors dislike". Thryduulf (talk) 12:31, 16 February 2021 (UTC)
 * That’s the problem. If an article seriously needs deletion, it is best to delete it immediately. Foxnpichu (talk) 23:05, 16 February 2021 (UTC)
 * Well, then, how about "Article for Immediate Removal" (or Deletion, etc.)? GenQuest  "scribble" 17:39, 24 February 2021 (UTC)

CentralNotice proposal for International Women's Day
A proposal has been made to run a CentralNotice banner for both anonymous and logged-in users from March 1-10 for International Women's Day, highlighting gender gap issues. The proposal is at CentralNotice/Request/Int. Womens day 2021. --Yair rand (talk) 11:36, 22 February 2021 (UTC)
 * I'm only a man, but can somebody tell me when International Women's Day is? You know, a date? Neither of those two links tell me when this damned thing is supposed to be. I guess all the women already know it, but if we're all supposed to celebrate it, or it's supposed to mean something, why is it kept such a big secret? &mdash; JohnFromPinckney (talk) 02:09, 23 February 2021 (UTC)
 * International Women's Day is 8 March. --Malcolmxl5 (talk) 02:25, 23 February 2021 (UTC)
 * Maybe the reason all the women already know when it is, is because they tried clicking the links, or reading the first sentence of International Women's Day. Levivich harass/hound 02:29, 23 February 2021 (UTC)
 * If you don't fancy Google, then there is this nifty online encyclopaedia that has articles about things like this and much more. It's called Wikipedia, you might even have heard of it? Anyway, you can find their article at International Women's Day, and in the very first sentence it says it's got a citation and everything! Thryduulf (talk) 02:32, 23 February 2021 (UTC)
 * Yes, friends, thanks for providing the actual date along with the snide remarks. I was 98.3% sure somebody was going say, "but it's right there in big letters!", and I had just completely overlooked it. And yes, I could have googled, or looked directly for a WP article on International Women's Day, but I foolishly followed the provided link to International Women's Day, thinking (sort of on autopilot) that that must be it.
 * And while it's good and right that International Women's Day (the unlinked one) included the date, I still think two other pages which make a big deal out of "International Women's Day" would at least mention when it is. You know, for us ignorant people who might learn something. I know when Christmas Day and the Fourth of July and New Years Day are, but I haven't learned IWD yet. Or maybe I'll know it now. &mdash; JohnFromPinckney (talk) 04:20, 23 February 2021 (UTC)
 * Second link in the OP, top of the page: Levivich harass/hound 04:27, 23 February 2021 (UTC)
 * Ah, now I see it. Still took me a whole minute, even with your directions. Thanks. &mdash; JohnFromPinckney (talk) 04:36, 23 February 2021 (UTC)
 * You're welcome. As a man, I'm proud you even asked for directions. Levivich harass/hound 05:52, 23 February 2021 (UTC)
 * International Men's Day is 19th of November. Emir of Wikipedia (talk) 21:51, 23 February 2021 (UTC)
 * Well, shoot, everybody knows that. Minor, finicky detail: I didn't know there even was a International Men's Day. &mdash; JohnFromPinckney (talk) 22:47, 23 February 2021 (UTC)


 * Opposed - WP should not engage in advocacy - no matter how noble the cause. Just spend the day improving articles about women. Blueboar (talk) 15:33, 25 February 2021 (UTC)
 * This is not advocating for a cause, this is a notice bringing to our attention several events aimed at filling in gaps in the encyclopedia. --Malcolmxl5 (talk) 15:35, 25 February 2021 (UTC)


 * Reiterating support for this central notice. You may disagree with advocacy, but worth noting English Wikipedia in general has done advocacy e.g. SOPA initiative, and while not community sanctioned, the Wikimedia Foundation sued NSA. This event itself is not advocacy and most concretely is a call to improve content on Wikipedia. Shushugah (talk) 15:49, 25 February 2021 (UTC)
 * I try to avoid where possible much celebration of such days, because they often serve as excuses to ignore relevant issues for the rest of the year, but if this encourages people to take part in events that aim to improve Wikipedia then I see no reason to oppose it. It is not advocacy, as in telling people what they should think, which I do oppose. Phil Bridger (talk) 16:32, 25 February 2021 (UTC)


 * I believe that the actual proposal for the banner has been made on meta. The original post by Yair rand above contains a link. Probably editors wanting to express support/oppose opinions should do so there, not here. Nsk92 (talk) 18:11, 25 February 2021 (UTC)

Cite book display: contributors/contribution should FOLLOW author/title, not precede them
Here I'm editing Carl Marzani. The entry of concern displays as Only on Wikipedia does the citation give top billing to the author of the Foreword. That's not good, please fix it, so that the entry appears like this:
 * King, Jr, Martin Luther; Nelson, Truman (1962). Foreword. Negroes with Guns. By Williams, Robert F. New York: Marzani & Munsell. OCLC 340047.
 * Williams, Robert F. (1962). Negroes with Guns. with Foreword by Martin Luther King, Jr; Truman Nelson. New York: Marzani & Munsell. OCLC 340047.

Even better, since the "Foreword" is actually two separate essays by King & one by Nelson, it would be best to have contribution1, contribution2 and contribution3 as parameters. Larry Koenigsberg (talk) 18:38, 1 March 2021 (UTC)
 * Please raise this at Help talk:Citation Style 1 which is where citation template issues are discussed. Peter coxhead (talk) 19:33, 1 March 2021 (UTC)
 * Done. Raised at Help talk:Citation Style 1/Archive 75. Larry Koenigsberg (talk) 21:50, 1 March 2021 (UTC)