RFC: New PDF icon[edit]

Should we replace the current PDF icon? –MJL ‐Talk‐^☖ 05:33, 8 September 2021 (UTC)

Background

Our current PDF icon is File:Icons-mini-file acrobat.gif . To put it simply, it isn't particularly good. It's a .gif made over 16 years ago. Berrely mentioned this in WP:Discord, so I set about coming up with a modern SVG version of the file. The result was File:Icons-mini-file pdf old.svg  File:Icons-mini-file pdf.svg .

Options

There are three options that should be considered here:

• Option 1 to support using File:Icons-mini-file pdf old.svg  File:Icons-mini-file pdf.svg 
• Option 2 where you agree that we should change File:Icons-mini-file acrobat.gif  but don't like File:Icons-mini-file pdf.svg 
• Option 3 to oppose any changes to File:Icons-mini-file acrobat.gif 
• Option 4 for removing the icon entirely.

Consensus for Option 2 should be followed up in a separate discussion. [Updated 15:35, 9 September 2021 (UTC)]

Further discussion (PDF icon)[edit]

Since opinions are split and some people noted that further discussion would be needed, leaving this section open. Jo-Jo Eumerus (talk) 16:41, 11 January 2022 (UTC)

• There are 15 icons in Commons:Category:PDF icons under Public Domain that are not based around the Adobe Acrobat logo (which was rejected above), listed below in alphabetical order of file name; the ones in italics were mentioned in the above discusison
  • Option 1: File:.pdf OneDrive icon.svg -
  • Option 2: File:Document-303123.svg -
  • Option 3: File:Icon pdf file.png -
  • Option 4: File:Icon pdf.svg -
  • Option 5: File:Icon-354355.svg -
  • Option 6: File:Ilovepdf.svg -
  • Option 7: File:PDF icon black.svg -
  • Option 8: File:PDF icon blue.svg -
  • Option 9: File:PDF icon bold.svg -
  • Option 10: File:PDF icon.svg -
  • Option 11: File:Pdf link icon.png -
  • Option 12: File:Pdf-155498.svg -
  • Option 13: File:Pdf-2127829.png -
  • Option 14: File:Pdf-47199.svg -
  • Option 15: File:Pdfreaders-f.png -

  I think that is too many options for a single RfC so we should try and narrow it down first. Unless anyone has better suggestions I propose a round of approval voting first to find the top 4/5 that people could support, with those being the options in a full RfC? Thryduulf (talk) 18:09, 11 January 2022 (UTC)

  Seems like a good plan, as I agree that 15 choices is too many. (As an editorial aside, the list could get quickly pruned somewhat by eliminating those which are unusable; some of these are indecipherable to me.) Do we need to first clarify .svg/.png formats? Or do we know that both are equally good (although that seems in some conflict with the note in the RfC close above)? — JohnFromPinckney (talk / edits) 04:52, 12 January 2022 (UTC)

  At their current sizes, I find all but 3, 9 & 10 nearly impossible to read. 7, 8 and 11 are a stretch, but I can make out the letters. I would have no idea what 6 means to indicate without context. Aza24 (talk) 05:15, 12 January 2022 (UTC)

  On my device, with my eyes, I can read option 9, and with difficulty 3, 4, and 10. Since I know I'm looking for "PDF", 5, 11, and 12 are on the boundary of recognizability. I could plausibly make out some of the others by removing my glasses and bringing my phone nearer my face, but I'm unconvinced that is the solution we're seeking. Folly Mox (talk) 05:50, 12 January 2022 (UTC)

  3, 9, 10 are the clearest in terms of legibility and actually conveying meaning. Since I'm aware that I'm on team-letters, one other option should be included which is option 14 that is both legible and would probably be understood over time. The issue is that it makes me think it's powerpoint, but that argument could be had in the 2nd RfC. Nosebagbear (talk) 11:55, 12 January 2022 (UTC)

  To clarify for any reviewer, 3 is the best of these Nosebagbear (talk)

• Yes, let's put one contender forward against the incumbent. Legibility is key here; I find 9, 3, 10 easiest to read in that order. Is it worth considering another alternative with the letters in red on white rather than white on red? That could save a couple of pixels at the sides, enabling the letters to grow slightly. I've tried playing around and can't make anything worth uploading but someone with a clue about graphic design probably could. Certes (talk) 14:31, 12 January 2022 (UTC)

  I think any colored text makes it harder to read the letters at such small size. I prefer something like 11, perhaps 9 with plain black text. MB 14:48, 12 January 2022 (UTC)

  Black lettering on 9 would work too, though readers may associate the red-white-black palette with PDF. Certes (talk) 14:56, 12 January 2022 (UTC)

  Maybe 9 with black text and a red outline of the document symbol is a way to get some red in there. MB 15:21, 12 January 2022 (UTC)

• 3, distant second:9. — xaosflux ^Talk 15:11, 12 January 2022 (UTC)
• For me 3 is the most clear, with 9, 10 and 11 readable but noticeably less so. Thryduulf (talk) 15:55, 12 January 2022 (UTC)

  Looking on a smaller (and dirtier) laptop screen 3 is by far the clearest, 9 is readable but not as easily. 10 and especially 11 I'm not convinced I could read if I didn't know what they said. Thryduulf (talk) 22:58, 17 January 2022 (UTC)

• I don't have clear preferences on what should be the one we should adopt, but I have some arguments against 2, 6, 7, 8, 11, 12, 14, 15.
  • The word "PDF" in 7 & 8 are simply not legible at all, and have an overall bad contrast.
  • 11 & 12 look good on zooming in but on my screen, they can be easily overlooked if one isn't searching for a logo on there.
  • 14 & 15 are not quite associatable with PDFs in general. The huge "P" in 14 makes it appear more like MS PowerPoint logo than PDF. In option 15, the average person will associate the green very closely with spreadsheets rather than PDFs (thanks to Excel & GSheets), plus the word "PDF" on it is too small to be legible.
  • 2 appears more like a basic Windows notepad app, again the word "PDF" is not legible either.
  • 6 is the logo of ilovepdf.com and shouldn't be used due to the very reasons some editors already raised regarding the Adobe relation in current one. Also, what does a reader coming across a random heart symbol in a certain external link understand of it? ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 19:25, 12 January 2022 (UTC)
    • To make it easier for whoever compiles the results, are you saying you have no objections to: 1, 3, 4, 5, 9, 10 and 13? Thryduulf (talk) 21:55, 12 January 2022 (UTC)

      Yes, as of yet, I approve of 1, 3, 4, 5, 9, 10 & 13. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 22:15, 12 January 2022 (UTC)

• On my laptop, I find 3 the easiest to read, then 10, then 9, then 11. 7 and 8 possess bad color combinations, options 4 and 12 are too small, and the others just don't look right, especially option 6. ResPM (T🔈🎵C) 00:01, 13 January 2022 (UTC)
• 3 if we're going to use an image, but I think of a Google-like text tag is still better. If we are using an image, there's no advantage to using an SVG if mediawiki is going to convert it to a raster image anyway. --Ahecht (TALK
  PAGE) 18:40, 13 January 2022 (UTC)
• Option 3 is by far the clearest for me. ― Qwerfjkltalk 18:07, 15 January 2022 (UTC)
• Option 3 Most recognizable for me, alternatively 10 as a second choice. — Preceding unsigned comment added by IAmChaos (talk • contribs) 23:17, 20 January 2022 (UTC)
• I'd suggest we just vote on 3, 9, and 10. They're by far the best options of the bunch. Mlb96 (talk) 04:34, 21 January 2022 (UTC)

This has been open a few hours short of 10 days and we have three clear favourites so is seems an appropriate time to close this round. Allocating 1 point for a first or equal first choice and 0.5 for a second or equal second choice the scores are:

Option	Votes
1	1
2	0
3	10
4	1
5	1
6	0
7	0.5
8	0.5
9	7
10	5.5
11	2
12	0
13	1
14	1
15	0

As 3, 9 and 10 are clearly the most supported, they should be the options for the formal RfC. I did initially say "4 or 5" options, but while there is a clear 4th choice (option 11) it is a long way behind and it doesn't seem sensible to make the RfC more complicated just to include it. I don't have time now to set that up, I might later today but after that it will likely not be until about Thursday so someone else taking point would be good. Thryduulf (talk) 10:57, 21 January 2022 (UTC)

Might want to count how many people opined in general. When folks are not treating a RfC as an either-or choice and supporting more than one option, the ratio of "support for a given option"/"total amount of participants" can be an useful metric to gauge consensus. Jo-Jo Eumerus (talk) 11:05, 21 January 2022 (UTC)

3, 9, and 10 are all equally acceptable to me at this stage. KevinL (aka L235 · t · c) 11:14, 21 January 2022 (UTC)

@Jo-Jo Eumerus by a quick count, 13 people expressed an opinion about 1 or more of the options before the summary. The discussion was explicitly set up as approval voting to find the options for an RfC, it was not intended to determine consensus for a final option. Thryduulf (talk) 11:31, 21 January 2022 (UTC)

Since you don't need consensus to start an RfC, Thryduulf, and this discussion seems more than sufficient, I think you should feel free to start it. KevinL (aka L235 · t · c) 02:34, 22 January 2022 (UTC)

@L235 as noted, I'm not going to have time to start it for a few more days. Thryduulf (talk) 01:19, 24 January 2022 (UTC)

RFC: Changing the icon for PDF files[edit]

Which icon should replace the currently used ones for PDF files? At #RFC: New PDF icon there was consensus to replace the current PDF icon (File:Icons-mini-file acrobat.gif ) with one that is not based on the Adobe Acrobat logo, but not on a specific replacement. At #Further discussion (PDF icon) all the public domain icons currently available at Wikimedia Commons that are not based on the Acrobat logo were considered and three identified as clearly better than the others, this RFC seeks to determine which of those options should be used. Thryduulf (talk) 09:37, 29 January 2022 (UTC)

Which icon should be used for PDF files?

• Option A: File:Icon pdf file.png
• Option B: File:PDF icon bold.svg
• Option C: File:PDF icon.svg
• Option D: Something else (to be followed up in a new discussion)

Discussion (Changing the icon for PDF files)[edit]

The following people commented in the first discussion: @MJL, Xaosflux, Yeeno, Joe Roe, Ahecht, Plutonical, JPxG, 1234qwer1234qwer4, CaptainEek, Robert McClenon, WOSlinker, Vulphere, Certes, Izno, JohnFromPinckney, Amakuru, Firefly, Anomie, Malcomxl5, Pppery, Isabelle Belato, Trialpears, Alexis Jazz, Wugapodes, PEIsquirrel, Isaacl, DiamondIIIXX, Blaze The Wolf, DGG, Tol, Vexations, Seddon, Qwerfjkl, Levivich, Szmenderowiecki, Herostratus, GhostInTheMachine, DGerman, Sdkb, Retswerb, Stifle, Nihiltres, Huggums537, Hog Farm, Aza24, Bilorv, Modest Genius, John M Wolfson, and Nosebagbear: Thryduulf (talk) 09:41, 29 January 2022 (UTC)

And the following people commented in the follow-up but not the first discussion: @JohnFromPinckney, Folly Mox, MB, CX Zoom, ResPM, IAmChaos, Mlb96, L235, and Jo-Jo Eumerus:. 09:42, 29 January 2022 (UTC)

Fixing pings: @Malcolmxl5 and Blaze Wolf:. Thryduulf (talk) 09:45, 29 January 2022 (UTC)

• Option A: This is the clearest on all the devices I have available to look at it on (desktop, laptop and Android mobile). Thryduulf (talk) 09:47, 29 January 2022 (UTC)
  • I oppose no icon, because highlighting that a link is not an HTML page is useful information for accessibility - not every device can (easily) read PDF files. Thryduulf (talk) 18:28, 29 January 2022 (UTC)
• Option A looks the best to me. ― Qwerfjkltalk 10:02, 29 January 2022 (UTC)

  Note: I'm on a tablet. ― Qwerfjkltalk 14:38, 29 January 2022 (UTC)

• Option A. The other two look dreadful on my browser, only A is crisp and clean.  — Amakuru (talk) 10:10, 29 January 2022 (UTC)

  Update following Thryduulf's note below: Still sticking with A. C is marginally better than B, but A definitely looks by far the clearest.  — Amakuru (talk) 11:38, 29 January 2022 (UTC)

  Further comment: I've checked on my phone too, and actually C is indeed very slightly better than A there, which might be what others are seeing, but A still looks fine on mobile, so A remains the clear victor overall given the much better rendering on my Windows 10 / Chrome setup.  — Amakuru (talk) 11:42, 29 January 2022 (UTC)

  Also oppose the suggestion of using text. That would be confusing and cluttered, whereas the current icon is fairly clear.  — Amakuru (talk) 17:38, 29 January 2022 (UTC)

• Option A. Seddon ^talk 10:11, 29 January 2022 (UTC)
• Option C - Clearer than option A. A. C. Santacruz ⁂ Please ping me! 11:10, 29 January 2022 (UTC)

  Option A - Nicest looking. A. C. Santacruz ⁂ Please ping me! 10:32, 29 January 2022 (UTC)

• Option A - clearest Nosebagbear (talk) 10:56, 29 January 2022 (UTC)
• @Nosebagbear, A. C. Santacruz, Seddon, Amakuru, and Qwerfjkl: I've just noticed that the image at Option C was actually displaying the option B icon. I've now fixed this, but you may wish to look again. Thryduulf (talk) 11:04, 29 January 2022 (UTC)
• Option C.--Vulp❯❯❯here! 11:14, 29 January 2022 (UTC)
• Option A, C is second, B is nope. In general C seems to be a better file, but when scaled down to 16px for this use case, A seems clearer while C gets a bit of a blur effect. At larger resolutions, I'm seeing the reverse. — xaosflux ^Talk 11:27, 29 January 2022 (UTC)
• Option A: This looks the best at the small size. -- WOSlinker (talk) 11:30, 29 January 2022 (UTC)
• Option A or C: A hard decision for me. On my PC, A is clearly the best, whereas on both my phone & tablet (using mobile version), C appears to be the best. B is last on all platforms though. ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 11:58, 29 January 2022 (UTC)

  I believe that's because A is a .PNG and C is a .SVG. Levivich 16:27, 29 January 2022 (UTC)

  For whatever reason, mediawiki renders the SVG as a 16x18 png on desktop browsers (which looks like crap) and a 32x37 png on mobile browsers (which looks fine). --Ahecht (TALK
  PAGE) 14:53, 9 February 2022 (UTC)

• Option B looks best on a small screen — GhostInTheMachine ^{talk to me} 12:24, 29 January 2022 (UTC)
• Option D: get rid of it. Links to files can be indicated with the text "(PDF)", no need for any icon. The option to get rid of it was introduced too late in the first discussion so it couldn't gain enough traction. — Alexis Jazz (talk or ping me) 12:37, 29 January 2022 (UTC)
• Option A or B: A looks slightly better on my laptop. Surprisingly, B is clearer on my mobile. C is a close third on both. I suspect this is very device- (and perhaps eyesight-) dependent; any of the three would be an improvement. Certes (talk) 12:45, 29 January 2022 (UTC)
• Option D (no icon) all of those icons look like they're from the 90s/early 2000s, tbh. And text "(PDF)" is adequate per above. – John M Wolfson (talk • contribs) 15:37, 29 January 2022 (UTC)
• D (no icon) - My preference remains to use a non-icon, text marker, like (PDF), or even stylized text, like this: PDF. Icons are more taxing, client and server side, than text, and while PDF icons won't make a big difference on the client side, and we can handle it on the server side, this website is only going to get bigger, and I see no reason to burden it with image icons when text will do. Option A looks better on my desktop; it's a PNG. C looks better on my iPhone; it's an SVG. But on my iPhone, I can't see any of the icons clearly enough to make out "PDF" because of the small screen, unless I zoom in. Also, text is word-searchable, where as icons are not. I just don't see any benefit to using any icon over text. Levivich 16:42, 29 January 2022 (UTC)
• Option D (no icon). But, in case we do stick with one, Option A looks better to me. Isabelle ^🔔 16:47, 29 January 2022 (UTC)
• Option A or D (no icon): Option A if icons are preferred, but they aren't that necessary. "(PDF)" is five characters, direct and concise. ResPM (T🔈🎵C) 16:54, 29 January 2022 (UTC)
• Option A or D (stylized text: PDF as suggested by Levivich) I think "A" is the best icon if we have to use an icon, but I believe the idea of stylized text is even better, and it should be presented as one of the options in these discussions. Huggums537 (talk) 17:07, 29 January 2022 (UTC)
  • @Huggums537: removing the icon completely was an option in the first RFC, it did not gain consensus then (using a different icon was). Thryduulf (talk) 18:28, 29 January 2022 (UTC)
    • What I mean is the stylized text should be presented as an option if there are future discussions as you indicated might happen per your original post by option D. So, we still have yet to see if that discussion will take place or if consensus will call for that option to be presented. Huggums537 (talk) 14:29, 30 January 2022 (UTC)
• My preference would be an icon, as they stand out - lots of the text is just noise. ― Qwerfjkltalk 17:33, 29 January 2022 (UTC)
• Comment - As per a comment above, I will !vote after viewing on another computer and on smartphone. Robert McClenon (talk) 17:48, 29 January 2022 (UTC)
• "No icon with '(PDF)'" is not technically feasible for generic old links to PDF, so it would need to be policy mandated somewhere or another. "No icon and nothing else" of course is quite feasible. :) My preferences are "no icon at all" (and I don't care about whether it becomes policy or not, but good luck getting that into MOS where it would likely live) followed by A or C (slight preference to A). Preferences exclude B totally. --Izno (talk) 17:52, 29 January 2022 (UTC)

  @Izno Can you do me a favor and, whenever asserting that something is not technically feasible, explain why? :-) Thanks, Levivich 18:05, 29 January 2022 (UTC)

  Levivich What makes you think it would be technically feasible, given that some PDFs do not live in a CS1/2 template or any other template, of which someone or another might have been thinking when they made that proposition? :) Consider WP:CONTEXTBOT in context of any response you might have. Izno (talk) 18:26, 29 January 2022 (UTC)

  @Izno: We have a robot helicopter flying on Mars, is one thing that makes me think it is technically feasible to add "(PDF)" after a link to a PDF on a website. Are you using the words not technically feasible to convey the meaning that a bot that changes PDF icons to text would violate WP:CONTEXTBOT? Because that is not what I think of when I think of the words technically feasible in the context of changing how a website works. Levivich 18:31, 29 January 2022 (UTC)

  That is precisely what I mean when I use the word technically feasible, as in technologically feasible, if that makes it easier for you to parse the words. If you think a change to MediaWiki for this would be accepted upstream, I am here to tell you that you are simply wrong, for the same reasons as CONTEXTBOT says. A bot would run into contextbot of course. That leaves a gadget to add it at any given edit time, or editor willpower to do so. Either way, it is not technically feasible to add the words after a link of interest automatically in such a fashion. Izno (talk) 18:41, 29 January 2022 (UTC)

  That is not what I understand "technically feasible" or "technologically feasible" to mean: both those phrases mean there's a technical problem, as in, a software or hardware limitation. A policy prohibition is not a technical problem. I'm glad you've explained it, because heretofore, I understood you to be saying the software can't do it.

  What would we need a bot for? This would be a CSS change, no? Levivich 18:47, 29 January 2022 (UTC)

  No. There is no CSS that will do this for you accessibly, which I presume is the reason you want the parenthetical PDF in the first place. Izno (talk) 18:58, 29 January 2022 (UTC)

  Again, can you explain, rather than assert, why this cannot be done accessibly? What's inaccessible about :after and content: ? Levivich 19:00, 29 January 2022 (UTC)

  It cannot be read by screen readers, which have the same issues as they would with the icon. Izno (talk) 19:29, 29 January 2022 (UTC)

  Ah, thanks for that explanation. Isn't the way it's done currently, with a CSS background image showing a PDF icon, also not web accessible? (It's Failure Technique 3.) So whether we change the icon, or we use text, it makes no difference to accessibility? Levivich 19:56, 29 January 2022 (UTC)

  Correct, no external URL icon is accessible. There is an argument that can be made that this is a case of progressive enhancement of course, since the CSS icon/text can be argued are extraneous to a well-titled URL. Izno (talk) 22:13, 29 January 2022 (UTC)

  I'm no expert, but looking at MediaWiki:Common.css and Help:External link icons, it appears the only options supported by MediaWiki are an icon or nothing. You could make an image of the plain text I suppose, but I can't think of any reason off the top of my head why that would be beneficial. Thryduulf (talk) 18:39, 29 January 2022 (UTC)

  @Thryduulf: I was able to accomplish it (replacing the icon with the text "(PDF)") with this local CSS hack just now. Levivich 18:54, 29 January 2022 (UTC)

• Option A Both B and C look blurry to me. I am opposed to no image, since I am personally quite glad to see the pdf icon at a glance, it is useful information. CaptainEek ^{Edits Ho Cap'n!}⚓ 18:06, 29 January 2022 (UTC)
• Option A or D, with "D" being a text-based equivalent such as the PDF used by Google. --Ahecht (TALK
  PAGE) 19:47, 29 January 2022 (UTC)
• Option A... glad to see change is actually taking place here! Aza24 (talk) 20:04, 29 January 2022 (UTC)
• Option A seems better. _{دَستخَط،} اِفلاق ^{(کَتھ باتھ)} 12:44, 30 January 2022 (UTC)
• Option A. Clearest of the A-B-c choices. The argument for no icon is reasonable, I just think an icon stands out more and works better. Herostratus (talk) 14:05, 30 January 2022 (UTC)
• I prefer SVGs as a concept so option C. The image is not blurred at all, but may have been rendered as such on some browsers. Stifle (talk) 10:59, 31 January 2022 (UTC)

  @Stifle: AIUI, the icon has to be a raster image and so if an SVG is chosen it will be a PNG rendering of the SVG that is displayed. I don't know if that makes a difference to your view. Thryduulf (talk) 12:10, 31 January 2022 (UTC)

  If that's so I would choose A (which appears to be winning a landslide anyway). Stifle (talk) 15:05, 31 January 2022 (UTC)

• Option A or D, as what there have been good arguments for both sides. Low-res text and Plaintext are both good ideas for cross-platform readability, and I am having a hard time choosing between them. ☢️Plutonical☢️ᶜᵒᵐᵐᵘⁿᶦᶜᵃᵗᶦᵒⁿˢ 12:01, 31 January 2022 (UTC)
• Still-unanswered question regarding.svg/.png formats: do we know that both are equally good (although that seems in some conflict with the note in the RfC close above)? I get different results depending on my device. The SVGs are better on my phone; the PNG is better on my desktop. — JohnFromPinckney (talk / edits) 12:13, 31 January 2022 (UTC)

  @JohnFromPinckney: All the SVG images are converted to PNG by mediawiki before being displayed (see meta:Community Wishlist Survey 2022/Multimedia and Commons/Improve SVG rendering). For whatever reason, mediawiki renders the SVG as a 16x18 png on desktop browsers (which looks like crap) and a 32x37 png on mobile browsers (which looks fine). --Ahecht (TALK
  PAGE) 14:56, 9 February 2022 (UTC)

• Option A. These appear slightly differently on different browsers, desktop vs mobile etc. probably due to the SVG scaling. I've tested a few and A looks acceptably clear on all of them. C is maybe slightly better when using Safari on mobile, but looks blurry on Firefox desktop. B has the same problem and the bold text is a bit overwhelming. Option A looks good everywhere I tried. It's also the smallest file size of the three, by an order of magnitude. Modest Genius ^talk 14:06, 31 January 2022 (UTC)
• Option A, with weak support for Option D, looks less blurry than Option C, however I have weak support for D since, if implemented correctly, it just saying (PDF) is fine, however as just plain text it looks weird. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 14:47, 31 January 2022 (UTC)
• Option D per the Ahecht example. A-C are all blurry to me with my normal browser and screen size and I can't really read the letters. I can recognized it means PDF by the red band. I would prefer not to go through that mental conversion and just have something clearer. A icon should be as discernible as the rest of the page. MB 15:42, 31 January 2022 (UTC)
• Option C/A (don't care which) but also I am still bitter that Option 1() didn't pass from the first RFC (so sorta Option D). It's a lost battle though. Whatever gets us done with the dang gif file faster is basically what I support (except Option B which just looks too silly in my opinion). –MJL ‐Talk‐^☖ 00:18, 1 February 2022 (UTC)
• Option A - Definitely looks better on desktop, slightly fuzzier than C for me on mobile but not bad. B doesn't look great on either. Not a fan of "(PDF)" in text but the stylized text suggested by Levivich seems like an ok secondary option. Retswerb (talk) 04:32, 1 February 2022 (UTC)
• Comment: Building on Levivich's text-based proposal and combining the pictures' visual elements into it, I made one that looks like this: PDF The text on it is sharper than it is in pictures, while also retaining the visual elements typically used to denote pdfs. Any suggestion from the community? ---CX Zoom(^he/_him) (^{let's talk}|_contribs) 13:44, 1 February 2022 (UTC)

  My initial reaction on a desktop (not looked on other devices yet) is that it's significantly larger than any of the icons, more dominant of its surrounds (not a good thing in this context) and no clearer than option A. Thryduulf (talk) 15:55, 1 February 2022 (UTC)

  I see the same as Thryduulf. I think this idea could be better than A, B or C and is worth pursuing, but that particular implementation isn't a winner. Certes (talk) 18:05, 1 February 2022 (UTC)

• Option B – Nice bold text, perfectly visible. Especially on higher density screen like mine with scale set to 125% it looks okay and is perfectly readable. — Polda18 (talk) 19:05, 1 February 2022 (UTC)
• Option A best on my device. — Wug·a·po·des​ 19:52, 1 February 2022 (UTC)
• Option D ~no icon + text, per Levivich and others; if we have to have an icon, Option B is the only one readable on my screen. Happy days ~ Lindsay^Hello 09:15, 5 February 2022 (UTC)
• Option A looks best to me; the text in the other options looks blurry at small size. kcowolf (talk) 03:48, 9 February 2022 (UTC)
• Option A, being the most legible on my device (a 27" 1080p desktop monitor), for what it's worth in sample size. Regards, User:TheDragonFire300. (Contact me | Contributions). 04:27, 9 February 2022 (UTC)
• Option A as the one that's sharpest, and thus most visible to me without reading glasses. (Sadly, I have become old!) The softer definition on B makes it liable to bleed. Guettarda (talk) 15:50, 9 February 2022 (UTC)
• Option B; second best Option C (1080p desktop monitor) --Wickey (talk) 13:07, 12 February 2022 (UTC)
• Option A, the clearest for me. Paul August ☎ 01:03, 17 February 2022 (UTC)
• Option A is the best clean visual on my monitor and color settings. Carlosguitar ^{(Yes Executor?)} 01:56, 17 February 2022 (UTC)
• Option A The "PDF" text is fuzzy on Option B and C, at least on my monitor/color settings anyway. Some1 (talk) 19:37, 20 February 2022 (UTC)

RfC: Block reFill tool until fixed[edit]

Block reFill tool until fixed. -- GreenC 21:53, 21 January 2022 (UTC)

WP:REFILL is a popular citation maintenance tool with great power, and likewise power to cause great harm. It has been largely abandoned for years, in terms of fixing bugs. The number of errors it creates is increasing with time. Its usage is increasing with time. The talk page is full of bug requests. The home page is full of warnings. The GitHub page is full of bug reports.

These are countless examples of bugs, here are two:

• edit and fix required.
• edit and fix required (note the user in this case has only ever edited Wikipedia in one article)

Many editors like reFill, when it works. However, many editors are also not fixing the problems it creates. The errors are increasingly complicated and difficult to determine. By letting the tool run rouge we are causing significant damage to the project. Blocking does not need to be permanent, restoration only requires someone to actively maintain and respond to bugs.

Alternatives to blocking are only for approved users, similar to AWB due to it's powerful ability to cause harm, only proven responsible editors should be allowed. How these things might be technically implemented (block, approved users) is unclear but I believe both are technically feasible with some investigation depending what the community wants to do if anything.

• Option A - Do nothing.
• Option B - Approved users only.
• Option C - Block until most known bugs are fixed.
• Option D - Something else.

Poll (block reFill)[edit]

• Option C. Per nom. This is more a vote for more robust software than anything else really. Old enough to remember a time when no software with known bugs would ever be put, or continue to be, in production. It is true, such software policies did use to apply. 50.74.109.2 (talk) 01:27, 22 January 2022 (UTC)
• A or B ReFill or Reflinks are helpful tools in getting at least some of the info filled in and reducing the repetitiveness of manually filling in references. I do go over the results because they often need fixing and none of these errors seem so major to me that we necessarily have to restrict access. If we do choose to, I think those of us who have proven conscientious enough in how we use the tools should still have access. – Muboshgu (talk) 17:18, 22 January 2022 (UTC)
• Option C first or B second as nom. -- GreenC 20:33, 22 January 2022 (UTC)
• Option C to start, but Option B is the better alternative once a process for approval is in place. Headbomb {t · c · p · b} 18:41, 25 January 2022 (UTC)
• A or D. ReFill is not perfect, and never will be. It has always come with a health warning. Its value outweighs its problems. To withdraw it, in any shape or form, will damage the project more than continuing to use it as-is. The 'D' would be to advertise for experienced developers, with the right technical knowledge and spare time to onwardly develop the tool. While there might be some quick fixes, the learning curve given little-to-no documentation and zero handover from the tool's author mean that making even the slightest change comes with too much responsibility for someone not already used to toolforge, and the whole developer stack. Curb Safe Charmer (talk) 23:13, 25 January 2022 (UTC)
• Option A or D -- it's hard to get behind blocking the use of ReFill, since I often use it to write articles. While I've written software to generate full-featured proper citations from Newspapers.com, for everything else I use ReFill. It's an unimaginable pain in the ass to fill out citations manually, and I check all of my ReFill cites by hand -- I'd estimate about one out of every ten will have a couple fields that are erroneously filled in, but even then it saves me several minutes. For example, oftentimes the article's title, publisher and author are fine, but the date is messed up -- this only takes a couple seconds to fix, versus typing in all of this information or copying it from the webpage by hand, which takes forever. At the same time, I understand the importance of fixing the tool, and the possibility that doing something drastic could force some action to be taken; I certainly haven't been devoting any effort to it, despite the fact that I could probably make a couple fixes, because it works well enough for my purposes. Perhaps it would be a useful compromise to block ReFill from being used in articlespace, which wouldn't affect drafts or userspace pages (and if you really wanted to use it in a mainspace page you could copy the source into a userspace sandbox to use it there). jp×g 07:33, 1 February 2022 (UTC)
• Options B and D. I use ReFill almost daily. Being aware of the bugs, I adjust results accordingly. I think this is rather like a chainsaw—very effective for the job it does, but dangerous for the person using it without knowing how. Those who know how should not be restricted while work is undertaken to remove the bugs. BD2412 T 17:54, 6 February 2022 (UTC)
• A or B. I use ReFill enough that I would miss it. Checking for errors is not a burden, although it would be nice if the bugs are fixed. - Donald Albury 21:06, 6 February 2022 (UTC)
• A or B/D, it's a tool for humans, not magic. Yes, it would be good if someone tried to fix it. Nonetheless, its results generally range from marginally improved, to improved, imo, and with care, better than that. As for process, it should not be removed from anyone, unless there is a showing of continued problems after discussion with the person. I suppose any "new" access could be restricted like a perm, were B adopted. -- Alanscottwalker (talk) 21:27, 6 February 2022 (UTC)

Discussion (block reFill)[edit]

• Administrator note we could use the abusefilter to block or warn on these edits as they seem to have a consistent edit summary we could latch on to; we could also exempt certain usergroups (e.g. extendedconfirmed) or users with an editcount above something from such a filter. While possible, I expect there will be significant pushback about making a new local mediawiki usergroup just for this. If set to "warn" every use would require a reconfirmation after getting the "warning" which can say whatever we want. (Please note one of the sample "bad" edits is by a user with 3000000+ edits that is also a member of restricted groups including autopatrolled). We can not easily make an on-wiki discretionary access control list, as we do not control this software - it is hosted off-site. Traditional administrative options are also available - such as placing editing blocks on users that are making disruptive edits. — xaosflux ^Talk 22:55, 21 January 2022 (UTC)

The examples seem to disrespect {{cbignore}}, though one of them has the |bot=medic parameter, which presumably limits cbignore's scope to a different bot. Should a filter warn (or prevent) edits with reFill in the edit summary which remove cbignore (or cbignore without parameters)? Or is the problem more widespread, involving errors other than a failure to respect cbignore? Certes (talk) 23:49, 21 January 2022 (UTC)

@Certes: that template says it applies to "participating bots". This edit was not made by a bot it was made by a human editor. Is there a reason you think that this utility is otherwise a "participating bot"? It may be possible to code an abuse filter for that though. — xaosflux ^Talk 00:09, 22 January 2022 (UTC)

No, my mistake, though authors of tools which suggest edits might want to consider complying as if they were bots. Certes (talk) 00:56, 22 January 2022 (UTC)

On reflection, I may have expressed a good idea badly. Observations: Certain citations confuse bots. Editors kindly mark these with cbignore. The two examples above are also marked with cbignore. Hypothesis: the sorts of citation that get marked with cbignore also confuse ReFill (though as a non-bot it has no duty to observe cbignore). Suggestion: detect edits where ReFill amends lines containing cbignore, and tag/warn/prevent as appropriate. Certes (talk) 14:26, 22 January 2022 (UTC)

• Is it possible to restrict usage of the tool by protection?--John Cline (talk) 00:43, 22 January 2022 (UTC)

  @John Cline: no, the protection tool can not distinguish the content or metadata of an edit. — xaosflux ^Talk 01:03, 22 January 2022 (UTC)

• Comment I would love for some new developers to take over this tool (and Reflinks too), to fix the numerous issues it creates for author/first/last parameters and other parameters. Thanks! GoingBatty (talk) 01:28, 22 January 2022 (UTC)

  +1 – Muboshgu (talk) 17:18, 22 January 2022 (UTC)

  The problem is getting a modified version live, I submitted a change to fix one of the errors caused by the tool a couple of years ago. If someone could solve this problem, then pogress could be made. Keith D (talk) 19:45, 22 January 2022 (UTC)

• See meta:Community Wishlist Survey 2022/Citations/New reference-filling tool. DMacks (talk) 19:09, 22 January 2022 (UTC)

  And Wikipedia:Village pump (technical)/Archive 194#Proposed Google Summer of Code project: expanding citations. Enterprisey (talk!) 06:05, 23 January 2022 (UTC)

• Also see Wikipedia:Bots/Requests_for_approval/BareRefBot. On hold due to ANI thread. It just fills in the bare refs for now, but the script can be upgraded to match the capabiltities of reFill or refLinks. I think a new tool rewritten from scratch is the future (I've looked at the source code of both tools, I didn't like working with it, but that just is me) Rlink2 (talk) 19:16, 22 January 2022 (UTC)

  Yes agree, best redone from scratch. Hope your bot works out and can convert all those refs before editors feel the need to run reFill. A number of people have tried to adopt reFill with little success fixing the dozens of bugs; it was written by a college student and abandoned. -- GreenC 20:07, 22 January 2022 (UTC)

  To anyone writing a new tool: please plan ahead and get a few more people involved in its development and maintenance. It would be greatly appreciated! isaacl (talk) 20:55, 22 January 2022 (UTC)

• Here is another bug (i think?) on the Chris Lattner article. The first and last names are obviously not "Apple" and "Inc.", doesn't make sense. But could be wrong Rlink2 (talk) 19:39, 22 January 2022 (UTC)
  • This is not ideal but is it really worth blocking the tool over something so innocuous as this? – Muboshgu (talk) 19:50, 25 January 2022 (UTC)

It is only one of perhaps 100s of reported bugs ignored for years. Is this bug even reported, and if it was, would it matter? -- GreenC 20:27, 25 January 2022 (UTC)

@Rlink2 and GreenC: looking at the markup of https://www.swift.org/ the head element contains the following:

<meta name="author" content="Apple Inc." />

Practically, how would you envisage that reFill, or any tool, should automatically determine that this is not the actual name of the author? Curb Safe Charmer (talk) 10:09, 26 January 2022 (UTC)

Monitor for unusual strings by sorting by count and seeing which have high counts and manually skim off into a file the bot can reference. -- GreenC 17:02, 26 January 2022 (UTC)

• Note that CurbSafeCharmer is the maintainer of reFill2 on GitHub [5] . I see very little change in the code for 3 years. In the past 24hrs a few issues were closed as invalid, not due to code fixes.[6] It still leaves many open issues.[7] Plus the many talk page reports (including archived pages). There isn't much happening in the code itself. This is not blaming CSC, as they say, it is a steep learning curve and a difficult project which explains why even the "slightest change" is so difficult and never gets done. -- GreenC 17:16, 26 January 2022 (UTC)

  @GreenC: There were eight issues in the GitHub repo, most dating back to 2015-2017 that the author and previous maintainer of reFill should have closed - I have done so today as it makes it easier to 'see the wood for the trees'. Of the 27 open issues, almost all are enhancements requests, rather than bugs. It is a small but significant distinction. I do not see the issue raised by Rlink2 above as a bug, for instance, as it is a request for reFill to do something new that it was not designed to do - there's no existing code for that which needs fixing. Curb Safe Charmer (talk) 17:50, 26 January 2022 (UTC)

Thank you for taking a few minutes to close some years old open tickets that are no longer valid. See the talk page and example diffs for lots more (and Phab). The main thing is no one is actively coding, for years, and so this garbage data continues to get added into Wikipedia at scale. Trouble reports for tools like this should be constant, see Citation bot talk page, it's a process of continually fixing issues. The tool has been effectively abandoned by developers. -- GreenC 18:22, 26 January 2022 (UTC)

• I would be willing to try to work on some fixes for the most egregious misbehavior of the tool and submit pull requests -- is there a list of the biggest issues? The GitHub issues don't seem to be prioritized very well. I would also need some instructions for setting up and testing on a local instance. If I had these things, though, I could commit to at least taking a look (although a few have said the codebase is daunting, so it may not result in any progress, but it's at least worth a try). jp×g 07:40, 1 February 2022 (UTC)

  @JPxG: Great, thanks for your offer of help. I will contact you on your talk page. Curb Safe Charmer (talk) 09:51, 1 February 2022 (UTC)

  @JPxG: Thanks for the offer to move this forward. Keith D (talk) 22:15, 6 February 2022 (UTC)

  Yeah we've heard this in the past, people say they will adopt it then nothing much happens. Similar to Citation bot, tools like this require constant attention to adapt to changing conditions with CS1|2, MOS, best practices, etc... it's a lifestyle not a 1-time fix. The original programmer was a college student, whose code is apparently not easy to work with, who quit and moved on in life. New programmers frequently paint themselves into corners and realize they need to rewrite and find it easier to quit. Others have looked it said it would be best to start over. -- GreenC 02:45, 7 February 2022 (UTC)

  Well, I think JPxG is a skilled coder and programmer, and is also a very nice Wikipedia editor who is trusted and easy to get along with. I trust he is more than capable to handle whatever might come in his way. And besides, he never said he would take over maintence of the tool (at least that's not the message I got - I could be wrong though). He said he would fix the most pressing issues as of right now,which is important and could be helpful. Rlink2 (talk) 04:12, 7 February 2022 (UTC)

  Oh sure JPxG is great agree. It's been frustrating to see one person after the next promise to help out keeping the tool alive in the process but no real progress is made. It has nothing to do with good intentions. Sometimes it's a lack of skill, sometimes it's a lack of time, or lack of interest. Going on for years. If it was harmless who cares but not harmless. If we do keep the tool alive, there needs to be a stop button of sorts so users can at least shut it down until certain bugs are fixed. Currently there isn't even that basic functionality which every bot or tool should have. -- GreenC 05:58, 7 February 2022 (UTC)

A more tenable solution[edit]

Over the last few days, I've had the opportunity to download the repository for ReFill and take a look at it. It doesn't seem to be badly written by any definition (in fact it seems quite well-written), although it does seem like it'll be very hard to work with. However, the point made above by GreenC is good -- I foresee a particular problem occurring here, and I think we should come up with some way to preempt it.

So, okay, let's say me and CSC sit down and hash it out and... learn how Vue works, I guess -- we figure out how to implement a couple of the most urgent bugfixes, maybe even modify or extend a feature (like, something that fixes cites for some the websites on BHG's lists). This is great, right? Except now I know how Vue works, which means I get a job where they pay me $99999999999, and stop having time to fix bugs in ReFill. This is presumably what happened to Zhaofeng, the original writer -- you can see on his GitHub that he is still making commits on a daily basis, and presumably his life rules because some of this stuff is really cool. But he is not fixing stuff in ReFill. Now, if I spend a million years learning how the hell ReFill works, presumably some day I will go to NASA to be a front-end rocket scientist, or I will get hit in the head with a meteorite, or whatever, and then this knowledge will be of little benefit to anyone (except possibly my web developer colleagues at NASA).

Anyway, the idea I had is that we could build up a decently useful page somewhere - like Wikipedia:Refill/technical and Wikipedia talk:Refill/technical, and everyone who wants to try and dick around with the code can convene there, to a) figure out what the heck is going on and b) share notes on what the heck they think is going on. We manage to do this perfectly well for everything else -- people get into an argument about politics and we end up with an ArbCom casepage filled with thousands of diffs and tens of thousands of words. I think that if we set this up, and still ended up with no progress being made, I'd support blocking ReFill until it was resolved (if only to get people motivated to help out). Alternately, we could leave it unblocked and make it fill in publication titles with auto-generated controversial statements about American politics ("Apollo 11 was an inside job", "the 9/11 landings were fake", "Donald Trump was actually born in Svalbard", etc) because that seems to effectively get people's attention. But I think if some people can be gotten to that page, if they later become busy, or get hit in the head by a meteorite, at least there will be something useful there for others to go off. jp×g 21:19, 7 February 2022 (UTC)

(in fact it seems quite well-written) Good to hear.

FWIW I do have a fix for the broken sites for ReFill specifically. I used it at the very very beginning of my journey of fixing bare refs until I decided to move on to my own stuff. But it might be helpful to you. Let me know if you want it.

Yes, a page like that would be great. Keep everything documented for future maintainers. But, I think the biggest issue is finding someone to work on it. You could have all the documentation in the world, but someone still needs to fix the bugs at the end of the day.

Thanks for taking this up JPxG. You're one of the most qualified people to take this on. Rlink2 (talk) 22:28, 7 February 2022 (UTC)

@Rlink2: I'm intrigued by your fixes - what do you have? It would be great if you could start a thread at the newly created Wikipedia talk:Refill/technical. Curb Safe Charmer (talk) 22:52, 7 February 2022 (UTC)

Thanks, JPxG. It is good to hear someone confirm that there's nothing inherently wrong with the reFill code. I would say there's nothing inherently wrong with the software architecture either. And I will stick my neck out and say that GreenC should evidence their claims that it is 'full' of bugs and warnings, or that 'one person after the next promise[s] to help out keeping the tool alive in the process' - who were they? "Others have looked [at] it said it would be best to start over" - who? Curb Safe Charmer (talk) 22:52, 7 February 2022 (UTC)

User:JPxG: I think that if we set this up, and still ended up with no progress being made, I'd support blocking ReFill until it was resolved . Good, agreed, let's do that. I won't be involved as I don't have the time. However, seeing as how hostile this tool has been to my own bot, literally undoing its edits for no reason, I have no choice but to continue monitoring the situation. I don't like being a squeaky wheel, but it's less work than monitoring reFill via Stream and having bot wars, or writing code to fix certain reFill errors which I already do (though not at scale). -- GreenC 04:00, 9 February 2022 (UTC)

Restricting user page creation of new users[edit]

Decrease edit requirement for being extended confirmed[edit]

Offering the Reply Tool as an opt-out feature[edit]

Note: This might not technically be a proposal, but I hope you'll excuse me posting here; I'm doing so in an attempt to make sure lots of people are aware of this upcoming change.

---

Hi y'all – the Editing Team is planning to offer the Reply Tool as an opt out feature to all people – logged in and out – at en.wiki this upcoming *Monday, 7 February 2022*.

The "Deployment Rationale" below is what's leading us to think now is a good time to move forward with this deployment. If this idea brings any concerns/questions to mind, we would value you sharing those thoughts so we can talk about them.

And for people curious about the work the Editing Team will continue doing to improve the Reply Tool, please see this update.

Note the 7 February deployment only pertains to the Reply Tool, NOT the New Discussion Tool (setting name: enable quick topic adding) or Topic Subscriptions (setting name: Enable topic subscription).

PPelberg (WMF) (talk) 22:12, 1 February 2022 (UTC)

EDIT: to clarify, this deployment only impacts people (logged in and out) using talk pages on the desktop site. Said another way: this deployment would have NO IMPACT on people (logged in and out) using talk pages on the mobile site. PPelberg (WMF) (talk) 04:30, 3 February 2022 (UTC)

Deployment Rationale[edit]

The Editing Team has the impression that now is a good time to offer the Reply Tool as a default at en.wiki based on the following:

• People do not seem to have any significant concerns about the Reply Tool being offered more broadly.^[1]
• The Reply Tool is reliable. Over the past 30 days, 99.9% of the 14,000+ comments 800+ people posted with the tool at en.wiki did not impact any other parts of the talk pages it was used on.^[2]
• Many people have confidence in the Reply Tool. At en.wiki, 2,800+ people have used the Reply Tool to post at least one comment since the tool was offered as a beta feature on 16 March 2021.^[3] And of these 2,800+ people, 25% have used the Reply Tool to post 10 or more comments.
• While there is additional functionality that could A) increase the range of comments people can use the Reply Tool to publish (e.g. votes^[4] and unindented comments within existing discussions^[5]) and B) expand how expressive the tool enables people to be (e.g. stronger template support^[6] and signature customization^[7]), we do not currently understand the implementation of these additional capabilities as needing to prevent people who are new from benefiting from being able to post comments more intuitively and for the comments they post being signed and indented in ways experienced volunteers expect and value.

PPelberg (WMF) (talk) 22:13, 1 February 2022 (UTC)

• @PPelberg (WMF): just to be clear, this going to be only the "Reply tool", not the entire suite of "Discussion tools" from beta preferences? — xaosflux ^Talk 02:07, 2 February 2022 (UTC)

  I'm glad you asked to clarify, @Xaosflux.

  Yes, the deployment planned for Monday, 7 February 2022 only pertains to the Reply Tool, NOT the New Discussion Tool (setting name: enable quick topic adding) or Topic Subscriptions (setting name: Enable topic subscription).

  I've updated the original post to make the above explicit. Please let me know if you notice any other ambiguities. PPelberg (WMF) (talk) 02:33, 2 February 2022 (UTC)

  I'm not seeing the discussion from the first citation; could you link to a specific section there?

  Overall, deployment sounds good to me. This will help make a lot of editors' lives easier! {{u|Sdkb}} ^talk 08:27, 2 February 2022 (UTC)

  Oops. Good spot, @Sdkb. Here is a link to the discussion I meant to reference in the "Deployment Rationale": Wikipedia:Village pump (miscellaneous)/Archive 68#Radical changes. PPelberg (WMF) (talk) 19:43, 2 February 2022 (UTC)

• Generally, I think this is the right direction to head—ever since Enterprisey developed his version of a "reply link" tool way back when, I have long been excited at the prospect of deploying this in a widespread format to help new editor engagement. With that being said, I would be mindful that this would be a relatively significant new feature in the editing interface, and some past rollouts of similarly significant new features have led to tension between the WMF and the English Wikipedia community (see e.g. Wikipedia:VisualEditor/RFC and Wikipedia:Arbitration/Requests/Case/Media Viewer RfC). I don't think the Reply tool is quite as invasive as VisualEditor and Media Viewer were, but because of those dark memories, I would be inclined to more broadly advertise to experienced editors that this change is going to occur—specifically, I'm thinking in MediaWiki:Watchlist-messages. Maybe this is overkill, but the English Wikipedia community can sometimes be really passionate against these software changes, particularly when they have the appearance of being performed without their consultation or consent. I've been using the Reply tool for a while now, and it is quite good—I just hope others see it the same way. Mz7 (talk) 09:43, 2 February 2022 (UTC)

  Thanks for the shoutout! I agree with everything you said. I guess it may seem like a silly step (and I think it sort of is). But we should definitely hold an RfC of some sort if we've learned from the history of this sort of thing. It doesn't even have to be that long (a week?) or laborious.

  PPelberg (WMF) and the team, thank you so much for all your hard work on this! I've been waiting for this day for a long, long time. Would it be possible to get links to some of those "suspicious" edits (I'm assuming that's what "sus" means in that table)? I really appreciate the inclusion of the table in the first place. Enterprisey (talk!) 10:34, 2 February 2022 (UTC)

  @Enterprisey, click the date for the column you want. Every suspicious edit is on the day's page. The most recent was this removal of a stray HTML tag, two days ago. Whatamidoing (WMF) (talk) 17:27, 2 February 2022 (UTC)

  Thanks @Enterprisey, it was helpful to pick your brain in the early stages of the project! ESanders (WMF) (talk) 17:39, 2 February 2022 (UTC)

  +1 to what @ESanders (WMF) shared above: thank you @Enterprisey for inspiring the Editing Team and passing on knowledge that's helped make the Reply Tool something many people use and value. PPelberg (WMF) (talk) 00:41, 3 February 2022 (UTC)

• @PPelberg (WMF): we may at least post a note somewhere like our watchlist header when it goes live to help head off any "what's this" confusion posts. That being said, probably should have 2 targets ready: (a) the location any issues should be reported; (b) a description/help page of the new feature (which should include the opt-out directions). mw:Talk pages project/Replying isn't really a good landing page for either of those - it is more of a project tracking page. Are there better targets ready somewhere? — xaosflux ^Talk 11:14, 2 February 2022 (UTC)

  @Xaosflux, there's mw:Help:DiscussionTools, which could be copied here. (Everything in Help: namespace at mw.org is public domain/CC-0, so you don't even have to worry about licensing attribution.) It might make more sense to put the section about the Reply tool in Help:Talk pages than to create another extension-specific page.

  The exact link for opting out is Special:Preferences#mw-prefsection-editing-discussion, and you could run that in the watchlist notice itself. In practice, I expect editors here to report problems to Wikipedia:Village pump (technical) no matter what we tell them, but mw:Talk:Talk pages project/Replying (i.e., its talk page) is a good "official" option.

  That said... it's already default-on for about half the editors in the movement. Across hundreds of wikis, I've seen about five requests for information on how to disable it and almost no bug reports. There have been some feature requests (e.g., support for voting-style discussions) and questions (e.g., why doesn't it recognize this editor's non-standard signature, or work on this page with a colored background?). Someone even wrote a quick user script (check the VPM archives; I copied it here) to change "[reply]" into the emoji or word of your choice. This experience suggests that we probably won't get that many questions, especially after the first day or two. Whatamidoing (WMF) (talk) 17:22, 2 February 2022 (UTC)

  @Whatamidoing (WMF): thanks for the note, I don't think we need to advertise the opt-out controls in any banners, just wanted to have somewhere to point editors, and have that page include the opt-out directions (not to the page mw:Talk pages project/Replying itself). — xaosflux ^Talk 18:12, 2 February 2022 (UTC)

  You could put it in the local Wikipedia:Talk pages project. Whatamidoing (WMF) (talk) 22:54, 2 February 2022 (UTC)

@Whatamidoing (WMF): -- just so I know (because I hate change) how do I opt out? -- Rockstone^{Send me a message!} 08:10, 3 February 2022 (UTC)

@Rockstone35, you'll just go to Special:Preferences#mw-prefsection-editing-discussion and turn it off. Whatamidoing (WMF) (talk) 21:56, 3 February 2022 (UTC)

• I'm thinking a watchlist notice would be good on launch day, something like:

{{Display/watchlist
 |until= 10 DaysFromNowMonth 2022
 |cookie=n
 |text=The [[Wikipedia:Talk_pages_project#Reply_tool|'''Reply tool''']] from the talk pages project has been enabled for all editors.  Should you have any issues or feedback, please [[Wikipedia talk:Talk pages project|let us know]].
}}

• Any feedback on this wording is welcome! — xaosflux ^Talk 01:12, 3 February 2022 (UTC)

  Making the reply tool opt-out is a big step for beginner friendliness. Wording should be this imo (with relevant links):
  "The talk page reply tool has been enabled for all editors. If you spot any issues or have any feedback for the Talk Pages project team, let us know at our talk page" ✨ Ed talk! ✨ 03:43, 3 February 2022 (UTC)

• @PPelberg (WMF): Does "all people" include mobile editors (logged-in and logged out)? Suffusion of Yellow (talk) 04:08, 3 February 2022 (UTC)

  @Suffusion of Yellow good question. The deployment currently planned for this upcoming Monday will only impact people – logged in and out – who are accessing the desktop site.

  I'm going to update the original post I made to clarify this. PPelberg (WMF) (talk) 04:26, 3 February 2022 (UTC)

  Out of interest — why not mobile? — GhostInTheMachine ^{talk to me} 20:49, 3 February 2022 (UTC)

  @PPelberg (WMF): Any idea how long it will take to bring this to mobile? The current mobile talk interface is fundamentally broken and no one seems interested in fixing it. Suffusion of Yellow (talk) 23:31, 3 February 2022 (UTC)

  hi @Suffusion of Yellow – the mw:Editing Team is planning to offer both the Reply and New Discussion Tools on mobile at an initial set of wikis within the next month or so (you can track progress on this work by following along with phab:T282638).

  I appreciate the level of expertise you've developed around mobile talk pages. If at any point you become motivated, I'd value hearing what – if any – questions/ideas you have about the broader set of mobile talk page challenges we are planning to address. PPelberg (WMF) (talk) 02:35, 4 February 2022 (UTC)

  @GhostInTheMachine good question. This deployment does not include the Reply Tool being made available on mobile because we are still refining the user experience for it. We will have a prototype ready to share soon, would you be interested in trying it out and sharing what you think about it?

  Also, in case you're interested in the broader set of changes we have planned to improve mobile talk pages, I recommend reading mw:Talk pages project/Mobile. If/when any other questions emerge about mobile, please do ping me! PPelberg (WMF) (talk) 02:22, 4 February 2022 (UTC)

• A tad short-notice for general awareness of rollout, but I've been using it on meta to get used to it, and it's significantly improved from even 3 months ago - especially in its tolerance to the most common thing I did to break it, which was adding ping templates as the first thing in the message. I think the first week will be a bit of a mess, but the general gain will be significant. Nosebagbear (talk) 09:50, 3 February 2022 (UTC)

  @Nosebagbear, I believe this is at least the fourth announcement so far; see Wikipedia:Village pump (miscellaneous)/Archive 68#Radical changes andWikipedia:Village pump (technical)/Archive 192#Tech News: 2021-38. I think the first conversation was last February (before Ops said no, which forced a multi-month delay), and there have been minor mentions off and on, such as at the end of this massive thread about topic subscriptions. As you can tell, though, even multiple discussions don't reach everyone. Whatamidoing (WMF) (talk) 22:17, 3 February 2022 (UTC)

• As someone who is not at all tech savvy… please explain what this is and what it is attempting to accomplish - using non-tech language. Don’t assume people know what you are talking about. Blueboar (talk) 00:24, 4 February 2022 (UTC)

  It adds a little reply link after talk page talk page posts that you can click on to reply to that particular message. It opens a small editing window below the message you're replying to, so you can reply without loading a new page. ScottishFinnishRadish (talk) 00:34, 4 February 2022 (UTC)

  @Blueboar below is a screenshot of the Reply Tool in case a visual is helpful

  

  Screenshot of the Reply Tool

  . You can also find more details about the tool by visiting this help page. PPelberg (WMF) (talk) 02:18, 4 February 2022 (UTC)

Alright y'all: it's been a couple of days since this discussion started and we thought it would be helpful to articulate the information that has surfaced in the discussion thus far. This way, we can collectively decide what happens next with this deployment with a shared set of ideas in our minds.

New Information

1. People are supportive: Everyone who has commented in the discussion thus far is supportive of the Reply Tool being offered as an opt-out feature, for all users (logged in + out), on desktop
2. Awareness is important: A significant number of volunteers who have commented in the discussion agree (and so do we!) that it would be wise to make as many people aware of this change as possible, ideally ahead of time. ^{[1] [2] [3] [4] [5]}
3. Announcement needs some more thought: There does not yet seem to be an agreement about what the most effective way(s) are of making people aware about the Reply Tool being made available as an opt-out feature on desktop.

*Please comment if you do NOT think aspects of the above are accurate. It's very possible I missed and/or misunderstood something someone said!

Next steps

With the "New Information" above in mind, I'm going to ping a few other folks who have been involved in testing and providing feedback about the Reply Tool^[6][7] to hear what they have to say...

@DannyS712, @Doug Weller, @JohnFromPinckney, @Klein Muçi, @Levivich, @Nick Moyes, @Pelagic, @ProcrastinatingReader, @Thryduulf, @Qwerfjkl: in this discussion we are talking about making the Reply Tool available as an opt-out feature for logged in and logged out users on desktop next week.

As people who are experienced using the Reply Tool at en.wiki^[7], we wonder: what do you think might be effective ways for making the wider en.wiki community aware of this Reply Tool deployment? PPelberg (WMF) (talk) 03:06, 4 February 2022 (UTC)

A question and a couple of comments before as head into the weekend...

Question

@Ed6767, @Enterprisey, @GhostInTheMachine, @Mz7, @Xaosflux: as people who have said this deployment would benefit from many people being made aware of it ahead of time, how do you think this announcement or announcements ought to be made? Would an RfC be valuable? Would a MediaWiki:Watchlist message be effective? Might making more posts on pages experienced volunteers are likely to visit (e.g. a couple relevant noticeboards, Village pump (technical) as @Whatamidoing (WMF) has done) be the best approach? Some combination of these options?

Comments

A couple of thoughts about what the mw:Editing Team is thinking...

• We agree with you in thinking that it's worthwhile to make as many people aware of the change before it happens as possible.
• We think the deployment date ought to depend on people having enough awareness that it's happening. Said another way: we are committed to revising the deployment date to leave more time for making people aware, if that ends up being necessary.

Next step

At around 16:00 UTC this Monday, 7 February, I'll check back in with you all so we can decide whether we move forward with the deployment on Monday or push it back a few days to execute the plan y'all might've come up with over the weekend.

Please ping me if anything urgent comes up; I plan to check back in on this discussion at least once over the weekend. PPelberg (WMF) (talk) 01:44, 5 February 2022 (UTC)

My only advice is “think in terms of next month rather than next week”. We here at enWP do not like surprises, and we tend to knee jerk reject things when surprised. So go very slowly with the role out. Announce the crap out of it - in as many different forums and formats as you can think of. Give people time to get used to the idea before you go live with it. Blueboar (talk) 02:53, 5 February 2022 (UTC)

It has been published in the administrator newsletter which means that a large proportion of active admins, and a number of non-admin editors have seen the announcement through that newsletter. Dreamy Jazz ^{talk to me | my contributions} 23:56, 5 February 2022 (UTC)

@Blueboar, @Dreamy Jazz, and @Pelagic: we appreciate you thinking through the question I posed about how best to make people aware of the planned deployment of the Reply Tool.

Considering it is still not clear to me, and other members of the Editing Team, whether y'all (all of the volunteers who have participated in this discussion to date) think an RfC for this kind of change is necessary, in the immediate-term, we are delaying today's (7 February) planned deployment of the Reply Tool.

Next step(s)

You can expect to see another comment from me before 5:00 AM UTC (8 Feb) with a proposed next step or steps.

Of course, if any new thoughts/questions emerge between now and then, we would value you sharing them.

cc @Ed6767, @Enterprisey, @GhostInTheMachine, @Johnuniq, @Dreamy Jazz, @Blaze Wolf. PPelberg (WMF) (talk) 20:46, 7 February 2022 (UTC)

Alright y'all, people in this discussion seem to agree:

1) Some volunteers are bound to be surprised by this change, no matter how many announcements are made

2) "1)" notwithstanding, it's preferable the Reply Tool deployment be delayed until more announcements are posted

Next steps

With the above in mind, what do you think of doing the following?

• @Enterprisey: are you able to take the lead on making sure this discussion is added to CENT?
• @Xaosflux: are you able to finish the work required to ensure the Reply Tool opt-out deployment is included in the watchlist banner?

And then we can all come back together to talk about the deployment timing once we see what people say in response to the announcements Enterprisey and Xaosflux will have posted. PPelberg (WMF) (talk) 01:37, 8 February 2022 (UTC)

@PPelberg (WMF): the WL notice is ready to go whenever this is ready to launch, just change the answered=yes to "no" at MediaWiki_talk:Watchlist-messages#Reply_tool_coming to enqueue it for processing. — xaosflux ^Talk 02:00, 8 February 2022 (UTC)

@Xaosflux ah, I see – thank you for sharing the link to the draft message. Although, what do you think about running the Watchlist message before the actual deployment?

...I ask the above thinking that people in this thread seemed to have agreed that making people aware of the deployment ahead of time is likely to be more impactful than waiting until after it's already happened. This way, people have an opportunity to raise any concerns. PPelberg (WMF) (talk) 20:22, 8 February 2022 (UTC)

@PPelberg (WMF): we certainly could do either or both, we generally only put something with a ready to go "call to action" in the watchlist, in that example it would be a "here is what this new thing is, tell us here of any issues". As far as a "before" goes, what is the call to action - if this is going to be a "proposal" that requires community consensus - then it seems big enough to advertise on WLN, a RFC section should be opened below that people can go to to participate in such a discussion. Has this evolved from a "the server owners are doing this thing" to a "should we do this thing" discussion? — xaosflux ^Talk 22:17, 8 February 2022 (UTC)

...we certainly could do either or both...

@Xaosflux: making announcements before and after the deployment sounds like a great idea to me.

Has this evolved from a "the server owners are doing this thing" to a "should we do this thing" discussion?

This discussion has made three points clear to me [i]:

• All of the volunteers who have commented in this discussion thus far agree deploying the Reply Tool as an opt-out feature is a good idea
• Many of the volunteers who have commented in this discussion agree there is value in announcing this deployment widely ahead of time
• There does not seem to be a clear consensus among the volunteers who have commented in this discussion whether a formal RFC is necessary

Combining the three points above with the fact that we are not yet aware of any objections to the Reply Tool deployment plan, I see the objectives of the "pre-deployment" Watchlist announcement as being to ensure experienced volunteers are aware of: A) An upcoming change to the experience they have using talk pages on desktop and B) Where they can go to voice any question/concerns about said planned change.

So maybe the messages end up looking like this...

Before: "The talk page reply tool will soon be enabled for all desktop editors. Should you have any questions or concerns about this deployment, please join the discussion at Village pump (proposals)."

After: "The talk page reply tool has been enabled for all desktop editors. Should you have any issues or feedback for the Talk Pages project team, please join the discussion at the project talk page." [ii]

...what do you think?

---

i. Please comment if you see anything missing from, and/or inaccurate within, the three points I articulated above!

ii. This is the same message you've already written. PPelberg (WMF) (talk) 02:49, 9 February 2022 (UTC)

This is a good message, and I would be happy to have this added to the watchlist. Dreamy Jazz ^{talk to me | my contributions} 20:47, 10 February 2022 (UTC)

@PPelberg (WMF): seems fine, once a launch date is determined maybe we activate the WLNotice a week ahead of time, let it run for a week after - and include the launch date in the message. Is there a new target launch date? Banner blindness is a thing, so don't want to summon editors to a discussion where no decisions are going to be made. If this is going to be a traditional process, then sure we do one early. Traditionally we'd open a RFC, for about a month, get comments, determine the results, then proceed if there is established support; in general the "default" for changes is status-quo. — xaosflux ^Talk 10:28, 9 February 2022 (UTC)

I am going to say that I've only noticed one issue with the reply tool and i Have no clue what causes it or if it can still happen. For whatever reason, in the past some sections people created couldn't be found by the reply tool with no real reason as to why. I don't remember where this was happening or who the users were that were causing this to happen, however it appears to be very rare. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 03:10, 4 February 2022 (UTC)

Hmm, the issue you are describing @Blaze Wolf sounds curious and elusive. I wonder if any of the cases described on this page could help explain what you experienced... PPelberg (WMF) (talk) 03:19, 4 February 2022 (UTC)

Could you explain what "a bug in Parsoid causing it to render the page differently from the PHP parser" means in layman's terms? ― Blaze Wolf^Talk_{Blaze Wolf#6545} 03:30, 4 February 2022 (UTC)

That's not relevant and is a distraction. You are being asked whether the explanation given at that link might match your experience. The explanation is saying that certain listed factors might cause "Could not find the comment..." and if those do not apply, the software might have a bug. If the latter, they would like a report including a permanent link to the page involved along with a description of exactly what you did and what you saw. The "file a task" is an overly optimistic request that you can ignore. Instead, post your findings here or at any noticeboard such as WP:VPT and someone will notify the appropriate people. Johnuniq (talk) 04:32, 4 February 2022 (UTC)

Geez dude. I was merely asking so I could try and understand what it means. If I can't ask questions here then I can go. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:51, 4 February 2022 (UTC)

@Blaze Wolf, would you please post that question either at Wikipedia:Village pump (technical) or at Wikipedia talk:Talk pages project? The next question will be whether you get this error message when you click the [reply] button, or when you've typed your comment and are ready to post it. Whatamidoing (WMF) (talk) 20:12, 4 February 2022 (UTC)

Blaze, the core MediaWiki software that renders wikitext to HTML is written in the PHP programming language, but it's a one-way conversion. There is another component called Parsoid that can do two-way, and Reply Tool uses it because ... reasons. Visual Editor also uses the Parsoid service. (Apologies to all the technical peeps reading my mangled explanation.) ⁓ Pelagic ( messages ) 12:21, 6 February 2022 (UTC)

This is a visible change. The reply links positioned after every post aren't exactly an obscure UI element tucked away in a toolbar. Will this flip the setting for everyone who hasn't already turned it on then off again? People will notice and say "why weren't we asked?"

Any RFC or banner should run before changeover, not after. Even if it means we have to wait another fortnight or month. Putting it up after the fact would be a very bad look.

On the plus side, a lot of people are already familiar with Discussion Tools thanks to years of fantastic consultation and outreach from Peter and WAID. But enwiki is a big place and we might be surprised to discover how many people still didn't know.

. ⁓ Pelagic ( messages ) 11:00, 6 February 2022 (UTC)

No problem, @Pelagic. The exact date is not important to the Editing team, so if you all think we need to delay, then that's okay. Just please come to some agreement about what should be considered "enough".

To give some context, back in 2013, I personally posted announcements about the visual editor to more than 100 pages at the English Wikipedia, it had been discussed in the village pumps for months, the team ran CentralNotice banners in multiple languages for two straight weeks ...and many editors were still surprised. I remember one person saying that she had been on vacation for the exact 14 days that the banners ran. Most of us in this discussion have probably also seen CENT-listed RFCs that are claimed later to have not been well-advertised enough, because 99% of editors don't follow RFCs or CENT, and they sometimes regret that they missed important discussions. I have also seen an editor participate at length in a discussion about a proposed change, and later ask why there had never been any discussion about that change. All of which is to say: no amount of effort can completely prevent surprises. The English Wikipedia is too big for everyone to know about everything, and we have too much to keep track of to remember even the things we do talk about. I expect that most editors will consider the Reply tool to be a pleasant surprise, but I do expect its appearance to surprise a substantial number of editors no matter what we do or when we do it.

Offhand, in the past few months, I know that this tool and its deployment has been mentioned in at least three village pumps, Wikipedia:Talk pages project (but only ~20 active editors watching that page), the Wikipedia:Administrators' newsletter, and at least two issues of m:Tech/News. What else do you want to add to that list? Whatamidoing (WMF) (talk) 05:55, 7 February 2022 (UTC)

I feel your frustration, Whatamidoing. In my imaginary ideal world there would be a formal RFC that, for once, could come down clearly in favour of change, because of all the great community work you have already invested, and because this is a feature that I believe most people deem beneficial. There's a danger it could get bogged down in "no consensus", which would be a saddening demonstration that participatory decision-making doesn't scale, and that enwiki is something like Conway's Game of Life where interactions are localised to small scale but cause surprising ripples.

As to choice of channel, I almost wrote earlier something like "hey, why not go all out and run a mw:CentralNotice banner, rather than just a watchlist banner or a WP:Centralized discussion listing?" Not knowing that you had been through that before.

Personally, I'd be wouldn't mind if you turned it on tonight. Maybe there's nothing more you can do to influence the amount of pushback. As you say, how much is enough? ⁓ Pelagic ( messages ) 14:17, 7 February 2022 (UTC)

I'm sure that the product manager would be willing to wait for an RFC, but the number of times volunteer-me has had conversations along the lines of "There should've been an RFC! – There was an RFC last month; here's a link to it – But there should've been an RFC!" leaves me doubtful that even that would work.

For clarity, I really do want as little surprise as possible. I am just not certain that we can materially shift the needle on that with any non-disruptive means. Whatamidoing (WMF) (talk) 16:48, 7 February 2022 (UTC)

I think that makes a lot of sense. I agree that having a up-or-down vote on the matter is probably not productive. Maybe we should give it a week with a T:CENT banner plus a watchlist notice? Enterprisey (talk!) 22:22, 7 February 2022 (UTC)

I understand there are those who are suspicious of change, and can find it hard to adapt. Nonetheless, the visual change being proposed is a brief string of text added to the end of comments. Editors remain free to add comments the same way they always have and ignore the new link. I think it's overkill for there to be a large-scale RfC on the matter, absent any indication that there is in fact a significant proportion of editors who object. As an example: once upon a time, the section edit link was right justified. A number of editors raised complaints when it was changed. I could be wrong, but I don't get the sense that it continues to be a simmering irritant to this day. isaacl (talk) 22:40, 7 February 2022 (UTC)

Locations notified[edit]

I'm adding in this sub-section so we can bullet-list all those places notified of the Reply tool rollout. Nick Moyes (talk) 22:53, 8 February 2022 (UTC)

• The change to default-on has been announced at the Teahouse: Special:Permalink/1070670917#Another Announcement: Reply Tool roll-out imminent, Special:Permalink/1070697461#Reply tool might get here soon by Nick and GGS. ⁓ Pelagic ( messages ) 20:17, 8 February 2022 (UTC)
• Help:Talk pages has had a new section on the Reply tool inserted (see here) (Please don't alter the section heading until rollout has finished, as other pages are now being linked to it).
• Help talk:Talk pages has been notified of the addition (see here). Nick Moyes (talk) 22:53, 8 February 2022 (UTC)
• Wikipedia talk:Help desk informed (see here). Post also made to WP:Help Desk on 8th February. Nick Moyes (talk) 23:26, 8 February 2022 (UTC)
• Wikipedia talk:Teahouse informed of delayed rollout. (see here). Nick Moyes (talk) 23:39, 8 February 2022 (UTC)
• Help talk:Introduction to talk pages/1 informed of future rollout (see here) Page is too basic to talk about something that isn't yet visible to users. Nick Moyes (talk) 00:01, 9 February 2022 (UTC)
• Wikipedia:Administrators' noticeboard informed (see here). Nick Moyes (talk) 00:09, 9 February 2022 (UTC)

I'm adding in this sub-section so we can bullet-list all those places notified of the Reply tool rollout.

@Nick Moyes what a great idea! PPelberg (WMF) (talk) 02:20, 9 February 2022 (UTC)

• User talk:Jimbo Wales notified a few days ago. ― Qwerfjkltalk 07:16, 9 February 2022 (UTC)

Reply tool next steps[edit]

Hi everyone, I really don't want to see a foundation (or developers) vs community fight here on what seems to be a small feature.

This discussion has kind of gone sideways - let's get back on track. The way I see it there are only two good options:

1. (HARD BLOCK) This new software deployment should be blocked on community consensus; we hold a normal RFC to get there. (Let's not pretend only the "deployment date" is under discussion - as "never" could be the result). Noting that such an RFC could spin in to debates about opt-out vs opt-in, new editors vs existing editors, default option, ip editor option; carefully setting up the RFC may help guide it.
2. (Gamma Test period) This is an advisory announcement only. A target date with some lead time is advertised. Anyone with concerns is invited (by way of notices) to test the feature (which AFAIK is not 'easy' to test in isolation?) - however deployment will be delayed if there are open bugs (not feature requests) in phab (link to what parent task should be used).

If the external-to-the-communty groups are willing to push forward (as almost all other software improvements are processed), then I suggest #2 is the way to go. My only concern with #2 is that it seems "tricky" to get people to test this, because the directions are to use a beta option which enables an entire suite of tools, not just this one.(Let me know if I'm missing something?) Directions for how to see the results of the change can be provided.

Thoughts? — xaosflux ^Talk 15:55, 9 February 2022 (UTC)

Discuss (Reply tool next steps)[edit]

Testing options? — xaosflux ^Talk 16:53, 9 February 2022 (UTC)

@Xaosflux: You can enable each beta feature individually. Yes you will still be enabling all discussion tools, however I don't see that as being a big of an issue. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 15:58, 9 February 2022 (UTC)

Indeed, you can enable the beta feature at Special:Preferences#mw-prefsection-betafeatures, and then disable the individual tools at Special:Preferences#mw-prefsection-editing-discussion. If you disable everything there except for "Enable quick replying", you'll see exactly what is proposed to be deployed as opt-out. Matma Rex talk 16:44, 9 February 2022 (UTC)

@Blaze Wolf and Matma Rex: thanks for the note! So yes, for #2 the "tester" directions would just be "Enable the Beta feature", "Only enable Enable quick replying". — xaosflux ^Talk 16:50, 9 February 2022 (UTC)

Just so you know, I myself would prefer #2. #1 makes it seems like this entire process of notifying people ahead of time was a complete waste if the software deployment were to be blocked by the community with the option for it to never be deployed. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 18:36, 9 February 2022 (UTC)

Personally, I think #2 is OK in this use case, but having been around to see mediaviewer, visualeditor, and flow deployment problems respect that the community could be wary. — xaosflux ^Talk 19:03, 9 February 2022 (UTC)

• So for #1 or #2 above, @PPelberg (WMF), Whatamidoing (WMF), and ESanders (WMF): is staff going to push for #2? — xaosflux ^Talk 16:56, 9 February 2022 (UTC)

  @Xaosflux, the mw:Editing Team supports moving forward with the "Gamma Test period" you described here and @Enterprisey and @Nick Moyes both expressed support for.^{[1] [2]} Also, planning the deployment for Monday, 7 March 2022, is fine with us.

  I've updated the deployment ticket (T296645) with this new deployment date.

  If/when you notice people reporting a significant issue with the Reply Tool, please ping me and I can add the issue as a sub-task of T296645. You're also welcome to boldly add any issues you believe would warrant the deployment being blocked. Although, I think it's important that the Editing Team review any issues of this kind.

  Does the above leave any part of the question you posed above unanswered?

  And before I sign off for the night, I wanted to express gratitude to:

  • @Gråbergs Gråa Sång, @Pelagic, and @Qwerfjkl for posting announcements throughout the wiki and updating relevant documentation
  • @Nick Moyes for seeing the value in, and taking the initiative to create a list of where the deployment has been announced
  • @Xaosflux for guiding this discussion toward clarity

  PPelberg (WMF) (talk) 03:29, 10 February 2022 (UTC)

• Thanks for starting this. I'm for #2; as I said, I can't really imagine what could be controversial about this (that's jinxing it, heh) besides the possibility of interference elsewhere on the page, but since we have hard numbers for that I'm sure it'll be fine. Enterprisey (talk!) 22:20, 9 February 2022 (UTC)
• (edit conflict) I'm for #2 as well. I think it's all about not surprising too many people, rather than seeking their permission for a rollout of an effective new tool. Either way, I'm still unclear if a Centralised Notice or Watchlist Notice is a) in the pipeline b) impossible to do c) deemed inappropriate/unnecessary. Personally, I'd prefer to read a banner that affects me, rather than all that fund-raising stuff. Even a non-editing IP visitor seeing such a banner notice would come away with a positive impression that they could participate in discussions should they ever wish to. What's not to like?
  ...and a final thought, how about preparing a Reply Tool Rollout Information page? Aim it directly at en-wiki editors, and summarise all information together in one place. Here's a mock-up of its bare bones if folk think it's worth running with the idea. Nick Moyes (talk) 23:50, 9 February 2022 (UTC)

  @Nick Moyes: we have Wikipedia:Talk_pages_project#Reply_tool, which can be expanded on for sure (and what we were planning on linking people to) - not sure we need a standalone page. — xaosflux ^Talk 00:02, 10 February 2022 (UTC)

  xaosflux I wasn't sure either. I only thought that if people were concerned about minimising community concerns or kickback, then it could be a sensible 'political' move to directly cater for them with a dedicated page or sub-page just for the rollout issue. I'm not trying to make work; it all depends on what level of concern you and others think there could be. Nick Moyes (talk) 00:17, 10 February 2022 (UTC)

  Such a big/important change really does deserve a dedicated page. I think it would make sense to start by simply splitting the Reply tool section out of the Talk pages project page and then possibly extend it to cover any further issues related to the deployment. That would also help to segregate any future talk page feedback from the talk page feedback for the other parts of the overall project — GhostInTheMachine ^{talk to me} 12:19, 10 February 2022 (UTC)

  Based on the experience of other wikis, I'm not sure this will feel like a big change, especially after the first two weeks.

  That said, if you want to create Help: content, then mw:Help:DiscussionTools has some screenshots and basic text. You can extract the plain wikitext from the translation system at this convoluted link. Whatamidoing (WMF) (talk) 21:00, 10 February 2022 (UTC)

  I think it's an important change, for those who want to use it, but I think it's also a minor change for those uninterested in it, as it can easily be ignored. I think from a help documentation perspective, having the two ways of replying consolidated under Help:Talk pages § Replying to an existing thread is reasonable. isaacl (talk) 22:52, 10 February 2022 (UTC)

  Enough community support here should be fine to plow forward with #2 as well. Maybe we pick a date, like March 7th and go with it. @Enterprisey: seems like phab:T296645 is the main ticket, so any possibly discovered bugs can reference it and block it. I'm going to block it with a community-consensus requirement right now, but that doesn't mean we need a "support RFC" - just that this section needs to get a direction. — xaosflux ^Talk 23:38, 9 February 2022 (UTC)

  Basically, option 2 is a final Gamma Test period - with the pass criteria being "no unresolved blocking bugs" (so the assumption is that this is ready to go and is bug free - for example if no one actually tests or reports new issues). — xaosflux ^Talk 23:43, 9 February 2022 (UTC)

• Number 2 seems like the best option out of the two. This change, although not minor, can be opted out of. Plus I see this change as only benefiting those who want to use the tool. I've been using this tool for a while, and it has saved me a fair amount of time. Dreamy Jazz ^{talk to me | my contributions} 20:53, 10 February 2022 (UTC)
• Go for #2. Mz7 (talk) 20:52, 12 February 2022 (UTC)
• I'm for #2. KevinL (aka L235 · t · c) 01:17, 17 February 2022 (UTC)

  Hey PPelberg (WMF), hope all is well. Looks like we have at least a local consensus in favor of #2. Is there anything further you need from us? Does the Gamma Test option work for your team? Let us know if there's anything we can do to help you with the rollout or logistics. Best, KevinL (aka L235 · t · c) 18:00, 20 February 2022 (UTC)

  hi @L235! Thank you for thing ping...

  Looks like we have at least a local consensus in favor of #2... Does the Gamma Test option work for your team?

  Wonderful. And yes, the "Gamma Test" option works well for the Editing Team. We are planning for the desktop Reply Tool opt-out deployment to happen on 7 March 2022, provided no issues we collectively see as "blocking" remain unresolved at that point in time. See phab:T296645#7699690.

  Is there anything further you need from us?

  The work y'all are doing to file tasks for issues people are raising (e.g. T302257, T268558, T302296)^[i] and post announcements to ensure people are aware of and expecting this change (e.g. Watchlist message) is a big help and we are grateful for y'all leading this. I think continuing to do those two things will go long a way.

  On our end, the Editing Team will be gathering later this week to review the issues volunteers at en.wiki have filed about the Reply Tool. We will use this meeting to identify which, if any, issues we see as needing to be addressed before the planned 7 March deployment. I will post the outcomes of this meeting before this week is over so that y'all can review it and if necessary, we can talk about it.

  Please let me know if anything above prompts new thoughts/question.

  ---

  i. Special shoutout to @Xaosflux) for taking the initiative to file these tasks...this is a big help. PPelberg (WMF) (talk) 22:23, 22 February 2022 (UTC)

  @PPelberg (WMF) I have not seen any show-stopper bugs get raised, please be sure to also check Wikipedia_talk:Talk_pages_project — xaosflux ^Talk 22:45, 22 February 2022 (UTC)

  I have not seen any show-stopper bugs get raised...

  Noted. If/when you encounter a bug that rises to this level, please do not hesitate to ping me or @Whatamidoing (WMF).

  please be sure to also check Wikipedia_talk:Talk_pages_project

  On it! PPelberg (WMF) (talk) 22:48, 22 February 2022 (UTC)

  hi y'all. Yesterday, the Editing Team reviewed (what we understand to be) the main issues volunteers at en.wiki have experienced with the Reply Tool.

  Of the issues we reviewed, we did *not* identify any issues thus far that we thought ought to block the mw:Reply Tool deployment scheduled for 7 March 2022.

  We would value any and all people here reading over the review we conducted and commenting here if you:

  1. Think there are issues we did not consider and/or
  2. Think there are issues that ought to be considered blockers that we determined not to be

  You can read over the results the review we conducted in Phabricator here: Determine what – if any – issues ought to block the deployment of the Reply Tool as opt-out at en.wiki. PPelberg (WMF) (talk) 01:11, 26 February 2022 (UTC)

  I didn't see phab:T301845 on the list, which was mentioned at Wikipedia talk:Talk pages project § Discussion tools hiding error messages?. Is it on track to complete QA testing prior to March 7? isaacl (talk) 04:07, 26 February 2022 (UTC)

  @Isaacl I wouldn't call that blocking - since it is a garbage in garbage out problem, correct? High level summary: If someone creates a malformed page with unmatched tags, some of the page will not display right in this situation? — xaosflux ^Talk 12:16, 26 February 2022 (UTC)

  As per request, I raised an issue that I think should have been considered and didn't appear on the list. I'm not convinced it should be a blocker, and perhaps its resolution timeframe makes it moot, which is why I asked about it. But it does introduce a change to existing behaviour, and hides the cause of an error which can make (to the outside viewer, a seemingly random amount of) text on the page disappear. I think it should be discussed. isaacl (talk) 16:36, 26 February 2022 (UTC)

  @isaacl The fix for T301845 is actually already deployed to Wikipedia, since last Thursday! (For future reference, you can deduce this by looking for the orange tags with the version number like "1.38.0-wmf.23" on Phabricator, and comparing that to the version shown on Special:Version.) Matma Rex talk 23:03, 26 February 2022 (UTC)

  Thanks for the update! isaacl (talk) 23:14, 26 February 2022 (UTC)

  A non-blocking issue I reported elsewhere, but never got a response to is the annoyance of the Preview shortcut (Alt-Shift-P) being used out of habit (as one does all the time in Source Editor.) I don’t need it to actually work, but I am constantly frustrated by it taking me out of the reply window and opening the print window at the top of the page. So, finding one’s way back down on a long talk page to some point in the middle where the reply window is located is a frequent annoyance for me. Just deactivating this key combination would be welcome. Nick Moyes (talk) 10:03, 26 February 2022 (UTC)

  This is phab:T302742. It's possible that something useful could be done with it (scroll down a little, so the preview can be seen more easily?). Whatamidoing (WMF) (talk) 20:05, 28 February 2022 (UTC)

• Down for whatever gets this deployed to everyone the fastest. WMF has done excellent work on this tool, and I'm excited to see how it improves talk page dynamics. ProcrastinatingReader (talk) 17:00, 27 February 2022 (UTC)

Bugs[edit]

It is already implemented on the Dutch wiki for a while: nl:Overleg:Bijlmerramp (without asking me and without having it enabled in the preferences).
One bug I found in the editor was:
If I edit something and after that I copy something by a middle mouse click (on linux), it is pasted top left at the start of the edit. It does not happen with CTR-V. A more disturbing bug is that when I reply to an earlier post in a thread, the reply is inserted after the last edit in the thread. --Wickey (talk) 11:54, 11 February 2022 (UTC)

• @Wickey: regarding the later, that sounds serious, but I haven't been able to replicate it yet. Could you set up a simple sandbox page (e.g. at User:Wickey/replytool) and document that steps that you are doing, what results you got, and what results you expected? — xaosflux ^Talk 20:56, 12 February 2022 (UTC)

Don't know how to do this and if there is a difference between en- en nl-wiki, but I replied to a comment early in a series of comments here and here. My reply appeared as a reply to the last one (or at least one lower in the thread) instead where I replied. I may be mistaken, may be it happens in the preview, but it happened already before. --Wickey (talk) 10:57, 13 February 2022 (UTC)

Reply tool editor[edit]

Is there a page somewhere that talks about the editor used within the reply tool and the plans to update it? I did start looking via mw:Editor but got lost in a maze of twisty little articles — GhostInTheMachine ^{talk to me} 13:28, 11 February 2022 (UTC)

Given that mw:Extension:DiscussionTools requires mw:Extension:VisualEditor, I'd assume it's based on Visual Editor and its 2017 wikitext editor. --Ahecht (TALK
PAGE) 14:27, 11 February 2022 (UTC)

In terms of engineering, the "backend" is mw:Extension:VisualEditor. This means that nearly all of Wikipedia:VisualEditor/Keyboard shortcuts will work, even in the wikitext source mode (if you have the toolbar enabled; it can be toggled off in prefs). The toolbar is custom. If you have suggestions for what ought to be in the toolbar, then you might want to skim through phab:T282153. Whatamidoing (WMF) (talk) 20:19, 11 February 2022 (UTC)

Method of surname clarification[edit]

Which format should we prefer to clarify the surname of biographical subjects with non-English names: hatnotes, explanatory notes, or something else? {{u|Sdkb}} ^talk 05:15, 3 February 2022 (UTC)

Background and rationale (surnames)[edit]

For many years, Wikipedia used hatnotes at the top of biographical articles for subjects with names that used Eastern name order or other naming conventions likely to be unfamiliar to English speakers. Since 2020, these have been consolidated in {{Family name hatnote}} (examples: 1, 2). Also since 2020, a set of templates has been available that clarifies surnames using an explanatory footnote (examples: 1, 2), although so far their use has been relatively limited.

As far back as 2011, concerns have been raised repeatedly about the hatnote approach (discussions: WP:VPP 2011, WT:MOSCHINA Feb. 2020, WT:HATNOTE Sept. 2020, and others). There are two main issues:

1. Emphasis: A hatnote is arguably the single most prominent place in an article after the title, since it appears above even the first paragraph and is emphasized through italics and indentation. However, the information in surname hatnotes is not all that vital compared to the essential biographical information in the first paragraph. Eastern name order, while an interesting factoid, does not relate specifically to an individual person. Further, because we refer to a person by their surname throughout an article, most readers would likely pick it up even if it were not spelled out for them. We normally try to avoid putting trivial pieces of information in the lead, as such information would be undue weight. The same principle applies to layout, where trying to include too much leads to banner blindness (as we see on many talk pages). Overall, the information in a surname hatnote is not as essential as the information elsewhere in the lead and does not seem to warrant a prominent placement if avoidable.
2. Fittingness: Per the WP:Hatnote guideline, hatnotes have a discrete and clearly defined purpose, which is to help readers locate a different article if the one they are at is not the one they're looking for. Under this core definition, using them instead for surname clarification is a misuse which muddles their purpose. It seems that (as with emphasis), the choice to use surname hatnotes way back in the early 2000s was likely not a deliberate preference, but rather an awkward shoehorn of information that did not easily fit elsewhere at the time.

Surname footnotes address both these issues: they reduce the visual emphasis of the clarification, while still preserving it for any interested readers and converting it to a form that fits its purpose. I therefore propose that we adopt a preference for surname clarification via explanatory footnotes. If passed, this would permit interested editors to transition articles to the footnote format, but it would not override local consensus at any article where editors decide to keep the hatnote format (which could be noted in a hidden comment). Relevant guidelines would be updated to state that footnote clarification is preferred but hatnote clarification may be kept if desired. {{u|Sdkb}} ^talk 05:15, 3 February 2022 (UTC)

Survey (surnames)[edit]

Please !vote Hatnote, Footnote, or something else.

• Footnote preference, as proposer. {{u|Sdkb}} ^talk 05:15, 3 February 2022 (UTC)
• Footnote exactly per nom. Levivich 05:24, 3 February 2022 (UTC)
• Footnote a.k.a. Support proposal per nom. I'll also go farther and ask to deprecate surname hatnotes community-wide (if this extra bit doesn't pass, then the proposer's version is still very good). In this case, they would be phased out gradually as editors get around to updating articles.
  These hatnotes I find to be quite bizarre, giving WP:UNDUE weight to trivia, and violating WP:HATNOTE's well-reasoned direction that such prominent placement is only for navigation. The WP:TRHAT section of HATNOTE especially applies here. Explaining naming conventions, regardless of what it is, is not so important a matter that it deserves to have the most prominent place in an article. A footnote (or failing that, anything else) serves the same purpose much better.
  The existence of these has also occasionally been used to justify arguments to add hatnotes for other personal information, such as gender pronouns. However, current practice is that any time such in-article clarification is done, a footnote is used, and it works well for these cases. (Example: ND Stevenson.) If that can work for gender pronouns, it can definitely work for surnames. Crossroads ^-talk- 05:48, 3 February 2022 (UTC) updated Crossroads ^-talk- 05:29, 4 February 2022 (UTC)
• Not hatnote per OP. No great opinion on the alternative, though I think I would recommend footnote if deemed necessary locally as advisement and not as general expectation. It probably just isn't necessary at all to point out which is the family name, also per the OP. --Izno (talk) 06:10, 3 February 2022 (UTC)
• Currently not voicing a preference, however I oppose the "preference" wording used in the proposal. If a decision is made that hatnotes shouldn't be used based on the arguments provided, then a a local consensus shouldn't override it. So if consensus arises for footnotes, I support complete adoption of it. This would also make it possible to very easily convert {{Family name hatnote}} (which has 66719 transclusions) without needing to check with the local editors of each page. --Gonnym (talk) 06:25, 3 February 2022 (UTC)
• Not footnote I'm not particularly vibing with the idea of adding to 66000 biographical articles an entire level 2 Notes subheading consisting entirely of "a. ^ This is an East Asian name. The surname is {{{1}}}." Folly Mox (talk) 07:19, 3 February 2022 (UTC)
• Allow all depending on level of likely confusion. I like the historically widely used hatnote approach because it sets out the conventions used in an article without impacting on the body. A footnote is the minimum that is necessary, as it is non-obvious which name ordering is used. This is especially confusing with Chinese compound surnames like Sima or Ximen: the family name of Sima Qian is Sima. With names like Lee Kuan Yew, it is hopeless to guess what is the last name, so the article needs to tell you. A reader searching for Cixin Liu needs to be reassured that Liu Cixin is the same person (so there is some navigational use for the hatnote). —Kusma (talk) 10:48, 3 February 2022 (UTC)

  For Cixin Liu, both orders are bolded per MOS:BOLDLEAD, which is how we normally handle topics with multiple names and I think is sufficient here. For a name where one order goes to one person and a different order goes to another, I'd support a hatnote. {{u|Sdkb}} ^talk 19:09, 3 February 2022 (UTC)

  Any decision here applies only to hatnotes about surname clarification. So Lu Ping would keep the hatnote For the Taiwanese writer, see Ping Lu. but the hatnote In this Chinese name, the family name is Lu. might be relegated. Certes (talk) 19:36, 3 February 2022 (UTC)

• Footnote or other non-hatnote. A hatnote is too prominent and usually applies to the entire article rather than to a detail such as surname clarification. Certes (talk) 11:27, 3 February 2022 (UTC)
• Allow either per Kusma. Stifle (talk) 12:00, 3 February 2022 (UTC)
• More information, please Hatnote Both of the examples given, the family name comes first, so at first glance it looks like the hatnote is worthless, that people should just know that in a Chinese name the family name is first. But I don't think that is the case. In the discussions, editors have already mentioned that sometimes it is unclear which name is the family name. I think to be fair, you should list examples of articles with hatnotes where the family name does not come first. This, I think would give editors trying to weigh in here a better snapshot of the impact/value of these hatnotes. I reserve my vote until I understand this better. StarHOG (Talk) 14:39, 3 February 2022 (UTC)

Okay, the article on Raul Neto sealed the deal for me. Thank you Kusma for providing several examples. This along with Mathglot's comments about wanting to know up front how to read an article and have a person's name in your mind correctly. The Antonio Arias (referee) article is also a good example of why we do not want this information as a footnote. It is only the brevity of this article that the reader is given information about the naming almost immediately. In a longer article, that footnote would be lost or never referenced by your average reader. I am now strongly for using the Hatnote to explain to readers the naming convention a person uses. StarHOG (Talk) 03:22, 4 February 2022 (UTC)

• Raul Neto has a hatnote and Antonio Arias (referee) a footnote about naming conventions with given names appearing first. Certes (talk) 14:45, 3 February 2022 (UTC)

  The last name doesn't always come first with Chinese name, especially with people who have lived elsewhere. There's Shiing-Shen Chern (family name is Chen) and the wonderfully weird Lowe Kong Meng. Category:Members of Academia Sinica is a bit of a mess with both naming orders widely used. —Kusma (talk) 15:14, 3 February 2022 (UTC)

  For some non-Chinese examples, consider Gloria Macapagal Arroyo or Arantxa Sánchez Vicario. —Kusma (talk) 15:18, 3 February 2022 (UTC)

• Footnote (ie Support proposal per nom). Makes perfect sense. MichaelMaggs (talk) 14:59, 3 February 2022 (UTC)
• Hatnote per Folly Mox, and the fact this is pretty important information you shouldn't have to dig for when you need it, and names don't often need other hatnotes so it's fine to use it for a non-disambiguating purpose for people. 107.242.121.51 (talk) 18:29, 3 February 2022 (UTC)
• I think Folly Mox, Kusma, and StarHOG make good points. If the way that hatnotes are actually used on thousands upon thousands of articles is inconsistent with WP:HATNOTE, perhaps it is WP:HATNOTE (a guideline, not policy) that needs revising. Should we also eliminate {{correct title}}, since that doesn't direct readers to another article with a similar name? Hatnotes in general resolve possible confusions regarding article titles, and their use in this respect is entirely consistent with that broader purpose. XOR'easter (talk) 19:38, 3 February 2022 (UTC)

  {{Correct title}} is the other notable exception to WP:HATNOTE, but it's much less common – <1k pages – and something that we will hopefully one day no longer need once future software improvements are made to MediaWiki. I'd rather reign in the purpose of hatnotes than let it broaden out to the point of meaninglessness, since allowing it to broaden has costs to readers: with a discrete purpose, it's safe for readers who know they've landed at the right page to ignore hatnotes, whereas if we allow them to become a catch-all place for important information, that no longer holds true and opens us to a bunch of sure-to-be-messy discussions about whether to have hatnotes for things like pronouns (see Crossroads' !vote above).

  With that said, I do acknowledge that fittingness is more of a secondary consideration than emphasis. The main reason I'm putting this forward is the emphasis concern, and the fact that clarifications would also fit better purpose-wise with footnotes is just an added bonus. {{u|Sdkb}} ^talk 21:01, 3 February 2022 (UTC)

  The article title would be the same regardless of which of the names is the surname, so I fail to see how this is consistent with the purpose of handling title confusions. The "correct title" template does 'alter' the title, so that placement makes sense - and is ideally temporary until MediaWiki is improved as noted by Sdkb. Crossroads ^-talk- 05:29, 4 February 2022 (UTC)

  The possibility of title-related confusion exists because readers are not unlikely to come to those pages from somewhere that used a different order. A hatnote is a convenient place to ameliorate that confusion. WP:HATNOTE was made for editors, not editors for WP:HATNOTE. I guess I fall into the allow all, including possible-something-else camp on this one, with a preference against footnotes but a recognition that a one-size-fits-all, across-the-board rule is probably suboptimal. XOR'easter (talk) 00:00, 5 February 2022 (UTC)

• Allow either per Kusma. There are cases where it's genuinely confusing enough to merit a hatnote, and other cases where it isn't. (t · c) buidhe 21:03, 3 February 2022 (UTC)
• Not sure yet; leaning 'something-else' (Summoned by bot) – I take the point about the original purpose of hatnotes, and that's somewhat persuasive, but otoh, presenting information clearly to the reader trumps just about anything else in my book, and if a majority of surveyees say hatnote makes it clearer, then I'm fine with that choice, too. Otoh, not sure footnote helps as much as I would like. I think a major part of the calculus for me, is I *want* to know how to properly identify someone, and I don't want to have to hunt for whether the Singaporean politician is Mr. Lee, Mr. Kuan Yew, or something else, and a corollary of this is that I don't want to feel like a fool after getting halfway through the article, and realize with embarrassment that I've had it backwards in my mind up to that point. That would be the fault of the article, not my ability to understand, and I would resent it. So, I'm basically okay with any solution that avoids that, and I think at this point, I'd like either a clear statement in the first or second sentence ("Lee Kuan Yew (surname: Lee) was a Singaporean lawyer and politician...") or a usage such as "Mr. James", "Prime Minister Martin" that makes it clear by implication, without necessarily stating it outright: ("Lee Kuan Yew was a Singaporean lawyer and politican. Lee was Prime Minister from 1959 to 1960..."). So basically, just get me the information by sentence #2, don't make me hunt too hard to find it, and I'm good. I'm not categorically opposed to having the surname in a hatnote just because hatnotes were initially designed for disambiguation, because it satisfies the "clarity" issue; but if a just-as-good solution offers itself, I'd vote for the latter. Mathglot (talk) 01:19, 4 February 2022 (UTC)
• something-else Perhaps a |surname= added to {{Infobox person}}. Tvquizphd (talk) 03:29, 4 February 2022 (UTC)
• Allow all per Kusma, specifically including Mathglot's something-else. On the one hand I'm sensitive to the slippery slope argument made by Crossroads, the last thing we need is a list of hatnotes at the top of articles. However I also agree with those who want to make sure that it gets communicated right away, and I'm conscious that getting it right - and communicating it right - matters. To inadequately purvey this info is to continue biases already rampant here and elswhere. What to do, then? Let's allow a variety of practices to flourish here and if the benefits of a particular approach eventually become clear we can prescribe/prefer/deprecate as needed. Retswerb (talk) 07:27, 4 February 2022 (UTC)
• Footnote, but use <ref group=note> to avoid it getting confused with normal references. Hatnotes are overkill for this - they should be used when there is potential for confusion with another article, not minor clarifications of surnames. Modest Genius ^talk 12:48, 4 February 2022 (UTC)
• Allow all There is unlikely to be a one-size-fits-all solution to this, and having options for how to handle it best per article is the best option. --Jayron32 14:16, 4 February 2022 (UTC)
• Against explicit preference for footnotes. The current practice doesn't fit well with the overall purpose of hatnotes, but I wouldn't like to see a shift from the misuse of hatnotes to the misuse of footnotes. Explanatory footnotes are used for tangential details, not for information that may be necessary to understand how to read the article.
  I would like to note that even though I disagree with the proposed solution, I don't question the existence of a problem, but that's part of a bigger issue that we need to tackle. The first sentence of a biography article will often contain a lot of details – nicknames, maiden name, spelling of name in native orthography, transliteration(s), pronunciation (in English or native language) – that create a difficult to parse thicket that stands in the way of readers getting to the bit that describes who the subject is. I think we need a dedicated space for that information: one that doesn't clutter the first sentence but is still prominent enough (the end of the first paragraph? the end of the lede? a new lede paragraph that's visually set off from the rest? a section of the infobox? a dedicated (info)box?....). Once that is done, and we have a space where readers will learn to expect all name-related information, then the content of those hatnotes will naturally fit in there. – Uanfala (talk) 15:34, 4 February 2022 (UTC)

  I agree with that problem statement, though I have no brilliant solutions. Footnotes seem less bad than hatnotes but I hope there's a better way. Certes (talk) 17:02, 4 February 2022 (UTC)

  Definitely a separate conversation to be had about this, I completely agree. Retswerb (talk) 09:31, 12 February 2022 (UTC)

• Hatnote ~ the footnote is a pain to have to scroll down to in order for important information ~ or, at most, allow all. Happy days ~ Lindsay^Hello 16:26, 5 February 2022 (UTC)
• Hatnote - the votes are leaning otherwise, and I assume that is because there are a ridiculous number of completely unnecessary hatnotes for names on biography articles that should be removed. Just because someone is from Asia doesn't mean they need a naming hatnote. However, when there is a reason that the name must be clarified, a hatnote is the correct way to do so. User:力 (powera, π, ν) 00:00, 6 February 2022 (UTC)
• Hatnote Understanding a person's name is quite important and so clarification should go at the top of their article, not the bottom. An infobox entry may be adequate and so we shouldn't be rigid about this. Andrew🐉(talk) 14:41, 7 February 2022 (UTC)
• Hatnote this information is too critical for a footnote, most of which don't get read. Headbomb {t · c · p · b} 21:43, 7 February 2022 (UTC)
• Hatnote much too important to have to go looking for it, and much too hard to explain and re-explain Spanish surnames, and way too many hispanic names that are first, middle and last name the same, so need the fourth surname as per Spanish language customs spelled out right up front. SandyGeorgia (Talk) 21:54, 7 February 2022 (UTC)

  @LindsayH@力@Andrew Davidson@Headbomb@SandyGeorgia, if you think that putting the information in a footnote would be insufficient emphasis, I'd urge you to consider @Mathglot's idea above to put it in the parenthetical after the name, where we already put name information like pronunciation and native language spellings, and to adjust your !votes if you'd consider it an acceptable outcome.

  I understand where you're coming from, in that names are an inherently important thing, but I think it's important to remember that in many cases (albeit not all), we can clarify a surname easily just by using it in the rest of an article, and we wouldn't want a strict outcome of "hatnote" here to prevent us from using other methods for the articles where they fit better. It's also worth remembering that anything is going to seem more important in a discussion where it's the explicit focus, but hatnotes don't just note the information alongside other things, they prioritize it by emphasizing a generalized note on naming conventions more than even an individual subject's nationality/occupation/birth date. No matter your preferred solution, I hope we can reach a consensus at least that that isn't ideal. {{u|Sdkb}} ^talk 22:12, 7 February 2022 (UTC)

  In hispanic names, the parenthetical just wouldn't make sense as part of the text; one's full name is Joe Bloe FatherLastName MotherLastName, and the parenthetical would take up valuable real estate in the middle of the first line to explain how hispanic surnames work. So our text would be cluttered with Thor Leonardo Halvorssen Mendoza (Halvorssen is his father's paternal family name, Mendoza is his mother's paternal family name, according to Spanish naming customs) ... it's just goofy to take up precious real estate for that. Hatnote does the job, is easier, and standard. SandyGeorgia (Talk) 23:08, 7 February 2022 (UTC)

  Sandy, I believe this is not the issue we are trying to solve. In fact, Nil Einne addressed this confusion directly below. What we care about in this discussion, if I'm not mistaken, is not *really* what the surname is, but *how we are going to refer to Mr. XYZ in the rest of the article. In that sense, we don't care if "Mr. Lee" means that "Lee" is his surname or first name, we just care that in this article, we refer to him as "Mr. Lee", because that's what the sources do. Same thing with a Hispanic surname, Russian patronymics, or Sitting Bull; it doesn't matter which one is the surname, or if the term "surname" even applies at all.
  In your example, therefore, there would be no long parenthetical at all; in your Halverson example, the second sentence already solves this, and says: "The New York Times described Halvorssen as a maverick 'who champions the underdog...'" so now we know that he is referred to as "Halverson" in the article, and that's all we need to know. Mathglot (talk) 23:22, 7 February 2022 (UTC)

  Missing ping User:Nil Einne. Mathglot (talk) 23:29, 7 February 2022 (UTC)

  @SandyGeorgia, sure it could work. Here's that article with efn footnotes and here it is with a hybrid parenthetical/footnote format. {{u|Sdkb}} ^talk 23:24, 7 February 2022 (UTC)

  The first (footnote via efn) was so hard to see that I had to go look for it in the footnotes and then backtrack to see where you had placed the efn (meaning, a casual Wikipedia reader will probably miss it, or not go look for it). The second is just what I said in terms of convoluted and cluttering the first line.

  To Mathglot, consider a common issue (not in this case because they don't have a close relationship, but I digress); father and son do business or politics together and their article deals a lot with both of them and has to distinguish them. If is very common for mothers and daughters, and fathers and sons, to have the same name, and even the same middle initial. Then, per Spanish naming customs, we would refer to them in text as Halvorssen Mendoza and Halvorssen Vellum. The hatnotes are doing a good job educating readers about Spanish naming customs and how they are used in writing; I don't see a way around it, and I consider them a valuable aid to readers. SandyGeorgia (Talk) 23:46, 7 February 2022 (UTC)

  Hi Sandy, that's possibly a good use case for keeping the hatnote, it might help in that case. If this is a fairly common situation, can you link a few examples so we can see what they actually do now? I'm particularly interested in how they handle this in the body of the articles.
  But even here, I can see an argument for dropping the hatnote: partly due to banner blindness, and partly due to proximity: if I were reading one of those articles, I presume that the person named in the article title would be introduced in the lead sentence and paragraph, and I'm not sure how far down the same-named father would be introduced. I think *that* is where I would want to see the explanation; by the time I get there, I won't remember the hatnote (assuming I ever read it, which I might not if I saw a picture or a lead sentence with a bolded title in the first sentence letting me know I was on the right page). When they bring up the father, that is the point where I want to know who is who; if they use words like "Senior" in their culture, maybe that is sufficient; or pere, and so on.
  In the George W. Bush article for example, his similarly named father isn't mentioned by name in the five-paragraph lead at all; he first shows up in section #Early life and career as "He was the first child of George Herbert Walker Bush and Barbara Pierce." and by that time, the hatnote is a distant memory, if it ever registered at all. Perhaps you are talking about father-son pairs with identical names, not even differing by a middle initial; here, I'd like to see those links and see how the articles treat them now. See also Alexandre Dumas. Mathglot (talk) 00:20, 8 February 2022 (UTC)

  My memory won't cough up the example I am trying to recall of two Panamanians who got mixed up on Wikipedia; it will likely come to me when this discussion is over. But the George H. W. Bush example accomplishes same. Do a ctrl-f on the word son to notice how awkward the text is, particularly starting with the Appearances section. If those two had Spanish names, that awkwardness would go away, as we would have clear names for both: Bush Walker is the father and Bush Pierce is the son. Ah, but it gets better in this case, because Jeb is also Bush Pierce. So, this is probably as good of an example as it gets.

  Gow to move forward with this example: I believe the goal of this discussion is to reduce the number of banners at the top of the article per banner blindness. A different goal is to educate about Spanish naming customs at the very top of the article, without adding clutter to the text. My concern with removing the banner is that you remove something that editors creating articles in the Spanish-language realm will clearly have noticed and can see how to easily use, and serves to educate broadly about Spanish names. We would be replacing it with either a footnote or in-text clutter that offer the potential for inconsistent use. I am sympathetic to your goals and open to being convinced, but we're not there yet. Maybe there's a third alternative, that we could explore with the Bush Walkers and the Bush Pierces. SandyGeorgia (Talk) 14:50, 8 February 2022 (UTC)

  I understand what you're arguing (purely in the sense of "discussing") for, but i'm not sure i agree; i have read Mathglot's suggestion and, i'm afraid, in mine opinion that would be far more disruptive to the flow of the lead sentence/paragraph. To take the example given there, i think it is essential that we are clear that Lee is the surname, and just using it in the next sentence is not clear, especially and specifically because the name order is different from that expected by what is probably the majority of our readers; in particular with this name it rather clashes with expectations because "Lee" is sometimes a forename in English, so it has the immediate appearance of being over-familiar, and did i (and therefore probably others) not know i might try and change to what appeared to be a more formal and appropriate usage. As for the first suggestion with this example, putting "(surname: Lee)" immediately after the name is very interuptive (surely there's a word for that?) to the flow of the sentence and i would strongly oppose that. I recognise the argument that it's not what hatnotes are for, but...so what? It works and (if it's essential we use them only as intended) we can say we are disambiguating any confusion over the name. Happy days ~ Lindsay^Hello 13:15, 8 February 2022 (UTC)

• Footnote. There's lots of background information that is often absolutely crucial to understanding a biography. Why stop at naming conventions? Often there's far more significant background detail relegated to a wikilink - if you're reading an article on a Qin dynasty court official, a completely blank slate reader may well need to click multiple other history articles before they can really get it. A hatnote just isn't the right place for this; stick it in text (if the name is expected to cause unusual confusion / dispute) or in a footnote, same as all other relevant content. A hatnote simply isn't the right spot in the same way that a maintenance banner isn't the right tool for the job; hatnotes are for Wikipedia navigation, not explaining background detail. SnowFire (talk) 10:21, 8 February 2022 (UTC)
• Hatnote as it's an important detail which often explains inconsistencies in the article between people's full and common names e.g. why Spanish/Portuguese people have multiple surnames, and why we only use one of them to refer to them. Allowing any type seems sensible too, but footnotes will never be read. Joseph2302 (talk) 00:38, 9 February 2022 (UTC)
• Hatnote per basically all of the above. I don't need to repeat what everyone else already said. I don't object to footnote templates also existing for this purpose, e.g. to use at an article that already has a lot of hatnotes. And we don't need either for a lead like "A B (Chinese: B A) ...". But use hatnote by default.  — SMcCandlish ☏ ¢ 😼  05:37, 11 February 2022 (UTC)
• Hatnote for now, as though there's the possibility of a better solution somewhere down the line that this discussion might lead to, hatnotes are the best we have for now. I feel that anyone advocating footnotes or presuming that readers will be able to work things out for themselves just by reading the article is confusing the average reader of English Wikipedia with the average editor, regarding their knowledge of MediaWiki's conventions, those of web pages in general, and their global perspective. When writing for a general natively English-speaking readership, I don't think of what I would understand, I think of what my parents or grandparents would understand. They do not know that Wikipedia has footnotes and that clicking the blue superscript characters leads to them. No matter how many times I explain it to them, they cannot remember that cultures other than their own, indeed all but a minority of the world's population, use naming systems other than <personal name> <family name>. They will read an article about an Icelandic person and be confused why the person is only referred to by their personal name, not by what they think is the person's family name. They will read an article about a Chinese person and be confused by why the person's name is shortened to what they think is the person's personal name. I will explain why they are mistaken, and they will have forgotten my explanation in a few days' time. These kinds of people need these things to be mentioned first of all, every time a name is not in <personal name> <family name>. Hatnotes are good at doing this (even if it's not their original purpose) because they at the same time visually get this information out of the way for people who don't need it, and it avoids making the first mention of the person's name even more complex. Tempjrds (talk) 19:12, 18 February 2022 (UTC)
• Hatnote. Long story short, hatnotes for this particular use enjoy a strong and longstanding consensus. The guideline on them should be updated to reflect this. – Finnusertop (talk ⋅ contribs) 17:54, 21 February 2022 (UTC)
• Hatnote While not perfect, at present this seems to best way to make it clear to our readers (many of which may not even be aware of Eastern-naming order) which name is the surname. At least for me as a mobile reader and editor, I would prefer a hatnote. I would also be opposed to adding something only in the infobox as not every last-first person article has an infobox. Link20XX (talk) 04:03, 22 February 2022 (UTC)
• Footnote per OP, Crossroads and Izno. WP:UNDUE weight to trivia. I really think that the best solution is to use a explanatory footnote, but just when it is necessary. Alexcalamaro (talk) 22:09, 1 March 2022 (UTC)

Discussion (surnames)[edit]

A |surname= parameter could also be added to {{Infobox person}}. Or guidance should be given to note the surname under the template's "Notes" section. 71.247.146.98 (talk) 12:46, 3 February 2022 (UTC)

I agree that this information belongs as structured data in the {{Infobox person}}. Tvquizphd (talk) 03:25, 4 February 2022 (UTC)

Tvquizphd and IP, how would you want it to display in an infobox? Make a sandbox mockup if you'd like. I'm not sure how viable that could be as a main method, though, since infoboxes are already trying to cram in a lot of information, and not all articles have them.

If we're exploring alternatives, I think Mathglot's idea of putting it in the parenthetical is the most viable I've heard so far. The advantage is that it'd place the information in the body, in a space that's already communicating name info (typically pronunciation). The disadvantage is that we'd only be able to reasonably fit a very short e.g. (surname: Lee), which would cause problems for the more complicated examples like Raul Neto above or Vietnamese people like Phan Xích Long. {{u|Sdkb}} ^talk 03:42, 4 February 2022 (UTC)

• The idea of developing this as Infobox information is appealing. It would match the Wikidata P734 family name, which is present for cases such as Sima Qian, Gáspár Miklós Tamás and other interesting cases such as Jan Vennegoor of Hesselink (see also this on the latter's doubling), but seems to be omitted for patronyms that might be associated with Mongolian people,for example. Populating an optional line in Infoboxes from Wikidata could allow a gradual move away from the use of hatnotes and towards more structured information which might embed types of naming? AllyD (talk) 08:44, 4 February 2022 (UTC)

Perhaps it can display in parentheses after or below |name=. An example would be:

|name=Name (Surname: |surname=Surname)

To display

Name (Surname: Surname)

Note variable values are slanted as a coding convention.

Or a structured note under |Notes= can be used.

Also there is the issue of meta-templates & related templates based on the infobox. A look at Category:People and person infobox templates shows a bunch. 71.247.146.98 (talk) 13:49, 4 February 2022 (UTC)

@Retswerb: I appreciate you bringing up the topic of bias in your !vote. One angle to look at this from is that the hatnote convention includes some strong biases about what readers know and don't know. We would never (and should never) put a hatnote at John Smith saying "the surname is Smith", since we assume that readers are familiar with Western name order, but we also assume that they're unfamiliar with Eastern name order and need this explained to them prominently. Granted, on a practical level, this is English Wikipedia and our efforts to take a global perspective need to have some limit. But I think it's worth noting that one benefit of making the clarification less prominent is that it'd also make these names less marked, meaning that we wouldn't be assuming so strongly that readers have a Western perspective in which non-Western names are this exotic other. {{u|Sdkb}} ^talk 07:45, 4 February 2022 (UTC)

• Surnames in an unfamiliar position is probably the easiest name hatnote situation to solve. Other naming conventions, such as patronymics, or perhaps having no surname, seem more difficult to clearly imply through usage in prose alone. Is this proposal aimed at removing Surname Firstname hatnotes, but leaving other Family Name hatnotes in place? CMD (talk) 07:57, 4 February 2022 (UTC)

  @Chipmunkdavis, any naming convention hatnote can be pretty easily converted to a footnote: just take the text in the hatnote and put it in a footnote. The same general considerations apply.

  I think that it's important that we're able to handle edge cases in whatever system we end up with, but I also think we should take care not to focus so much on the most complicated instances that we lose the forest for the trees, as I see happening a little above. It's also worth remembering that this information is going to seem a lot more important here where we're hyperfocused on it than it will in the context of an actual article where it's one of many things to arrange in balance. {{u|Sdkb}} ^talk 08:09, 4 February 2022 (UTC)

  It does not make sense (and feels like a bit of the bias Retsweb mentions) to treat patronymics and single names as edge or particularly complex cases; they are established and regularly used naming systems. They might be unfamiliar to some or most English speakers, but they're whole forests in themselves. Framing a discussion as relating just to surname firstname order when it is intended to have a wider impact seems likely to lead to more confusion, not less. Footnotes may work for whatever the case is, but other suggestions above that were built in response to the framing of the question, like the "(Surname: Lee)" and the infobox surname parameter, will simply not work. CMD (talk) 08:24, 4 February 2022 (UTC)

  @CMD It would be nice if the Template:Infobox person could accomodate many naming conventions with many options |surname=, |matronym=,|patronym=, |tekonym=, |laqab=, |nisba=, and even perhaps |mononym=. Some examples might look like |surname=Lee or |mononym=triyatno. If no infobox or too much infobox, I think a simple parenthetical "(Surname: Lee)" or “Triyatno (mononymous, born 20 December 1987)” would do. I’ll post on Project Anthroponymy to see if anyone there has ideas.Tvquizphd (talk) 17:07, 4 February 2022 (UTC)

  I would not object to that. If it is done, perhaps the relevant wikilink could serve as the communicating text to the reader in place of the hatnote. CMD (talk) 17:59, 4 February 2022 (UTC)

Entirely a fair point! My personal take is that our general readership is probably unfamiliar enough with non-Western naming conventions that the value of pointing them out overcomes the detriment of marking them - but that's entirely an assumption on my part. Retswerb (talk) 08:08, 4 February 2022 (UTC)

The occasional Western surname also needs a note: Emile Smith Rowe (surname Smith Rowe) vs. Leo Stanton Rowe (surname Rowe). Certes (talk) 16:56, 4 February 2022 (UTC)

I'd welcome an explanatory note at Marion Zimmer Bradley. Never sure what end of the bookshelf to use for her books. —Kusma (talk) 18:28, 4 February 2022 (UTC)

• I'm slightly confused here. The opening comment etc refers only to surnames. But the template also deals with patronyms although for some reason we still have stuff Template:Malay name. Is this proposal only to deal with surnames? Also the opening comment claims "because we refer to a person by their surname throughout an article" but again that is not the case. We use whatever is the norm to refer to the person so for people without surnames this is often (but not always) their given name. Also we should not forget that even for people with surnames, name order can be more complicated than simple family name given name, given name family name e.g. Carrie Lee Sze Kei, Michelle Yeoh Choo-kheng or Daniel Lee Chee Hun. Nil Einne (talk) 06:45, 7 February 2022 (UTC)

  @Nil Einne: Yes, I can validate that confusion. In fact, I don't think this is really about surnames at all; I believe it's about how to refer to someone via a short name (if any) throughout the article, when we are not referring to them by their long, convoluted name, as in Sandy's example of Thor Leonardo Halvorssen Mendoza.
  Imho, we don't really care which is the father's name, mother's name or any of that; what we care about, is how they are referred to "for short". This is cleared up in sentence #2 of that article, and the answer is: Halvorssen. Who cares which ancestor bore that name? I don't. In such articles as importance would attach to knowing about their mother and father, because it's duly covered by reliable sources, than by all means, go into it in the body of the article, and even link our articles (not hatnotes!) about Hispanic surnames as appropriate. But I see no reason why the Thor Halvorssen (human rights activist) article needs a hatnote, and I don't care what his surname is. The #Background section explains in some detail his relationship to famous ancestors including a President Mendoza, and for anyone who's interested, they can read that, and follow the links. But all we really need to know about Thor Leonardo Halvorssen Mendoza's name, is that he is referred to as "Halvorssen" in the article, presumably because that's what the sources do. I don't see why a hatnote would be required at all, or even helpful. By the way, what is Sitting Bull's surname? Mathglot (talk) 23:41, 7 February 2022 (UTC)

  One more thing that occurs is that in some cases, the current family name template actually servers another purpose although I'm doubtful many readers understand this who didn't already know. If we take Chinese names like Lee Hsien Loong and Chong Sin Woon, it mentions the generation name. This isn't of relevance to how we refer to the person in the article since we use the family name but it conveys an important point.

  If you are referring to these people by their given name, it should be Hsien Loong or Sin Woon, never Hsien or Sin. While this applies to most two character Chinese given names too (double characters is sort of exception I guess), it's a special problem with generation names because calling someone Hsien/Sin or Hsien Lee/Sin Chong (as may happen in the west, even if you put the first name as Hsien Loong/Sin Woon in the form) can be confusing when multiple siblings are involved as it's unclear precisely who you're referring to. (If you did want to use one character only Woon or Loong will me more appropriate.)

  This is mostly a problem with Malaysian and Singaporean given names as it's where the practice of rendering the two characters as two "words" with spaces predominates. Those from Mainland China generally follow pinyin and don't include a space; those from Taiwan and Hong Kong, and while not Chinese names, those from (either) Korea where there's a similar issue, generally use hypens. Those in Western countries mostly use either don't include a space or use hypens since they're aware of the problem if they don't.

  That said, the generation name parameter seems to be hardly ever used (those were the only 2 examples I could find with a space in the given name) and I think it's hard to populate especially without OR since not all 2 character given names include a generation name. Also as said, this is an issue which technically applies to all 2 character Chinese give names even in cases where it's not a generation name; and I'm very doubtful anyone reading our hatnote is going to understand this point if they didn't already know from the name.

  And there are plenty of other naming issues which can cause confusion which we do not clarify in each article. For example Karpal Singh was not Muslim and while his name may sometimes be referred to as Karpal Singh al Ram Singh the al is from a/l and is unrelated to the al in Arabic names. (Having trouble finding links talking about this now, but in the past, there were reports of people coming under special scrutiny because their passport rendered the a/l as al since / cannot be used in the name part of machine readable passports and assumptions were made that the al meant they were Muslim. I suspect this is one reason why that is no longer done [8].)

  Nil Einne (talk) 00:30, 8 February 2022 (UTC)

  @Nil Einne: (edit conflict) This is more of an aside, but the generation name param |suffix= is used in template {{Portuguese name}}, which was sufficiently different due to this very param, that that template did not get merged into the {{Family name}} template when the mega-merge took place. There are 90 occurrences of the template that use param |suffix=. Mathglot (talk) 01:05, 8 February 2022 (UTC)

  Just pinging User:Primefac to this discussion and proposal, as they were responsible for the family name hatnote mega-merge, and may have something to say either about the somewhat narrower issue in this discussion, or the larger one at the top of this proposal. Mathglot (talk) 01:28, 8 February 2022 (UTC)

  Taking into account Mathglot's comments, would a "commonly known as" property be more apt? Or is this making the issue even more convoluted? 68.173.76.118 (talk) 02:04, 8 February 2022 (UTC)

  As a reply to the ping - I genuinely don't care how this information is displayed (my prior involvement has largely been in standardising template usage and minimising maintenance burdens). If necessary, though, I'm happy to consult on the hows, whys, and "what ifs" so that others may make a better decision. Primefac (talk) 09:23, 8 February 2022 (UTC)

• Suggestion. Okay, this is going to sound absolutely buck-wild, so I am going to drop this radical idea and walk away: use {{Notice}}. I know; I know.. This is heresy. I'm talking something small like this. Not going to make any arguments for this suggestion since I know it's one of those things that will probably appease zero sides of this discussion. If I'm wrong, then let me know. –MJL ‐Talk‐^☖ 19:21, 15 February 2022 (UTC)

  Alas, I think you're correct that that wouldn't appease anyone. My whole goal here is to decrease the prominence of the information to something more commensurate with its importance, whereas that would increase its prominence. {{u|Sdkb}} ^talk 19:30, 15 February 2022 (UTC)

I guess this is a vote for hatnote presentation in some form. I am a bit confused as to why user MJL considers it "radical". 74.72.146.123 (talk) 19:04, 19 February 2022 (UTC)

Actually, I think something like this could be an excellent way forward, provided the notice is floated to the right, like Template:IPA notice. This would be similar to the way natives names for Buddhist concepts are currently formatted using a dedicated template (example of use: Four Noble Truths). – Uanfala (talk) 20:46, 19 February 2022 (UTC)

• Suggestion I agree that knowing the surname can be helpful for understanding the article (and less importantly for editing the article when there is inconsistent usage). Adding to the infobox doesn't seem practical since they are not required, and there are over 150 different templates that are used on biographies. Coordinates are displayed at the very top right, and that space should always be available in a biography article. What if we use that space for a very short note (e.g. "Subject shortname is foo^[a]") with a footnote link allowing the full explanation to be provided in a footnote. I don't know if "shortname" is the best way to collectively refer to all the variations that have been mentioned here, but the concept is to use both a brief hatnote-like statement of the shortname with an explanatory footnote. MB 22:53, 19 February 2022 (UTC)

  I really like this idea, or something similar that might provide a third way. Retswerb (talk) 00:51, 20 February 2022 (UTC)

  Just want to point out that looking cursorily, it seems that many of the person infoboxes are meta- or wrapper templates for {{infobox person}}. In such cases, adding a surname parameter to the core code would make it generally available. 104.247.55.106 (talk) 14:21, 20 February 2022 (UTC)

  Many are also wrappers of {{infobox sportsperson}}. Yes, updating the core code would make it available to the wrapper template, but each of them would still need an update to use it. MB 19:00, 20 February 2022 (UTC)

  That's an interesting idea and I can imagine that it can be made to work. But the text will need to be visually more prominent (say, surrounded in a box), otherwise, I'm sure that most readers won't think to look at the tiny text in the top-right corner for that sort of information. – Uanfala (talk) 23:12, 26 February 2022 (UTC)

• I'll throw out another, perhaps more creative type of possible solution. This comes from what I've observed sports broadcasters tend to do, e.g. here/here, which is to use capitalization. In our implementation, this could come through smallcaps, e.g. this, or even a combination of smallcaps and tooltips, e.g. this. I'm curious what folks think of these, as my read of the discussion above so far is that few editors see hatnotes as the ideal solution but many also don't like footnotes. {{u|Sdkb}} ^talk 22:18, 23 February 2022 (UTC)

  There's no accounting for taste, but I find the caps solution very unappealing aesthetically. These pages will stand out as a sore thumb imo, and applying this format will probably necessitate changes to several established MOS guidelines. 71.105.141.131 (talk) 01:53, 24 February 2022 (UTC)

  Another interesting idea, but I'm not sure I can imagine people accepting it. It's also not going to work well in all cases (what do you do with Slavonic patronymics?) and if in the end we're going to rely on footnotes (or tooltips) this brings us back to the start of this discussion. – Uanfala (talk) 23:12, 26 February 2022 (UTC)

Trimming excessive notices at AFD[edit]

Take a look at Special:Permalink/1070790824, picked at random from today's nominations. Surely this is excessive? Unfortunately, it has become the norm at AFD. Is there some way that (a) this can be done in a single edit, rather than umpteen (Special:Diff/1070789018/1070790824); (b) that doesn't make it look as if there has actually been discussion, making it harder for AFD patrollers to find discussions that need some additional participation; and (c) isn't so inanely repetitive? Surely a single line with all of the lists in one sentence is better? How can the semi-automated scripts (User:Enterprisey's User:Enterprisey/delsort in this particular case but there are other tools) be improved to cut out the multiple edits and the repetition? Uncle G (talk) 14:06, 9 February 2022 (UTC)

Well I don't think anyone would object to collapsing a long list of deletion sorting notices with a heading that clearly identified them as deletion sorting notices, but other than that I think the list length is not a significant issue. I have no opinion regarding the multiple edits. Thryduulf (talk) 16:00, 9 February 2022 (UTC)

My preference would be to collapse them all down to a single notice that just lists off the topics, something like

• Note: This discussion has been included in the deletion sorting lists for the following topics: News media, Finance, Websites, Israel, Companies, Cyprus, Ukraine and Business

Much less clutter, especially for mobile users (since the mobile apps and website ignore small tags and display the text full size. 192.76.8.77 (talk) 19:52, 9 February 2022 (UTC)

That would be a nice feature. Beeblebrox (talk) 20:21, 9 February 2022 (UTC)

I am not 100% sure that's a good idea. I think we need at least four more editors to comment on whether they like the IP's suggestion or not. User:力 (powera, π, ν) 01:13, 12 February 2022 (UTC)

I too like IP's suggestion. Hemantha (talk) 08:18, 12 February 2022 (UTC)

This would actually be pretty easy to fix in the script (see here), so if someone wanted to update {{delsort}} to take multiple lists, I could sort it on my end pretty quickly. Enterprisey (talk!) 23:48, 17 February 2022 (UTC)

@Enterprisey I mocked up a version that takes multiple lists in {{Deletion sorting/sandbox}}. Note that the signature paramter has been changed from |2= to |sig=.--Ahecht (TALK
PAGE) 05:04, 18 February 2022 (UTC)

@Ahecht, cool! Could we make it shorter, like what the IP proposed - each list just adds the name of the list? Enterprisey (talk!) 05:09, 18 February 2022 (UTC)

@Enterprisey  Done --Ahecht (TALK
PAGE) 15:50, 18 February 2022 (UTC)

Nice. I would suggest we put the new template at a different page title because there are probably old workflows that use |2= for the signature. I think this is a fine opportunity for a little BOLDness, so I'll update the delsort script after your next response. Enterprisey (talk!) 21:05, 18 February 2022 (UTC)

and forgot the ping... @Ahecht Enterprisey (talk!) 23:19, 18 February 2022 (UTC)

@Enterprisey I put it at {{Deletion sorting/multi}}. --Ahecht (TALK
PAGE) 02:38, 19 February 2022 (UTC)

Neat! Seems to work. Enterprisey (talk!) 07:05, 19 February 2022 (UTC)

To clarify, I only made it collapse multiple lists when my delsort script is used to add multiple lists in one edit. If multiple edits are made, then it won't work. Collapsing the list when multiple edits are made is possible, but it would be some more work, which I don't have the time for at the moment. Enterprisey (talk!) 09:14, 19 February 2022 (UTC)

On point (a), multiple edits occurred due to the way script was used. If multiple topics are selected before clicking save, the script indeed does a single edit to the AfD page. See this diff from this sequence for example. hemantha (brief) 07:01, 10 February 2022 (UTC)

Adding .delsort-notice { display:none;} to custom css will remove the notices altogether. For compaction, use this javascript snippet in whichever custom script location. Hemantha (talk) 08:18, 12 February 2022 (UTC)

I'm not sure why @CAPTAIN RAJU: didn't use the existing "add multiple DELSORT topics in a single edit" feature. User:力 (powera, π, ν) 01:13, 12 February 2022 (UTC)

Thanks for the mentioned me.I couldn't find any rules for multiple edit delsort tags.And Multiple delsort editing can't be my mistake, there are no restrictions. I feel compatible to delsort tag a multiple edit. I also tag delsort with mobile browser or app.Thanks.CAPTAIN RAJU^(T) 13:04, 12 February 2022 (UTC)

• I agree with the point made in the OP, and would endorse some modification to the delsort message templates that allows them to be collapsible. I would like to take the opportunity to shill the Oracle for Deletion, which lets you sort recent AfDs by page size and !vote count (meaning it doesn't get quite as bamboozled by delsort notices). jp×g 23:44, 13 February 2022 (UTC)
• Is it the norm? I'm used to seeing around 2-3 notices per discussion, though admittedly I haven't closed any AfDs for a while. Looking at last week's log it does seem like there are more than usual, but that is basically all down to one person. So rather than talk about changing a template that has worked fine for years, we could just politely ask @CAPTAIN RAJU: can you please try to be more restrained in your tagging? – Joe (talk) 10:47, 19 February 2022 (UTC)
  • Of course, I am restrained in my tagging and will try to be more restrained.Thank you.CAPTAIN RAJU^(T) 11:13, 20 February 2022 (UTC)
  • I believe CAPTAIN RAJU is doing an excellent job in making sure AfDs promptly hit the relevant delsort lists, and we should be grateful for it. Unless there is a consistent pattern of inappropriate listings, which I take is not the case here, I don't see a need for more restrained tagging. However, if CAPTAIN RAJU is able to combine the delsorts in a single edit, that would be helpful. – Uanfala (talk) 20:39, 19 February 2022 (UTC)
  • Tagging is useful; having the tags take up so much space is not. And while this particular instance isn't that bad, I've seen AfDs with 20+ tags on them, which takes up an unreasonable amount of space. That new template posted above is excellent for remedying this, I would support making it the default way to tag deletion discussions. Mlb96 (talk) 07:42, 20 February 2022 (UTC)
    • Enterprisey's update to the tool appears to have been just in time to make the one hundred delsort notices on this mass nomination appear no bigger than an average paragraph. – Uanfala (talk) 22:16, 20 February 2022 (UTC)
  • No, because that would be the wrong focus. This isn't about the specific editor who happened to be the one who edited the randomly chosen AFD discussion, or even about the categorizations, but about improving the tools and making their end results better. Uncle G (talk) 21:38, 21 February 2022 (UTC)
• Happy it was useful, then (@Uanfala). More broadly, AfD nominations created by Twinkle still seem to stack the tags; which Twinkle developer should be contacted to change this? I don't think the change would be too complicated - just switch from subst:delsort to subst:deletion sorting/multi. Enterprisey (talk!) 08:01, 21 February 2022 (UTC)
  • See https://github.com/wikimedia-gadgets/twinkle/issues/1519 and https://github.com/wikimedia-gadgets/twinkle/blob/20c0d0235262fa6ee6659a905a2141b37944aca3/modules/twinklexfd.js#L810 Uncle G (talk) 21:38, 21 February 2022 (UTC)

Bot proposal (AFC submission templates)[edit]

Should a bot that adds AFC templates to drafts be made? – AssumeGoodWraith (talk | contribs) 08:08, 15 February 2022 (UTC)

I propose a bot that adds AFC submission templates ({{afc submission/draft}}) to new drafts that are missing them. (in draftspace)

Why?[edit]

• I've seen newcomers make drafts, without any submission template. Whatever the reason is, most of them probably don't know how to submit the draft.
• Even if the draft is hopeless, the newcomer can still learn from it.
• Experienced users can easily remove the template, if it is undesired.
• The template contains some useful links for those newcomers who are looking to actually create an article.

Some samples: [9], [10]

Please note: The template being added is the unsubmitted template, not the template you get from {{subst:submit}}

Discussion (AFC submission templates)[edit]

@AssumeGoodWraith: Why is this an RFC and why is it here? You should read WP:RFCBEFORE to see the steps you are expected to have taken before starting a formal request for comments. Requests/ideas for bots are much better placed at WP:Bot requests. 192.76.8.70 (talk) 14:41, 15 February 2022 (UTC)

• I don’t have a problem with adding the AFC template to drafts that are in DRAFTSPACE. I would have an issue with doing so to “drafts” located in USERSPACE. The latter should be thought of as sandboxes - pages where a user is playing around with ideas. Those ideas might not be intended to be viable as potential articles (for example, I have created “drafts” in my userspace that are half formed ideas for a potential new section for an already existing article). Blueboar (talk) 16:23, 15 February 2022 (UTC)

  @Blueboar: The OP specified in their proposal that this bot would only add templates to pages in draftspace. 192.76.8.70 (talk) 18:06, 15 February 2022 (UTC)

I've seen the problem of a user not knowing their draft was not going to get any atttention, recently. But I don't think auto tagging it that way is a good solution. Better would be to leave the creator a talk-page message explaining what to do when they're ready to submit. It would probably be easy to get approval for such a bot. Dicklyon (talk) 17:27, 15 February 2022 (UTC)

• Invalid RFC there is a clear process that should be used for this: WP:Bot requests. As such, an RFC is not needed, as RFC is meant for when a process doesn't exist. Joseph2302 (talk) 17:31, 15 February 2022 (UTC)

  I disagree. It's better to have a wider discussion on such a thing to establish consensus before doing a bot request, where the review will be much more narrow and technical, and will want to see an established consensus for the proposed changes. Dicklyon (talk) 17:35, 15 February 2022 (UTC)

• As a BAG member any such request at WP:BOTREQ would be told to get consensus for the task at WP:VPR (those who actually read WP:BOTREQ would know this, see third sentence for those new to bots), so this is the right place to hold that RFC. Headbomb {t · c · p · b} 18:12, 15 February 2022 (UTC)

  What part of this task is controversial enough to require an RFC? As far as I can see this is basic maintenance, - these templates are already added to pages in draftspace if you use the article wizard, any of the preload templates, any of the draftification scripts and there's a small army of volunteers running around adding these templates by hand to pages that don't have them. If we've already have had editors running around draftsapace with AWB for years doing the same thing I don't see why this would be controversial enough to require a central RFC, it's certainly going to be less controversial than the bot that was changing indents on every talk page on the project. 192.76.8.70 (talk) 18:40, 15 February 2022 (UTC)

There has been substantial objections from the community on tagging drafts as drafts before. This is another proposal along the same idea. Not saying this will or won't pass, or if even if this is a good or bad idea, but mass tagging drafts with anything is something that requires clear consensus. Headbomb {t · c · p · b} 21:26, 16 February 2022 (UTC)

• If we are going to have a RFC on this then Yes, obvious support from me since these templates are added to basically every page in draftspace by hand anyway, they're basically required to use the AFC process, a frequently recurring source of confusion I've seen at the teahouse is people not knowing how to submit a draft without the template on it, the template performs a number of other maintenance tasks in draftspace (e.g. tagging G13 eligible pages) and editors who don't want them will almost certianly be experienced enough to use user space drafts, botsdeny or similar. Anything that makes it easier for people to write their first article is a good thing. 192.76.8.70 (talk) 18:40, 15 February 2022 (UTC)
• Strong Support Reduce headaches for new users & AFCers. Can't think of a negative aspect to it. Happy Editing--IAmChaos 00:15, 16 February 2022 (UTC)
• Maybe for drafts created by non-confirmed editors who are still non-confirmed at time of bot run, who are effectively going to have to go through AfC, but for everyone else this wouldn't be appropriate, because AfC is not a compulsory process for anyone, and the purpose of draftspace is not solely for AfC drafts, even if they constitute a large number of drafts. ProcrastinatingReader (talk) 12:35, 16 February 2022 (UTC)
• Support for pages created by non-confirmed editors per ProcrastinatingReader. I have notified Wikipedia talk:WikiProject Articles for creation and Template talk:AfC submission of this discussion. --Ahecht (TALK
  PAGE) 18:18, 16 February 2022 (UTC)
• Support for pages by inexperienced editors. I took a look at a day's worth of new drafts. We don't want to make difficulties for the experienced editors who use Draft space for translations and other new articles before moving their work to mainspace themselves. I would suggest using extended confirmed user as the criterion. StarryGrandma (talk) 20:02, 16 February 2022 (UTC)
• Support for all new draft pages, regardless of the editor. Much simpler. Experienced editors who don't like the templates can remove them. Also, auto-welcome the editor of they have no non bot edits to their user_talk page. --SmokeyJoe (talk) 03:52, 17 February 2022 (UTC)

  Auto welcoming is a perennial proposal. That's going to probably require a separate RFC (if I wanted to add it) – AssumeGoodWraith (talk | contribs) 06:09, 17 February 2022 (UTC)

• Support for inexperienced editors or time delayed if applied to all drafts, maybe 1 day from creation delay? The draft could still be worked on by experienced editors even though it is created thus the delay. Some editors may have the habit to do incremental saves while fleshing out the draft. – robertsky (talk) 08:49, 17 February 2022 (UTC)
• Support for non-confirmed editors (or non-XC editors). I'd alternately (maybe even additionally) support a bot message to user talks letting them know how to add the template themselves (with a Teahouse link or some way to ask "can someone add this template for me? I don't understand wikitext"), for non-XC editors only. It is worth a little bit of headache to any cases where an extraneous template is added or message is sent to someone who knows how to revert it, for the cases where a newbie will be unable to navigate AfC when that is the process they should be using. And even though confirmed-but-new editors can move drafts into mainspace themselves, in many cases it would be much better for them and for us were they to go through AfC. — Bilorv (talk) 00:23, 19 February 2022 (UTC)
• Support procedurally, this is in order; procedurally we will discuss, !vote, and approve the proposal here, then the BAG will validate the specific bot doing this. As far as whether this is a good idea: yes, it is. If a non-ECP editor creates a draft, a bot should add the AFC template (but not start the "submitted" timer) in all situations. When it is an ECP editor ... normally probably also yes, but maybe it gets complicated. But BAG won't approve a bot that edit-wars, so it will be fine. User:力 (powera, π, ν) 01:48, 20 February 2022 (UTC)

RfC#2 : Removing links to portals from the Main Page's top banner[edit]

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.

This proposal was meant to assist in moving the process forward. After the objection of many participants, such as the one by Levivich (with which I do not agree but do not intend to enter into debates either), I'm withdrawing the proposal. The issue could be taken up by other interested parties. -The Gnome (talk) 09:05, 17 February 2022 (UTC)

---

Should the Main Page continue to display the portals right next to the "Welcome to Wikipedia" sign as they currently stand? Or should that display be changed in any way? (They are the links pointing to the arts, Biography, Geography, History, Mathematics, Science, Society, Technology, All portals.)
A: We should leave the display as it currently stands.
B: The display should be changed.
Note that option "B" includes any of the following steps: removing the portals entirely from the Main Page; moving the portals somewhere else on the Main Page; any other change in the current display. If option "B" is chosen, then the specific change could be determined in a separate RfC. -The Gnome (talk) 10:16, 16 February 2022 (UTC)

• Comment: Check out previous discussions here, here, and here. Disclosure: As it happens, I closed the previous RfC on this issue as "no consensus." Nothing should be implied by that closing and, naturally, I will not take part in this RfC, which I initiate to overcome, as the case might be, the stumble in the process. -The Gnome (talk) 10:16, 16 February 2022 (UTC)

Survey (portal links)[edit]

• Option A. Other than some people disliking portals and/or their prominence nobody has yet managed to demonstrate that there is anything problematic about the status quo. Could improvements be possible? Maybe, but if so then propose that specific improvement with a mockup and a clear explanation of why it is an improvement. Thryduulf (talk) 11:52, 16 February 2022 (UTC)

  The argument that there is no harm violates basic web usability best practices, which have understood since the 2000s that there is inherent harm to keeping essentially unused links on your home page. {{u|Sdkb}} ^talk 17:27, 16 February 2022 (UTC)

  Except these links are not unused. In the last rfc those supporting removal claimed this, but the data they presented in support of that argument actually showed the exact opposite - the portals and links to them are well used by readers of the encyclopaedia. Note I'm not saying what we have is perfect, I'm saying what we have is better than some hand-waving towards an unspecified alternative that may or may not feature links to portals. Thryduulf (talk) 20:10, 16 February 2022 (UTC)

Concept with portals link moved

Concept with language switcher

• Option B. In particular, per the prior discussion, I support replacing the portal links in the top banner with a line in the "Other areas of Wikipedia" section reading Content portals – A unique way to navigate the encyclopedia (pictured). Also, depending on how the Desktop Improvements Project resolves phab:T293470, where they're trying to figure out where to put the new language switcher on Main Pages, I may support using the newly freed space in the banner for the language dropdown menu, somewhat like the concept (pictured). My rationale is the same as last time: we shouldn't be devoting space on the Main Page to links that are barely ever used, that don't represent our best work, and that clutter its design. {{u|Sdkb}} ^talk 17:51, 16 February 2022 (UTC)
• Option A - Such a directory is necessary and that piece of prime real estate should not be left empty; altering it without a concrete plan for adequate replacement (and possibly even complete removal) is not something one should favor. — Godsy ^(TALK_CONT) 18:39, 16 February 2022 (UTC)
• Option B per Sdkb. Ajpolino (talk) 19:15, 16 February 2022 (UTC)
• Option B - as per above, this space should instead be used for the language switcher. As shown by the above page view statistics and despite their place on the Main Page, portals simply aren't used much and a language switcher would likely be of much more use to readers. Remagoxer ^(talk) 19:17, 16 February 2022 (UTC)
• Option A, with the suggestion to work on improving those portals (if only we had more portals like Portal:Cheshire, we would not have this kind of discussion) instead of removing the links. If the portal links end up removed from the Main Page, I would suggest to put a link to portalspace into the Navigation sidebar, above or below "Contents". —Kusma (talk) 19:19, 16 February 2022 (UTC)

  The portal folks have been on notice for years that if the space wasn't improved, things like this would happen. If they were going to be improved, they would've been improved. {{u|Sdkb}} ^talk 19:53, 16 February 2022 (UTC)

  It's tricky to spend time improving something when you have to spend most of your wikitime repeatedly rejustifying the things existence. The characterisation of people as "portal folks" shows that the completely inappropriate battleground attitude did not die with the arbcom case. Thryduulf (talk) 20:13, 16 February 2022 (UTC)

  Repeated RfCs have failed to find consensus for destroying the portal namespace or for unlinking it to prevent anyone from finding it. Despite that, two thirds of portals have been deleted. What remains is the best of the portals, and many of those have improved significantly. Certes (talk) 20:42, 16 February 2022 (UTC)

• Option B. Simply spreading the information on the left across the page, in a thinner row, would be an improvement. I am a member of the History Project and have just clicked on its portal for the first time. Nice stuff, not least the sample featured article which is one of "mine" , but I fail to see why or how portals justify a place on the main page, even less one at its head. Gog the Mild (talk) 19:20, 16 February 2022 (UTC)
• I guess I'll have to go for option A given the format of this RfC, which is flawed. There are fundamentally three choices here: keep them where they are, remove them entirely, or move them somewhere else. If you have three options then an RfC should be about those three options. Consolidating two of the options into one inherently biases the process against the remaining option. These links get substantial numbers of clicks and represent the only way that the main page allows people to navigate Wikipedia's content. I would be happy to support moving them somewhere else, but there is no option to support that. Hut 8.5 19:23, 16 February 2022 (UTC)
• B - Note, I prefer that we be rid of portals entirely. But, that wasn't the way the community wanted it. GoodDay (talk) 19:54, 16 February 2022 (UTC)
• Option A, not because I can't imagine an improvement but I can't bring myself to vote for an entirely unspecified change. For example, I oppose leaving a blank space to "slightly modernize the user interface" and I do not accept the weird notion that "A reader who would want to learn something new would just read an article at random". The links are useful and should only be displaced by something that is better. Thincat (talk) 20:10, 16 February 2022 (UTC)
• Option B, remove Portal links for reasons described in previous RFC, but also procedural objection. This is a self-inflicted wound of needlessly closing a well-attended RFC as "no consensus" so that it can be re-run in violation of WP:NOTBURO. Editor time is valuable, don't make people vote on the same issues constantly. I also disapprove of someone who is not an advocate of changing the status quo starting such a discussion while only mentioning the affirmative case for the change indirectly via links to previous discussions, and creating such a vague "do something" Option B. I already see people complaining that they don't wish to vote for an unspecified change - which I can hardly fault them for! I wouldn't want to either! An actual advocate would have offered a concrete proposal so that people knew what they were voting on, so this is going to be scuffed. This is not a good way to run an RFC. (Nothing personal against the editor who created this RFC, I'm sure they're acting in good faith, but this is the equivalent of somebody trying to help you sell your house by painting it purple overnight.) SnowFire (talk) 20:51, 16 February 2022 (UTC)
• Option A. Without any prejudice, I think this RFC is not well-formed. I have noted my reasons further in the discussion section, but, it currently is phrased as a "Remain as-is" vs "Change; but will not tell you what it will change to / do not know what the new one is going to look like". With the alternative remaining an unknown -- I would want to retain the current links as-is. Thanks. Ktin (talk) 21:10, 16 February 2022 (UTC)
• Option A per Ktin. If we change it, I need to know what we change it to before agreeing to the change. Headbomb {t · c · p · b} 21:23, 16 February 2022 (UTC)
• Option A. Option B is to remove one sort of functionality from the main page and just leave the space... blank? If we're going to fart around in a main page redesign, let's do one. At the very least, we might have decided what the actual long-term outcome might be BEFORE creating this further (perhaps inadvertent) effort to expunge portals from the pedia. THE MAIN PAGE IS ITSELF A PORTAL. (sorry for shouting) Linking to other portals is one logical and coherent way to use the space. BusterD (talk) 21:35, 16 February 2022 (UTC)
• Option A. Should dump portals all over.....but option B leaves us with a blank space.Moxy- 21:53, 16 February 2022 (UTC)
• Option A, regretfully, as the Language switcher does seem like a possibly good idea (plus French Wikipedia appears to be already doing it), but we need to know what the B-alternative actually is. Otherwise, 'B' seems too much like, "I just don't like 'A'." Mathglot (talk) 22:14, 16 February 2022 (UTC)
• Option A. It feels like deja vu here... another RFC proposing removing the portals but with no clue as to what will go in their place. Like Thryduulf, and like my previous !vote, I might be amenable to the right proposal - perhaps one that reduces the vertical footprint of the banner altogether, but I'm not going to give a carte blanche to any change whatsoever.  — Amakuru (talk) 22:16, 16 February 2022 (UTC)
• Close this RFC, it's so out of process as to be disruptive. The closer of the last discussion should not be starting the next one. Where's the RFCBEFORE? Where's the neutral statement? Where are the meaningful options? This appears to me to be an attempt to manufacture consensus for the status quo by making the other option "something else", which is so vague, almost no one will vote for it. This is a complete waste of editor time, and if I hadn't voted in the last discussion, I would close this myself. Levivich 22:54, 16 February 2022 (UTC)
• Option A because the other option is a pig in a poke and we've already established that there's no consensus for any particular change. Andrew🐉(talk) 23:12, 16 February 2022 (UTC)
• Option B - As I stated in the previous RFC, I favor keeping the links, but moving them to a less prominent location on the page. Blueboar (talk) 22:21, 16 February 2022 (UTC)
• Option B. Remove the nine portal links from the top frame, move them under the "Community portal" link under "Contribute" in the left frame. Possible replace "Community portal" with "Portals".

The nine portal links in the top frame consume far more prime real estate than they are worth. An old page view analysis showed that only 1 in 1000 main page views lead to a main page portal click, and for every main page portal click, only around 1 in 1000 go on to click a second tier portal link. This indicates that main page readers do not find the portal links useful or interesting. --SmokeyJoe (talk) 03:57, 17 February 2022 (UTC)

• Option B, yet again, per all the cogent arguments made last time around. I've gone back and compared this RFC to the last one three times and I'm baffled as to how we ended up here, asking the same question again. The question we had last time was whether the portal links should remain as is or be removed from the top banner, with a note specifically including the possibility of them going elsewhere on the page if removed from the banner. At the close of that discussion we were told that this is an adulterated result and the decision seems clear: We have no consensus to move forward with altering the Main Page through this RfC because it did not offer clear-cut choices and thus did not manage to elicit clear-cut responses - and now the author of that closure gives us the same options yet again: leave the portal links alone or make an unspecified change. What am I missing here? Full support of the objections already raised by others, this particular dead horse has been beaten enough. Retswerb (talk) 09:12, 17 February 2022 (UTC)

Discussion (portal links)[edit]

• Perhaps this should be added to WP:CENT?A. C. Santacruz ⁂ Please ping me! 10:33, 16 February 2022 (UTC)

  Added. {{u|Sdkb}} ^talk 18:03, 16 February 2022 (UTC)

• Procedural objection – this is precisely the debate format we agreed to avoid in December's RfC. Picking off options such as the status quo one by one for not having an absolute majority over all other options combined will probably result in a less popular option being selected. Certes (talk) 13:51, 16 February 2022 (UTC)

  The previous discussion had 30 votes in favor of removing the portals and 17 in favor of keeping them, so I'm not particularly worried about some silent majority that wants to preserve them. This isn't how I would've framed this RfC, as I think we could've directly !voted on alternative options here, but I think we're likely to get to the same result, just with an extra step. {{u|Sdkb}} ^talk 17:31, 16 February 2022 (UTC)

  No, the previous discussion had 47 votes for and against various different possibilities. Because of the nature of the RfC it is simply not possible to divide the comments into two clear groups - which is why we are here. And unfortuntely this RfC is again trying to divide people into two clear groups based on their support or opposition to three different options that are not mutually exclusive and so stands very little chance of achieving consensus for anything. Thryduulf (talk) 20:17, 16 February 2022 (UTC)

  I agree that this stands little chance of achieving consensus as written, and that's because it didn't simply ask "Keep or Remove" and instead has this useless "do something!" vagueness in Option B. The original RFC was actually better on this offering two concrete proposals. I disagree though that there were too many various different possibilities actually supported in the previous RFC: a majority of editors favored the simple removal option. Now we'll probably require two full RFCs at best to figure out what this means, since if Option B wins, there'll have to be a pointless follow-up RFC. This is precisely how RFCs should not be run. SnowFire (talk) 20:58, 16 February 2022 (UTC)

  a majority of editors favored the simple removal option except they didn't. The RFC was not a vote and there was a mixture of support for the options of "keep as is", "remove and replace with nothing", "remove and replace with something" (various somethings specified and not specified) and "move them elsewhere" (with various locations specified and unspecified). Thryduulf (talk) 21:55, 16 February 2022 (UTC)

  I didn't mean to reopen the AN debate, but that isn't a rebuttal to what I wrote. All I said was that a majority of editors favored the simple removal option, which is true. That means throwing away any of the other options. (Maybe more obvious in a hypothetical case where 80 vote X, 15 vote Y, and 5 vote Z - the fact that there's a mixture doesn't matter.) SnowFire (talk) 23:53, 16 February 2022 (UTC)

• Pinging prior participants who haven't already commented here (batch 1): JBchrch, Gog the Mild, Anarchyte, Retswerb, EpicPupper, CaptainEek, Jackattack1597, Firefly, Pldx1, Schierbecker, Vexations, SmokeyJoe, Izno, Sandstein, Guilherme Burn, Gadfium, Remagoxer, Blueboar, UnitedStatesian, Ruslik0, Calliopejen1, AleatoryPonderings, Bilorv, Neil Shah-Quinn, Levivich, Aza24, Zero0000, SnowFire, Cavalryman, Moxy, NightWolf1223. {{u|Sdkb}} ^talk 19:11, 16 February 2022 (UTC)
• Batch 2: Kusma, BusterD, Wikmoz, @Ktin, Whatamidoing (WMF), Hut 8.5, Xaosflux, Guilherme Burn, Dege31, Amakuru, Thincat, Dream Focus, Calidum, Andrew Davidson, Chicdat, Alanscottwalker, Espresso Addict, GoodDay, Northamerica1000, 力, JackFromWisconsin, Isaacl, Pppery, The wub, and JuxtaposedJacob:. {{u|Sdkb}} ^talk 19:12, 16 February 2022 (UTC)
• Shouldn't this have an RFC tag on it? NW1223(^{Howl at me}/_{My hunts}) 19:45, 16 February 2022 (UTC)
• Comment. This RFC (if it is that) is not well formed, imo. It is framed as a "Remain as-is" vs "Change; but will not tell you what it will change to". If there is a concrete option B, I would be willing to evaluate. Else, in the current phrasing -- I am not sure what we are signing up for. Ktin (talk) 21:10, 16 February 2022 (UTC)
• I disagree with one option covering all possible changes to the main page: it could be "remove all links to portals", or "reinstate articles for improvement in that top space" for all anyone knows. It's not a good way to figure out how to change the main page: there are lots of people who want different changes, but that doesn't mean any one change must be found to have consensus support. isaacl (talk) 21:16, 16 February 2022 (UTC)
• I advised two or three times over the last 12 or so months, to get rid of portals entirely. But does anybody agree with me? Nope. GoodDay (talk) 03:44, 17 February 2022 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.