Open main menu

Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab Miscellaneous 

New proposals are discussed here. Before submitting:

« Archives, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159

Contents


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

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

  No change, added for reference

Do you support this change? Thanks! Ladsgroupoverleg 21:09, 29 May 2019 (UTC)

  • 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)
  • 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)
  • 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)
  • 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)
    For clarity, Oppose full and template, support others. * Pppery * it has begun... 02:09, 5 June 2019 (UTC)
  • 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)
  • 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)
  • 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)
  • I don't feel strongly either way. —TheDJ (talkcontribs) 07:12, 4 June 2019 (UTC)
  • Oppose full per User:pythoncoder, indifferent/support the rest. – John M Wolfson (talkcontribs) 00:09, 5 June 2019 (UTC)
  • 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)
  • 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)
    • Comment On "other wiki", the symbols are chosen because a letter won't make sense. Viztor (talk) 00:56, 14 June 2019 (UTC)
  • Oppose for full and template only, support others per pythoncoder.--Vulphere 17:22, 12 June 2019 (UTC)

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

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

(Discussion moved from Template talk:Infobox civilian attack#Suspected perpetrator field? on recommendation to gain full consensus.) I struggle to see the benefit of listing a "suspected perpetrator" in an infobox, especially when a suspect is part of an ongoing case and will be either removed or moved to "perpetrator" when that is complete. Looking at Christchurch mosque shootings and the contention over how prolific suspect Brenton Tarrant's name should be (see ongoing RfC about keeping suspect's/suspects' name in lead), I don't think his name in an infobox offers any encyclopedic value (officially and legally, as little doubt as there is over his guilt, it has not been proved yet) and if anything only unduly promotes his name which we should also avoid. When a suspect is proven to be a perpetrator, they become part of the historical/encyclopedic record of the attack rather than the subject of a current matter/desire for notoriety. Christchurch is one particular case, but I don't think it's unique in this regard. I suggest this field be removed. U-Mos (talk) 03:28, 22 March 2019 (UTC)

(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)
  • 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)
  • 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)
  • 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)
    • 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)
      • 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)
        • Deprecate |perpetrator= and add |convicted_perpetrator=. --Izno (talk) 14:15, 22 March 2019 (UTC)
          • 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)
            • 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)
              • +1. Never lose the dream, even if forced to drop the stick. ―Mandruss  21:56, 22 March 2019 (UTC)
            • 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)

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)

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 User:U-Mos is reasonable, but a plain "perpetrator" field should remain as an option even so. Because sometimes, for example, a widely known perpetrator might flee to ISIS territory or the next equivalent and not be prosecutable. Suspected perpetrators also should be described when sources widely describe the accusation. (WP:WELLKNOWN) Wnt (talk) 07:42, 23 March 2019 (UTC)

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)
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)
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)
This is incredibly poor reason. 90% people do not read beyond the infobox. Ruslik_Zero 13:47, 27 March 2019 (UTC)
  • 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)
    • 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)
      • Yes, they need to be in the infobox because this is important information. Ruslik_Zero 13:47, 27 March 2019 (UTC)
        • +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)
  • Creating an additional template for suspects and one for perpetrators would remove all the confusion. ~^\\\.rTG'{~ 23:35, 25 March 2019 (UTC)
  • 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)
  • 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)

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)

  • 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 (talkcontribs) 23:35, 18 May 2019 (UTC)


Proposal for a new file naming criteria: harmonize extension nameEdit

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 JPEG files are split between .jpg, .JPG, .jpeg, .JPEG, .Jpeg, .jPG, and .JPeG, .JgP, while PNG files are split between .png, .PNG, .PnG, .pNG, and .Png. Even if the "jpg" vs "jpeg" shouldn't be standardized (I think it should be), I believe that the differences in capitalizations should be resolved, since file names are case sensitive. Thus, I propose the following new criteria, to be added to 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))

Survey (file format names)Edit

  • Support new criteria as proposer --DannyS712 (talk) 23:12, 29 May 2019 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • Oppose per Redrose and Risker. Thryduulf (talk) 17:43, 3 June 2019 (UTC)
  • 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 (talkcontribs) 07:17, 4 June 2019 (UTC)
  • 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)
  • Oppose per Redrose and Risker.--Vulphere 17:24, 12 June 2019 (UTC)
  • 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)
  • 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)
  • Support, but iff such changes are synchronized on/with Commons. Headbomb {t · c · p · b} 21:35, 29 June 2019 (UTC)
  • Meh per Risker. Solution looking for a problem. Kudpung กุดผึ้ง (talk) 23:29, 10 July 2019 (UTC)

Discussion (file format names)Edit

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

RfC: Deprecate webcitation.org aka WebCiteEdit

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)

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)

Survey (deprecate WebCite)Edit

  • Support per above and survey bump. -- GreenC 14:49, 13 June 2019 (UTC)
  • Support I used to use WebCite but Wayback does everything it did, and better.-- Pawnkingthree (talk) 16:34, 13 June 2019 (UTC)
  • 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)
  • 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)
  • 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. AhmadTalk 16:29, 16 June 2019 (UTC)
  • 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)
  • Support - per above. ___CAPTAIN MEDUSAtalk 17:58, 19 June 2019 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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 Enwiki entry. But unless the WebCite maintainer(s) very quickly inform Wikipedia (or the world) about a major overhaul and long-term sustainability project and convince us that the probability of future down time will drop to very low, this proposal makes sense. The world of knowledge should not be dependent on a single well-intentioned, hardworking individual. See the discussion section below for a related proposal of implementation, which seems to implement Rhododendrites' point above: add archive1url, archive1date, dead-archive1url, archive2url, archive2date, dead-archive2url, ... parameters to the standard citation template; possibly retain the WebCite urls but convert them to archive2url, archive2date, dead-archive2url=yes. [Comment: I have added a huge number of WebCite urls to Enwiki and I'm hoping that webcitation will return to online status at least long enough to make sure that alternative archival backups can be created. A lot of articles risk being greatly weakened without archival references, and this especially affects WP:BIAS.] Boud (talk) 16:43, 22 June 2019 (UTC)
  • Support per above.--Vulphere 05:50, 27 June 2019 (UTC)
  • Support per above. Johnbod (talk) 00:38, 2 July 2019 (UTC)
  • Support no downside, lots of positives. Headbomb {t · c · p · b} 01:05, 3 July 2019 (UTC)
  • 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)

Discussion (deprecate WebCite)Edit

  • 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)
    • Wikipedia:List of web archives on Wikipedia Graeme Bartlett (talk) 23:16, 13 June 2019 (UTC)
      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)
    • 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)
  • @GreenC: This RfC is not showing properly at Wikipedia:Requests for comment/Wikipedia technical issues and templates, so in accordance with 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)
    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)
    OK, after JJMC89 (talk · contribs) did this, the effect is this. --Redrose64 🌹 (talk) 15:57, 14 June 2019 (UTC)
  • 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)
    (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)
    • 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)
  • 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. hujiTALK 18:49, 16 June 2019 (UTC)
    • @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)
      • links: Archive.org Archive.today. Thryduulf (talk) 23:32, 16 June 2019 (UTC)
        • @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. hujiTALK 23:37, 16 June 2019 (UTC)
          • 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)
            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)
  • 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)
@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)
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)
@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)
@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)

─────────────────────────

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

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)

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)

Manual of Style for fictional characters?Edit

Hello. Back in 2012, we discussed a possible MoS proposal on fictional characters at WP:MOS/VG and Sergecross73 (talk · contribs · blocks · protections · deletions · page moves · rights · RfA) and I made a proposal for fictional characters, using the 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)

  • Is this meant to solve some actual problem not already covered by the MoS or some other guideline? Curly "JFC" Turkey 🍁 ¡gobble! 22:58, 18 June 2019 (UTC)
    Yes, there are a lot of disputes related to whether or not fictional characters should have their own article spun out, and there have been for many years now. It aims to give guidance with that. Sergecross73 msg me 23:08, 18 June 2019 (UTC)
    Sergecross73 how is that a MoS issue? MoS doesn't deal with content. Curly "JFC" Turkey 🍁 ¡gobble! 00:28, 19 June 2019 (UTC)
    Look, I don't care where its hosted, or even if my guidance in particular is used. I want there to be a wide-ranging discussion where we can get an enforceable consensus, because the recurring disputes in the area are both a massive time sink and a source of sour feelings among many disagreeing-but-very-good-editors. Sergecross73 msg me 01:00, 19 June 2019 (UTC)
    What are the recurring disputes? Why would having a character MOS be more effective at preventing them than letting the MOS for the various media set their own guidelines? Argento Surfer (talk) 13:10, 19 June 2019 (UTC)
    My two comments above just explained the problem and what I wish to accomplish. I don’t understand why this is so hard to understand. I’ve observed years of disputes and I wish to cut down on them. This is all very bizarre. I’ve never encountered so much skepticism for a desire to solve a problem while having complete openness on changing their stance. I’d get it if I had a controversial stance. But I just want resolution of any kind. Sergecross73 msg me 23:13, 19 June 2019 (UTC)
    I re-read your comments twice, and maybe I'm blind, but I do only see you talking about "recurring disputes" without links or descriptions. Do these disputes have recurring themes? Do they often end with outcomes that conflict with similar, earlier discussions? Without details like that, it's I find it impossible to evaluate the potential impact of your proposal. Argento Surfer (talk) 13:05, 20 June 2019 (UTC)
    • At least to me, yes. Our articles on notable fictional characters particularly in any form of serial work often focuses far too much on primary material. For example Rick Grimes (which actually has a decent "out of universe" set of sections but still has far too long in the tooth on the fictional biography), and I'm sure I can find more with some time. People writing these fictional biographies tend to want to go by breaking it up by each serial element (episode, comic issue, etc.) rather than describe the broad trends. No existing MOS or P&G really says anything against this, barring the lack of secondary sources for notability. Because we tend to allow works of fiction to serve as sourcing for themselves, these articles seem to get away with excessive reliance on primary sourcing.
    • I would then probably add that the focus of these articles should be on the out-of-universe facets more than the in-universe ones. How was the character conceived? How has the character changed over the years? How have they been received in the world of critics? etc.
    • Then another whole thorny issue is when you have multiple iterations/versions of the same character, ala something like Robin (character) especially when it comes to NFC use. That's a whole pickle that we really haven't touched on. --Masem (t) 00:17, 19 June 2019 (UTC)
      • "How have they been received in the world of critics?" Why? This is at best a trivial aspect of the topic and of minimal interest to a reader. I have a few relatives (my sibling, a few cousins, and a niece) who are Wikipedia readers, but not editors. They only read the plot sections and just ignore whatever "critical" opinion is added as indifferent. Dimadick (talk) 16:19, 22 June 2019 (UTC)
        • So, because people misunderstand the purpose of Wikipedia, and misuse it accordingly, we need to accommodate that? Wikipedia isn't supposed to be Cliffs Notes For Pop Fiction. -Jason A. Quest (talk) 16:28, 22 June 2019 (UTC)
  • To clarify, is the text of User:Sjones23/Proposal what is being proposed here? Satellizer el Bridget (Talk) 00:47, 19 June 2019 (UTC)
  • Support at least some set of guidelines. I would estimate that we have tens of thousands of articles on fictional characters, mostly comic book characters. bd2412 T 00:54, 19 June 2019 (UTC)
  • Support I think this is a great idea.Blue Pumpkin Pie (talk) 01:01, 19 June 2019 (UTC)
  • Oppose as instruction creep, until it can be demonstrated this will solve concrete problems our guidelines don't already address, rather than be a collection of pet prescriptions. Curly "JFC" Turkey 🍁 ¡gobble! 01:55, 19 June 2019 (UTC)
  • I think Masem does bring up some good points. I give the example of Sansa Stark, a major character that appears in two different mediums, and with two very different storylines. Right now the article is 75% in-universe retelling of her story by book and by season (all unsourced, naturally) and only then comes the real life coverage of the character. This is excessive reliance on primary sourcing even on a well-known character with a number of reliable sources available. I think WP:PLOT argues that summary descriptions of works should be limited, yet it's not being done in many (most?) character articles. Then there's the whole issue of having hundreds of articles like Griffin Castillo, AJ Chandler, Nick O'Bannon, Nitro (comics), A. J. Chegwidden and Natalie Marlowe that obviously fail MOS:REALWORLD on a whole (as in, there's no independent sourcing on these characters). I think that the rules do exist regarding coverage of fictional elements in wikipedia voice but I'd personally welcome some discussion regarding what we should reasonably expect from an article about a fictional character (development, reception, difference between original work and adaptations, merchandise, casting, etc.). RetiredDuke (talk) 18:23, 19 June 2019 (UTC)
  • I also think this could be expanded to articles that handle more than one character and List articles that handle characters.Blue Pumpkin Pie (talk) 21:42, 19 June 2019 (UTC)
    I would definitely think that we can include "list of characters" as part of a MOS for fictional characters in general. We're not talking notability here (there is no specialized notability for fictional characters, they are expected to meet the GNG), but the biggest issue in both single character and character lists is that the content from primary seem to be around 90% of the article, ideally it should be 50% or lower. Outside of WP:NOT#PLOT, and the little that is in WP:WAF, there is nothing to help with this imbalanced primary/secondary ratio. --Masem (t) 23:20, 19 June 2019 (UTC)
  • Don't support the current wording of User:Sjones23/Proposal, if this is what is proposed, but do support a centralized MoS guideline, as currently TV has Wikipedia:Manual of Style/Television#Character article structure, WikiProject Fictional characters has Wikipedia:WikiProject Fictional characters/Style guide, Video games have Wikipedia:Manual of Style/Video games#For characters, comics have Wikipedia:Manual of Style/Comics#Characters 2 and there are probably others. This needless fork of guideline has in certain situation also conflicting style guides. --Gonnym (talk) 00:07, 20 June 2019 (UTC)
    I plan to merge all of the guidelines there into a single MoS guideline. Lord Sjones23 (talk - contributions) 05:57, 21 June 2019 (UTC)
  • Oppose per WP:CREEP. I just had a look through the FAs of this sort. To start at the top, consider the vexed question of infoboxes. Should fictional characters have an infobox like Jabba the Hutt or not, like Tom Swift? There's no practical consensus on this, is there? Andrew D. (talk) 09:04, 20 June 2019 (UTC)
  • Oppose as instruction creep, the question of standalone notability for a fictional character should be determined by WP:GNG on a case by case basis, while the MOS is not the right area for such decisions, thanks Atlantic306 (talk) 11:54, 20 June 2019 (UTC)
  • Oppose per User:Atlantic306 and User:Andrew Davidson's rationale. Would've supported per WP:NOTCREEP however the matter seems a lot more complicated and integrated into wikipedia. Consensus would seem very mixed on the matter too so, echoing Atlantic306 I'm going to emphasize his/her argument that "Standalone notability ... should be determined by WP:GNG on a case by case basis."
  • Oppose I made an essay in 2016, which is linked as WP:A&M/CHARACTER based on common layouts found on GA and FA anime and manga related character articles. This being said, we already have so many projects doing their own thing here. In theory its a good idea, but implementing it across Wikipedia is another matter. - Knowledgekid87 (talk) 15:57, 20 June 2019 (UTC)
  • As seen by what Gonnym pointed to, we already have style guides for fictional characters. And we have Wikipedia:Manual of Style/Writing about fiction. Flyer22 Reborn (talk) 05:12, 21 June 2019 (UTC)
    • That doesn't solve a lot of problems with fictional characters. In recent months I've seen various problems for which there have been no specific answers, even for simple things like how you should write the chaacter's name in the lead sentence. A common thing that I see is editors not being able to separate fiction and reality. They like to add birth dates, often based on OR, or claim citizenship for particular characters based on how it applies to the real world. When you try to refer to WP:WAF or other guidelines to resolve the problem, there is no guidance in the area. We really do need something specifically for fictional characters. --AussieLegend () 06:22, 21 June 2019 (UTC)
      • So which MOS or essay do you propose we go by? We have an MOS mention for comic book characters, an MOS mention and essay for anime characters, a style guide for fictional characters, an MOS mention for television characters, and an MOS about writing about fiction. - Knowledgekid87 (talk) 15:23, 21 June 2019 (UTC)
        • I would start by looking at what you've mentioned and improve those if necessary. Then, look at what is common to all and create a MOS based on that. --AussieLegend () 08:31, 22 June 2019 (UTC)
  • SMcCandlish and I have previously discussed a centralized MOSWORKS (see also Talk:Virtual Pool 3). It would be a massive undertaking. I'd be willing to work with other editors to consolidate our guidance on works, fictional and otherwise, of which the characterization is a part. That said, I would reject the 2012 Sjones page out of hand. --Izno (talk) 16:26, 22 June 2019 (UTC)
    • Since a few of us in this thread repeat this sentiment, maybe the question for a RfC shouldn't be if we should adopt Sjones's page, but wether we should consolidate the various MoS and essay pages on fictional characters into one MoS. --Gonnym (talk) 09:31, 27 June 2019 (UTC)
      • Perhaps the thing to do, then, is to make a draft of what such a consolidation would look like. bd2412 T 19:49, 27 June 2019 (UTC)
      • Yeah, I'd Just Do It after finding a few likeminded editors from the various groups maintaining pages that talk to characters/works, and other fictional/non fictional things of similar nature. --Izno (talk) 21:30, 27 June 2019 (UTC)
        • I would oppose the idea as there are so many different character universes. Things for comics or fictional characters like Juliet may not apply for things that have to do with an anime/manga character and vise versa. - Knowledgekid87 (talk) 23:38, 7 July 2019 (UTC)
          • I think that's a bit irrelevant. All character articles should strive for a few things: concept and creation, involvement in the works in which they appear, reception, themes, and legacy, i.e., their focus should be about their real-world impacts. --Izno (talk) 00:49, 8 July 2019 (UTC)
  • Oppose per User:Atlantic306 and User:Andrew Davidson.--Vulphere 06:19, 27 June 2019 (UTC)
  • Oppose. We're not currently at a state where we could "solve" all these diverse series of issues all at once. Yes, various fictional characters are treated differently in WP, because the fiction treats them differently. Maybe would devise some sort of classification system and create useful guidelines for each, but that's just step one of many required, and that by itself is too big a step. Perhaps we could start with a few essays that suggest some ideas for how some types of fictional characters could be identified and treated, and see if that clarifies how we might start to find a way to cover everything. All I know is dictating something right now would actually delay these preliminary steps, and inhibit a workable solution. --A D Monroe III(talk) 21:05, 27 June 2019 (UTC)
  • Comment to several of the opinions above:
    • We are not talking about fictional character notability. We've tried setting a standard, and there just isn't any. Fictional characters must show they meet the GNG with secondary sourcing about the character, to have a standalone article. This proposal does not change that.
    • I agree that in detail, how a comic book character is treated compared to a film or television character will be significantly different at that level, but at the broad scope, there are still many common things we expect to see in all articles on fictional characters: concept/creation, development, a brief fictional summary, and reception to the character. Regardless of the media, every character should have something akin to that. There are MOS elements that apply across the board, how to write about in-universe events, concise plot aspects, etc. We don't want to get too far in the way of special approaches needed in, say, comic books for generational characters or those with many different iterations, but the same basic concepts that would apply to a notable one-off character apply there. Should a MOS for fictional characters be developed it is not intended to step on the toes of any other medium's specific MOS, and should be harmonizing those parts. --Masem (t) 18:34, 8 July 2019 (UTC)

RfC: Ending the system of portals take 2Edit

Should the system of portals be ended? This would include the deletion of all portal pages and the removal of the portal namespace. This of course does not include our main page or other portal style pages as they are not in the portal namespace.....with the current event portal being moved--Moxy 🍁 03:41, 19 June 2019 (UTC)

Rationale discussionEdit

It's clear that the portal space is no longer support by the community. Since the last rfc to retain portals and desire to try improve what we had...and then mass creation of automated portals; we have had 4000 plus portals deleted in the past 6 months with very little opposition and participation in those talks. Many portals have been deleted with just a few votes with most having zero improve attempts. At this point with only 900 or so left we should consider the fact it's over. What do others think? Should we just keep deleting one by one or does the community except that it's a failed experiment and our resources can be better used.--Moxy 🍁 03:35, 19 June 2019 (UTC)

Regarding "with just a few votes" - When I look at any xFD if the nom makes a good case and all the !votes are to delete (even if there are only one or two of them) then I don't usually bother to !vote. Many other editors may do similar. DexDor (talk) 05:25, 19 June 2019 (UTC)
The vast majority of editors do not go to, or even know about, xFD, so removing things via that route probably doesn't give an accurate picture of true feelings of the community. Randy Kryn (talk) 13:19, 19 June 2019 (UTC)
The vast majority of editors do not go to, or even know about, any type of Wikipedia discussion. ―Mandruss  14:41, 19 June 2019 (UTC)
Those at the isolated deletion board don't care about the last Rfc and they have littld interest in updating any or even giving the community a chance to fix them. If there is any desire to retain portals we will need content editors to step up and update the portals. As of now portals are being deleted bases on views or the fact a topic like the military of the United States is considered not a broad topic. If no one is will to help there is no point in having them...as they will all be gone soon anyways. I voted last time to end portals...but now find myself trying to explain that back door deletion is not what the community intent was in the last Rfc. I still think they should be deleted overall...but am not a fan of the non policy bases they are being bandwagon deleted.--Moxy 🍁 19:09, 19 June 2019 (UTC)\
Well, I have occasionally looked at some portals since the last RfC and they looked fine. It's rather a mystery why some people would want to trash every portal that might interest others and the last RfC suggests rational people do not. It's fine to trim, but 900 is just not that many pages and neither is 4000. Alanscottwalker (talk) 19:51, 19 June 2019 (UTC)
  • I think this proposal is too rash and misses a lot of points that would help build consensus. Given the lack of consensus in the previous RfC, the next step is not to propose all or even most portals be deleted. The recent mass portal deletions were in response to what was as much a conduct dispute as a content dispute. The XfD discussions were largely because a proposal for a new speedy deletion criterion applying to all portals created by a single user failed to gain consensus. Pointing to those to say that there is consensus to delete all portals is not a good example. The AN discussion has over 10 proposals on how to handle portals, some of which, like proposals 7 and 13, seem like they might actually find consensus.
If anything, the problems pointed out regarding the upgrades to portal maintenance can at best show that we should not create any more portals as they are likely to wind up unmaintained and just as complex as before. I think a proposal to mark WP:PORTAL historical but maintain what we have for the time being is far more likely to gain consensus than deleting portals en masse. Lots of people believe there are portals which still have value and are actively maintained and so blanket deletion is not going to find consensus because of that.
I fear that this discussion is only going to harm consensus building by making people more entrenched in their positions. It's unlikely to pass and those who support portals will be more likely to view further good faith attempts at consensus building as attempts to delete all portals. I suggest this be withdrawn or closed in favor of a more nuanced proposal. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 21:25, 26 June 2019 (UTC)
  • Procedural close this bad faith, disruptive RFC. This proposal is just a blatant act of bad faith by Moxy, who doesn't understand what was actually decided at the 2018 WP:ENDPORTALS RFC. That was a proposal to delete all portals, now, and it was rejected. That's all; it was not a decision to keep any individual portal, just a decision not to delete them all immediately.
However, Moxy has spent the last few weeks opposing deletion of long-abandoned portals, repeatedly making the false claim that ENDPORTALS decided to keep them all.
This pseudo-RFC is just a re-run of the false binary thinking, intended to demolish a straw man. It posits them single option of deleting them all, in the hope that when that's rejected Moxy can then use the outcome to oppose deletion even of abandoned crap.
The current situation is that good portals are being kept, but the abandoned junk is being deleted. Moxy's aim is simply to stop that cleanup, and there is no need for the community to waste its time indulging this game-playing. --BrownHairedGirl (talk) • (contribs) 20:38, 1 July 2019 (UTC)
Just have to read There exists a strong consensus against deleting or even deprecating portals at this time . Not sure that it could be more clear...so here we are again trying to get you to move in the right direction to no avail. Have you seen what is being said here??? You 2 have been asked many many times to give the community time to fix the portals you guys dont like......simply not possible to fix hundreds of portals at a time. --Moxy 🍁 20:46, 1 July 2019 (UTC)
Moxy, it was a decision to not delete all portals now.
It was not a decision to never delete any portal ever.
It's a great pity that Moxy's deep deficiency in logic and of reading comprehension does not debar him wasting the community's time with this WP:POINTy RFC. --BrownHairedGirl (talk) • (contribs) 21:00, 1 July 2019 (UTC)
Your simply not doing right by our editors and this should be clear by all the feed back your getting . Cant believe you dont understand why editors are upset with you 2 ...your deleting portals based on view and what you guys think is not a big topics....zero effort at fixing portals that are clearly valid like Wikipedia:Miscellany for deletion/Portal:Military of the United States that has 1,197 featured and 3,088 good articles to use. Now you 2 are deleting portals based on no attribution...thats every portal we have a ... So were does your deletion end and the fixup work begin?? 3000+ portals deleted is definitely not what the RfC is looking for.--Moxy 🍁 21:12, 1 July 2019 (UTC)
Your Moxy, the feedback I am getting is very clear that most editors have no objection to the deletion of portals which fail the portal guidelines, while keeping those which do meet the guidelines. It's a great pity that you continue to refuse to actually read the guidelines. If you did read and comprehend them, you might understand why Wikipedia:Miscellany for deletion/Portal:Military of the United States was closed as delete.
However, there has always been a small trickle of editors like yourself who object to the deletion of even portals which have been abandoned for a decade ... and every now and then one of them tries to make a drama.
Fixup begins whenever you or anyone else wants to start fixing them. --BrownHairedGirl (talk) • (contribs) 00:00, 2 July 2019 (UTC)
...Erm, I have no leg in this discussion overall, but "deep deficiency in logic and of reading comprehension" (EDIT 16:58, 6 July 2019 (UTC): and other comments regarding them elsewhere in this discussion) reads as a clear, unambiguous personal attack to me, or at the very least, highly uncivil (I was considering saying as such on your talk page, but something in me said to bring it up here instead, even though part of me is worried that could escalate things), and I'm quite frankly appalled that it's coming from not just any random user but rather a sysop, of all people. It's gotta be possible (and, indeed, appears quite possible, from some of the other things you said) to argue against Moxy's position (or what you believe their reasoning for opening this RFC was) without stooping to the level of suggesting they can't comprehend the processes or previous outcomes related to this discussion. - Purplewowies (talk) 16:53, 6 July 2019 (UTC)

Voting discussionEdit

  • Oppose: I think we should keep portals, because they're useful for organization, navigation, and bridging between reading and project space. Benjamin (talk) 06:36, 19 June 2019 (UTC)
  • WP:ENDPORTALS: Electric Boogaloo? Moxy, I would suggest pausing this a bit to work on the wording of the RfC, at least. The last RfC got muddled up with Wikipedia:Community_portal and Portal:Current_events (with the intention being that the current events portal would be moved to Wikipedia space), and with some opposition to full deletion (with preferrence a slower process than Nuking the whole space). So I would suggest some rephrasing of the RfC question or changes to the format to allow a consensus for a less dramatic step. Galobtter (pingó mió) 12:32, 19 June 2019 (UTC)
    Done I guess we should make it as clear as possible.--Moxy 🍁 19:30, 19 June 2019 (UTC)
  • Oppose, this was fully discussed in the last well-attended and novel-length RfC. Some editors have worked diligently on the collection since then. Randy Kryn (talk) 13:13, 19 June 2019 (UTC)
  • Not now per Galobtter. I think you're right that recent developments might have changed consensus. I agree with the spirit of the proposal, but per the last RFC, Community portal and Current Events are going to be stumbling blocks to consensus unless there's an explicit plan to deal with them from the beginning. I think you should withdraw this and consider a better compromise than deleting portals which I don't think will find consensus. Wugapodes [thɑk] [ˈkan.ˌʧɹɪbz] 14:41, 19 June 2019 (UTC)
    Note: Wikipedia:Community portal probably isn't relevant - it isn't in portal namespace, isn't a WP:Portal and was only mentioned once in the previous RFC. DexDor (talk) 18:15, 19 June 2019 (UTC)
    Have amended wording for those not familiar with topic portals.--Moxy 🍁 19:30, 19 June 2019 (UTC)
  • Oppose The major portals still appear on the main page and that's not a problem. People bickering about lesser portals is typical disruption per WP:LIGHTBULB. Tsk. Andrew D. (talk) 22:36, 19 June 2019 (UTC)
  • Oppose I have been appalled by the tone of the discussions at MFD but I simply haven't have the inclination to take part. All the same, I think portals should continue. Thincat (talk) 08:03, 20 June 2019 (UTC)
  • Strong Oppose - We already had a lengthy discussion on the matter that has its own subpage saying there is a "strong consensus" to retain the portals, no need to beat a WP:DEADHORSE. - Knowledgekid87 (talk) 16:02, 20 June 2019 (UTC)
  • Oppose That there was consensus to delete some portals does not imply consensus to delete all portals. Articles are deleted every day at AfD but this does not imply a consensus to delete the article space. Hawkeye7 (discuss) 19:46, 20 June 2019 (UTC)
    Going by the reasons for deletion that I see most days I think that there are some editors here who would like to make this place neat and tidy by deleting the whole of article space, so they would be able to argue about things without having that messy encyclopedia to worry about. Phil Bridger (talk) 20:38, 20 June 2019 (UTC)
    This just goes against WP:IMPERFECT (which is a policy), no amount of deletion cleanup will ever be enough to please everyone. Things that hinder editing I can understand, but to go after things just to go after them is wrong in my opinion. - Knowledgekid87 (talk) 15:16, 21 June 2019 (UTC)
  • Oppose I'm against deleting high level portals such a those on the main page and Portal:Contents, plus any others which don't duplicate article content such as Portal:Current events and Portal:Featured content. I would be happy to consider proposals to drastically reduce the number of portals but not get rid of them entirely. Hut 8.5 12:53, 22 June 2019 (UTC)
    My guess is this is the plan...deleted all but main portals..--Moxy 🍁 12:00, 24 June 2019 (UTC)
  • Strong support. I feel that portals are long obsolete and that their removal is inevitable and would benefit Wikipedia. Also, in response to those who note that we have had a discussion on it before, I remind you that that was over a year ago and that consensus can change. Having said all that, I get the feeling that consensus does not currently support the eradication of the namespace, so I will support the form of consensus that is closest to it (such as removing all but the main-page portals, etc.). EDIT: After thinking it over for a little bit I realize that I've been a bit overly harsh on portals. I still see no use for them personally, and would not oppose deleting all but the main-page and non-article-duplicating portals, but those who really want to maintain the portalspace should be able to do so provided that they don't spam with cruft and, most importantly, help the encyclopedia. – John M Wolfson (talkcontribs) 18:02, 26 June 2019 (UTC)
  • Strong oppose. Look, there are a lot of useless portals. If that makes the whole system useless to you, fine, ignore them. If you think it could be useful but it isn't because of the cruft, then decide whether it's worth your time to help clean it up. If it is, then do it. If it isn't, see sentence 2.
    The "resources" argument is fundamentally misbegotten. There is no common pool of resources that we draw on. There are volunteer contributors, who allocate their resources as suits them. --Trovatore (talk) 19:51, 26 June 2019 (UTC)
Would be nice but efforts to improve are just reverted....got just a few editors voting rrsulting in deletion of thousnads of portals.--Moxy 🍁 21:41, 26 June 2019 (UTC)
Moxy, if you genuinely believe that efforts to improve are just reverted, then please post evidence of this. I have seen no evidence of this raised at MFD or at WT:WPPORT ... so unless you can show actual evidence I will mark it down as simply more of Moxy's lies.
As to just a few editors voting rrsulting in deletion of thousnads of portals, that's a blatant lie (as in something which you stated it when you knew to be untrue). As Moxy well knows, the majority of the deleted portals were removed in two mass deletions of automated portals: one, and two). Those were widely-advertised discussions, and they were some of the most heavily-attended MFDs ever. Claiming that this is just a few editors voting is a simply a lie designed to deceive other editors. --BrownHairedGirl (talk) • (contribs) 21:10, 1 July 2019 (UTC)
More lies what are you talking about? Cant BS the facts girl...its clear portal after portal that was not automated is being deleted by just a few votes (as mentioned here by others). As for your revert I am simply not sure what to say]...editors cant do much when an admin is reverting fix attempts now can we. You sure your on the right side here...are you doing right by our editors?--Moxy 🍁 21:47, 1 July 2019 (UTC)
Moxy, either you are either a congenital liar or you have a very poor grasp of facts.
You claimed just a few editors voting rrsulting in deletion of thousnads of portals.
The facts are that:
  1. ~2500 automated portals were deleted by overwhelming consensus at the two mass MFDS.
  2. Another ~1900 automated portals were deleted per that consensus
  3. ~570 portals have subsequently been deleted at MFD, in discussions with varying numbers of participants.
So your claim that a few editors have deleted thousands of portals is a complete lie. That description could be applied to at most a few hundred portals.
As you know, those portals have been deleted because they don't meet the portal guidelines ... so your whole claim of this being the work of a few editors is either more lies, or a paranoid delusion.
Now, that diff.[2]
  1. It is not a revert. It was a removal of a category on Portal:Washington, D.C..
  2. I removed Category:Portals by city because the portal was already in the subcat Category:United States portals by city, so per WP:SUBCAT it shouldn't also be in Category:Portals by city. This is very very basic categorisation policy, so it is bizarre that you try to make an issue of this at in an RFC.
So that's another of Moxy's fairy tales disposed of. So where exactly is this evidence of portal improvement being blocked? --BrownHairedGirl (talk) • (contribs) 23:51, 1 July 2019 (UTC)
  • Oppose Portals are useful.--Vulphere 05:48, 27 June 2019 (UTC)
  • Oppose The possibilities are important to retain. I look at Portal:Feminism and only wonder where Gender-responsive prisons could be referenced. The article isn't even categorized correctly! I may inhabit the search box, but users should have other ways of finding topic-related articles. We need multiple avenues for discover. Shenme (talk) 22:00, 1 July 2019 (UTC)
  • Oppose - IMHO they should all be killed with fire ... however the last portal RFC was closed with a consensus to keep these .... I don't support repeatedly creating the same RFC in the hope consensus will change even if I do disagree with said consensus. –Davey2010Talk 21:53, 2 July 2019 (UTC)
  • @Davey2010, I agree with all that. I voted delete in the 2018 RFC (as the lesser evil of a binary choice), but I accept the outcome and see no benefit in a re-run.
However, this proposal isn't actually born out of a desire to end portals. The proposer Moxy actually wants to keep all portals, and this RFC is a thoroughly bad faith straw man proposal after Moxy's objectives failed through other channels.
In the last 4 months, many portals have been deleted at MFD because they were abandoned, stillborn, or had too narrow a scope. These last few months have seen a cull of several hundred of the worst portals, because they failed the criteria set out in WP:POG. Moxy has objected to many of these deletions, almost always without success.
So Moxy and others have tried to change the guidelines to remove the quality criteria. See e.g. WT:Portal/Guidelines#How_often_to_update? and WT:Portal/Guidelines#Pageviews where such proposals have been roundly rejected. In his characteristically abysmal writing style, Moxy has been quite explicit about his goal: "We need to fix what the criteria are so deletionest cant use it in a bad way,,,should be greadre towards improvement and sustainability over deletion. criteria."
Having failed to remove the quality threshold from the guidelines, this RFC is a straw man: Moxy hopes that its rejection will allow him to claim that there is a consensus not to delete any portals.
This disingenuous tactic is foolish, because most editors can well understand that a decision not delete the entire namespace is not a decision to keep every piece of ten-year-old abandoned junk in portalspace. There are some really good portals which serve readers well, and most editors want to see the junk culled while keeping the good stuff ... but Moxy is going to play his transparent game of trying to pose it as a binary choice between keep keep all or delete all.
I'm inclined to think that there should be some certification process for RFCs, requiring a number of co-signatories before the Village Pump can be abused in this way. It is a waste of the community's time for a linguistically-challenged "editor" to be free to unilaterally start to waste the community's time with this sort of straw man game. --BrownHairedGirl (talk) • (contribs) 00:15, 3 July 2019 (UTC)
Hi User:BrownHairedGirl, I agree if they're not being used then yeah I see no valid reason for keeping them,
I have to say looking at their contribs I'm rather disappointed at the continuous !votes on various portal MFDs- The time trying (and failing) to keep these crap could seriously be better spent on writing or improving articles for our readers,
If they've genuinely created this to make some sort of point then I hate to say it but they've all but failed on that too. –Davey2010Talk 00:57, 3 July 2019 (UTC)
@Davey2010, given the exceptionally poor writing skills which Moxy has displayed in all the discussions I have seen, it is probably a blessing that Moxy puts their efforts into defending the indefensible chunks of portalspace rather than polluting articlespace with gobbledygook such as We need to fix what the criteria are so deletionest cant use it in a bad way,,,should be greadre towards improvement and sustainability over deletion. criteria. --BrownHairedGirl (talk) • (contribs) 01:04, 3 July 2019 (UTC)
  • Oppose. The last widely advertised RfC, only last year, closed with a consensus to keep the portal space. I'm involved in portal editing & I have literally tripped over this by accident, so it does not seem widely enough advertised. Espresso Addict (talk) 07:15, 7 July 2019 (UTC)
  • Oppose. I think portals can fill a niche that lists and navboxes cannot fill. An interactive guided exploration into the subject scope. And that does not mean a bunch of navboxes collected together in colored boxes, but rather a focus on modern multimedia technology and a more visual narration style than what would otherwise be acceptable in the article-sphere. Maybe a lot of portals did not do a good job at that in the past and some attempts to make the portals easier to maintain actually made them less attractive and useful, but I do not see the need to throw the baby out with the bathwater. If Wikipedia wants to stay in touch with the next generations, then it should also try and utilize other navigational methods than just a bunch of boring lists of links that you can hover over with your mouse (still a great improvement to boring lists of links that you cannot hover over with your mouse by the way). I also agree with User:Espresso Addict that the decision to delete all portals should be on a similar scale than the last RfC. Hecato (talk) 10:46, 11 July 2019 (UTC)
  • Oppose. This same stupid proposal has already been made many times before in the past, all of which close with consensus to keep them. People clearly find them useful as per the consensus of last time, so why this is being brought up again I will never understand. Namcokid47 (talk) 23:27, 11 July 2019 (UTC)

Proposal for a policy to speedily move advert/COI pages to draftEdit

We have over 18,000 pages tagged as {{advert}}, and nearly 13,000 tagged as {{COI}}. Some of these are actually in reasonably good shape, but need to be slightly more balanced and have some puffery removed, while others are barely more than a resume or a page of promotional jargon. In the middle ground, there are a substantial number of pages that are for individuals and entities that are probably notable, and which are not fit for speedy deletion under CSD:G11 as unambiguous advertising or promotion, but which also are not in a shape to properly serve our readers. As an administrator, I probably deal with more of those than the average editor. I would like to be able to speedily move pages that are farther towards the bad end to draft space. I propose the adoption of a policy structure along the lines of CSD:G11, but directed at articles that are theoretically fixable, but predominated by advertising, promotion, or clear COI content to the point that they require substantial revision to be a useful and credible part of the encyclopedia. bd2412 T 00:50, 27 June 2019 (UTC)

I agree with this concept. In borderline cases where there is some genuine encyclopedic content, it is better to preserve it as a draft than to delete it outright. Any good faith editor can do cleanup work and then move the draft back to main space. Cullen328 Let's discuss it 04:16, 27 June 2019 (UTC)
I would support this in principle. My main concern is in borderline-borderline cases where there are roughly equal amounts of promotion and content, but I think such concerns could be ameliorated and are not fatal to the idea. – John M Wolfson (talkcontribs) 05:27, 27 June 2019 (UTC)
Just to pick an example to see how this would work. NASCAR is marked advert. Would you like to draftify it? ☆ Bri (talk) 03:19, 28 June 2019 (UTC)
  • That is a good question, and the answer is no, since that page is not clearly "predominated by advertising, promotion, or clear COI content". This would be a policy directed at pages that have some smattering of salvageable content, or are clearly notable topics that should have an article, but which have very little on the page that is not advertising, promotion, or clear COI content. Basically, it would cover pages that fall outside CSD:G11, but whose content does not really serve readers looking to learn neutral and unbiased information about the subject. 04:25, 28 June 2019 (UTC)
What would the eventual fate of such a page be? I am talking empirically, not in terms of policy. Jo-Jo Eumerus (talk, contributions) 07:55, 28 June 2019 (UTC)
  • Empirically, the fate of such a page will be whatever editors make of it. I have previously solicited the creation of a banner for pages that are sent to draft through AfD ({{AfD-userfied}}), and I these pages would be similarly tagged, so they would show up in a maintenance group together. Of course, the ones that no one really thinks are worth having in the encyclopedia will end up being abandoned, which is a better result then having them abandoned in mainspace. bd2412 T 16:04, 28 June 2019 (UTC)
Support as a part of new page patrol. Quarantining new promotional articles in draft space deprives spammers of what they want - being indexed by Google. I quarantine a lot of suspected undisclosed paid adverts - from what I've seen about 10-20% get deleted via G5 or G11, <5% get tendentiously moved into mainspace by the author, sock or meatpuppets, <5% get moved into mainspace via AFC and the rest will be deleted via G13 once the time expires (but that's because I block the creators in most circumstances). A G13 deletion isn't too much of a concern - we don't want drive-by spam by non-contributors anyway. MER-C 09:58, 28 June 2019 (UTC)
  • I'm inclined to interpret this as a deletion policy by the backdoor (I don't think that's the intent, I just think that's what it is). The loss of drafts through G13 will make up such a large proportion (either no-one watching, or no-one avid enough to fix them (particularly a hoard of such)) that it would be more coherent to amend DELPOL and note that they are automatically to be refunded on request. Please note I do not advise this. Nosebagbear (talk)
I would say that if the topic is notable, but there isn't relevant or encyclopedic content it can be deleted at AfD for being promotional, even if it doesn't reach the unambiguously promotional level needed for CSD. See WP:DEL#4 Nosebagbear (talk) 11:55, 28 June 2019 (UTC)
  • I am trying to do something here for the edge cases, the ones that have some glimmer of promise. Those frequently survive AfD precisely because of that glimmer, but are then forgotten and remain in their dismal state for years thereafter. Of course, these are generally not subjects that are vital to our encyclopedia, so if they end up getting deleted as abandoned, it is not a great loss. However, it is to our detriment to keep them in mainspace perpetually, with drive-by added tags lingering, and it is an administrative burden to the project to go through deletion discussions which often resolve nothing where the solution is not going to be a binary "keep" or "delete". bd2412 T 16:10, 28 June 2019 (UTC)
Is there a reason to only apply this reasoning to articles with COI issues? Let's accept that, in some cases, pages are plagued by such serious promotional tone issues that having them visible in mainspace does more harm to readers than good (despite those pages having some small amount of redeeming content). What about an article on a notable topic that's dominated by a long-standing WP:COATRACK with no sign of improving? Or an article on a notable topic which is written like a personal essay with ruinously jumbled prose? Couldn't such articles also fall in the Goldilocks zone where the issues are so bad that the article is more likely to confuse or mislead a reader than help them, but not so bad that they'd qualify for speedy deletion (or even AfD)? Colin M (talk) 17:41, 28 June 2019 (UTC)
  • The proposal is not limited to COI, but also includes ADVERT. I see your point, but my concern is that articles in these categories are more likely to actively misinform our readers. Of course, a COATRACK problem can also be a form of advertising. At the moment, however, we only have 69 pages transcluding {{Coatrack}}, so it is on a much smaller-scale problem than more direct advertising. Also, I would clarify that COI should only be an issue where it is an undeclared COI, particularly the kind where a topic is the product of SPAs bombarding a title with promotional factoids rather than a reasonable assessment of the sources. bd2412 T 17:52, 28 June 2019 (UTC)
    • That makes sense. I would support something like this. Based on my somewhat limited experience, I can believe that the scale of the problem is large. I realize that the best solution in these cases is to just fix the problem by removing the promotional content and rewording the WP:PUFFERY, but I just can't muster any enthusiasm for spending even 20 minutes picking through sources to try to clean up an article about a borderline notable dating app/jewelry maker/music blog/whatever. I'd prefer if paid editors didn't get to profit because everyone is too apathetic to spend the time cleaning up their mess. Colin M (talk) 21:57, 28 June 2019 (UTC)
I like the idea and would support such a proposal. There are always large numbers of new articles coming through at NPP that pose the problem outlined by Colin M immediately above: not such sheer promotion that they could be CSD'd, not suitable for a jaunt at AfD because they could conceivably be cleaned up, but cleaning up would take a fair amount of (disagreeable, grudging) work and is not likely to happen in a hurry. Result, promotional content live in mainspace for an indeterminate length of time. Having a clear mandate to refer the responsibility of making these acceptable back to the creator would be most welcome. --Elmidae (talk · contribs) 17:37, 5 July 2019 (UTC)
It is already common practice for new page patrollers to draftify newly created articles that are not ready for mainspace (WP:DRAFTIFY) and they can expire there then get deleted if inactive. If I understand this would be different and recommend to do it even with older articles that have long standing COI/promotion issues, but not blatant enough for CSD/AfD? I have a concern though: there are so many and there's the issue of cross-namespace redirects and cross-namespace wikilinks not allowed when moving non-orphans (so we'd treat those links just like for deleted articles, presumably). Where to draw the line, how to evaluate? We'd probably need a few guidelines as part of the proposal... —PaleoNeonate – 21:07, 5 July 2019 (UTC)
I expect that cross-namespace redirects would be deleted, as they are with any article moved to draft. We probably would need some additional guidelines, but I think the standards would not be much different from those for moving a new article to draft space. Consider, if one article is brand new, and another of the same quality is ten years old, why should the new one be moved to draft and the old one allowed to remain in mainspace merely because it is old? Perhaps there is some greater chance that the authors of the new article will still be around to improve it, but that is not a good reason to maintain bad content in mainspace perpetually. bd2412 T 01:30, 6 July 2019 (UTC)
  • Moving to draft is equivalent in many cases to a six-month-delayed speedy deletion, with less admin supervision than the other speedy criteria. That's a no, in case there was any doubt. They are far more likely to get improved in mainspace. In my experience we need less draftifying not more. It's entirely acceptable to take any long-term tagged article to AfD if its net benefit to the encyclopedia seems in doubt. Failing that you could always try improving it. Novel approach, but it has been known to work. ETA: See for example Ntoi Rapapa (although that was moved as a BLP lacking sources) & King Billy Island which continue to exist only because I idly refreshed the G13 queue before going offline. Espresso Addict (talk) 04:04, 6 July 2019 (UTC)
    We are talking about over 30,000 articles here. Sure, they should be improved, but if the people writing them are using Wikipedia to advertise, then they should be given some incentive to clean them up other than their being a tag on the page. We have articles that have been tagged like that for over ten years. bd2412 T 14:34, 7 July 2019 (UTC)
    This seems to come down to a preference for, regarding a given notable subject, having no article until someone writes an acceptable one; versus having live a bad, promotional article, for a possibly long period. I do prefer the former. --Elmidae (talk · contribs) 17:41, 7 July 2019 (UTC)
  • Support proposal. I appreciate all the hard work editors who patrol these pages take. Pages with serious COI and advert issues that are on notable subjects and aren't suitable for mainspace should be moved to be moved to draft. Our policies and guidelines shouldn't allow COI editors to game the system. --Gonnym (talk) 14:49, 7 July 2019 (UTC)
  • There are too many of them, and too few people to fix them. I can fix about 2 a day if I do little else-- 1 a day is more realistic, which for me comes to about 25 a month, or 150 in 6 months, which is the standard time at Draft. There are probably about 20 other people who could do as much, lets suppose half of them are willing, that's 1500. Othe people who waould do a smaller about woul dprobably do at least as much as those of us willingto concentrate on it, so that's about 4,000 in 6 months. We have about 5 times that. Of course, not all will be fixable, but the only way to see that is to try--if they were obviously unfixable they swould have been deleted not tagged. But more fundamentally, this is furthermore an improper use of draft space. The criterion for promoting from draft to main space is that the article would probably pass afd. These arearticles thathave not been deleted--standard were lower in the past, but even so, probably half of them would have a decent chance of passing afd--and, if so, they should't be in Draft space.We already have a considerable amount of confusion in AfC about the proper standards for passing, and we already have a lage of about 2 months for the non-obvious drafts. All of this would be made much worse. Kudpung, and those few people of us who have been helping him over the past three years have managed to at least keep AfC/draft from being an inconsistent chaos, and this would negate all that we've been doing. DGG ( talk ) 19:03, 10 July 2019 (UTC)
  • Support At least it is one tiny step in the good direction. But more steps are needed. I have too often seen promotional articles being kept at AfD as "it can be fixed by normal editing". And then it stops and the promo stays there. The Banner talk 19:47, 10 July 2019 (UTC)
  • Support in principle, and The Banner makes a concise and valid observation. However, as DGG states, there are too many of them, and any solution requires far more examination than a binary response to the proposal. The process of NPP and AfC are closely related but are nevertheless as different as they are similar, their functions are however beginning to converge somewhat (which is what DGG and I have been striving for) at least in terms of quality and application of notability standards and deletion criteria. The main difference is that NPP is strictly a triage (and please look that up if its military meaning is not immediately clear), while AfC can and does do some very easy fixes but is still not obliged to. Nevertheless, neither system is a Field Hospital or a MASH for lazy article creators or ones who pretend not to understand our laws of creation, especially UPE and COI creators (see WP:BOGOF) - the WP:ARS is the best venue for such articles that might show some potential for surviving AfD.
The Draft namespace was created thus allowing the useless WP:INCUBATOR (where articles were left to rot indefinitely) to be deprecated. Drafts can be quasi automatically deleted G13 if they are not touched for 6 months, and this is good, but the namespace should not deliberately be used as a backdoor route to deletion.
Over the past 12 months a lot of work has been done, and for once with excellent collaboration between the community and the WMF coordinated by MMiller (WMF), myself, DGG, Barkeep49, Primefac, Insertcleverphrasehere, Kvng, Vexations, and others to modernise the two systems with new technology, and the work done at WP:Copypatrol by Diannaa and Sphilbrick.
Nevertheless it's probably too late for the 18,000 pages tagged as {{advert}}, and nearly 13,000 tagged as {{COI}} mentioned by BD2412 - we simply just do not have the peoplepower to address them, and as clearly shown by the current backlogs in both systems where for example of the 700+ holders of the WP:NPR user right, only two (yes, 2) are doing well over 90% of the work.
We need fewer minor-rights hat collectors, and more truly skilled and qualified reviewers who can work quickly but judiciously through their respective article feeds - which incidentally are now both available at the combined feed. Kudpung กุดผึ้ง (talk) 23:24, 10 July 2019 (UTC)
  • Support. This is de facto already part of the WP:Draftify as used by NPP already, at least for cases of a clear conflict of interest of the author. This is of course, not yet policy, but would be good to be codified. — Insertcleverphrasehere (or here)(click me!) 23:41, 10 July 2019 (UTC)
  • 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)
    • 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)

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 trying to fight the deluge. I'd rather see us make more liberal use of WP:G11. Note that to a certain extent, banishing something to draft space doesn't keep it out of the search engines. There's wiki-mirrors out there that grab drafts and fold them into their mirrored mainspace, which then indeed does get indexed. With less SEO-juice than directly from here, true, but I've seen mirrored drafts end up at the top of search results. The other problem with tossing the garbage into draft space is that it just institutionalizes WP:BOGOF, which is certainly not what we want. I agree that moving spam out of mainspace is a good idea (which is why I'm only semi-opposed to this), but let's not toss it into draft. Just get rid of it, either through a more liberal G11 policy, or more aggressive use of WP:AfD. -- RoySmith (talk) 14:36, 12 July 2019 (UTC)
  • 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)
  • 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)
  • Oppose per Kvng. WP:IMPERFECT is still a policy last time I checked and this proposal flies in the face of it. Even poor articles, if they can be improved, are welcome says our policy, not "Poor articles should be hidden from sight". If the subject is notable, WP:FIXTHEPROBLEM, don't hide it. If the article is completely without anything that can be salvaged, G11 already applies. If there are bits that are okay, don't remove the whole thing but just the parts that are problematic (cf 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)

Proposal: To make it clearer that there are multiple Wikipedias (for several different languages), note the Wikipedia's language in the title logo for each WikipediaEdit

Many, if not most, users seem to have an incorrect mental model of what Wikipedia is. They seem to think that it is a single global encyclopedia, encompassing all of the world's languages. When users navigate to Wikipedia, they automatically go to the Wikipedia for the particular language that their computer is configured for, and therefore they often don't realize that there are actually multiple Wikipedias, one for each of several of the world's languages.

Why is this a problem? If a user has a mental model of a single Wikipedia that encompasses all of the world's languages, then they may get frustrated or angered by a Wikipedia page that uses a spelling in the particular Wikipedia's language, rather than in the topic's language of origin (if it's different). They may think that Wikipedia is appropriating, belittling, or ignoring the topic's language of origin. This is especially true for the English-language Wikipedia (as it is so comprehensive, and includes many topics about subjects whose names in English are different from the name in its language of origin). Users often do not understand that - being the English-language Wikipedia - article titles generally use the common spelling/usage in English - i.e., WP:COMMONNAME.

Proposal: Note each Wikipedia's language prominently near the top of each page. For example, change the text of the Wikipedia logo from:

Wikipedia
The Free Encyclopedia

to

English-language
Wikipedia
The Free Encyclopedia

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

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)
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)
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)
  • 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)
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)
  • 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)
  • 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 Other language Wikipedias? I'm not convinced that this misconception is widely held enough to justify changing the strapline. Phil Bridger (talk) 17:40, 29 June 2019 (UTC)
  • 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)
  • 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)
    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)
    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)

End the SignpostEdit

WP:SNOW Interstellarity T 🌟 11:38, 3 July 2019 (UTC) (non-admin closure)
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.

Should Wikipedia:Wikipedia Signpost be discontinued? wumbolo ^^^ 20:11, 2 July 2019 (UTC)

Survey (End the Signpost)Edit

  • Yes. Many have asserted that editorial changes would solve disputes, but the team of editors keeps getting worse and the harassment more vicious. I love reading old Signpost articles, but I believe that it has become a net negative and a waste of time. wumbolo ^^^ 20:11, 2 July 2019 (UTC)
  • No The Signpost (for which I volunteer) is not only the editing community's best news source for the Wikipedia movement, it is one of the best collators of community sentiment, helping all to understand where we collectively sit. Especially now, under the dictates from a distant home OFFICE, a sense of collaboration and community is key. Wumbolo, a non-contributor upset about perceived sleights, wants to kill what little community conversation we have outside massive RfCs and talk page discussions. Chris Troutman (talk) 20:19, 2 July 2019 (UTC)
  • No. This request by Wumbolo is insufficient because he cites the editorial board (for which I am a member) as the problem. My apologies to Wumbolo for any distress that our coverage has caused, but I'm not exactly empowered to change the direction of the Signpost here. I wasn't even involved with the last issue nor do I even have the influence or control to make publishing decisions. No offense to Smallbones, but the paper is currently structured to run like a benevolent dictatorship à la Leviathan. Our people are great, but our structure is what's lacking. –MJLTalk 20:34, 2 July 2019 (UTC)
  • No but the culture there needs to change (see [3] in particular), big time, and become much less of a walled garden. The Signpost has a purpose, and publishing mockery, anonymous allegations, and BLP violations is not part of it. Headbomb {t · c · p · b} 20:34, 2 July 2019 (UTC)
  • No Wumbolo has failed to present evidence that The Signpost is a net negative. Cullen328 Let's discuss it 20:36, 2 July 2019 (UTC)
  • Not yet. The Signpost needs to stop pretending Gamaliel and others didn't happen and stop pretending that policy doesn't apply to them, but there's still a legitimate function for it. ‑ Iridescent 20:37, 2 July 2019 (UTC)
  • Not Never One of my favorite things about Wikipedia. More please. -- GreenC 20:58, 2 July 2019 (UTC)
  • Not quite time: In my view, The Signpost has its issues: it seemingly always manages to inflame and infuriate its readership; the editor-in-chief needs to consider their words and actions long before the newsletter goes to press; and the culture over there needs serious change in light of Headbomb's good suggestions. Having said all that, however, I believe it serves its function as an internal newsletter quite well. For now, it should remain. Javert2113 (Siarad.|¤) 21:20, 2 July 2019 (UTC)
  • No. They are trustworthy and I enjoy their reporting. Anne drew (talk) 21:29, 2 July 2019 (UTC)
  • No - No reason has been provided, and we shouldn't delete something all because of one silly report. –Davey2010Talk 21:45, 2 July 2019 (UTC)
  • No. It may need a bucket of cold water thrown over it, and some extra heads to restrain some of its excitability ... but while its's not as good as in the old days, it remains a net positive. --BrownHairedGirl (talk) • (contribs) 23:51, 2 July 2019 (UTC)
  • No What is it about Wikipedians, babies and bathwater? Triptothecottage (talk) 23:56, 2 July 2019 (UTC)
  • No. The current issue around the Signpost is 100% fixable, and is only one case out of many that have gone otherwise fine. --Masem (t) 00:02, 3 July 2019 (UTC)
  • No There wouldn't be anything left of Wikipedia if we applied such a "nuke it because there is a problem" reasoning rather than "fix it because there is a problem". Meters (talk) 03:54, 3 July 2019 (UTC)
  • No a clear overreaction to this situation. MarnetteD|Talk 04:02, 3 July 2019 (UTC)
  • No. You dont burn a house down because there is a crack in one of the supporting columns but fix it. CASSIOPEIA(talk) 04:22, 3 July 2019 (UTC)

Discussion (End the Signpost)Edit


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.

Need your opinion on Wikipedia’s gender gapEdit

Hi all!

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 bowen-yu@umn.edu and I can share more info and plan a time to connect. Bobo.03 (talk) 19:36, 3 July 2019 (UTC)

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)
That is a terrible approach. — The Hand That Feeds You:Bite 21:43, 6 July 2019 (UTC)
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)
  • @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)
  • 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)
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)
@Bobo.03: As long you recognize that there's always going to be a gap, given the real world/historical bias against women. By that I mean, look at the heads of states and people in power from all of recorded history. Those are by far, men. Even today, we have roughly ~25 female heads of state, in ~200 countries (1/8th, or around 12-13%). Look at the same in science, arts, whatever. Again mostly men. Prior to the 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. Headbomb {t · c · p · b} 04:00, 8 July 2019 (UTC)
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)
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)

Accessibility (understandability) as a requirement for GA and FA class articlesEdit

The requirements for WP:B class articles require that the article "presents its content in an appropriately understandable way" and that "it is written with as broad an audience in mind as possible." This would logically mean that classes higher than B (WP:GA? and WP:FA?) would also have this requirement, but it doesn't. This could technically allow for articles to assume lots of prior knowledge before reading, without efforts to explain certain concepts where possible. As it stands now, the closest thing to an accessibility requirement is that the prose should be "clear and concise" for GA and "engaging and of a professional standard" for FA. Scientific papers usually pass these requirements, but they are written for experts in the field, not for laypeople; this type of writing shouldn't be what Wikipedia is aiming for.

My proposal is straightforward: mention accessibility as a requirement under the "well written" section of WP:GA? and WP:FA?. This could amount to simply adding a single word and it would make it crystal-clear for nominators and reviewers alike what is expected of the article.--Megaman en m (talk) 09:04, 4 July 2019 (UTC)

  • 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)
  • 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)
  • WP:Accessibility is part of our manual of style, and so could be linked along with the MOS pages currently cited by the GA and FA criteria, but I'm not sure that this is the same as what the original poster means by "accessibility". Phil Bridger (talk) 09:33, 4 July 2019 (UTC)
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:B? does a good job of explaining it, maybe we could use that as a base. For WP:GA? we could add accessibility as a third requirement under the 'well written' section, something like "c. The article must not require excessive prior knowledge and explains technical terms where possible.". For 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)
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)
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 Danish, but that would be missing the greater point. Technically, another way to increase consistency would be to just remove the accessibility requirement of 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)
One example I can think of is Crater (constellation), specifically the Features section. In my comments on the FA nom I, mentioned that section and invoked 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)
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)
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)
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)
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)
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)
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)
I agree with David Eppstein that there are many articles that we should include and allow to be at GA or FA class, in all academic topic areas, that are difficult for many people to understand. We should be stretching people. But, having said that, and as a postgraduate student of mathematics, I find many of our mathematical articles unnecessarily obfuscatory, which reflects most mathematicians' inability to write in a clear, understandable, way. I find most mathematics pretty easy to understand, but also find most of our mathematical articles pretty difficult to understand. Phil Bridger (talk) 19:14, 4 July 2019 (UTC)
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)
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)
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)
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)
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)
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)
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)
  • 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 penumbra of WP:GACR between "prose is clear and concise" and "stays focused on the topic without going into unnecessary detail", but I think it would be beneficial to mention it explicitly. Agree that it need not be a whole new criterion, and could be as simple as adding a few words. cf. 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)
So do most people agree that the sixth requirement of B class should be incorporated one way or another into the FA and/or GA requirements? It doesn't have to have its own section.--Megaman en m (talk) 06:34, 6 July 2019 (UTC)
  • 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)
  • I'm leaning oppose on this proposal given WP:CREEP and the vague possibility that a sufficiently niche topic that couldn't be written from a general point of view would thus be excluded from FA status. Furthermore, I'd argue that the following sections from the 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 (talkcontribs) 05:31, 7 July 2019 (UTC)
@Trovatore: If asked, the nominator should be able to state who the audience of the article should be. This way, the reviewer can gauge how they should enforce the understandability requirement. For example, (most?) biographies should be written for: everyone. If the reviewer finds unexplained jargon, they should ask for it to be explained. Articles on the grammar of a language should be written for: people with basic background in linguistics/grammar. Writing such an article for people without the necessary background would be nigh-impossible; most of the article would end up explaining basic linguistics rather than talking about that language's grammar. It would be up to the nominator to argue that it is not feasible to write the article for "everyone". There is of course still a risk of not agreeing on what "basic background in linguistics" actually is. This problem is not unique to understandability however. The prose being "clear and concise" and what constitutes 3b. "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)
@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)
@John M Wolfson: My answer above to Trovatore might ease your fears of having niche articles inadvertently excluded from FA/GA. On the current FA requirements: I don't agree they enforce understandability as mentioned in 6. 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)
@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 (talkcontribs) 07:52, 7 July 2019 (UTC)
@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)
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)

I think most editors instinctively understand that a GA should of course also satisfy the general B-class criteria. Although there are some complications around this idea: B-class assessment is usually made by WikiProjects, which adapt the B-class criteria to their special needs. And somewhat annoyingly, the numbering of the 6 GA criteria is so different from that of the 6 B-class criteria that it is seriously confusing. B1 is strengthened to GA2, B2 is covered by GA2-GA4, B3-B4 are covered by GA1, B5 is essentially GA6 + asking for infoboxes, and B6 is not explicitly covered by GA1.

The last point, which Megaman en m has discovered, is because GA1b doesn't require full MOS-compliance but only certain sections, not including MOS:JARGON. I think this is not because MOS:JARGON shouldn't be applied but because in contrast to what is listed in GA1b it's just a tiny section. Maybe it could be added to the list anyway?

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 WP:MEDRS sources regardless of what is supposed to be supported) or about what is in their scope. Hans Adler 11:53, 7 July 2019 (UTC)

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

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)

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

Proposal: Incorporate the 6th requirement of B-class to GA and possibly FA (the exact wording is a topic for later). In other words: Make GA and/or FA articles formally comply with WP:AUDIENCE.

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)

VoteEdit

  • 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)
  • 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:GACR 1a with a link 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)
  • 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)

RfC: Add 'create an article' option in the interfaceEdit

Should we add a "Create an article" button/link in the interface/sidebars? Headbomb {t · c · p · b} 02:04, 7 July 2019 (UTC)

The problemEdit

One thing that always puzzled me is why we don't have a "create an article" button in the sidebars. Or similar. Imagine you want to get involved on Wikipedia, and you barely know a thing about it, but you want to create an article about say Hymenopterida, an insect superorder.

Tell me, how do you figure how to create that. There's nothing to guide you. If you search for 'create' in your interface, you have the option to create a book. There's nothing to create an article. There's no help link, no create button, no draft option, no tutorial, nothing. So, I propose we add a "Create an article" link/button to the interface, which would direct people to a landing page similar to

Non-registered Non-(auto)confirmed (Auto)confirmed Extended confirmed  

Welcome to Wikipedia, the encyclopedia anyone can edit! Because you do not have an account, you cannot yet create articles directly in the encyclopedia. You must first register an account and gain experience as a Wikipedia editor.

Once you have a registered an account, the following pages will help you gain this experience

  • Help:Getting started, which has several tutorials and primers about Wikipedia conventions and policies
  • Help:How to edit, which explains how exactly to edit the encyclopedia
  • Wikipedia:Sandbox, a page where you can freely experiment without having to worry about breaking anything

After you have created an account, you will be able to create an article through the Article wizard, which will guide you through the process, and explain basic concepts like notability, verifiability, and what reliable sources are. At the end of the process, your article will be created as a draft, and experienced editors will review it. Be aware that the reviewing process currently has a 2+ months backlog, with 3,985 pending submissions waiting for review.

which 'tab' you would land on would depend on your user access levels, and we could customize the advice/information to target the experience level of the person landing on that page. Headbomb {t · c · p · b} 19:10, 7 July 2019 (UTC)

!Vote (old proposal, withdrawn)Edit

This discussion has been closed. Please do not modify it.
The following discussion has been closed. Please do not modify it.
  • Support as proposer. Headbomb {t · c · p · b} 02:04, 7 July 2019 (UTC)
  • Support. Sounds like a great idea that would help convert our readers into editors. The article wizard is an ideal place to direct new editors to, since it encourages them to use non-public-facing areas of Wikipedia (the sandbox, a user space sandbox, and the draft space) to create content. These areas are low-pressure "safe zones" where editors can get familiar with our editing tools (wikitext or the VisualEditor) without the pushback of being reverted after making a mistake. Hopefully, these zones help new editors learn the ropes and eventually become comfortable enough to participate in other areas of Wikipedia. — Newslinger talk 02:35, 7 July 2019 (UTC)
  • Oppose - Editors should not be creating articles before they know something how how to edit Wikipedia, what its aims and policies are, and how articles should be made. Adding a "create an article" link is only going to provoke a lot of badly written, poorly sourced, stub and sub-stub from people more interested in self-aggrandizement then in improving the encyclopedia. Let people spend some time here first during which they can learn the lay of the land and, in the course of it, learn how to create an article. Beyond My Ken (talk) 04:38, 7 July 2019 (UTC)
  • Oppose within the current framework. See my comment under discussion. Espresso Addict (talk) 05:12, 7 July 2019 (UTC)
  • Oppose At this age, Wikipedia should not be encouraging brand-new editors to create articles upfront; apart from the link being misleading because new editors and IPs cannot create articles technically. People should reasonably be conversant with wikitext and minor tasks until such time they intuitively find the way to create articles, that's the time they should do that. That process is an important learning curve and may takes days, week or months depending on the prior experience of the individual, but it does not matter. – Ammarpad (talk) 05:31, 7 July 2019 (UTC)
  • Oppose as premature. See my comment in the discussion section. Kudpung กุดผึ้ง (talk) 06:16, 7 July 2019 (UTC)
  • Oppose per above. We need to encourage the improvement of existing articles more than the creation of new crap ones. MER-C 11:07, 7 July 2019 (UTC)
  • Oppose per comments by Ammarpad above and Kudpung below. At the moment, the most direct way to create a new article comes either from first searching the wiki for existing references, or expanding upon a redlink, both good starting points for a new editor. MarginalCost (talk) 13:13, 7 July 2019 (UTC)
  • Oppose the existing procedure forces the person further along the learning curve before creating an article. Granted, possibly not far enough, but why make things worse?--Wehwalt (talk) 14:11, 7 July 2019 (UTC)
  • Oppose - AfC is drowning in unreviewed drafts. I don't believe NPP is much better off. Anyone who knows enough to be able to write a basic article, knows how to go about doing so (or ask how). Anyone who doesn't, shouldn't be having it made easier for them. Nosebagbear (talk) 15:28, 7 July 2019 (UTC)
  • Neutral - I support the sentiment/aim; there are probably people who could be great editors intimidated by the learning curve or where to look. But, and this might be because I've spent some time on Wikia lately (where there is a page in the interface for this), I fear this is likely to get people to start creating articles just because they can (i.e. not good ones) in a way that's likely to increase low-quality or speedy-able articles (and increase work for people involved in their maintenance) much more than it's likely to find good ones. - Purplewowies (talk) 16:33, 7 July 2019 (UTC)
  • Oppose – I agree with Ammarpad's and Nosebagbear's reasoning. Levivich 16:36, 7 July 2019 (UTC)

!Vote (new proposal)Edit

  • 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. Headbomb {t · c · p · b} 19:20, 7 July 2019 (UTC)
  • 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)
@Sphilbrick: I moved your !vote to the new section, since you made it after the revised proposal. However, time-wise it's pretty close to when things were reshuffled, so I'm pinging you to make sure your !vote reflects the current proposal and not the old one. Headbomb {t · c · p · b} 19:24, 7 July 2019 (UTC)
Headbomb, Thanks for the heads up. S Philbrick(Talk) 20:59, 7 July 2019 (UTC)
@Sphilbrick: Wikipedia:Article_wizard/Referencing also now warns against copy-pasting from sources, for what it's worth. I hope this brings you in the support category. Headbomb {t · c · p · b} 21:05, 7 July 2019 (UTC)
  • 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)
  • 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 drafts in non-public-facing areas of Wikipedia (their user space sandbox and the draft space). These areas are low-pressure "safe zones" where new editors can get familiar with our editing tools (wikitext or the 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)
  • Support I think this is an excellent proposal. Giving new people proper direction on how to get started is a good thing. CThomas3 (talk) 21:40, 7 July 2019 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • Support a trial for the many good reasons articulated above (and below) by Elmidae, Tryptofish, Kudpung, and others. Happy days, LindsayHello 06:15, 12 July 2019 (UTC)
  • Support giving it a try at the very least. XOR'easter (talk) 17:26, 12 July 2019 (UTC)
  • 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)
  • 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)
  • Support as trial per Newslinger. Directs users to the correct places and tutorials, before they make bad articles that get deleted. ~~ OxonAlex - talk 09:30, 16 July 2019 (UTC)

Discussion (Create an article)Edit

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)

  • 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)
    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 (tc) 05:58, 7 July 2019 (UTC)
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)
  • @Espresso Addict and Johnuniq: If not AFC, then somewhere (e.g. Wikipedia:Your first article). They need to know how they can create articles. Yes this causes low-quality stuff to be submitted, but newbies that want to create articles need to have a clear path on how to do this. Headbomb {t · c · p · b} 05:49, 7 July 2019 (UTC)
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)
Well, whatever is at the end of that link (WP:Create an article/WP:Article wizard/WP:Your first article/WP:Whatever we decide) could be a general landing page, with a short explanation that to create articles in the mainspace, you need to have some Wikipedia experience, or you go through the article wizard and upload them as Drafts so others can review them. Headbomb {t · c · p · b} 06:09, 7 July 2019 (UTC)
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)
  • 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)
    • 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)
  • Updated with just 273‎ bytes to address concerns raised in this section....Wikipedia:Article_wizard/Referencing.--Moxy 🍁 06:45, 7 July 2019 (UTC)
  • 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)
  • 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)

@Espresso Addict, Kudpung, Nosebagbear, Beyond My Ken, MarginalCost, MER-C, Wehwalt, Purplewowies, and Levivich: How about a landing page that looks something like User:Headbomb/Create an article? I've also added the mockup to the above so you could see what it would look like. Which 'tab' you would land on would depend on what useraccess level you have, so this could be tailored to the experience level of each person landing there. Headbomb {t · c · p · b} 19:07, 7 July 2019 (UTC)

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)
@Levivich: well, the new !vote section is up. Headbomb {t · c · p · b} 19:30, 7 July 2019 (UTC)
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)
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)
Kudpung, I'm also not aware of an active project on this, though I am currently only following the stuff on Phab that is directly related to the NPP wishlist items. — Insertcleverphrasehere (or here)(click me!) 05:12, 8 July 2019 (UTC)
@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)

Article Interlink PagesEdit

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 disambiguation page or a Set Index Article, and would consist of:

  • 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 Article Interlink Page is for a person who appears in multiple articles. It should be converted to a full article only if they can be shown to have significant coverage in multiple independent reliable sources that meets Wikipedia's notability guidelines such as for general biographies or for 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:AFC and 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)

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)
@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)
I think it could be case where WP:XY applies. Emir of Wikipedia (talk) 21:26, 7 July 2019 (UTC)
  • 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)
  • 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)

Hidden category: Pages which will not work if movedEdit

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)

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)
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)
If we take the example you gave of {{Year in various calendars}}. Without diving into the code that much, I don't see how any change in titles should break its usage if it was coded correctly. You have about 4 styles available: 3 BC, AD 1, 2000 and 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)

Minceraft easter eggEdit

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

My account
My talk
My edits

09:14, 10 July 2019 (UTC)

Discuss at Talk:Minecraft. Doesn't fit here. (And please see WP:SIGNATURE.) — Arthur Rubin (talk) 10:05, 10 July 2019 (UTC)

RfC: WP:Dashboard on sidebarEdit

As it (to me at least) appears to be the easiest way to access ongoing discussions, I think it should be on the sidebar (maybe below the Com. Portal). Should it? Remagoxer (talk) 10:04, 11 July 2019 (UTC)

Yep, go for it. ——SerialNumber54129 10:12, 11 July 2019 (UTC)
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? Remagoxer (talk) 10:29, 11 July 2019 (UTC)

Semi-protect templates by defaultEdit

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)

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)

Password policy for users with certain advanced permissionsEdit

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)

See m:Password policy. The most common attack vector is actually passwords shared with and leaked from other sites. It doesn't matter how complicated a password is if it's being read elsewhere. Users with advanced permissions also have access to 2FA. -- zzuuzz (talk) 09:41, 12 July 2019 (UTC)
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)
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)

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)

It is available. See Help:2FA. — JJMC89(T·C) 03:52, 15 July 2019 (UTC)

Disambiguation namespaceEdit

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)

  • @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)
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)
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)
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)
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)
Lists are different from disambiguation pages, and serve a different purpose. Banana Republic (talk) 03:04, 15 July 2019 (UTC)

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

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)
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)
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)
Nope, I'm wrong. Interesting. Maybe that should be a request in for the devs. --Izno (talk) 04:27, 15 July 2019 (UTC)
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)

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)

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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
In reply to the post of 02:14, 15 July 2019 (UTC): yes - the notice at Wikipedia talk:Namespace#Disambiguation namespace and this refers to Wikipedia talk:Disambiguation/Archive 33#Dab page location which in turn refers to Wikipedia:Village pump (policy)/Archive 50#ALL disambiguation pages to end "(disambiguation)", Wikipedia talk:Disambiguation/Archive 31#Hatnote redirects to disambiguation pages. and Wikipedia:Village pump (policy)/Archive 84#Uniform Disambiguation page naming. Some of these discussions link to other previous discussions. --Redrose64 🌹 (talk) 19:49, 15 July 2019 (UTC)
  • On the idea of somehow tying DAB to wikidata... OH HELL NO! Blueboar (talk) 20:00, 15 July 2019 (UTC)
  • I'd oppose this. Seems like it would require a massive amount of work to implement a solution in search of a problem.--CNMall41 (talk) 22:14, 15 July 2019 (UTC)

Option to disable Wikimedia project greetingsEdit

Whenever I visit a Wikimedia Foundation website for the first time, it always leaves a welcome message on my talk page.
Granted, the talk pages for different projects are kept separate, but these messages seem presumptuous at best.
It would be nice if there was an option to opt out of greetings, so that I could go from project to project without needing to bother with dismissing notifications. Daniby2013 (talk) 05:26, 16 July 2019 (UTC)