Wikipedia:Village pump (proposals)

Proposal/RFC: Recoloring page-protection padlock icons to be consistent with the interface

There is a clear consensus to replace the current design with the proposed design for:

1. Semi-protection
2. Move protection
3. Pending changes protection
4. Extended confirmed protection

Permanent protection

was not changed.

Some editors objected to replacing the current design with the proposed design for:

1. Full protection
2. Template protection

largely because of the concerns raised by pythoncoder:

The full protection and template protection locks look too much like the interface-protected lock vs. under this proposal. We should not be making the locks look identical in the name of branding.

There is no consensus for or against the "full protection" and "template protection" proposed icons owing to many editors not specifically discussing them so there is no prejudice against opening a new RfC to discuss only these two proposed icons.

Cunard (talk) 09:37, 14 July 2019 (UTC)

The following discussion 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.

---

Hello everyone. Padlock icons have been redesigined to be more accessible which is great but they lack one small part, using the consistent color scheme we are using in the interface. Recently, several parts of the interface have been recolored to algin with the software interface. More generally speaking Wikimedia UI style guide. You can see the discussions in Special:Diff/754712927. In short, we use the same blue shade (#3366cc) as much as possible, from "Publish edit" button to the left border of ambox (notice) to color of links in mobile frontend, this blue-ish plus a dedicated set of grays is to give feeling of ink and book and giving a consistent look/experience to readers and sort of brand ourselves with those colors. Lots of small and invisible changes have been made (like chaning background of wikitable and infoboxes) to help aliging with the consistent color scheme. This padlock icon recoloring is a good step too IMO. Most changes are invisible to naked eye and we don't need to agree on all of them, you can shout out that color of padlock "foo" seems wrong to you. You can see the reasoning behind this color scheme in Wikimedia UI style guide.

Type of protection	Current design	Proposed design
Permanent protection †
Full protection
Template protection
Semi-protection
Move protection
Pending changes protection
Extended confirmed protection		Extended confirmed protection

† No change, added for reference

Do you support this change? Thanks! Ladsgroup^overleg 21:09, 29 May 2019 (UTC)[reply]

• To my eye, the only padlock that looks different is full-prot. The rest look virtually identical. —A little blue Bori v^_^v ^Bori! 21:16, 29 May 2019 (UTC)[reply]
• Support since I can think of no possible negative consequence of this. It's not clear to me that this change does any good, but if there's no real drawback and you think it's helpful, then I'm all in favor. Go for it. Ajpolino (talk) 22:16, 29 May 2019 (UTC)[reply]
• Semi, ECP, and Pending look almost exactly the same. Move barely changes. Template goes from a pink to a red and Full goes from a gold to an orange. Those last two are the most likely to be controversial. I'd definitely support the first four. --AntiCompositeNumber (talk) 22:32, 29 May 2019 (UTC)[reply]
• I can see the move icon get notably bluer with the Wikimedia UI color, but otherwise have similar opinions to AntiCompositeNumber. * Pppery * _{it has begun...} 22:43, 29 May 2019 (UTC)[reply]

  For clarity, Oppose full and template, support others. * Pppery * _{it has begun...} 02:09, 5 June 2019 (UTC)[reply]

• Oppose for full and template only, support others. The full protection and template protection locks look too much like the interface-protected lock vs. under this proposal. We should not be making the locks look identical in the name of branding. —pythoncoder (talk | contribs) 18:10, 1 June 2019 (UTC)[reply]
• Support these minor changes. I find myself agreeing with User:Ajpolino: There's no obvious harm, and you think it's helpful, so let's do it. WhatamIdoing (talk) 05:35, 3 June 2019 (UTC)[reply]
• Ambivalent support. Minor changes which don't do any harm (though I can't say any good they do either). – Ammarpad (talk) 05:54, 4 June 2019 (UTC)[reply]
• I don't feel strongly either way. —TheDJ (talk • contribs) 07:12, 4 June 2019 (UTC)[reply]
• Oppose full per User:pythoncoder, indifferent/support the rest. – John M Wolfson (talk • contribs) 00:09, 5 June 2019 (UTC)[reply]
• Oppose the Yellow 30 for full prot, the golden lock just looks better to me and yellow30 seems to "brown", from the reference palette, Yellow 50 seems to bright as well. — xaosflux ^Talk 03:41, 5 June 2019 (UTC)[reply]
• Comment What about changing the full protection shackle to be more like the one used at Commons and other wikis, for the sake of consistency? funplussmart (talk) 19:27, 10 June 2019 (UTC)[reply]
  • Comment On "other wiki", the symbols are chosen because a letter won't make sense. Viztor (talk) 00:56, 14 June 2019 (UTC)[reply]
• Oppose for full and template only, support others per pythoncoder.--
  here 17:22, 12 June 2019 (UTC)[reply
  ]

• Moved back from archive for closing. Ladsgroup^overleg 22:55, 9 July 2019 (UTC)[reply]

---

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.

Remove "suspected perpetrator" field in Template:Infobox civilian attack

(Discussion moved from

U-Mos (talk) 03:28, 22 March 2019 (UTC)[reply

]

(Comment copied from original discussion) I concur. There's no reason for this parameter to exist – when the identity is known and certain, the appropriate parameter is "perpetrator", and when it is not, it doesn't belong in the infobox at all to begin with. TompaDompa (talk) 08:17, 22 March 2019 (UTC)[reply]

• I agree. This gets into NOTNEWS territory. We have to be aware that a reported “suspect” can be falsely accused (for example: the reports that Richard Jewell was a suspect in the bombing that took place during the Atlanta olympics). At a minimum, we need to wait until a “suspect” is actually charged with the crime before we report names. Blueboar (talk) 12:59, 22 March 2019 (UTC)[reply]
• I also agree. If suspects are to be named in the article then we can word things to make it clear that they are only suspects, and to say whether they have been charged or prosecuted, but an infobox entry is too blunt an instrument for such sensitive content.
  Phil Bridger (talk) 13:33, 22 March 2019 (UTC)[reply
  ]
• The idea makes sense, but I know from how less experienced editors see infobox fields and if you took out the suspected perp field, they will want to fill the name in on the actual perp field because they feel it would complete the infobox (unaware of the implications of this towards BLPCRIME). --Masem (t) 13:36, 22 March 2019 (UTC)[reply]
  • Well, that gets us into the murkier question of what fields should be included in an infobox in the first place. Perhaps we shouldn’t even have a “perpetrator” field. Indeed, when it comes to this sort of topic, we probably need to question whether an infobox is aporopriate at all. Is an infobox an appropriate method for conveying information in an article about a mass killing? Blueboar (talk) 13:55, 22 March 2019 (UTC)[reply]
    • Arguably yes, it just shouldn't be filled in until after conviction. (Contrast that to a religon= field in the BLP infobox ) Its that well-intentioned editors unaware of why the field is blank will think to fix it blindly. --Masem (t) 14:09, 22 March 2019 (UTC)[reply]
      • Deprecate |perpetrator= and add |convicted_perpetrator=. --Izno (talk) 14:15, 22 March 2019 (UTC)[reply]
        • That would of course mean that when the perpetrator dies and there is no trial, there is nowhere to add them. Which is not necessarily a bad thing. TompaDompa (talk) 17:28, 22 March 2019 (UTC)[reply]
          • I think we should find a way to identify the perpetrator in some such cases, for example if there is a mass shooting that ends with the perpetrator killing himself (it's nearly always a "him"). The best way to deal with this whole issue would be for Wikipedia to stop trying to be a news service and only to have articles about events when good secondary sources (which breaking news reports are not) exist, but people putting forward that point of view always seem to get shouted down by people saying, "of course it's notable, it's front-page headlines in all the newspapers."
            Phil Bridger (talk) 17:50, 22 March 2019 (UTC)[reply
            ]
            • +1. Never lose the dream, even if forced to drop the stick. ―Mandruss ☎ 21:56, 22 March 2019 (UTC)[reply]
          • And in cases where the perpetrator dies and there is no trial I believe that there's a difference between jurisdictions. In some places an inquest into the death of a victim will name in its verdict the person who caused the death, and in others it will not.
            Phil Bridger (talk) 17:54, 22 March 2019 (UTC)[reply
            ]

I support changing "perpetrator" to "convicted" - feels more appropriate for factual record rather than mere description of an event, and hypothetically if there was an appeal in process or new doubts over a historical case it wouldn't invite any unnecessary infobox changes.

U-Mos (talk) 06:23, 23 March 2019 (UTC)[reply

]

Changing Wikipedia's infoboxes because some politicians want to play damnatio memoriae is not a good idea. Offering a choice of a "convicted" field per

WP:WELLKNOWN) Wnt (talk) 07:42, 23 March 2019 (UTC)[reply

]

I don't see how describing suspected perpetrators in the infobox, where the room for nuance is scant to none, would be helpful. In prose is a different matter. TompaDompa (talk) 10:34, 23 March 2019 (UTC)[reply]

Why not? There are a lot of cases where the perpetrator is known beyond reasonable doubt but will never be convicted. Judicial sentences are not the only reliable source of information. On contrary there are cases where the person convicted is known not to be the perpetrator! Would not it be helpful to describe convicted but not guilty persons in the inforbox where the room for nuance is scant to none helpful? You seem to put to much trust in formal convictions. In addition, what is conviction? There is no clear definition of this term. Ruslik_Zero 08:45, 24 March 2019 (UTC)[reply]

That a convicted person may not be the perpetrator seems a very good reason for the change to me. Having the field as "convicted" removes any form of supposition, leaving any nuances or complications to the prose where they can be outlined in all necessary detail.

U-Mos (talk) 08:53, 24 March 2019 (UTC)[reply

]

This is incredibly poor reason. 90% people do not read beyond the infobox. Ruslik_Zero 13:47, 27 March 2019 (UTC)[reply]

• Convicted is not quite the right answer. If the perp dies he is not convicted. If he confesses or brags/claims responsibility we can name without conviction. I'd venture that at least half the places this box would be used never see a conviction. Legacypac (talk) 09:28, 24 March 2019 (UTC)[reply]
  • Why's that an issue? If they die, and are therefore not convicted, do they need to be in an infobox?
    U-Mos (talk) 23:05, 25 March 2019 (UTC)[reply
    ]
    • Yes, they need to be in the infobox because this is important information. Ruslik_Zero 13:47, 27 March 2019 (UTC)[reply]
      • +1 to LegacyPac's point about conviction being the wrong standard for this, with suicide bombings and most unprosecuted war crimes being two obvious cases where the perpetrator is known with certainty but there is no judicial process confirming guilt.--Carwil (talk) 17:15, 1 April 2019 (UTC)[reply]
• Creating an additional template for suspects and one for perpetrators would remove all the confusion. ^{~^\}\_\.rTG'{~ 23:35, 25 March 2019 (UTC)[reply]
• Oppose. In some cases it is appropriate for us to name the perpetrator prior to his conviction (e.g. when extremely widely reported in highly public events, or when the suspect evaded capture and trial (which in many places can't be done in absentia) - but it known with a high degree of certainty). In other cases - e.g. historic cases, events in warfare, etc - while we might not have a definite perpetrator it might still be appropriate to name in the infobox those covered extensively in RSes. Icewhiz (talk) 11:45, 2 April 2019 (UTC)[reply]
• The template should first be merged into {{Infobox event}}; then the parameters should be rationalised. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:40, 2 April 2019 (UTC)[reply]

Note: This proposal was restored from the archive for the purpose of consensus being assessed and the discussion closed. TompaDompa (talk) 22:31, 18 May 2019 (UTC)[reply]

• Not sure if this means it's still open for votes, but if so support per
  WP:NOTNEWS, etc. Any time it's actually warranted can be covered in article prose. – John M Wolfson (talk • contribs) 23:35, 18 May 2019 (UTC)[reply
  ]

Proposal for a new file naming criteria: harmonize extension name

Hi. I recently came across some oddly named files, and it prompted me to do some digging. Below is a table of the number of images hosted locally on enwiki by file extension in the name:

jpg Extension Count .jpg 586975 .JPG 39738 .jpeg 20617 .JPEG 309 .Jpg 62 .Jpeg 16 .jPG 1 .JPeG 1 .JpG 1

png Extension Count .png 167198 .PNG 9677 .PnG 1 .pNG 1 .Png 1

svg Extension Count .svg 25507 .SVG 13

gif Extension Count .gif 21548 .GIF 749

tif Extension Count .tif 596 .tiff 402 .TIF 17

ogg Extension Count .ogg 9294 .OGG 24 .oga 1

Other Extension Count .pdf 476 .mid 146 .ogv 91 .bmp 65 .webp 48 .webm 40 .wav 31 .mp3 19 .xcf 15 .opus 9 .MID 7 .flac 2 .pov 1

You can see, for example, that

WP:FMV/W

:

• Harmonize file extension format names to ease their usage

With the following extension name formats prefered: .jpg, .png, .svg, .gif, .tif, and .ogg. This is not a proposal to prefer a specific formatfile type over another, but rather to standardize the suffixes for files already of the same format. --DannyS712 (talk) 23:10, 29 May 2019 (UTC) (clarified 10:15, 27 June 2019 (UTC))[reply]

Survey (file format names)

• Support new criteria as proposer --DannyS712 (talk) 23:12, 29 May 2019 (UTC)[reply]
• Meh for most feel free to clean up the obvious ones with very low populations, but I really don't care to see 40,000 files renamed from JPG to jpg for example. — xaosflux ^Talk 23:40, 29 May 2019 (UTC)[reply]
• Oppose First, please establish a need for the change - for instance, does a variant extension mean that a file becomes undisplayable? Second, you say "harmonize file extension format names to ease their usage" - in what way would usage be eased? Third, this is unenforceable, since there are far more images hosted at Commons than here on English Wikipedia, and we cannot make a decision here that would change policy on Commons. --Redrose64 🌹 (talk) 10:15, 30 May 2019 (UTC)[reply]
• No thank you. I can appreciate the desire to keep things tidy and organized, and I give the OP credit for doing the research and crunching the numbers. But if the name/extension of a file isn't impeding its use in any way (and I don't see how it can be), then this is a make-work project that will annoy all the thousands of users who uploaded images to Enwiki with the "wrong" file extension without any improvement to the file, to its use in articles, to its usability. More importantly, the overwhelming number of files used on English Wikipedia are hosted on Wikimedia Commons, which does not have such criteria for files. In other words, there are still going to be tens to hundreds of thousands of images that *still* have the "wrong" file extension. It's not possible to enforce consistency on this. Risker (talk) 16:46, 30 May 2019 (UTC)[reply]
• Support - making the format names consistent will help in some situations where users might "fix" image files without realizing that the formats are case sensitive (because of course they are...), and as Danny says might also help users find files in some situations. There really is no down side to this. The "mark-work" is not placed on anyone, as I'm pretty sure Danny, as a person that helps out with bot requests, will do this themselves, and users should feel no more annoyed by this, as they would if an article or template was moved. Also, specifically, I'd hate to see files like "pNG" in a FA. Now that's annoying. --Gonnym (talk) 17:18, 30 May 2019 (UTC)[reply]
• Oppose per Redrose's comment about the proposed change not syncing with Commons and Risker's comment about make-work that annoys thousands. It was interesting to see the data about enwiki though, so thank you for posting them. Killiondude (talk) 19:34, 2 June 2019 (UTC)[reply]
• Oppose per Redrose and Risker. Thryduulf (talk) 17:43, 3 June 2019 (UTC)[reply]
• I see no good reason for this honestly... Maybe the mixed case versions would be acceptable to me, but the rest... It's just not an issue i regularly see people struggle with. —TheDJ (talk • contribs) 07:17, 4 June 2019 (UTC)[reply]
• Support basically per Gonnym. I see this as basically like an MOS-type thing. The source (the user who uploaded the file) may do things however they want in their personal usage, but Wikipedia will harmonize usage for itself. --Khajidha (talk) 22:10, 7 June 2019 (UTC)[reply]
• Oppose per Redrose and Risker.--
  here 17:24, 12 June 2019 (UTC)[reply
  ]
• Support. Having spent a considerable amount of time on the related project of moving non-descriptive TLA-titles for Commons files to names descriptive of the file contents, it was surprising and unpleasant the degree to which file names for completely unrelated things could be identical but for capitalization of the filename extension. It is not technically difficult to make every filename unique irrespective of this capitalization, and we should do it. bd2412 T 02:07, 17 June 2019 (UTC)[reply]
• Weak Support - having been tripped up many times by suffix variations, and resolved several troubleshooting requests by new users who couldn't get an image to display (for this reason), I would appreciate this. That said, I think all of those cases I've been involved with were on Commons, not here. It would be ideal for this to happen there, too, but I just don't see any downside here. Assuming Danny is willing to tackle the particulars, I see no reason to get in the way. I don't really see "annoyance" as a reason not to do this, either. Anyone dedicated enough to their watchlist to care about such a thing should know how to hide bot edits. — Rhododendrites ^talk \\ 18:00, 23 June 2019 (UTC)[reply]
• Support, but
  b} 21:35, 29 June 2019 (UTC)[reply
  ]
• Meh per Risker. Solution looking for a problem. Kudpung กุดผึ้ง (talk) 23:29, 10 July 2019 (UTC)[reply]

Discussion (file format names)

Notified: Wikipedia talk:File names, Wikipedia talk:File mover DannyS712 (talk) 23:12, 29 May 2019 (UTC)[reply]

• See also: c:Commons:Village pump/Proposals/Archive/2018/12#Normalize file extensions for new uploads
• @Redrose64: file extensions are case sensitive - for the 749 .gif files that are named as .GIF, users must remember to capitalize the file extension. The data above only deals with files that are hosted locally, and it would be easier to use local files if extension names were consistent. --DannyS712 (talk) 16:10, 30 May 2019 (UTC)[reply]
  • I'm having a hard time wrapping my head around this explanation. Do people *really* enter the entire file name by hand including extension when searching for/inserting a file? They don't use the search function? They don't copy/paste the file name? Risker (talk) 16:39, 30 May 2019 (UTC)[reply]

    I do, and others probably do so too, or even if they don't it would be easier to do so if extensions were standard --DannyS712 (talk) 16:41, 30 May 2019 (UTC)[reply]

    I don't see how this would make copying and pasting any easier or harder than it is with inconsistent names.

    Phil Bridger (talk) 18:04, 30 May 2019 (UTC)[reply

    ]

    File extensions are case sensitive on Wikipedia and some operating systems like Unix. But on Windows-type setups, they are case-insensitive. If you use a Windows application like

    MS Paint to create an image, then when you come to save the file for the first time you get a dialog box which includes a selection for the file type. The selection that you make will set the file extension, and it's always uppercase (you can use Explorer or similar to rename the file with a lowercase extension later on, and it won't make any difference as far as Windows is concerned - but not all users will bother to do that). Who are we to say that lowercase is the only correct form? Do Unix browsers reject uppercase file extensions? --Redrose64 🌹 (talk) 22:18, 30 May 2019 (UTC)[reply

    ]

    @Redrose64: I don't use a unix system, and I am explicitly not saying that lowercase only is the correct form. All I suggest is that the extension formats be consistent. This should make absolutely no difference to users (such as yourself) that copy-and-paste the file name, but for users that want to type the file name, it should be consistent. If (not a part of this proposal) a bot were to execute the file moves, meaning that there wouldn't be any extra work for users, what downsides would you see from harmonizing the formats? I understand where the differences come from (thanks for that explanation by the way) but that doesn't mean that they should be kept. --DannyS712 (talk) 07:20, 17 June 2019 (UTC)[reply]

• I really don't see any value to this proposal, other than making things look tidy, which, if you looked at my desk, you would see is not something that I rate highly, so it would be better if people spent their time on doing something that actually improves the encyclopedia rather than on such make-work projects.
  Phil Bridger (talk) 18:04, 30 May 2019 (UTC)[reply
  ]

Moving the file to the consistent file names could be automated by a bot (leaving a redirect), except if the filename is already in use. --Chanc20190325 (talk) 18:05, 1 June 2019 (UTC)[reply]

But why do it? What benefit does this bring to Wikipedia, especially when most of the files we use are are hosted at Commons?

Phil Bridger (talk) 18:48, 1 June 2019 (UTC)[reply

]

To clarify: the above data is for images that are hosted here on enwiki. I've added the data for commons below. --DannyS712 (talk) 06:03, 3 June 2019 (UTC)[reply]

Commons data

jpg Extension Count .jpg 38954436 .JPG 7115025 .jpeg 722895 .JPEG 7176 .Jpeg 961 .Jpg 583 .jPG 47 .JPg 24 .jpG 15 .JPeG 7 .jPeG 7 .JpEg 5 .JpG 3 .jPg 2 png Extension Count .png 2473405 .PNG 125542 .Png 34 .pnG 2 svg Extension Count .svg 1493642 .SVG 507 .Svg 4 gif Extension Count .gif 167101 .GIF 5515 .Gif 16 .gIF 1 tif Extension Count .tif 1110594 .tiff 200199 .TIF 3357 .TIFF 16 ogg Extension Count .ogg 919282 .oga 7166 .OGG 312 .Ogg 15 pdf Extension Count .pdf 443407 .PDF 867 .Pdf 1 webm Extension Count .webm 71003 .WebM 36 .WEBM 4 .Webm 1 djvu Extension Count .djvu 108225 .Djvu 2 .DJVU 1 wav Extension Count .wav 127401 .WAV 26 ogv Extension Count .ogv 69589 .OGV 15 mid Extension Count .mid 5056 .MID 314 Other Extension Count .flac 15305 .mp3 8571 .xcf 1283 .stl 1022 .webp 670 .opus 661

• See also a related discussion - Wikipedia:Village pump (proposals)/Archive 74#Several changes to file naming --DannyS712 (talk) 10:59, 10 June 2019 (UTC)[reply]

RfC: Deprecate webcitation.org aka WebCite

This RfC is to allow editors and archive bots the voluntarily leeway to stop using webcitation.org and replace existing webcitation.org URLs with other archive providers where available. To begin divesting from WebCite. 14:49, 13 June 2019 (UTC)

Background:

• Approximately 5% of Enwiki archive URLs are to webcitation.org, 5% to archive.today, 2% to "others" (Library of Congress, etc), and 88% to archive.org - in raw numbers there are about 5 million archive links of which about 250,000 to are to webcitation.org
• webcitation.org is unreliable. Talk:WebCite#Service_outages lists known outages and there have been others. Outages can last for days and weeks.
• WebCite is a non-profit and almost shut down in 2013 due to lack of funding. The site has not changed since - documents, features, bugs etc.. no evident development of the service or changes to the website in years. Bug reports go unanswered and unresolved. It appears to be the work of Gunther Eysenbach and not a full-time occupation.
• WebCite is one of the oldest archiving services. It was unique for archiving on-demand vs. automated crawling. On-demand archiving is now available at Wayback, Archive.today etc.. a standard feature at most archive services. There is nothing that sets WebCite apart that other archives can not do, and do better.
• WebCite uses a system of accepting archive requests, returning an archive URL, backgrounding the job then emailing if the archive was successful or not. Often users submit a job and get the URL and paste it into Wikipedia without waiting to see if the archive request was successful. As a result:
• WebCite has the highest rate of archive link rot. My bot
  WaybackMedic
  monitors archive links and WebCite is the leader in terms of raw numbers of links that need replacing with other archives, despite only representing 5% of the total archives.

Proposal:

• Archive diversity is important.
  WP:WEBARCHIVES
  lists about 20 archive providers currently in-use on Enwiki. Plus, not every archive has every page, some will have a page that others do not (eg. archive.org does not have everything). In the end it is up to users which archive provider they choose.
• This RfC would demonstrate a general best practice of avoiding and/or changing WebCite URLs to other archive providers. Deprecate does not ban the site or make a hard red-line rule. It would give users and bots some leeway to begin changing URLs and point to this RfC as a rationale. It would change the documentation to encourage users to use a different provider. Users who still wish to maintain a WebCite URL can add {{cbignore}} to keep bots away and act as a notice to maintain the URL. If WebCite is the only source for an archive it should obviously be kept and not converted into a {{dead link}}. -- GreenC 14:49, 13 June 2019 (UTC)[reply]

New Developments (July 10, 2019):

• Webcite is now back online. What happened this time is unknown.
• They are not accepting new pages to be saved.
• As the RfC nominator I should disclose that I am now a Paid Editor of Internet Archive, which happened recently after the RfC. More information at User:GreenC/Paid editor. I am not paid expressly for this project or RfC but I guess anything is related. This RfC was initiated on my own volition, was not requested by anyone nor is it connected to why I became a paid editor. A 5 week outage with no communication from WebCite, and the long history of outages, is why.
• Bots started replacing dead WebCite links abut that has stopped since they are online. -- GreenC 17:13, 10 July 2019 (UTC)[reply]

Survey (deprecate WebCite)

• Support per above and survey bump. -- GreenC 14:49, 13 June 2019 (UTC)[reply]
• Support I used to use WebCite but Wayback does everything it did, and better.-- Pawnkingthree (talk) 16:34, 13 June 2019 (UTC)[reply]
• Support per the above. Kudos to the initiator for one of the best written proposals I've seen on Wikipedia. Thryduulf (talk) 21:43, 15 June 2019 (UTC)[reply]
• Support. It's clearly beneficial both to readers and editors to prefer archive sites which are more stable and actively maintained, if they are equivalently archiving the content. Alsee (talk) 06:06, 16 June 2019 (UTC)[reply]
• Support It is out of service again and is unreliable due to its outages. The archive for links that are dead needs to be reliable. Ahmad^Talk 16:29, 16 June 2019 (UTC)[reply]
• Support its better to use a archive website which is more reliably up, so that our readers can nearly all of the time see the archived source. I agree that outright banning of WebCite is a bad idea, as diversity in archive websites is a good thing, but conversion to Wayback is something which (unless WebCite becomes more reliable) needs to be done. Dreamy Jazz 🎷 ^{talk to me | my contributions} 21:16, 18 June 2019 (UTC)[reply]
• Support - per above. ___CAPTAIN MEDUSAtalk 17:58, 19 June 2019 (UTC)[reply]
• Oppose for the reasons I wrote below. All of the arguments given here are why other archivers are better than WebCite. They aren't reasons why WebCite is useless or detrimental except insofar as there is a better alternative. My position is that the best solution would be making it so that we can use multiple archivers. Redundancy. A citation has a WebCite archive? Add one for archive.org and archive.to. There are problems with all of them. That's not to say that the others aren't overall better, but that it doesn't need to be a choice. If we can use multiple, nothing is gained by removing WebCite. — Rhododendrites ^talk \\ 05:16, 20 June 2019 (UTC)[reply]
• Support; at the very least, using WebCite to save pages that are currently live should be discouraged since better options are clearly available. Jc86035 (talk) 10:48, 20 June 2019 (UTC)[reply]
• Support - Seems like a reasonable proposal. Editors can continue to use "WebCite" if they wish, it just wont be via bot. - Knowledgekid87 (talk) 16:25, 20 June 2019 (UTC)[reply]
• Support - There are no indications that the situation with WebCite will improve in the future; instead, it is reasonable to expect further deterioration. — kashmīrī ^TALK 09:54, 22 June 2019 (UTC)[reply]
• Support - I think that WebCite has to be given full credit (with citations :)) for (apparently) being a pioneer in on-demand URL archiving. I'm not sure how to do that, apart from solidifying its
  WP:BIAS.] Boud (talk) 16:43, 22 June 2019 (UTC)[reply
  ]
• Support per above.--
  here 05:50, 27 June 2019 (UTC)[reply
  ]
• Support per above. Johnbod (talk) 00:38, 2 July 2019 (UTC)[reply]
• Support no downside, lots of positives.
  b} 01:05, 3 July 2019 (UTC)[reply
  ]
• Support with certain qualifications. In software development, 'deprecated' usually means the use of the feature is discouraged and it will most likely be removed in a future version. I think it should just be discouraged indefinitely, or until the service becomes trustworthy again (or completely dysfunctional). And I think it should be acceptable to use WebCite as a secondary archive, as a backup. Archive services go down or become untrustworthy. If Wikipedia is supposed to exist indefinitely then using just one archive service for a source is probably not a good idea.
  Template:Web cite only supports one archive link at the moment, but Template:Webarchive supports several (Thanks to User:GreenC for pointing that out). Cite-web should probably be expanded to allow multiple archive links. Bots should only add archives, not remove or replace archive links unless they are dead. Hecato (talk) 15:44, 10 July 2019 (UTC)[reply
  ]

Discussion (deprecate WebCite)

• Comment Could we have a list of the other web archiving sites available? Personally, I am only aware of https://archive.is/ In my experience it's not true that they all do everything. Some may capture greater depth in terms of links off the selected url which may be necessary for context. They also don't all capture the same content, for instance, webcite captures pdfs, unlike archive.org. Philafrenzy (talk) 22:00, 13 June 2019 (UTC)[reply]
  • Wikipedia:List of web archives on Wikipedia Graeme Bartlett (talk) 23:16, 13 June 2019 (UTC)[reply]

    Thanks, the number on that list allowing on-demand archiving, which is what we are principally concerned with here, is small is it not? Philafrenzy (talk) 01:13, 14 June 2019 (UTC)[reply]

  • Archive.org captures PDF so does archive.today (ie. archive.is) and most of the others. This RfC concerns webcitation.org which does not work at all. Like, right now. It is a dead site, forcing 250,000 links on Enwiki offline. For about a week and counting. This is not the first or even fifth time. It is unadvised to use it if other equally good options are available. -- GreenC 00:42, 14 June 2019 (UTC)[reply]
• @
  WP:RFCBRIEF (sentence beginning "If the RfC statement is too long"), please provide a brief and neutral opening statement. --Redrose64 🌹 (talk) 22:12, 13 June 2019 (UTC)[reply
  ]

  User:Redrose64: This RfC is to allow editors and archive bots the voluntarily leeway to stop using webcitation.org and replace existing webcitation.org URLs with other archive providers where available. To begin divesting from WebCite.

  -- GreenC 00:31, 14 June 2019 (UTC)[reply]

  OK, after JJMC89 (talk · contribs) did this, the effect is this. --Redrose64 🌹 (talk) 15:57, 14 June 2019 (UTC)[reply]

• Is there a reason that we shouldn't add the website to the blacklist at this time? Replacement first? --Izno (talk) 00:31, 14 June 2019 (UTC)[reply]

  (moved from survey section). There are times it is the only archive provider for a given page, it is worth keeping in the toolchest, for now, but make it a last resort and begin the process of moving away where possible. -- GreenC 00:51, 14 June 2019 (UTC)[reply]

  • Also, adding to the blacklist can have the effect of making it difficult to edit any article that includes a link to this site. Risker (talk) 21:54, 15 June 2019 (UTC)[reply]

• Comment WebCite has one very important feature: it allows you to request archiving a page, and returns an archive URL. To the extent I know, archive.org does not have an on-demand archiving feature (and I'm not sure if any of the other alternatives have this feature either). In light of this, I don't think banning WebCite is a great idea. huji—TALK 18:49, 16 June 2019 (UTC)[reply]
  • @Huji: archive.org does have an on-demand archiving feature (go to https://archive.org/web/ and use the "save page now" option in the bottom right). Archive.is (AKA archive.today) also does archiving on demand (from the main page of that site). I'll do them for this page immediately after this comment and add the links in my next edit. Thryduulf (talk) 23:30, 16 June 2019 (UTC)[reply]
    • links: Archive.org Archive.today. Thryduulf (talk) 23:32, 16 June 2019 (UTC)[reply]
      • @Thryduulf: sorry, I meant to say that it does not have an "automatable" way of requesting pages. For instance, on fawiki we are currently using the webcitation Python library in this Pywikibot script to archive all links on pages that are being promoted to GA or FA (so that future readers of our "best" articles will have a way to access their references in the future). This cannot be done robotically using Archive.org because (to my knowledge) it does not have an API for requesting page archives. huji—TALK 23:37, 16 June 2019 (UTC)[reply]
        • user:InternetArchiveBot has options that I think might be what you are looking for (submitting live links to the internet archive), Cyberpower678 is the person to ask about that I believe. [1] also seems to suggest APIs are available. Thryduulf (talk) 00:22, 17 June 2019 (UTC)[reply]

          Thryduulf, Yes. IABot has authorized access to the advanced SPN2 APIs. Regular users have open access to the SPN APIs. archive.org allows for automated archiving of weblinks. Also archive.org already does this for all 900 WMF wikis. —CYBERPOWER (Chat) 00:29, 17 June 2019 (UTC)[reply]

• Comment - It seems like the best approach would be to allow use of as many of the archives as possible, no? Archive.to has its own problems, after all (previously blacklisted, with multiple RfCs ending in its allowed use, preferred by some users while avoided by others, etc.). Wouldn't discrete parameters and redundant archives be the surest bet against linkrot? — Rhododendrites ^talk \\ 19:41, 16 June 2019 (UTC)[reply]

@Rhododendrites: (moved from the survey to discussion section). Yes the RFC proposal says exactly this, you can use WebCite, if you want. But there are good reasons to deprecate. Deprecate does not mean "you must not use" or blacklist, it means archive of last resort and default switch to others when possible. It isn't about picking favorites, I really do wish WebCite were available and reliable. -- GreenC 01:37, 17 June 2019 (UTC)[reply]

Aside: not sure why, but this didn't generate a notification for some reason? Yes the RFC proposal says exactly this ?? I said we should allow use of as many archives as possible. This is a proposal to not use a particular archive. Regardless of whether it's a suggestion or a hard rule, all of the reasons are predicated on the idea that we shouldn't use it because others are better. I say we shouldn't have to choose one over another. The best solution is finding a way to take advantage of all of them. WebCite may not be as good as another service, but WebCite and that other service is better than either one. If you see a WebCite citation, supplement it with an archive.to and/or archive.org; none of these are reasons to replace. — Rhododendrites ^talk \\ 05:10, 20 June 2019 (UTC)[reply]

@Rhododendrites: WebCite is offline. http://webcitation.org is dead. Maybe they will come back? These extended outages are not new, though I've never seen it go this long. The outages are getting longer, more frequent, the site is not maintained or updated.. no updates or news on Twitter or anywhere about what is happening. Emails to the owner go unanswered (as always). So I'm confused why you said "all of the reasons are predicated on the idea that we shouldn't use it because others are better". Unless by better you mean "not dead". -- GreenC 16:07, 20 June 2019 (UTC)[reply]

@Rhododendrites: It seems to me you're making a proposal for a modification of Wikipedia:Citation templates: allow the use of multiple archival parameters, e.g. archive1url, archive1date, archive2url, archive2date, ... The more critical a Wikipedian thinks that the reference is, the stronger his/her motivation to list at least two archived copies of the reference. A maximum number of archives should probably be set - 2 or 3? By default, the second and subsequent archivenurls would be hidden or semi-hidden from the reader; if the archive is long-term dead, then a bot could easily swap between them. A simpler possibility could be to add a dead-archive1url, dead-archive2url, ... parameter, similar to the present dead-url=yes|no. This proposal might let robots add new archive1urls while converting existing Webcite archiveurls to archive2urls with dead-archive2url=yes, rather than deleting the webcite urls. This would be useful for cases where Webcite has a good quality copy (in terms of avoiding javascript rubbish, zillions of external scripts, and so on) but the other archiver doesn't. Boud (talk) 16:28, 22 June 2019 (UTC)[reply]

This already exists with {{webarchive}} which supports up to 10 archive URLs and was made for this purpose.

{{cite web |url=http://example.com |title=Example website |archiveurl=http://web.archive.org/web/20190101000000/http://example.com |archivedate=2019-01-01}} {{webarchive |format=addlarchives |url=http://archive.today/20190609163259/http://example.com/ |date=2019-06-09 |url2=https://wayback.archive-it.org/all/20190621232545/http://example.com/ |date2=2019-06-21}}

Produces:

"Example website". Archived from the original on 2019-01-01. Additional archives: 2019-06-09, 2019-06-21.

To be honest though few people use it, and not many people add archives at all much less worry about redundancy. I wouldn't worry too much about it, bots can replace dead archive URLs with other archive URLs. My bot could fix the WebCite problem in a couple weeks if needed and so can IABot. We have bots for this. The only question is how many of these URLs are unique to WebCite that no other archive provider has, thus are irreplaceable. This is an open question that will be answered once the bots start replacing URLs. -- GreenC 16:57, 22 June 2019 (UTC)[reply]

Thanks for sharing this. First time I've seen {{webarchive}}. I think it would be better built into the citation templates, but that the functionality exists is good to know. I do still feel like we (or maybe just I) don't have the sufficient information to write off WebCite for good. Unless we know it's gone forever, if it's the lone archive of a page, a temporary broken link seems preferable to none. If it's not the lone archive, it would be just as easy to supplement it with another archive as it would be to replace it. — Rhododendrites ^talk \\ 18:05, 23 June 2019 (UTC)[reply]

It's nice to know this already exists. I don't expect that I'll be paranoid enough to use it often - it's enough work to add a single archive for each reference. But we'll see: I wasn't paranoid enough to expect webcite to have such a long down time... Boud (talk) 00:56, 24 June 2019 (UTC)[reply]

Support with amendment "Archive diversity is important..." agreed. We should avoid discouraging people from using WebCite, while archiving content with other services. Other services could go down as well. The most important reason to continue archiving pages with WebCite is addressed in the article on this service: "WebCite checks robots.txt only at the time of archiving, Internet Archive checks robots.txt occasionally, so changes in robots.txt (which can be caused by a change in the ownership of the domain name) can result in removing the cached pages from the Internet Archive." Otherwise the new owner of a URL could destroy all record of the publisher who owned the URL before by using robots.txt.--Truthtests (talk) 22:19, 9 July 2019 (UTC)[reply]

That robots.txt information is outdated. Internet Archive largely ignores robots.txt in part for the reason you describe. More information at Wayback Machine. -- GreenC 22:48, 9 July 2019 (UTC)[reply]

Manual of Style for fictional characters?

Hello. Back in 2012, we discussed a possible MoS proposal on fictional characters at

WP:MOSANIME as a reference. A few months ago, I also proposed and withdrew an RFC here. Long story short, one of these suggestions is to propose some sort of manual of style for the fictional characters. I'm planning to open a centralized discussion to see how we can manage a MoS regarding all fictional characters (i.e. Video games, anime, novels, TV series, films, etc.). Thoughts? Lord Sjones23 (talk - contributions) 22:46, 18 June 2019 (UTC)[reply

]

• Support. This is de facto already part of the
  click me!) 23:41, 10 July 2019 (UTC)[reply
  ]
• I also support this. We as an encyclopedia need to be serious about SPAM as there are huge financial incentives for people to use us in ways counter to our mission. As Kudpung points out having skilled editors make this determination while still giving time for notable content to actually be improved strikes me as a win. It also seems like this might be easier for some people if G13 were a PROD rather than a speedy but that's a different discussion for a different day. Best, Barkeep49 (talk) 23:57, 10 July 2019 (UTC)[reply]
  • I want to point out that the standard for accepting at AfC is that thearticle will probably pass an AfD.Articles that are only somewhat promotional will generally pass AfD if the subject is more than borderline notable. (It's been a major accomplishment in the last year or 2 that the ones that are borderline promotional nd borderline notable generally do not get kept--a few years ago the argument that even the borderline ones should stay and be improved in mainspace was generally accepted, and it sitll sometimes is, because AfD is by its nature inconsistent. So if we move to afc, and then they get accepted by a reviewer, who thinks they will pass, many possibly most, of them will be kept, with the cost of everyone involved doing a great deal work both at afc and afd with nothing to show for it. Remeber that anyone may assign a coii or advertising tag, whheher legitimately or illegitimately, and it is actually posssible that about 1/3 actually do deserve to stay in mainspace and be improved. DGG ( talk ) 14:09, 12 July 2019 (UTC)[reply]

D.

• Semi-Opposed. This is just tossing a problem over the wall. Draft space is already flooded with junk, and the folks who work there are
  WP:AfD. -- RoySmith (talk) 14:36, 12 July 2019 (UTC)[reply
  ]
• Oppose - This is a bit more than tossing the problem over a wall, it is tossing a problem into a dumpster hidden over the wall. Articles are unlikely to be improved in Draft space. When they don't get improved, they get G13 deleted after 6 months. If we want to delete these, let's delete them. Feel free to convince me otherwise but passing them through draft space is just an alternate and inappropriate delete path. ~Kvng (talk) 15:30, 12 July 2019 (UTC)[reply]
• Comment - I have another active concern about over-the-wall uses of Draft space. See Wikipedia_talk:New_pages_patrol/Reviewers#WP:NPPDRAFT_vs._AfC_acceptance_criteria. ~Kvng (talk) 15:41, 12 July 2019 (UTC)[reply]
• Oppose per Kvng.
  WP:STUBIFY). This proposal would open the door to so much abuse because it will, as Espresso Addict rightly puts it, basically mean that they will be G13ed when nobody fixes them, which is likely most of the time, especially those articles that have been in the mainspace for years and whose creators have long left. Last but not least, it's easy to forget the reader's best interest. Someone looking about information about a subject is better served by a shoddy article than by no article at all and if interested at all, might actually use this opportunity to fix some problems they perceive. Many editors got their start by noticing something wrong or missing and fixing or adding it. We should encourage these readers to become editors and that requires keeping sub-par articles in mainspace where people can actually find them. My first attempts (back in the good old days of 15 years ago) were clumsy additions of new articles on books I liked but had no article and fixing typos and suchlike, stuff I couldn't have done if there hadn't been imperfect articles to fix. Regards SoWhy 16:38, 12 July 2019 (UTC)[reply
  ]

(and similarly for other languages' Wikipedias). Ross Finlayson (talk) 05:22, 29 June 2019 (UTC)[reply]

No. That's just superfluous. All Wikipedia logos are already localized to the language of the wiki. If you go to the French Wikipedia https://fr.wikipedia.org, the logo reads in French Wikipédia, L'encyclopédie libre, the text is not even in English so it borders impossibility to be confused on which language domain one is unless you don't understand the language. Localization is more than any translation to tell you now you're on a xxx-language Wikipedia. You know it by mere seeing if you understand the language. The same thing goes for all other language versions. See m:Wikipedia logo in each language. – Ammarpad (talk) 05:57, 29 June 2019 (UTC)[reply]

I think you misunderstood what I said; please read it again. I never said that a user is confused about which language 'their' Wikipedia (i.e., the one that they're taken to, based on their computer's language preference) uses. What I said is that users are often confused about the fact that there are multiple Wikipedias (for multiple languages). Noting each Wikipedia's language prominently near the top of the page would help do this. There might be better solutions, though. Ross Finlayson (talk) 06:34, 29 June 2019 (UTC)[reply]

I don't know if it is often but it definitively happens. Gråbergs Gråa Sång (talk) 10:36, 29 June 2019 (UTC)[reply]

• If we had a tag saying "Wikipedia - the Free English language encyclopedia that any one can edit" - would there not be a danger that this might make some readers think that Wikipedia is only available in English? Vorbee (talk) 14:49, 29 June 2019 (UTC)[reply]

Perhaps the tag should say: “Wikipedia(En) - one of several Wikipedia brand encyclopedias - that anyone can edit.” Blueboar (talk) 15:26, 29 June 2019 (UTC)[reply]

• Wrong venue - As noted above, this is the English Wikipedia, and as such, any discussions here have absolutely zero influence over how any other Wikimedia project chooses to self-identify. The place to discuss this is at Meta (either meta:Requests for comment or meta:General requests, not sure which). --Redrose64 🌹 (talk) 17:08, 29 June 2019 (UTC)[reply]
• Just concentrating in the English Wikipedia, which we can influence even though the WMF has made it clear that this is only influence and not power, how about just having a link in the left side panel to
  Phil Bridger (talk) 17:40, 29 June 2019 (UTC)[reply
  ]
• Wrong venue and even if it weren't this is like changing a chandelier in a condemned house as long as the T&S controversy rages. —A little blue Bori v^_^v ^Bori! 18:21, 29 June 2019 (UTC)[reply]
• Question - "When users navigate to Wikipedia, they automatically go to the Wikipedia for the particular language that their computer is configured for" When I navigate to Wikipedia itself (rather than an article from an external search engine), in the sense that I would if I didn't get how the language prefix worked (i.e. wikipedia.org (or even .com), the page is a search page that presents some of the most popular languages around the logo, with the number of articles on each. Is there some sort of place where navigating to Wikipedia in that manner redirects you based on computer (or browser) language, or are you speaking of searching a topic in a specific language in a search engine? - Purplewowies (talk) 22:14, 6 July 2019 (UTC)[reply]

  With one exception, all links to Wikipedia pages (whether internal wikilinks or URLs from outside) are language specific; for instance, the URL for this page is https://en.wikipedia.org/wiki/Wikipedia:Village_pump_(proposals) - the language code is the en after the first two slashes. The one exception is the URL https://www.wikipedia.org/ which is the "official" front page for the entire Wikipedia; that offers various means of proceeding further, but all of them require the user to choose a language to continue in. --Redrose64 🌹 (talk) 23:24, 6 July 2019 (UTC)[reply]

  Yeah, I understand the language code thing; it just seemed like the OP was saying if you went directly to Wikipedia and your OS language was English (and if you don't already know about different languages of Wikipedia, I feel like you'd be likely to go to www.wikipedia instead of (for example) enwiki if you were going straight to Wikipedia and not Googling), then you'd be redirected to enwiki and never see the no-language-code front page, which doesn't make sense (at least to me), and that page at least gives you an inkling there are multiple projects, regardless of what you search or where you go from there. 0_o The assertion just confused me is all because it sounded like it was talking about something in a way that it wasn't a thing. - Purplewowies (talk) 04:06, 7 July 2019 (UTC)[reply]

Are you curious about what tools are effective in reaching Women in Red’s goals? Are you interested in contributing to the building of scalable solutions for closing Wikipedia’s gender gap?

I’m with a group of researchers working on using Artificial Intelligence (AI) tools to promote gender diversity in Wikipedia contents and thus to close the gender gap. We want to make sure you, as an important member of the community, can be heard as we build and refine these AIs.

We would like to invite you to a quick interview to share your thoughts about gender gaps on Wikipedia and the current efforts, as well as potential solutions to them. It would only take about 30 minutes over phone or video chat. We will send you a $15 Amazon gift card as a way to thank you for your time.

For more details about our project, please refer to our Wikipedia page here.

If you decide to participate, your opinion could help build the future of Wikipedia. Hope to talk to you soon! Reply to this message here or send me an email at [email protected] and I can share more info and plan a time to connect. Bobo.03 (talk) 19:36, 3 July 2019 (UTC)[reply]

The best approach for Wikipedia in this area, is to adopt a gender-blind practice. Editors shouldn't be identified as male or female. GoodDay (talk) 16:28, 6 July 2019 (UTC)[reply]

That is a terrible approach. — The Hand That Feeds You:^Bite 21:43, 6 July 2019 (UTC)[reply]

Not to mention it's already a thing. You don't have to bring up your gender or lack thereof unless you wish to. Heck, I'm a woman and while I mention it offhand sometimes, on the software end I'm gender-neutral in my preferences. I think gender-blind is a bad idea because it doesn't necessarily address actual issues that might be causing a gender gap in Wikipedia's editors (that have potential solutions on Wikipedia's end, anyway). (Maybe for other reasons too.) But I feel like I don't have any ideas I could put into words that are applicable to this issue on Wikipedia in terms of helping alleviate it, myself. - Purplewowies (talk) 22:08, 6 July 2019 (UTC)[reply]

• @Bobo.03: Is there no way of participating in text (e-mail or talk page)? I'd be interested in participating but don't use telephone or video chat. Espresso Addict (talk) 07:23, 7 July 2019 (UTC)[reply]
• What gap are you referring to? The alleged gap among editors or among articles? Or both? Are you not starting from a dubious premise, ie: that there is a noteworthy gap and that, if so, it can be fixed? All this said, I echo Espresso Addict re: the means of communication. - Sitush (talk) 07:33, 7 July 2019 (UTC) To clarify: research that has a predetermined goal of improving representation of alleged marginalised groups but which uses a method that excludes people with low bandwidth and/or hearing disabilities seems somewhat hypocritical. - Sitush (talk) 07:58, 7 July 2019 (UTC)[reply]

Hi, @Espresso Addict: @Sitush:, yes, guess we can do it through user talk page if live audio chat is impossible for you, though it’s always the best to chat alive, so that we can ask followup conversations and have a more involved chat. I’ve left a message on your talk page. Looking forward to hear back from you. Thanks!

We refer to the content gender gap (e.g., gaps among articles, etc). We are working on this project with the goal of helping close the gap and we’d hope it would work. Bobo.03 (talk) 03:36, 8 July 2019 (UTC)[reply]

@

second wave of feminism, the Caroline Herschels

are the exception rather than the rule. The gap should be commensurate with the biases of history.

A wording/mentality that will help you win support is language that recognizes this and wants to bring the gap to what it should be given the history of the world. Reducing the gap is good. Achieving parity (fully-closed gap) is, in many fields, impossible and undesirable. If, in the 1970s, biology had a 60% men/40% women breakdown, then biographies from the 1970s should have a rough aim of having a 60%/40% breakdown, although that has to be adjusted in light of bias against women. Many will have been prevented from having career that are as prolific as men, due to a variety of reasons, and that will skew the notability curve towards men more, so maybe the end result should be 70%/30% instead of 60%/%40. Likewise, if in the 2010s the breakdown is now 20%-80% due to a shift in who studies biology, the result should be around 20%-80% before adjusting for source/productivity bias.

b} 04:00, 8 July 2019 (UTC)[reply

]

Using live audio chat means you have chosen a tool that will obviously attract a very biased sample of editors. Not a wise approach when your goal is to reduce bias in another area. HiLo48 (talk) 03:46, 8 July 2019 (UTC)[reply]

Thanks for your message, Bobo.03. Editors here are very used to communicating via the medium of talk pages, and it's easy to ask any follow-on/clarification questions as necessary. Espresso Addict (talk) 03:51, 8 July 2019 (UTC)[reply]

The requirements for

My proposal is straightforward: mention accessibility as a requirement under the "well written" section of

• Could you clarify what changes would be made to ensure "accessibility" is met? The word covers a potentially huge area, and I'd like to know what would be required. Adding a request for "accessibility" isn't as crystal clear as you may think! - SchroCat (talk) 09:20, 4 July 2019 (UTC)[reply]
• That sounds like something that's easier to say but harder to define: how would you define a more accessible FA in one word? ——SerialNumber54129 09:22, 4 July 2019 (UTC)[reply]
• Phil Bridger (talk) 09:33, 4 July 2019 (UTC)[reply
  ]

I was indeed not referring to that kind of accessibility, I'm referring to making articles as easy to read as possible while still including complex topics.

As to the wording, I now see that it would have to be defined more clearly than I stated it originally. The sixth requirement

WP:FA?

we could add: "b. Accessible: The article can be understood by a broad audience and explains technical terms in the article itself."

I'm not sure if the wording should differ between FA and GA, but I tried writing it such a way that the FA requirement for accessibility is "stricter" than the one for GA, although I recognize I might not have done a great job at that. The specific wording is tentative and open for input.--Megaman en m (talk) 09:48, 4 July 2019 (UTC)[reply]

Rather than try to add further rules onto an already rule-laden process without an indication of the problems, could you find some examples of FAs and GAs you see as problematic? Thanks - SchroCat (talk) 10:02, 4 July 2019 (UTC)[reply]

My proposal isn't intended to expose problematic GA or FA articles, rather it is aiming to rectify internal inconsistency between requirements and offer clarity to reviewers and nominators. I could find various instances of terms in GA or FA articles not being adequately described to a lay audience, such as "accusative morphosyntactic alignment" in

WP:B?, but that would not be the right way to go in my opinion.--Megaman en m (talk) 10:41, 4 July 2019 (UTC)[reply

]

One example I can think of is

WP:AUDIENCE, which says, among other things, Make your article accessible and understandable for as many readers as possible., which I think is exactly what Megaman en m is talking about. I'm not trying to shame this specific article or say it shouldn't have been promoted to FA, but I do think that providing context to the (non-expert) reader is still an area where this article could improve, and I like the idea of it being an explicit part of the FA/GA criteria (even if it's only briefly mentioned). Colin M (talk) 16:47, 5 July 2019 (UTC)[reply

]

I think your first step - if you want to pursue this further - is finding another term. For Wikipedia, accessibility is defined as linked above. You want something different, so for clarity that then needs another name. --Gerda Arendt (talk) 12:03, 4 July 2019 (UTC)[reply]

Accessibility would be the usual term for what I'm talking about, but if a paraphrase is needed, maybe just say that the article has to be "understandable"? That's the term used in the

essay on the perfect article describing the same concept.--Megaman en m (talk) 12:44, 4 July 2019 (UTC)[reply

]

If it's "understandability", then FAs should already be compliant - having at least five reviewers per article (normally from non-specialists, unconnected wth the subject matter) means that should be the case already. - SchroCat (talk) 12:51, 4 July 2019 (UTC)[reply]

Understandable is what is used by the relevant guideline, Wikipedia:Make technical articles understandable, and yeah, people are going to be confused if you use the word "accessibility" so I would recommend "understandability". Galobtter (pingó mió) 13:11, 4 July 2019 (UTC)[reply]

That's an interesting way of looking at it, I haven't considered that. But this still leaves GA "vulnerable" to the understandability issue, as the single reviewer is usually familiar with the general subject and might not consider the viewpoint of a layperson. For example, the reviewer of a video game article nominated for GA might not stop to think that a layperson might not know what experience points actually do.--Megaman en m (talk) 13:00, 4 July 2019 (UTC)[reply]

I don't believe that "The article can be understood by a broad audience" is always possible, so your proposal would exclude (from FA at least) some topics from being covered at all. For instance, an article I've worked on that is currently rated as B-class, Dehn invariant, has a lead that I hope can be read by mathematically-inclined high school students, but some later content (particularly "Realizability") that might well be difficult for undergraduate mathematics majors. That is not because of any intention to make the article difficult, but rather because after making it as easy to access as I could it was still difficult; it is a technical subject and some technicality is unavoidable. Should such articles be automatically barred from being at a higher class? Should there be no incentive to work towards making such articles better, because it cannot be rewarded with a higher class? —David Eppstein (talk) 18:47, 4 July 2019 (UTC)[reply]

I agree with

Phil Bridger (talk) 19:14, 4 July 2019 (UTC)[reply

]

It is of course the case that any article should be able to attain FA status, in principle. Some topics reasonably require some preexisting knowledge for the more basic concepts; if we had to explain every single piece of jargon in an advanced article about genetics, the article would become unmanageably long-winded. My proposal is that a serious attempt is made to avoid these technicalities or explain them when possible (e.g. when it can be adequately explained in a sentence or two). If the concept needs to be mentioned, is complex, and can't be explained shortly, then a simple wikilink is all we can do.

For example, a language article should not explain what a noun or tense is. But, when it comes to terms like "accusative morphosyntactic alignment" mentioned above, even someone with a introductory knowledge in linguistics might be left scratching their head. I recognize that it might be difficult sometimes to determine what a "basic" concept is versus a more advanced one, but that alone shouldn't be a reason to can the proposed understandability requirement. As a side-note, more complex concepts should preferably be mentioned near the end of the article; the introduction should

ease people into the topic at hand, not scare them away.--Megaman en m (talk) 19:18, 4 July 2019 (UTC)[reply

]

Yes, "can be understood by a broad audience" might be too strong a requirement. But

WP:B? uses the wording The article presents its content in an appropriately understandable way. It expands on that by saying It is written with as broad an audience in mind as possible. Although Wikipedia is more than just a general encyclopedia, the article should not assume unnecessary technical background and technical terms should be explained or avoided where possible.. I think wording along these lines would address your concern, and not automatically exclude any articles about technical subjects out of the gate. For a highly technical subject "as broad an audience as possible" might actually be pretty narrow, and should be considered in light of the set of readers who are likely to actually reach the page. Someone with only a very basic math education is unlikely to reach Dehn invariant, so their ability to comprehend the article's content shouldn't be a strong consideration. Colin M (talk) 17:17, 5 July 2019 (UTC)[reply

]

I might call it "readability". But I think at least most regular FAC nominators at least hope that reviewers will help out on this. I know as a lawyer I have a tendency to use jargon in my field. That has sometimes led to reviewers going "huh?" I'd like to say "we're already doing this" but I'm waiting really for actual examples in recent FAs.--Wehwalt (talk) 23:47, 4 July 2019 (UTC)[reply]

Readability is the closest thing I could think of, where there is a score generated on a readability scale. Alanscottwalker (talk) 00:00, 5 July 2019 (UTC)[reply]

Readability is a related – and useful – concept, but it's not what I'm talking about exactly. Readability would readily fall under the current "well-written" requirements.

Responding to Wehwalt: Someone pointed out that the fact that FA requires multiple reviewers who are usually not knowledgeable; this sort of fixes the understandability problem nicely. However the problem still remains for GA articles, due to the fact that it only require single reviewer who usually is knowledgeable about the subject. I would also like the requirements for all the classes to be internally consistent. By that I mean that a lower class shouldn't have a requirement lacking in higher classes (I'm talking about the 6th requirement in

WP:B?

.

Long story short: I now think that the understandability requirement is not practically necessary for FA class. However, for reasons of consistency and the reviewing process, GA would still benefit from this requirement for the reasons mentioned above.--Megaman en m (talk) 07:47, 5 July 2019 (UTC)[reply]

The B-class criteria "presents its content in an appropriately understandable way" and that "it is written with as broad an audience in mind as possible." are reasonably practicable and reasonably clear in intent. How they would be interpreted in any specific case will depend on the topic. Is there any reason to assume that B-class criteria no longer apply when an article is proposed for GA and FA? Feedback on what is appropriate and possible should come from someone who has the background necessary for the target audience. This is usually a person who is not already an expert, but in many cases must have some existing understanding of the broader level of the topic. When there is uncertainty or disagreement among reviewers, it could be useful to first come to some agreement on who is the target. The proposer should have a reasonably good idea of this, and should be able to explain why. · · · Peter Southwood ^(talk): 08:23, 5 July 2019 (UTC)[reply]

Because B-class doesn't require peer review, there is a good chance some B-class articles don't fully comply with the B-class requirements. GA is where, for the first time, the adherence to the requirements get scrutinized by an impartial reviewer. Therefore, it should at least contain all the requirements from lower classes, including understandability. The average (knowledgeable) GA reviewer will focus on more on the listed requirements, especially prose, grammar and sourcing. Understandability might fall through the cracks and be "re-discovered" during a potential FA nomination.--Megaman en m (talk) 08:39, 5 July 2019 (UTC)[reply]

• Whole-heartedly support this. This is already a factor I consider when doing GA reviews (and I imagine many others do too, even if subconsciously). You could argue that this already exists in the
  WP:AUDIENCE, which expands on why and how to make an article "accessible and understandable for as many readers as possible". Colin M (talk) 16:57, 5 July 2019 (UTC)[reply
  ]

So do most people agree that the sixth requirement of

GA requirements? It doesn't have to have its own section.--Megaman en m (talk) 06:34, 6 July 2019 (UTC)[reply

]

• I certainly agree that an article that could practically be written in such a way that a broad audience could understand it, but is not, should not be FA and perhaps not GA. My concern is, who exactly is judging the extent to which it can be written non-technically?
  Aside: This is a perennial problem with the {{technical}} template. Very frequently it is added to articles with no indication of how understandability could be improved, or even where the article fails to be as understandable as possible. The simplest explanation seems to be that the tagging editors don't understand the material themselves, and for that reason suppose that there is something wrong with the exposition, which may or may not be true but which they are not equipped to judge.
  So either you give non-technical reviewers veto power over promotion of technical articles, or you ask them to simply trust the judgment of experts that the material is presented as clearly as possible. I can't say that either of those options is especially attractive. --Trovatore (talk) 08:06, 6 July 2019 (UTC)[reply]
• I'm leaning oppose on this proposal given
  FACR
  could be interpreted to already imply an accessibility requirement:

its prose is engaging... (from 1a)

it neglects no major facts or details and places the subject in context (from 1b)

(Emphasis mine on both)

If the prose is engaging, it engages a general audience, which would imply that a general audience could understand it. If the subject is placed in context, then a person sufficiently aware of the context from the article could then understand the details.

Having said all of that, I would not vociferously oppose the proposal if the consensus evolved to overwhelmingly favor it. – John M Wolfson (talk • contribs) 05:31, 7 July 2019 (UTC)[reply]

@

unnecessary detail" can run into similar problems. In short: I believe that any potential downsides are outweighed by the upsides of having both the reviewer and nominator keep the broadest audience possible in mind.--Megaman en m (talk) 07:46, 7 July 2019 (UTC)[reply

]

@Megaman en m: Well, I guess that answers part of my concern, but the deeper issue here is, how is a reviewer, not having the background needed to understand the topic of the article, expected to judge whether it is written appropriately for the intended audience? Can we specify that such a reviewer is expected to ask for expert help on such matters? --Trovatore (talk) 22:21, 10 July 2019 (UTC)[reply]

@

WP:B?. I find technical papers on linguistics engaging, but I wouldn't have a non-expert read them. They also place the subject in the right context, although they usually do so by introducing even more jargon. An understandability requirement is not currently covered by other FA/GA requirement and would help people in the reviewing process focus on the important task of keeping the intended audience in mind.--Megaman en m (talk) 07:46, 7 July 2019 (UTC)[reply

]

@Megaman en m:, that does somewhat assuage my fears of writeability for niche topics. As for placement in the right context with linguistics (basic grammar, etc.), I guess that's what internal links are for. – John M Wolfson (talk • contribs) 07:52, 7 July 2019 (UTC)[reply]

@John M Wolfson: Internal links are useful, but they should primarily be for people wanting to read more about that topic rather than "required reading material". They should only be relied upon as a last resort.--Megaman en m (talk) 08:08, 7 July 2019 (UTC)[reply]

It all depends. There are what I call "101 articles" (from the classic designation for basic university courses in the US) that should not assume much knowledge. Then there are "202" articles that have "prerequisites" when it comes to knowledge and may have to rely on links for basic concepts, and possibly higher numbers as we get more specialized. Some articles are hybrid, an article on a ship may be "101" when it comes to its history but "202" or more when it comes to the ship's specifications and equipment. While we don't have as much information on reader reaction as I would like (I supported the old feedback tool), FA nominators and reviewers have seen a lot of talk page comments, reactions on TFA day and other people's reviews, and do a good job in gearing things properly. I'm just not certain what we are supposed to do differently.--Wehwalt (talk) 11:01, 7 July 2019 (UTC)[reply]

I think most editors instinctively understand that a GA should of course also satisfy the general

The last point, which Megaman en m has discovered, is because GA1b doesn't require full MOS-compliance but only certain sections, not including

Another thing one might add to the GA criteria, and which might actually be enough on its own: Normally a GA should should satisfy the B-class criteria of the appropriate WikiProject(s). But this should be clearly marked as something GA reviewers don't have to check. It would be significant extra effort and could have unwanted effects where WikiProjects have strange ideas about B-class criteria (e.g.: may only use

To move this discussion forward, I started a voting process.--Megaman en m (talk) 10:30, 8 July 2019 (UTC)[reply]

Can the lack of opposition be taken that most people are okay with this proposal?--Megaman en m (talk) 19:19, 14 July 2019 (UTC)[reply]

No. (See also

WP:POLSILENCE

.)

As for me, I'm not necessarily opposed, but I don't feel my concerns have been adequately addressed. --Trovatore (talk) 19:41, 14 July 2019 (UTC)[reply]

I don't think you've made your case about FA, and from the comments, I didn't see much of an attempt to have a change to WP:WIAFA. I don't have an opinion on GA.- (Wehwalt) -19:44, 14 July 2019 (UTC)

The problem

Proposal: Incorporate the 6th requirement of

Why?: "Understandability" is very important, yet it is not specifically required for FA or GA status. This new requirement will help people in the reviewing process keep the average reader. This will also improve consistency between the classes.--Megaman en m (talk) 10:30, 8 July 2019 (UTC)[reply]

Vote

• Support (as proposer) With GA usually being the first time that an article undergoes peer review, the reviewer should pay just as much focus on understandability as grammar and sourcing. The FA review technically fixes this problem by having multiple reviewers act as they lay audience reading it for the first time, therefore "correcting" it for understandability. The single reviewer for GA is usually knowledgeable about the subject, which could cause them to overestimate the background knowledge of the average reader. I still believe that understandability deserves a mention in FA, even if just for the sake of internal consistency between classes.--Megaman en m (talk) 10:30, 8 July 2019 (UTC)[reply]
• Support for the reasons I wrote above. I think the most unobtrusive way to do this would be to add a few words to
  WP:AUDIENCE. A whole new subcriterion of 1 (i.e. 1c) would also be fine, though that would require some template changes. Colin M (talk) 22:09, 8 July 2019 (UTC)[reply
  ]
• Pending. I could support this if it were clarified that understandability is relative to the inherent difficulty of the material, and that reviewers without the background needed to understand the material should ask for expert help in evaluating this criterion. ---Trovatore (talk) 20:00, 14 July 2019 (UTC)[reply]

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. This page has been added to the following lists: Wikipedia proposals Wikipedia technical issues and templates When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.

Should we add a "Create an article" button/link in the interface/sidebars?

which 'tab' you would land on would depend on your

!Vote (old proposal, withdrawn)

!Vote (new proposal)

• Support as proposer. I agree directing people to AFC directly isn't ideal, so instead I propose we direct them to a landing page explaining how to get involved in Wikipedia.
  b} 19:20, 7 July 2019 (UTC)[reply
  ]
• Oppose Neutral If anything, we should be taking steps to make it harder for brand-new editors to create articles. I spend a fair amount of my reviewing copyright reports, and the number are by brand-new editors attempting to create a brand-new article, largely by copying and pasting some reliable (or not so reliable) source.--S Philbrick(Talk) 19:18, 7 July 2019 (UTC)[reply]

@

b} 19:24, 7 July 2019 (UTC)[reply

]

Headbomb, Thanks for the heads up. S Philbrick(Talk) 20:59, 7 July 2019 (UTC)[reply]

@

b} 21:05, 7 July 2019 (UTC)[reply

]

• Support new proposal – I think it will help those who want to create new articles more easily learn how to do it and how to do it the right way. That, in turn, would make things better at AfC and NPP. I particularly like that it can specifically cater to editors based on their experience level. – Levivich 19:45, 7 July 2019 (UTC)[reply]
• Support. My rationale for the previous proposal also applies here, with modifications. This sounds like a great idea that would help convert our readers into editors. Headbomb's tutorial is an ideal place to send new editors to, since it directs them to essential reading that helps them understand Wikipedia's conventions and expectations. Then, it encourages them to create
  VisualEditor). Since they're drafts, and not live articles, patrollers won't revert the new editors immediately after they make a mistake, which can be burdensome for patrollers and discouraging for new editors. Any outstanding issues get addressed when the editors ask for help, or are ready to submit the drafts for review. Hopefully, these zones help new editors learn the ropes at their own pace, and eventually become comfortable enough to participate in other areas of Wikipedia. — Newslinger talk 20:43, 7 July 2019 (UTC)[reply
  ]
• Support I think this is an excellent proposal. Giving new people proper direction on how to get started is a good thing. CThomas³ (talk) 21:40, 7 July 2019 (UTC)[reply]
• Support new proposal. The landing page is a good idea. Also, this process seems to be a good way to get new productive editors involved in Wikipedia. If new editors can create acceptable articles then they might have a stake in participating here. This may encourage them to participate in other areas that need editors. Also, learning how to create acceptable articles is a great way to begin learning how editing works on Wikipedia. ---Steve Quinn (talk) 06:35, 8 July 2019 (UTC)[reply]
• Support It's bizarre that the sidebar has comparatively obscure options like Create a book but doesn't have the fundamental option of creating a new article or page. I regularly create articles and do so by generating a red link and then clicking through on that – a process that is not intuitive and which would be hard to explain to a new editor. Andrew D. (talk) 08:48, 8 July 2019 (UTC)[reply]
• Support with reservations. I like the general approach but before bringing the whole thing into general use, I think it needs to be carefully tested, perhaps in conjunction with specific virtual editathons. Reactions from new users and their reviewers should be taken into account.--Ipigott (talk) 12:43, 8 July 2019 (UTC)[reply]
• Support new proposal. It will help new users to create drafts first, instead of live articles. I also like the customized landing depending on editor status. Megalibrarygirl (talk) 15:01, 8 July 2019 (UTC)[reply]
• Support Trial - like the idea and even the execution is snazzily slick. I do however think Ipigott has something on it being trialled. I'm not sure if limiting it to a virtual editathon is the only way to go, but an 8 week trial would be good - see whether hits on those pages, and page/draft creation, vary significantly. Nosebagbear (talk) 17:54, 8 July 2019 (UTC)[reply]
• Support a trial - provided some dedicated attempt is made beforehand to figure out whether WMF has something similar in the works already (as noted below). Not much point in working at cross purposes! Otherwise, this strikes me as a well-executed improvement. Some more work on the exact content will be necessary. E.g., auto-confirmed users may be more "experienced" then fresh IPs, but they still should be strongly steered towards AfC and cautioned against direct mainspace creation. Also, pointers to the Adventure sounds like a good idea. --Elmidae (talk · contribs) 19:15, 8 July 2019 (UTC)[reply]
• Support a trial - This is a much better approach. Obviously, the various texts can probably be tweaked a little, but the concept is certainly worth a try. Beyond My Ken (talk) 01:09, 9 July 2019 (UTC)[reply]
• Support for trial only. I don't think we can really know whether this will lead to an increase in articles we would want to keep, or if it will lead to an increase in junk and disappointed contributors. There's only one way to find out. But there would have to be a thorough review by the community after the trial, before anything should be implemented permanently. --Tryptofish (talk) 18:35, 9 July 2019 (UTC)[reply]
• Oppose We already have too many articles, already. Fully a third of all articles ought to be deleted. I wouldn't support anything that encourages the hoi polloi to create articles. Chris Troutman (talk) 23:28, 9 July 2019 (UTC)[reply]

• That makes sense. After all, it's not like we invite everyone to edit Wikipedia, or anything like that. As has been said numerous times in the past, everything has already been discovered anyway. Beyond My Ken (talk) 04:04, 11 July 2019 (UTC)[reply]

• Support trial only: While my general sentiment is aligned with that of Mr. Troutman (namely, we have too many articles), I can't see the harm in running a trial of this. Any further attempts to expand such a trial to the entirety of Wikipedia would depend on the data received, community sentiment and discussion, etc., etc. —Javert2113 (Siarad.|¤) 00:03, 10 July 2019 (UTC)[reply]

• BTW, even if we were to grant "we have too many articles" (which I don't), that is really not the same thing as "we don't need any more articles", is it? Beyond My Ken (talk) 04:06, 11 July 2019 (UTC)[reply]

• Support a trial for the many good reasons articulated above (and below) by Elmidae, Tryptofish, Kudpung, and others. Happy days, Lindsay^Hello 06:15, 12 July 2019 (UTC)[reply]
• Support giving it a try at the very least.
  talk) 17:26, 12 July 2019 (UTC)[reply
  ]
• Oppose I don't think that directing people to create new articles as a form of editor recruitment is a good idea. Most articles written by new editors are deleted pretty quickly as unsuitable. Sending them through AfC is better but will still result in the submission being declined, possibly repeatedly. At this point the new editor is unlikely to continue. As Wikipedia has matured its standards for articles have increased and the number of suitable topics which don't have articles has shrunk, meaning that articles from new editors are much less likely to be useful. I suspect that the main effect of this will be to push up the AfC and/or NPP backlogs rather than to recruit more editors. We would be better off directing them to improve existing articles instead. Hut 8.5 13:08, 13 July 2019 (UTC)[reply]
• Oppose as this will result in more junk to delete and therefore an increase in admin/reviewer workload (a department which is already badly understaffed). Agreed that improvements should be made to help newbies get involved, but this is not it. -FASTILY 22:40, 14 July 2019 (UTC)[reply]

Discussion (Create an article)

I just clicked through Wikipedia:Article wizard and did not see anything about notability (well, there is "For further information, please visit our guide on notability" but someone wanting to write about their garage band is not going to see that). A "create article" link is setting new editors up to fail or at least to be frustrated by waiting for the overloaded draft review. The article wizard would first need toughening up. It needs a section on notability and a section with links on asking questions. Johnuniq (talk) 04:00, 7 July 2019 (UTC)[reply]

• Please let's not channel more good-faith newbies into Articles for Creation, which is where the wizard sends people. It was never designed as a nurturing place for good-faith newbies to make their first edits. Espresso Addict (talk) 05:10, 7 July 2019 (UTC)[reply]

  AfC is a much better and user-friendly route than normal new page patrolling, as someone who patrols pages occassionally, rest assured, most of them are not treated as nice, with a "this is wrong", "this needs to be fixed", but more of a "your article is wrong in this way, and will be deleted, get it?" --qedk (t 桜 c) 05:58, 7 July 2019 (UTC)[reply]

I disagree. Sitting waiting for perhaps months until someone gives you a capsule review that takes a degree in wikispeak to unwrap, and then just says "no" in acronym speak, appears to me even worse than a swift speedy. At least the speedy route is quick, contains appeal instructions, and might just throw you in the way of a friendly admin. Espresso Addict (talk) 06:06, 7 July 2019 (UTC)[reply]

• @
  b} 05:49, 7 July 2019 (UTC)[reply
  ]

I seem to recall a long discussion involving I believe Kudpung on where to send genuine newbies in the context of mainspace creation being permanently turned off for non-autoconfirmed editors, but I don't think there is a suitable venue at present. I'd certainly support creating one but I doubt it's as easy as it sounds. Espresso Addict (talk) 05:58, 7 July 2019 (UTC)[reply]

Well, whatever is at the end of that link (

b} 06:09, 7 July 2019 (UTC)[reply

]

In my experience, this [4] is the kind of article that newbies submit on species (let alone the much more complex taxonomic entities), and that was far from the editor's first edits, and positively stellar compared with the worst I've tripped over. And with species, there's none of the problem with notability that plagues say (auto)biographies. Espresso Addict (talk) 06:22, 7 July 2019 (UTC)[reply]

• As every AfC and New Page reviewer knows - and they are the only people who have an overview of what gets created nowadays - the last thing we want to be doing is making it too easy to create more junk. There is no disputing the fact that the encyclopedia has matured since its creation. The vast majority of new articles nowadays are obscure BLP from South Asia, Bollywood, Phillipino Beauty Pageants, reality shows, one-line stubs about soccer players, newly named asteroids, and blatant corporate spam. Help should be offered immediately at the registration interface, and as far as I know, the WMF is working on a new landing page right now - a long awaited project since they originally started and disbanded it under various pretexts in 2012. Let's give it time to develop, and let's not lose the breathing space we gained with the introduction of ACPERM which we fought 7 long years for. Kudpung กุดผึ้ง (talk) 06:18, 7 July 2019 (UTC)[reply]
  • Couldn't agree more. I urge anyone about to caste a !vote here to go have a good look at the new page queue before they say anything. Article creation should be one of the last tasks new editors are guided towards, not the first. Triptothecottage (talk) 13:04, 7 July 2019 (UTC)[reply]
• Updated with just 273‎ bytes to address concerns raised in this section....Wikipedia:Article_wizard/Referencing.--Moxy 🍁 06:45, 7 July 2019 (UTC)[reply]
• The problem is that the slogan 'the encyclopedia anyone can edit' has been allowed to be interpreted too loosely. Anyone can also ride a bike or drive a car, or sail a 470, or fly a Cessna 152, it's easy enough, but there is a learning curve (that's why kids bicycles have training wheels), and the rules of the road, the sea, and the air have to be learned. A good Article Wizard can do much to help, but the whittled-down-to-nothing thing that's replaced what we had used before ACPERM was rolled out is all but useless, and that's why AfC is so backlogged. The Article Wizard should be the training wheels.Kudpung กุดผึ้ง (talk) 07:47, 7 July 2019 (UTC)[reply]
• Wikipedia Tutorial Button? - all the answers above are bang on. But how about instead of just avoiding making our job (AfC/NPP) harder, we push some more people towards a tutorial, whether WikiAdventure or otherwise? Nosebagbear (talk) 15:30, 7 July 2019 (UTC)[reply]

@

Headbomb, that I like and support... funneling the editor through the right process depending on their experience level. Nice work! (And thanks for the ping.) – Levivich 19:27, 7 July 2019 (UTC)[reply]

@

b} 19:30, 7 July 2019 (UTC)[reply

]

Exactly something like that is what the WMF is currently working on. But we all know what goes on at Phab. Perhaps Insertcleverphrasehere, the defacto coord of NPR knows, or Primefac, the de facto coord of AfC. Kudpung กุดผึ้ง (talk) 00:17, 8 July 2019 (UTC)[reply]

Other than the

WP:AFCIMPROVE discussion from May 2018, I have not heard anything about changing or updating any part of the AFC process. Primefac (talk) 01:08, 8 July 2019 (UTC)[reply

]

click me!) 05:12, 8 July 2019 (UTC)[reply

]

@Headbomb: - I'd suggest adding the Adventure for the latter 3 (I realise that like WP:CENT, it becomes less valuable the more you have). Regardless of that, looks nice (I also had no idea that you could set viewing by permission level, but obviously that makes sense because the same occurs when you hit an editing lock) Nosebagbear (talk) 11:33, 8 July 2019 (UTC)[reply]

If a topic does not meet general or subject-specific notability guides, but is noteworthy enough to be covered in some degree at another article, then it can be redirected (with or without merge) instead of being deleted. If a topic of marginal notability is covered at two or more articles and there is no clear primary redirect then this doesn't work. An "Article Interlink Page" (Ok, there is probably a better name) would allow a better and consistent handling of topics of some level of noteworthiness but limited RS coverage. It would be not entirely unlike a

• 1-2 fully-referenced sentences outlining the topic and ending in a colon
• A bulleted list of brief claims of noteworthiness, each with a bluelink where the topic is covered and an RS reference. Links to indefinitely bounded lists are not to be included (eg, a list of those holding a particular notable position is fine, while a list of people in a particular occupation is not)
• An AIP footer (different for different types of AIP) which would run something vaguely like This
  creators
  .
• Reflist
• Appropriate categories

I believe that this restricted format would:

• provide an intermediate level of inclusion between those who should have no article and those who should have a full article -- something approximating a mini Who's Who entry.
• allow a less bitey way of handling (particularly) a bunch of biographical articles of marginal notability without opening the floodgates for definite non-notables
• be resistant to promotionalism
• simplify some decisions at
  WP:NPP
• reduce some of the inflows into AFD and provide
  an alternative to deletion
  for some of those which do make it there.
• be better than a bunch of scattered redlinks (possibly with inconsistent naming)
• be searchable/categorisable (and probably highlightable in article text with script)
• be potentially bot-identifiable where restrictions are not met (>2 sentences in intro, bullet without reference, bullet without bluelink, bluelink without mention, link to indefinite list, ...). Removal of the AIP template should triggers NPP as conversion of a redirect does.
• provide some guiderails for editors who wish to expand the topic

Ultimately, having the AIP might also allow us to escape the currently useful trap of presumed notability for new articles of sportspeople (as well as others such as bishops) who have limited independent and significant biographical coverage immediately available, but who would generally appear at multiple articles. They could instead be given an AIP with links to their coverage at seasonal articles (diocesanal articles, etc) until sources are actually found. ^~Hydronium^~Hydroxide^~(Talk)~ 10:46, 7 July 2019 (UTC)[reply]

Often a topic can be shoehorned into a location article. Eg a school, or a shopping centre could be covered in that geographic location. I am not very convinced by the set index for a non-notable topic. It would be better to redirect and then link from the section to other relevant sections. Can you think where this is needed? One example could be the location of some crime that is newsworthy enough to make a location article, and the business could be part of a chain. But it is probably "undue detail". Graeme Bartlett (talk) 12:11, 7 July 2019 (UTC)[reply]

@Graeme Bartlett: Some examples of the type of thing where I see an AIP as a useful option would be:

• Musical groups with multiple bluelinked members (potentially meeting NBAND#6) but not sigcov
• Musicians with extemely limited RS biographical coverage who appeared in multiple bluelinked bands (potentially meeting NBAND#6)
• Creators with limited public profile who don't meet WP:CREATIVE but with multiple works that would meet NBOOK, NFILM, etc due to a marginal level of critical coverage.
• Minor actors with multiple film/tv feature roles and basically no RS bio coverage
• Winners of bluelinked pageants with limited coverage who subsequently went on to a further bluelinked pageant
• Companies with limited coverage but multiple notable products
• Unsuccessful party political candidates with some level of coverage at multiple bluelinked elections

^~Hydronium^~Hydroxide^~(Talk)~ 13:27, 7 July 2019 (UTC)[reply]

I think it could be case where

WP:XY applies. Emir of Wikipedia (talk) 21:26, 7 July 2019 (UTC)[reply

]

• Oppose this idea. I believe there is value in in-prose redlinks because they encourage eventual article creation (even if that means waiting until the subject's notability can be demonstrated). I also think creating an additional set of pages that are exempt from
  WP:N is a bad idea. UnitedStatesian (talk) 21:32, 10 July 2019 (UTC)[reply
  ]
• I don't think this is a bad idea. In a way, that's almost what already happens if the subject's name is ambiguous: there'll be a dab page and the relevant entry there is sort of a mini version of what an interlink page would look like. – Uanfala (talk) 17:08, 14 July 2019 (UTC)[reply]

I suggest we create a hidden category, something like Category:Pages which will not work if moved, mostly to be populated by those templates which, well, will not work if the page is moved, as they use {{PAGENAME}} in a non-trivial manner. The only ones I'm sure of are the year articles, using (directly or indirectly) {{Year in various calendars}}, but I'm sure other projects than WikiProject Years have templates which will cause trouble.

I suppose {{DISPLAYNAME}} (although not exactly a template) may also require work, but that should be a bit obvious if the mover actually looks at the page before moving it. — Arthur Rubin (talk) 18:59, 8 July 2019 (UTC)[reply]

It's always good to identify a problem before proffering a solution. Apart from the pages using {{Year in various calendars}} (which we know for sure they're not going to be renamed overnight without discussion) what other set of articles fall into this description? – Ammarpad (talk) 09:05, 9 July 2019 (UTC)[reply]

I don't know of any other systematic problems, but I've been active in WikiProject Years for some time. I suppose a database search for templates using {{PAGENAME}} might be productive, although I noticed that there are some templates which used to use {{PAGENAME}} which now use LUA modules. There are definitely some categories which use {{PAGENAME}} to locate their primary article as displayed, so that if either the article or the category is moved, the category text will be wrong. — Arthur Rubin (talk) 08:40, 10 July 2019 (UTC)[reply]

If we take the example you gave of {{

911 (year). If the code is set up to only look for numbers and unless the words "BC" and "AD" are changed, I don't see how anything should break with a page move from "911 (year)" to "911" or from "AD 1" to "1 (year)" (or even from "911 (year)" to "911 (best year ever)"). Before tagging pages with "will break if moved" its a better idea to first see if the design is set up correctly. --Gonnym (talk) 09:01, 10 July 2019 (UTC)[reply

]

Minceraft is Minecraft easter egg. Please create easter egg section in Minecraft article and redirect Minceraft there.

09:14, 10 July 2019 (UTC)

Discuss at

WP:SIGNATURE.) — Arthur Rubin (talk) 10:05, 10 July 2019 (UTC)[reply

]

Yep, go for it. ——SerialNumber54129 10:12, 11 July 2019 (UTC)[reply]

I cannot, as I am not an iadmin and cannot find it on the Wikidata page (I guess I should clarify this was brought here because it would be a site-wide change). Unless I'm just confused?

talk) 10:29, 11 July 2019 (UTC)[reply

]

Did you know why most of the templates are protected? It's because they're high risk. To prevent vandalism, we should do this. Is that okay? 114.124.165.28 (talk) 09:16, 12 July 2019 (UTC)[reply]

This is already done where appropriate; see User:MusikBot II/TemplateProtector. Protecting each and every template by default is probably overkill. -- zzuuzz ^(talk) 09:44, 12 July 2019 (UTC)[reply]

I think the current password policy isn't that effective for some reason. There are still compromised accounts that are trying to edit the Main Page. I think we need a new password policy for these users.

The new policy is:

• at least ten characters including at least a capital AND a lowercase letter
• at least a number and a symbol
• shouldn't be in the fifty most common passwords

Thanks 114.124.165.28 (talk) 09:34, 12 July 2019 (UTC)[reply]

See

2FA. -- zzuuzz ^(talk) 09:41, 12 July 2019 (UTC)[reply

]

Enforcing what appears in a password is known to negatively impact recall of the password, and That Leads To Re-use. However, two of your requirements are already met; see link above. --Izno (talk) 14:01, 12 July 2019 (UTC)[reply]

I think the meta password policy is sufficient for advanced users without specifying which character components are necessary. — xaosflux ^Talk 13:24, 14 July 2019 (UTC)[reply]

I'd personally like to see an optional 2nd factor introduced into the login process ... or is that, in fact, already available? --User:Ceyockey (talk to me) 02:32, 15 July 2019 (UTC)[reply]

Help:2FA. — JJMC89 (T·C) 03:52, 15 July 2019 (UTC)[reply

]

Since disambiguation pages are not considered encyclopedic, why are they in the main space? Has it been previously discussed to have a Disambiguation namespace so that the article count (currently standing at 5,887,631) would be more representative of actual encyclopedic articles? Banana Republic (talk) 02:14, 15 July 2019 (UTC)[reply]

• @Banana Republic: This topic has appeared in the context of other conversations a few times, but there is only one conversation I can find (quickly) which is dedicated to it—Wikipedia:Village_pump_(technical)/Archive_33#Disambiguation:_namespace. This conversation is negative on the idea and presents some arguments. Personally, I think that disambiguation could, in the long term, be folded into Wikidata functionality, with the concomittent elimination of DAB pages and replacing with a search facet which draws on dab-data, but that's not something close to being discussed at present as far as I know. --User:Ceyockey (talk to me) 02:30, 15 July 2019 (UTC)[reply]

That was a rather short discussion, and it appears that it contained a basic fallacy. One user wrote "Disambiguation pages are still articles". Perhaps they were considered articles in 2008 when the discussion took place, but they are not considered articles today by Wikipedia:Disambiguation which states that "Disambiguation pages are not articles and so should not be tagged as orphans". It therefore seems that if they are not considered articles, they should not be in the article namespace. Banana Republic (talk) 02:43, 15 July 2019 (UTC)[reply]

There are lots of things in the mainspace that are not articles. Like redirects, (some) lists, etc. Killiondude (talk) 02:48, 15 July 2019 (UTC)[reply]

Per this link, redirects are not counted in the article count.

Per Wikipedia:Manual of Style/Lists, lists are considered as list articles.

This means that if disambiguation pages were to be put into their own namespace, the article count would reflect the number of articles plus 1 (the main page, which is not considered an article). Banana Republic (talk) 02:59, 15 July 2019 (UTC)[reply]

I was making the point that some lists are akin to disambiguation pages in that they are nothing but links. Killiondude (talk) 03:02, 15 July 2019 (UTC)[reply]

Lists are different from disambiguation pages, and serve a different purpose. Banana Republic (talk) 03:04, 15 July 2019 (UTC)[reply]

According to Template:Disambiguation, there are approximately 190,000 disambiguation pages on Wikipedia (that incorporate the template). This is approximately 3% of the 5.89 million pages that are counted as articles. I think it would be good idea to have those 190,000 articles removed from the article count, and have a more meaningful article count. Banana Republic (talk) 03:16, 15 July 2019 (UTC)[reply]

Where would the links point, then? What would be at those titles? If an editor makes a link to Seal or Pop or Frank Smith, or a reader searches for that term, would the link point to a redirect to this new space? There isn't an article that could remotely be considered the primary topic for any of those terms. bd2412 T 03:54, 15 July 2019 (UTC)[reply]

Per

WP:INTDABLINK, "Links to disambiguation pages from mainspace are typically errors". Therefore, with perhaps a few exceptions that I cannot think of, there should not be any links to disambiguation pages from within the mainspace articles. Banana Republic (talk) 04:07, 15 July 2019 (UTC)[reply

]

I am fairly certain that pages which include <code>__DISAMBIG__</code> are not included in article totals. --Izno (talk) 04:26, 15 July 2019 (UTC)[reply]

Nope, I'm wrong. Interesting. Maybe that should be a request in for the devs. --Izno (talk) 04:27, 15 July 2019 (UTC)[reply]

I would think that developers would want to see a consensus before considering implementing such a change. Banana Republic (talk) 05:38, 15 July 2019 (UTC)[reply]

As pages change whether they are disambiguation pages or not (when we decide what is or what is not the primary topic), the sharp distinction of an extra namespace does not look like a good idea to me. Having Mercury redirect to Disambiguation:Mercury also does not look like an improvement. The main advantage of the proposed change seems to be that it might make it easier for our article count to be more accurate, but that is hopeless anyway, with sub-articles and with lists split into several articles because they are too long otherwise. Whether we overestimate the "correct number" by 3%, 5% or 10% (or underestimate it because of merges that really are covering separate topics) isn't relevant unless we pretend the "article count" actually means anything at all other than "Wikipedia is really big, and still growing". And we shouldn't pretend it means any more than that. —Kusma (t·c) 09:01, 15 July 2019 (UTC)[reply]

Such a move would be a case of the article count tail wagging the encyclopedia dog. We are here primarily to build an encyclopedia, not to worry about things like article count, so any decision should be made on the basis of what makes for a better encyclopedia. People are free to count articles in any way they want without the encyclopedia being disrupted for the sake of counting them.

Phil Bridger (talk) 09:21, 15 July 2019 (UTC)[reply

]

Article count is only one issue. The bigger issue is to drive home the point made in WP:Disambiguation that Disambiguation pages are not articles. Nothing makes the point more clear than to put them in their own namespace. Banana Republic (talk) 12:43, 15 July 2019 (UTC)[reply]

So you propose spending hundreds of hours of editor and developer time on driving hime a point made by a throwaway remark about whether certain pages should be tagged as orphans, without presenting any evidence that confusion over this point has caused the slightest of problems? I won't be commenting any further here, because I have better things to do with my time than discussing pointless proposals.

Phil Bridger (talk) 14:03, 15 July 2019 (UTC)[reply

]

Yes, the transition would indeed require some effort, but I think it is an effort worth exerting. I think it is worthwhile to keep things clean and keep non-articles out of the article namespace. Banana Republic (talk) 14:29, 15 July 2019 (UTC)[reply]

Disambiguation are IMHO a reading aid to help readers find the article they really want to read. A service to readers. To hide them, is not helpful at all. The Banner talk 13:09, 15 July 2019 (UTC)[reply]

The proposal would not make disambiguation pages hidden. It would only make hat notes that currently point to disambiguation pages such as George Washington (disambiguation) point to Disambigution:George Washington instead. Banana Republic (talk)

And it would make lots of pages become redirects to the disambiguation namespace. Someone who wants a working copy of the encyclopaedia would need to copy not just the article, but also the disambiguation namespace. Your fallacy is to assume that only "articles" can be in the article namespace. Many lists and outlines are not proper "articles" either, nor is the Main Page. (Moving the Main page to a different namespace, say, portal or Wikipedia, is a proposal I would support, though). —Kusma (t·c) 13:29, 15 July 2019 (UTC)[reply]

Your fallacy is to assume that only "articles" can be in the article namespace. Huh???? That's a fallacy?

Many lists and outlines are not proper "articles" either. I don't know what you mean by "outlines" (perhaps you meant "stubs"?), but as already pointed up earlier, per Wikipedia:Manual of Style/Lists, lists are considered as list articles. Banana Republic (talk) 13:48, 15 July 2019 (UTC)[reply]

Outlines, like Outline of biology. Or one of the 500+ articles that transclude Template:Outline footer. Often also called a "rough sketch". The Banner talk 15:10, 15 July 2019 (UTC)[reply]

Per the nutshell in Wikipedia:Outlines, An outline is a list article, and hence would not be impacted by this proposal. Banana Republic (talk) 16:10, 15 July 2019 (UTC)[reply]

The nutshell states An outline is a list article, arranged hierarchically, that helps a reader learn about a subject quickly, by showing what topics it includes, and how the topics relate to each other. So even when you want to push this down to just a list, it is still a special type of list. The Banner talk 17:09, 15 July 2019 (UTC)[reply]

I'm still unclear about what benefit this will provide. From the readership POV, it seems like the best case scenario is for it to be exactly as good as it is now. From an editor POV, it seems like this only complicates things. Off the top of my head, it seems like we'd need a redirect page in place of the DAB page, so that errant links to seal, for example can properly get forwarded to Disambigution:seal. I generally dislike the phrase, "a solution in search of a problem" because it's often used dismissively, but this proposal sure seems like it qualifies. Could you specify what will be fixed? Matt Deres (talk) 16:03, 15 July 2019 (UTC)[reply]

I think it's a cleaner way to do things. If disambiguation pages are not considered articles, they should not be in the article namespace, and should be included in their own namespace (since they would not fit in any other existing namespace). Implementing this proposal would leave the main page as the only non-article in the article namespace (since redirects do not count anyway). Banana Republic (talk) 16:13, 15 July 2019 (UTC)[reply]

I get that aspect of it, but to what end? What problem are people having that this will address? Matt Deres (talk) 17:53, 15 July 2019 (UTC)[reply]