Jump to content

Wikipedia:Village pump (proposals)/Archive 153

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

RFC: Let's add Template:Draft to all drafts

Moved from: Wikipedia:Village pump (policy)#RFC: Let's add Template:Draft to all drafts

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Should we add {{Draft article}} to all pages in the Draft namespace (see Draft:Medicine Trails for how that looks), other than those with {{AFC submission}} (and possibly drafts created by people who are on the opt-out list). Headbomb {t · c · p · b} 18:19, 20 August 2018 (UTC)

!Vote

  • Support as proposer. The benefits of the template are rather huge, especially to newcomers going through WP:AFC (in no specific order):
  1. Warnings if articles/redirects already exists in the mainspace (see Draft:List of Nicktoons)
  2. It clearly identifies the page as a draft, in case someone links to the page directly, accidentally/maliciously presenting it as a real article when it's not
  3. Links to find sources, helping to write the article
  4. Links to various automated tools (e.g. citation bot) to help deal with tedious aspects. (See [1], "User-activated" = likely via template.)
  5. Links to logs of the associated mainspace articles to help reviewers identify the re-creation of a topic deleted 42 times and other similar issues.
  6. Adds a 'time since last edit' to help gauge if it's actively editing or not
  7. Adds a button to facilitate submission to WP:AFC and reduce the number of good drafts that go unsubmitted / G13'd
  8. Categorizes the page in Category:Noindexed pages
  9. Whatever bot would add this could respect Template:Draft article/Opt-out for people who don't want this to be added to drafts they create, if this is desired. (This is not a live feature, but it can be seen in the sandbox version here.)
I can't think of any drawbacks. Headbomb {t · c · p · b} 07:12, 26 August 2018 (UTC)
@Ivanvector: G13 already applies to all pages in the Draft namespace. – Finnusertop (talk ⋅ contribs) 18:57, 20 August 2018 (UTC)
Yeah but this proposal would preemptively tag pages with a countdown, casting the net just a bit wider than current. Thus, I'm opposed. Ivanvector (Talk/Edits) 19:11, 20 August 2018 (UTC)
You however forget the obvious: This would also warn people the drafts are about to be G13'd, and also make the articles much easier to improve and turn into articles, thus saving a lot more from G13. Otherwise G13 bots will just delete without any warning. Opposing this doesn't reduce the amounts of G13 anymore than opposing calendars to be posted in the office reduces aging. Headbomb {t · c · p · b} 19:45, 20 August 2018 (UTC)
Deleting content just because it's old is pointless antagonization of new content creators, and until there's a proposal to deprecate G13 completely I'm opposing all proposals related to it. It's a long-standing personal policy. You can take the comment for what it's worth in context of this discussion, probably not much, but I'm opposed and I won't be convinced otherwise. It might be a stupid hill to die on, but here I am. You should spend your energy badgering someone else. Ivanvector (Talk/Edits) 19:56, 20 August 2018 (UTC)
The "good reason" is found in our core content policies, which require VERFICATION, forbid OR, etc. Without a reversible deletion clock on draft material, the draft space could be exploited by writers or misunderstood by readers in ways that bypass these core CONTENT policies.... assuming draftspace is "content" at all. NewsAndEventsGuy (talk) 20:10, 20 August 2018 (UTC)
Facepalm Facepalm no, there is no good reason to delete any page for the sole reason that it's old, which is the sole function of WP:G13. If there are "core content issues" with pages in the draft space, we already have methods and processes to deal with them, and they do not require a timer. G13 is only "delete old pages". Ivanvector (Talk/Edits) 14:26, 21 August 2018 (UTC)
Double-double facepalm to you for not acknowledging the argument -- you have characterized draft material as "content" and just ignore WP:CCPOL simply because its in draft space. When a bold edit in article space violates CCPOL oftentimes that text is reverted within the hour. Why should we tolerate the same violation forever just because it is in draft space? NewsAndEventsGuy (talk) 14:54, 21 August 2018 (UTC)
Triple-dog-facepalm on you, then, for ignoring my argument. Of course CCPOL is central; if a violating edit occurs on a draft it should be repaired immediately, and there is no reason not to do so. G13 excuses editors waiting six months to fix such problems or ignoring them altogether, and then throws out the baby with the bathwater. It's not a solution for content issues in draft space, it just deletes all content good and bad because a timer expired. Ivanvector (Talk/Edits) 11:09, 23 August 2018 (UTC)
I didn't go further down this offtopic road because its an offtopic road, but in reply I didn't ignore it. I just chose to not observe the obvious flaw in your reasoning. In your mind, the possibility that an editor (A) might - maybe - notice and then (B) might - maybe - care enough to act..... if I understand you correctly thhat potential is sufficient to give unnoticed CCPOL vios an indefinite waiver. I can be convinced that is a good thing by tweaking CCPOL so it says draft space is indefinitely exempt, but I doubt the community will approve such a thing. A long countdown on the selfdestruct timer strikes a nice balance between honest diligent content development and maintaining some standards. NewsAndEventsGuy (talk) 12:33, 23 August 2018 (UTC)
I'm with you up to "tweaking CCPOL so it says draft space is indefinitely exempt". Aren't we both arguing the opposite of that? That drafts are no more exempt from content policies than any other article? That if there's a CCPOL violation in draft space it should be dealt with? Same as in article space? As for editors maybe noticing things, that's how it works in article space - errors don't get corrected until someone notices them. I would say we agree to disagree, but now I'm not sure which point we're disagreeing on. Ivanvector (Talk/Edits) 12:39, 27 August 2018 (UTC)
Thanks for engaging, I've taken us off on this tangent far enough. Carry on NewsAndEventsGuy (talk) 12:46, 27 August 2018 (UTC)
It'd be pretty trivial to add a "submit to AFC" button, like there is in {{User draft}}. But that's a separate concern, which you can bring at Template talk:Draft article.Headbomb {t · c · p · b}
  • Support and Strong Support if you can add a "submit to AFC" button. I've have lost count of the endless enquiries at OTRS who ask how it will be until their draft page goes live - but their page has no banner and it's just sitting there. I then tend to go in and add the AfC template to the top so they can press the button! Ronhjones  (Talk) 22:46, 20 August 2018 (UTC)
@Ronhjones: See Template:Draft article/sandbox. Needs testing however. Headbomb {t · c · p · b} 23:13, 20 August 2018 (UTC)
  • Support now that the template text has been significantly rewritten. Thanks. Mike Peel (talk) 18:10, 25 August 2018 (UTC) Oppose in current form. Drop "This is not a Wikipedia article:" and "It should not necessarily be considered factual or authoritative." from it and I'll consider supporting it, though, as some of it (particularly the finding sources links, but also the statement that it is a draft) is useful. Otherwise it's unnecessarily disparaging for editors writing the draft articles. As a potential middle-ground, add the caveat of "yet" to both of those statements (or add it to the first and drop the second). In general, we should focus on supporting new editors, not disparaging them. Thanks. Mike Peel (talk) 22:50, 20 August 2018 (UTC)
e/c That's yet another perennial non-reason described generally at WP:Arguments_to_avoid_on_discussion_pages#Surmountable_problems, though I see below that Headbomb is working with your comments to improve it, which is great NewsAndEventsGuy (talk) 23:19, 20 August 2018 (UTC)
@NewsAndEventsGuy: I clearly posted my rationale for opposing this in its current form, with constructive suggestions for how to improve it. Dismissing it as "yet another perennial non-reason" is quite offensive and inappropriate. Mike Peel (talk) 23:47, 20 August 2018 (UTC)
Thanks for the make-it-better feedback which as Headbomb advised is better discussed elsewhere. "Surmountable problems" and the reasons they should be avoided in these discussions, has been a part of the page I linked since 2011, and its origins arose in a similar list of arguments to avoid in deletion discussions way back in 2007 after a talk discussion. The make-it-better feedback is welcome, thanks! But fact we need to work on it is a "surmountable problem", not a very weighty reason for the closer to consider, as described at WP:not counting heads. Sorry if you're ticked off, but referencing longstanding procedure is hardly inappropriate. NewsAndEventsGuy (talk) 00:32, 21 August 2018 (UTC)
@Mike Peel: I don't really see the "disparaging-ness" of the template. The first (This is not a Wikipedia article) is a factual statement: it's not an article, it's a draft. The second could probably go as redundant / implied by "work in progress", but the exact wording of the template should be likely be discussed on the talk page more than here. Headbomb {t · c · p · b} 23:16, 20 August 2018 (UTC)
The version at Template:Draft article/sandbox is looking better, and I've done some copyediting there to help improve it. If that can be made live, then we're heading towards something that I can support. Thanks. Mike Peel (talk) 23:43, 20 August 2018 (UTC)
  • Oppose as is, but Neutral on the idea in general. By the latter I mean that I am also neutral on the idea of automating the welcoming of new users, which seems like the same sort of thing, although there's never been broad consensus to do so. Oppose as is because the main idea would seem to be to get the links in front of a new user. But when I take a closer look at the links, I don't know that they would actually be of help even if the user did click on them.
  • The first line is basically "have you ever used a search engine? If you do, Wikipedia prefers Google" followed by a bunch of paywalled sources and -- the one link I do like -- TWL.
  • The tools on the second line are more useful for an experienced editor. They're the sort that would add to the perception that Wikipedia is not user-friendly and/or that editing is too complicated. In other words, it seems like those tools are things for down the line, not right when starting an article. — Rhododendrites talk \\ 23:44, 20 August 2018 (UTC)
  • Support per Ronhjones it sounds like the intention and functionality of draft space is not as clear to new users as it is to us. The sandboxed version with the "Submit" button seems like it would be particularly useful here. I don't think dropping an introduction template on each new draft is an undue impediment to the work of regular editors using draft space, so it seems like adding this template has potential to address a problem with little-to-no downside. Cheers! Ajpolino (talk) 23:48, 20 August 2018 (UTC)
  • I've even found pages, after an OTRS post, that had The "Draft article not currently submitted for review" banner on the first edit, and they just wiped it out. When I've explained that they had lost the banner (with the submit link) they are surprised. I think the AfC banner is so big, that they just want it out of the way. We need to ensure we keep any banner as small as practicable. Ronhjones  (Talk) 00:15, 21 August 2018 (UTC)
  • Support This would accomplish the dual purpose of informing readers of the draft nature of the page, as well as provide potential new editors with tools to help them along in the process. — AfroThundr (u · t · c) 02:02, 21 August 2018 (UTC)
All editors actually. I know the first thing I do when reviewing a draft is run Citation bot on it. The logs are new, but they're pretty great if you're looking at bands and people. Headbomb {t · c · p · b} 02:07, 21 August 2018 (UTC)
  • Support, Informs and provides tools to help editors find sources? Sounds like an a 2-birds-one-stone situation. Opposers at present seem off base to me; there is nothing factually incorrect about the writing of the notice. — Insertcleverphrasehere (or here) 02:09, 21 August 2018 (UTC)
  • Oppose as a traditional template - Unnecessary. This has always been an optional informative message for those who wish to display it, similar to {{user sandbox}}. I presume this would be done by bot. What if an editor removes it for various but sensible reasons? Would the bot then re-add it? That aside, I strongly concur with Ivanvector above. I would also oppose the addition of an AfC button. — Godsy (TALKCONT) 02:23, 21 August 2018 (UTC)
@Godsy: the template supports a minimalist minimalist output for those who desire it, and I'm sure any bot that deploys the template can easily be told not to revert war with people who remove the template for whatever reason (and be exclusion compliant). Headbomb {t · c · p · b} 03:13, 21 August 2018 (UTC)
By traditional template, I mean any template actually placed on the page. I also concur with Graeme Bartlett below. — Godsy (TALKCONT) 03:25, 21 August 2018 (UTC)
  • Oppose if it is in draft space it is a draft, and unindexed, if anyone copies it as they are entitled to they may or may not remove the draft header. When the page is move to mainspace, it causes more work to cleanup. Graeme Bartlett (talk) 02:51, 21 August 2018 (UTC)
@Graeme Bartlett: the template hides itself if it is placed in mainspace (it will give an error message when previewing though). Headbomb {t · c · p · b} 03:28, 21 August 2018 (UTC)
If that is the case then no one will notice it in mainspace. If it does eventuate, then it should go in a hidden category so that someone can clean it up. But I see no reason to tag a draft with a compulsory draft tag. Graeme Bartlett (talk) 06:13, 21 August 2018 (UTC)
That's in the works. I need a good category name for that, but it's trivial to implement once I have it. Been working on a lot of little other things though. Headbomb {t · c · p · b} 09:48, 21 August 2018 (UTC)
  • Weak support (preferring Sitenotice deployment): An on-screen advisory box for Drafts should provide value, both to highlight that the article sits outside mainspace and to advise the inexperienced on the steps towards completing and publishing. (I agree with Rhododendrites’s analysis that the current template’s Find sources and Automated tools lines are often going to be too specialist for the latter purpose.) Delivering the message via Sitenotice as highlighted by xaosflux in the discussion below seems a better option than intruding on each draft’s content. AllyD (talk) 08:00, 21 August 2018 (UTC)
The templates are not just for newbies, they're for everyone, so they need to serve multiple needs. Headbomb {t · c · p · b} 09:48, 21 August 2018 (UTC)
Why is it not only for newbies? Why should a template be forced to drafts of experienced users against their wishes? –Ammarpad (talk) 10:18, 21 August 2018 (UTC)
Draft space is collaborative and open to everyone, no one owns drafts. If you want to be left alone working on a thing, that's what user drafts are for. Headbomb {t · c · p · b} 11:26, 21 August 2018 (UTC)
That's an odd response. The point is that including links that aren't useful for newbies, and in fact potentially confusing, defeats the point. If the point is to help the experienced users working in draftspace at the expense of newbie experience, that's problematic. Either the point is to facilitate monitoring newbie contributions (maintenance, pushing them towards AfC, and/or, as others have stated, making it easier to delete their drafts), or it's to provide resources to help them with the editing process. In the second I don't think it succeeds, and it's only the second that I would be supporting. If we're being realistic, though, the practical function of draftspace is the former. We like to pay lip service to the idea of using it to collaboratively edit, but I'd like to see some evidence of experienced users using draftspace to collaborate in a way that couldn't just happen in mainspace. Other experienced users that use draftspace wind up abandoning it when they realize nobody actually comes across their drafts for collaborative purposes and it offers only downsides vs. userspace. — Rhododendrites talk \\ 14:57, 21 August 2018 (UTC)
@Rhododendrites: We should have links that's useful for everyone dealing with drafts. Take a look at {{Draft article/sandbox}}, you have links to help editors find sources (useful to everyone, but mostly noobs), and links to assist formatting citations (useful to everyone, especially newbies), with suggestions on how to improve it (noobs), and fix common errors and problems that are otherwise hard to spot (mostly advanced editors), and links to help submit to AFC (noobs). There's something for everyone, even if somethings will be more useful to certain editors than others. Headbomb {t · c · p · b} 15:07, 21 August 2018 (UTC)
I've looked at the links. They look to be the same ones I described in my !vote above, no? — Rhododendrites talk \\ 15:14, 21 August 2018 (UTC)
  • Oppose as redundant make-work. There's already a word "Draft" in front of the name of the article. That's sufficient for me. --Jayron32 15:17, 21 August 2018 (UTC)
  • Support Informs people who find drafts as to what it is. SemiHypercube ✎ 17:46, 21 August 2018 (UTC)
  • Oppose Neutral. If we want this to show up on all Draft pages, it would be better to add it via Common.js or even a MediaWiki extension, rather than creating hundreds of thousands of extra revisions to slow down the database. Plus I honestly don't find this template useful. If someone knows how to create an article draft, I'm sure they know how to use search engines. And do we really need to tell them what a draft is? The list of automated tools are useful, but it seems like we should put them under the Tools menu rather than in a template as they would be useful for all articles, not just unsubmitted drafts. Kaldari (talk) 02:49, 22 August 2018 (UTC)
I know how to use a search engine, but this is a still a major time saver. Steps to go to look up Foobar in both Google Scholar and Google Books.
  • Open new tab. Go to google. Search for Google scholar. Click google scholar link. Type or copy-paste "Foobar". Click Search. Browse results.
  • Open new tab. Go to google. Search for Google books. Click google books link. Type or copy-paste "Foobar". Click Search. Browse results.
Are there more efficient ways to get there? Sure, but I never remember them. Or, with this template, it's "Click", "Click", and boom, you're there, without having to double-check your inputs, or remember to -wikipedia your searches. Adding via common.js or whatever might be possible, but that very likely wouldn't interact with AFC templates, which supplant {{Draft}} when they are used. I'd support making the tools available by default (i have them on mine, but that's from a .js confits), few people would even notice them or remember that they're even there. Headbomb {t · c · p · b} 03:05, 22 August 2018 (UTC)
[as Ron Popeil]: Aren't you sick of how hard it is to google things? don't you wish there were something that could just do the mousing and clicking for you? But wait, there's more! now there's no need to choose between all those confusing Bings and DuckDucks and Googles because the world's largest reference work will just choose Google for you when you create a page!" Sorry, Headbomb. You aren't necessarily wrong, but this is all I could think of reading the above. — Rhododendrites talk \\ 03:20, 22 August 2018 (UTC)
You are absolutely right of course. perhaps we should put a series of links so that people can bing it instead.*cringe... cringe* — Insertcleverphrasehere (or here) 03:56, 22 August 2018 (UTC)
I just use Mozilla Firefox which has search keywords. Ctrl-L, g, foobar, enter. Takes a couple seconds, less than clicking an unpredictable link. Sure, we should tell everybody to use appropriate (FLOSS) software for their wiki work, but maybe there are better ways. --Nemo 18:51, 22 August 2018 (UTC)
  • Neutral. Don't really care if this does get implemented but umm, doesn't it kinda defeat the purpose of having a Draft namespace? It'd just be redundant. -- œ™ 03:08, 22 August 2018 (UTC)
@OlEnglish: look at {{Draft article/sandbox}}. The only redundancy is specifically marking things as a draft, but that's a benefit/protection against people using drafts as fake articles, and also gives links/guidance on what drafts ares and what to do with them. Headbomb {t · c · p · b} 03:13, 22 August 2018 (UTC)
  • Oppose I fail to see the benefit of this even to newbies and even more perturbed about why it should be forced upon users who know better and who don't want it despite it being essentially pointless and generally needless. Seems to be classic example of a solution looking for a problem. –Ammarpad (talk) 18:32, 22 August 2018 (UTC)
  • I find the proposal bizarre. The template currently reads "It is a work in progress that is open to editing by anyone. Please ensure that [it] meets our core content policies [...]", which is valid for any Wikipedia article (cf. Mike Peel's comments above). Are we going to put it on 5 million articles as next step? If this namespace confuses people and gets editing stuck, maybe it's more effective to move the 30k articles out of the namespace and use normal wiki processes to handle them. --Nemo 18:59, 22 August 2018 (UTC)
  • Oppose as pointless make-work. Mangoe (talk) 14:13, 23 August 2018 (UTC)
  • Oppose per WP:CREEP and WP:TCREEP. Andrew D. (talk) 13:53, 24 August 2018 (UTC)
  • Strong oppose We don't need the template on all articles in the draft namespace. Felicia (talk) 19:58, 25 August 2018 (UTC)
  • Neutral - struck my "oppose" !vote above but not the comment. I see after reading more of the discussion below that nothing about the changes proposed here has much to do with modifications to G13 and so I have no reason to oppose the proposal, though I remain opposed to blanket stale draft deletion. I have more thoughts about how we use draft space now but that's for a different discussion. I'm calling this comment "neutral" because I don't really support the proposal, but I see nothing really wrong with it. If we're going to do mass-templating (or automatic templating) of drafts, I think it would be better to combine {{draft article}} with {{Afc submission}} and just make one template that alerts readers to the page's status as a draft and also navigates editors through the AFC process. This isn't that, but it's a start I suppose. Good work on the template, whatever happens. Ivanvector (Talk/Edits) 12:54, 27 August 2018 (UTC)
  • Support The examples at Draft:Medicine Trails and Draft:List of Nicktoons convince me this will be helpful to some new editors. Whilst I firmly support WP:NOTAG, this template seems useful. Not to everyone, but to enough. Quiddity (talk) 19:28, 28 August 2018 (UTC)
  • Oppose Neutralthis process is headed in the right direction but I think the opt-out page should be automatic for at least every autoconfirmed editor if not every 30/500 editor. As far as I can tell from the discussion below that isn't the plan (or isn't technically feasible). However the benefit for newer users is real so I can't quite bring myself to oppose. Best, Barkeep49 (talk) 03:44, 29 August 2018 (UTC) Limited use for new editors active annoyance for experienced ones. Best, Barkeep49 (talk) 04:46, 29 August 2018 (UTC)
@Barkeep49: I really don't see why we should assume that experienced editors would not make use of the template. I'm an experienced editor, and I make use of this template all the time when I'm in draft space. It'd be ridiculously easy to opt-out, so let's not assume the preference of 42,000 people. It'd literally be a 5 second thing. Headbomb {t · c · p · b} 03:51, 29 August 2018 (UTC)
@Headbomb: I mean the same could be said in reverse - let's have it so auto patrolled (4k) or extended confirmed (40k) would opt-in to get the notification. It would literally be a 5 second thing if they wanted to opt-in. Best, Barkeep49 (talk) 04:00, 29 August 2018 (UTC)
Opt-in programs rarely, if ever, get noticed. For instance, {{AFD help}}, a decidedly noob-centric template is added to every AFD now. About 90 advanced editors, out of 42,000 opted out. That's a 0.2% opt out rate. Making that template display on an opt-in basis would have meant pretty much mean being entirely ignored, because no one would have seen it in the first place. Headbomb {t · c · p · b} 04:06, 29 August 2018 (UTC)
Headbomb, no one will ever remember the opt-out template and it will get in the way of actually formatting a real article to have it there for absolutely no reason. Also, please don't assume that opt-outs are simple for contributors who do their absolute best to stay away from anything technical (which I consider templates). Your last simple fix to another "newbie-helping" project (making AfDs ugly and distracting for absolutely no added benefit) took me 10 minutes to figure out.
These cosmetic changes (including the AfD template you laud above) don't help anyone and making users who have been here for a decade remember an obscure template in order to figure out how to make a draft not be an eyesore to look at while writing is not an easy fix. It's a waste of time and contributor resources. If anything the AfD thing should be used as an example of why not to go forward with this idea. Also, there's a reason opt-in programs don't work: no one wants the stuff that is being peddled. TonyBallioni (talk) 04:10, 29 August 2018 (UTC)
@TonyBallioni: "no one will ever remember the opt-out template" clearly nonsense, especially when it can be mentioned in the template. Headbomb {t · c · p · b} 04:23, 29 August 2018 (UTC)
@Headbomb: I stand 100% behind my statement. No one will remember the opt-out template. TonyBallioni (talk) 04:27, 29 August 2018 (UTC)
You don't need to remember anything, the option is literally presented to you. Headbomb {t · c · p · b} 04:30, 29 August 2018 (UTC)
... if it is presented to us, that means the bot will run and tag the damn thing on drafts that people want opted-out, which means that they will have to go and look up the template they will never remember so the bot doesn't edit conflict with them while they are drafting. So, no, it is not easy to remember and not a user friendly process. TonyBallioni (talk) 04:34, 29 August 2018 (UTC)
(edit conflict) @Headbomb:I think we both understand the relative implications of an opt-in vs opt-out model. My point is I see real value in this template - for newer and less experienced editors. I do not, based on my own experience creating articles, my experiences as a new page patroller, and the discussion below about the behaviors of experienced editors in draft space, see the value for experienced editors who I am grouping as those with either the autopatrolled or extended confirmed permissions - I would be inclined to say autopatrolled but the discussion below has referenced extended confirmed. Since this is an RfC I'm confident that the closer can give the appropriate weight to my !vote when closing this. Best, Barkeep49 (talk) 04:17, 29 August 2018 (UTC)
@Barkeep49: see above reply to Tony. Headbomb {t · c · p · b} 04:23, 29 August 2018 (UTC)
How is there any value in this template for anyone? It is perhaps the worst graphically designed thing we have on the entire project, is confusing to read, and contains a bunch of links that have no explanation as to why they are useful or needed, and just tells you that it is a draft, which as others have pointed out, is implied by the fact that the word Draft: is in front of the name of the page.
Crappy proposals like this and the AfD help nonsense only serve to make us feel better about WP:BITE. They don't actually help new users. The best way to help new people is to actually talk to them, which the AfD rejection templates do: they provide links to ask questions, etc, and AFCH refers people to the Tea House.
If someone can tell me why projecting an Windows 3.1 era graphic that contains links with no explanations to new users would actually help them or make them think anything better of this project, I'll gladly support. I think there is about as good a chance of that as the moon falling from the sky, but I'm open to being proven wrong. TonyBallioni (talk) 04:27, 29 August 2018 (UTC)
The links are pretty self explanatory. Doesn't take a rocket scientist to figure out what "Find sources: Google." is all about. But if something is unclear, that can always be clarified. Headbomb {t · c · p · b} 04:44, 29 August 2018 (UTC)
@TonyBallioni: I think presenting places to find RS when creating a new article has value. I agree that the AfC templates following reviews are superior but this is an attempt to get them on the right path before then. I certainly don't feel strongly about it and could probably be convinced to outright oppose. Best, Barkeep49 (talk) 04:36, 29 August 2018 (UTC)
Barkeep49, the links have no explanation as to their usefulness, no explanation of the RS policy, no explanation of how sources are to be cited, no reason why you would even want to click on the links. It makes sense for experienced Wikipedians, but doesn't help new people because of how horribly designed the whole thing is. The thing is: experienced Wikipedians don't need the links, and new people are likely just going to ignore them or use them incorrectly if no explanation is given. Combined with how awful the thing looks, this is literally the last thing I would want a new user to see. TonyBallioni (talk) 04:40, 29 August 2018 (UTC)
Ok TonyBallioni I'm convinced and I see the moon is still in its rightful place. Best, Barkeep49 (talk) 04:46, 29 August 2018 (UTC)
  • Oppose: This just seems like a massive waste of time, effort, and server resources. There is already a Draft: tag in front of every page in draft space. There is no reason to mark them with a template when the system marks them for you. Forcing it upon everyone unless they explicitly opt-out also seems like a great example of WP:CREEP. Something that should be avoided. --Majora (talk) 04:35, 29 August 2018 (UTC)
  • Oppose per above. Waste of server resources to add, and textbook template creep. -FASTILY 05:45, 29 August 2018 (UTC)
  • Oppose: This template only says the page is a draft and (essentially) nothing else. If we were to mandate some template, the template should have some functionality (e.g., a link to a page of the same name in mainspace). —- Taku (talk) 09:41, 29 August 2018 (UTC)
@TakuyaMurata: drafts are proposed new articles. The vast majority of the time, there is no 'page of the same name' in mainspace. When there is, it is mentioned, see Draft:List of Nicktoons, for example. See the first !vote for what functionality the template offers. Headbomb {t · c · p · b} 10:02, 29 August 2018 (UTC)
@Headbomb: No, no, the link appears if there is a corresponding page or not in mainspace. Most of times, the link will be red; this is useful since the draft page will appear in “what links here”. To repeat my larger point, it is unnatural to use this template for purposes other what it was intended: saying the page is a draft page. It is much more natural and straightforward to create a template that provides functionalities like a link to a mainspace page and other bookkeeping (e.g., whether a draftpage is promising or not.) Rather low usage of this template should tell many people don’t find it useful (but of course, some do and that’s fine). —- Taku (talk) 11:01, 30 August 2018 (UTC)
@TakuyaMurata: The template already create a "What links here" entry... So I'm not really sure what you're asking here. See e.g. Special:WhatLinksHere/Medicine Trails with an incoming link from Draft:Medicine Trails. Headbomb {t · c · p · b} 11:31, 30 August 2018 (UTC)
@Headbomb: That’s a bit sneaky and quite confusing; it’s far more transparent to have a red link. Anyway, this really enforces my (and others’) larger point, which you are not getting: it’s simply wrong to expand this simple template with bloated functionalities. The template says the page is a draft page and it should not be doing more than that. What if someone needs a template like Template:User sandbox? It is useful and makes sense to have some bookkeeping/maintaince template; this template isn’t one and shouldn’t be one. —- Taku (talk) 12:42, 30 August 2018 (UTC)
  • Oppose Imagine that a new user clicks on one of the "easy tools" (Peer reviewer) and finds "API Warning: Subscribe to the mediawiki-api-announce mailing list at <https://lists.wikimedia.org/mailman/listinfo/mediawiki-api-announce> for notice of API deprecations and breaking changes. Use Special:ApiFeatureUsage to see usage of deprecated features by your application." That's what happened when I clicked on it. Or try another easy tool: citation bot, which brings up "> Expanding 'Draft:Medicine_Trails'; will commit edits. Reading authentication tokens from tools.wmflabs.org." If users actually read templates, and clicked on all the links provided (which I doubt) that experience would be enough to drive them away. Vexations (talk) 10:29, 29 August 2018 (UTC)
I contacted the tool's maintainer about this. In the meantime, I've simply disabled the link. Headbomb {t · c · p · b} 11:16, 29 August 2018 (UTC)
Thanks for that, but I think I've just shown that nobody actually reads those templates. And that includes the people discussing them. Vexations (talk) 11:27, 29 August 2018 (UTC)
  • Comment - As far as I am aware, when someone creates a draft currently, they are already tagged as {{AFC submission}}, correct. However, not all drafts are required to go through AfC, so surely this doesn't make sense? I think I'd only support the proposal if the tag was of more use... Say, if it auto-added the article to the WikiProject tag on the talk page. The tag currently gives a list of websites to search for sourcing, however, a new user would be stuck to know which of these are reliable, without say reading other policies. Some Wikiproject have thier own specialist sourcing lists (say, at WP:VG/S, which has a custom google search listed), which if tagged as a video game, if the tag could promote this instead, I'd be behind. Lee Vilenski (talk • contribs) 07:58, 30 August 2018 (UTC)
That's what the "WP Refs" link is intended to be I believe (or rather a pre-filtered list of acceptable refs). But that also misses quite a lot of reliable sources. Tagging talk pages would be a matter for a different bot (or different bot task), but could certainly be done based on the |subject= category when it's used. Headbomb {t · c · p · b} 10:45, 30 August 2018 (UTC)
  • Support Helps new users understand how the daft space works better, I see a lot of potential in having it on draft pages. – BrandonXLF (t@lk) 00:03, 31 August 2018 (UTC)
  • support Draftspace is for drafts. Yes they should be labelled as drafts with the template. Helps new users stay on-mission, using WP appropriately. Jytdog (talk) 01:36, 2 September 2018 (UTC)
  • Oppose A very friendly informative template would probably be a good idea. This seems to fall a bit short of that. Anything short of that (even if reasonably good) is intimidating and scaring, even if that was not intended. North8000 (talk) 22:53, 3 September 2018 (UTC)

Discussion (Let's add Template:Draft to all drafts)

I think there was a syntax issue preventing Template:Editnotices/Namespace/Draft from showing that should now be resolved. Note, this should already be an edit notice for the entire draft space, and could be expanded without some mass-bot editing campaign. Thoughts? — xaosflux Talk 19:53, 20 August 2018 (UTC)

No opinion; if there is an easy way to flag this material as draft and set the (reversible) G13 deletion clock I'm for it. NewsAndEventsGuy (talk) 20:11, 20 August 2018 (UTC)
Edit notices are a separate issue. They don't really do anything until you click 'edit', and a large part of having these templates is to both a) help you find things before you click 'edit' b) give you incentives to click edit c) reduce the amount of hoops you have to go through to do something productive and find the information you're looking for. Headbomb {t · c · p · b} 20:15, 20 August 2018 (UTC)
@Headbomb: may be a good case to push for Per-namespace sitenotice capability? — xaosflux Talk 20:54, 20 August 2018 (UTC)
@Xaosflux: That would be absolutely fantastic! Headbomb {t · c · p · b} 20:55, 20 August 2018 (UTC)
Count me in too NewsAndEventsGuy (talk) 20:59, 20 August 2018 (UTC)

I just calculated a ballpark number for pages this will affect, using the 14 August database report and transclusion count (this does count pages which transclude multiple templates multiple times). I found that draft and AFC templates are transcluded 34,327 times and there are 39,888 non-redirects in the draft namespace. Therefore approximately 5561 pages will be affected, 14% of all drafts. This is the lowest estimate. Danski454 (talk) 21:04, 20 August 2018 (UTC)

Sounds like an easy task for a bot to me. Ronhjones  (Talk) 22:48, 20 August 2018 (UTC)
That's the idea. But I want consensus before making WP:BOTREQ. Headbomb {t · c · p · b} 22:49, 20 August 2018 (UTC)
I would oppose automatic g13, as well as un-nominated g13 deletions. It is much better if a person gets to see the draft before slapping it on, as other deletion criteria may be more appropriate. And if the draft is worth rescue then there is chance when g13 application is considered, or when the admin looks at it prior to deletion. Also other people may look at the draft as it is pending deletion. →The purpose here is not to get rid of junk, but to add useful content to the encyclopedia. Graeme Bartlett (talk) 23:27, 20 August 2018 (UTC)
To be clear, nothing in this proposal isn't is about G13, save for making it easier for people to edit drafts and submit them. Headbomb {t · c · p · b} 23:31, 20 August 2018 (UTC)
Headbomb, nothing...isn't ? I think you mean the exact opposite of what you have written. — fr + 15:26, 21 August 2018 (UTC)
fixed Headbomb {t · c · p · b} 15:36, 21 August 2018 (UTC)

Comment: The subject parameter could provide useful categorisation allowing users to find drafts in their fields of interest, but the list of possible choices does not cover all potential articles. There are human activities that do not fit correctly into any of the categories listed. As an example, I would watch a category that would notify me of drafts in my particular field of interest, which is underwater diving, but how would it fit in with these options? · · · Peter (Southwood) (talk): 05:20, 26 August 2018 (UTC)

@Pbsouthwood: well it's just a matter of creating the category and {{Draft article}} can then support it. Alternatively, you can ask for help on the {{Metabanner}} talk page to add support for the Draft-class to {{WikiProject Scuba diving}}. Headbomb {t · c · p · b} 06:25, 26 August 2018 (UTC)
That is true as far as the example goes. There are probably an unknown but significant number of topics that don't fit into any of the listed categories. Also, it is likely that many editors in draft space will not know how to usefully categorise their draft. I suggest a default value of unknown, which would allow the category gnomes to fix. (or this may already exist?). Category:Human activities could catch some of them, probably not all. Cheers, · · · Peter (Southwood) (talk): 06:35, 26 August 2018 (UTC)
Presumably by "the {{Metabanner}} talk page" you mean Template talk:WPBannerMeta, but the place to propose a change to Template:WikiProject Scuba diving is surely Template talk:WikiProject Scuba diving, or perhaps Wikipedia talk:WikiProject Scuba diving. Once consensus has been obtained there, you can then proceed; if you don't know how to do it, then you can ask for assistance at Template talk:WPBannerMeta. This last step shouldn't be necessary, since I know exactly what to do and Template talk:WikiProject Scuba diving has been on my watchlist for the last nine months. --Redrose64 🌹 (talk) 17:24, 26 August 2018 (UTC)
Obviously. This is not something that needs to be clarified every time I post. Headbomb {t · c · p · b} 17:46, 26 August 2018 (UTC)
[ec] Yes, that looks like the way to go about it. To recap, {{WPSCUBA}} can be modified to include the option of |draft=, which would be useful to the project to identify and keep track of drafts on project related topics, but someone still has to tag them for the project. This seems hardly ever to be done by the article creator, probably because they usually don't know it can be done, or how to do it. Is this proposed template likely to increase useful project tagging, or in some other way make the drafts more visible to those who might be interested? The subject parameter appears to be optional, so I guess it would seldom be used. Having a default of Category:Uncategorised draft would allow patrollers to spot uncategorised drafts and add their best estimate of a suitable category. This may get more interested and topic competent eyes onto them, which should improve their chances of making it to mainspace. · · · Peter (Southwood) (talk): 18:16, 26 August 2018 (UTC)
I agree an 'uncategorized' category would be nice. I'll add that to the template, although once it's at AFC, chances are that category will be gone. Headbomb {t · c · p · b} 18:19, 26 August 2018 (UTC)

Pinging all neutral/opposes @Quiddity, Ivanvector, TonyBallioni, Rhododendrites, Godsy, Graeme Bartlett, Jayron32, Kaldari, OlEnglish, Ammarpad, Mangoe, Andrew Davidson, and Felicia777. The template has undergone a significant overhaul since the start of the RFC (see how it looks on Draft:Medicine Trails or Draft:List of Nicktoons) and the customization options. Please see the updated arguments for inclusion and see if that shifts your objections/neutral. Headbomb {t · c · p · b} 07:23, 26 August 2018 (UTC)

Forgot to @GreenMeansGo: Headbomb {t · c · p · b} 14:05, 27 August 2018 (UTC)
diff from the start of this thread -- in terms of the content of the box, is the main difference adding the AfC link? (and the different styles)? It would help to be clear about which of those versions is being proposed to add. — Rhododendrites talk \\ 14:06, 26 August 2018 (UTC)
@Rhododendrites: There's been changes to several templates/modules used by the template as well. Changes visible in the above diff is the template will hide itself automatically in mainspace (but give an error in preview mode), has a tighter wording, {{Draft article check}} is now integrated in the message box rather than appear as a separate hatnote, {{Wikipedia logs}} is inlined with {{automated tools}} to save space, you can (optionally) reduce the template to a "minimalist" version, and there's now an AFC submission button (Draft-space only).

But changes not apparent in that diff are that {{automated tools}} is much more concise [see diff], with a Citation bot interface+functionality much improved, {{Find sources}} is now much better organized [see discussion], and {{Draft article check}} no longer throws a warning if a mainspace article/redirect doesn't exist, and will use a small Nota bene* icon when there are article/redirects found [see diff].

And what's being proposed is to add {{Draft article}}, which will always update itself to whatever the most recent version of it is. -Headbomb {t · c · p · b} 14:24, 26 August 2018 (UTC)

I'm still broadly in favor of increased use of the template, and broadly against adding it to every draft. If we are going to automate it, it should be similar to the way hostbot operates. We ought not retroactively put it on everything in draft space, and we should restrict the addition to new drafts only to those created by either unconfirmed, or non-30/500 editors. If someone joined WP before hostbot was created, it's not going to invite you to the Teahouse just because you haven't been previously invited. Similarly, if we set a bot loose that's going to start adding tags to drafts created by, for example, DYK grand masters who always start their articles as drafts, then we're just going to annoy a lot of people unnecessarily. GMGtalk 14:19, 27 August 2018 (UTC)
@GreenMeansGo: Drafts have a very temporary life shelf and is dominated by newcomers, rather than Illustrious Looshpahs. There is very little danger of tagging a 5-year old draft to 'annoy' someone, a 5-year old draft would have been G13'd by now. But after the initial bot run (~5000 drafts, since the other 30,000 or so already have the template, or an AFC template), the bot could easily stick to new drafts and not re-add the template if removed. I don't buy that the template isn't useful to DYK grandmasters, but they could always remove it if that was the case, and the bot wouldn't edit war with them. Headbomb {t · c · p · b} 14:33, 27 August 2018 (UTC)
I mean, it's not that they couldn't remove it, it's just that I imagine every single one of them would, so we shouldn't make an automated tool that is pretty much guaranteed to waste editor time in ~5 second intervals in perpetuity. It looks like we're averaging somewhere between 10 and 20 draft creations per day from users who are 30/500 confirmed, and from the looks of it, most of these are being directly moved into mainspace rather than submitted to AfC, as one would expect from 30/500 editors. So it's not clear that there's really being much of any value added there at the expense of a predictable and perpetual, if minor nuisance. However, for users who are not 30/500 confirmed, the type that are going to show up at the Teahouse and ask why their article was deleted, and who use up five minutes of a host's time to figure out and explain that what they have created is an unsubmitted draft, those are the ones that are actually going to benefit from something like a link to WP:CCPOL. GMGtalk 14:57, 27 August 2018 (UTC)
@GreenMeansGo: If that's the hold up, there could easily be an "opt out" list, where you sign up (Template:Draft article/Opt-out) and you've opted out forever on whatever draft you create. Headbomb {t · c · p · b} 16:39, 27 August 2018 (UTC)
@Headbomb: The new template is an improvement and seems more useful. I've changed from oppose to neutral. I would still prefer for this to be part of the UI rather than something that is added into every draft by a bot (although I'm not sure what the best way to implement that would be). Kaldari (talk) 18:51, 27 August 2018 (UTC)
@Kaldari: well, see this as a temporary solution, till we have something better for the UI. The per-namespace site notices seem promising. Headbomb {t · c · p · b} 19:01, 27 August 2018 (UTC)
@Headbomb: Note that you could use TemplateStyles to have the {{AFC submission}} template hide the Sitenotice. Not sure how smooth that would be, but it might work. Kaldari (talk) 20:29, 27 August 2018 (UTC)

What if instead of adding a template into the pages, we simply make it part of the namespace itself? So that all pages in the draft namespace show it, regardless of their current status, just by virtue of being in that namespace. Cambalachero (talk) 17:52, 27 August 2018 (UTC)

I'd support that, but that's Xaosflux's per-namespace site notice thing. It's not enabled, so this is the alternative. Headbomb {t · c · p · b} 18:05, 27 August 2018 (UTC)
We already have Template:Editnotices/Namespace/Draft, but that is only displayed when editing. I know of no easy means for displaying a notice when viewing all pages in a namespace. --Redrose64 🌹 (talk) 19:28, 27 August 2018 (UTC)
@Headbomb: But we are not in hurry for us to be looking for "any alternative," are we? why not wait till when the per-namespace notice is enabled? If work on it is stalled then it looks like a good candidate for the upcoming Community Wishlist Survey. –Ammarpad (talk) 06:43, 28 August 2018 (UTC)
"Not in a hurry" doesn't mean sitting on our asses for 4+ years and doing nothing. We have a working solution now, so let's use it rather than wait until 4 years turn into 8. Headbomb {t · c · p · b} 06:49, 28 August 2018 (UTC)
"...Solution" for what problem? –Ammarpad (talk) 07:11, 28 August 2018 (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.

Watchlist pop-ups?

Might it be possible for the account Watchlist to implement pop-ups that summarize small revisions? Or even show a list of recent small revisions? That way we don't need to visit the article, look at the history, and do a compare. It'd be a nice time saver. Praemonitus (talk) 22:09, 11 September 2018 (UTC)

Add to Special:MyPage/common.js 
importScript( 'User:Writ Keeper/Scripts/commonHistory.js' ); // Backlink: [[User:Writ Keeper/Scripts/commonHistory.js]]
Should be standard IMO. Not a pop-up but essentially the same, view diffs from watchlist without clicking through to the article. The limit is it only shows most recent edit and I agree it would be useful to show further back but no idea how. -- GreenC 22:42, 11 September 2018 (UTC)
Do you have navigational popups enabled? I noticed it's not in your common.js, but you can also install via Special:Preferences. What you described is mostly what I use the tool for. Killiondude (talk) 23:22, 11 September 2018 (UTC)
Thanks, I'll give those a try. Praemonitus (talk) 22:15, 12 September 2018 (UTC)

RfC: Proposal: make subjects actively in the news ineligible for GANs and FACs

Withdrawn: I've poorly worded the problem and proposal, resulting in comments and !votes whose rationales miss the point. The problem remains one that needs to be addressed, so I will reintroduce when I've better reformulated them. Curly "JFC" Turkey 🍁 ¡gobble! 00:32, 13 September 2018 (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.

Proposal: WP:GANs and WP:FACs for subjects undergoing rapid changes (e.g. prominent politicians at the height of their careers) generally should be autofailed at GAN and FAC as inherently unstable. Curly "JFC" Turkey 🍁 ¡gobble! 00:19, 12 September 2018 (UTC)

Discussion (make subjects actively in the news ineligible for GANs and FACs)

Support as proposer: Yes, I'm aware such articles have been promoted in the past—let's not trip down WP:OTHERSTUFFEXISTS. I've thought this for a while, and wouldn't have submitted such an article myself. This most recently came up with the Doug Ford article, which I've contributed to but am not the primary editor:

  • Ford became premier of Ontario three months ago, and is the sort of personality that constantly makes news. What happens in the coming months and years will undoubtedly be the keystone to his bio—the article will expand and be reshaped as the RSes inevitably multiply.
  • Ford is a divisive personality, which has also led to instability in the article—earlier this year, we dealt with editwarring, sockpuppeting, and POV pushing, as well as heated debates on the talkpage. That was before he won the premiership—the article has since gone from an average daily readership of 59 hits to a 1265, and his actions have dominated Canadian headlines of late. More eyes will inevitably lead to more active editing—for instance, in the last couple days we've had everything from vandalism to the addition of entire new sections, as well as page protection.
    Not every such article will be so heated, but the principle remains the same—when a great number of changes are inevitable in the foreseeable future, the page is inherently unstable.

Having articles promoted to GA with this sort of timing only makes a joke of the whole article-recognition process—while every article is a "work in progress" and can be improved, subjects at the heights of their careers are so inherently unstable that they should be considered ineligible for promotion.

Please keep in mind that I'm proposing this for such articles in general—let's keep any issues with the Ford article itself at Talk:Doug Ford. Curly "JFC" Turkey 🍁 ¡gobble! 00:19, 12 September 2018 (UTC)

  • I would guess this RFC isn't necessary for FACs because there is criterion 1e. It is stable: it is not subject to ongoing edit wars and its content does not change significantly from day to day, except in response to the featured article process. You're proposing to change the similar criterion (5) in the GAC from Stable: it does not change significantly from day to day because of an ongoing edit war or content dispute. to...? --Izno (talk) 00:46, 12 September 2018 (UTC)
    • Izno: I don't have a proposed wording, but a lack of editwars and content disputes is not a sign of "stability". I suppose I'm looking for the sort of wording that implies the article is in some way "settled"—that is, edits tend to be copyedits rather than significant addition or reorganization of content. Curly "JFC" Turkey 🍁 ¡gobble! 02:47, 12 September 2018 (UTC)
  • Oppose I won't speak to FAs as I am not familiar enough with them, but GAs already have a stability criteria. Like most things it is left up to the reviewer to decide if they feel the article is stable enough for a review to be conducted. Also given the inconsistent timing of reviews (many wait months for a review) it is entirely possible that someone could be nominated and then before the review is picked up get in the news. The current guidelines work well enough. AIRcorn (talk) 02:08, 12 September 2018 (UTC)
  • Oppose. Echoing Izno and Aircorn, both FA's and GA's have stability criteria. Some articles might be in the news often simply because of the nature of the subject, but aren't necessary unstable. It should be up to the reviewers' discretion to determine whether the article is eligible for GA or FA status on a case by case basis. If the article is constantly updating 100 times a day, or is the subject of an edit war, I'd argue it's already ineligible for GA status right off the bat based on the criteria. For that reason, this ban is unnecessary. epicgenius (talk) 02:25, 12 September 2018 (UTC)
    • Aircorn, epicgenius: as has been pointed out at Talk:Doug Ford, the stability criteria at GAN refers to editwars and content disputes. The issue I've raised is of articles that will inevitably undergo significant expansion and reorganization. Curly "JFC" Turkey 🍁 ¡gobble!
      • @Curly Turkey: I think "significant expansion and reorganization" would need to be clarified. For instance, if it's a building in the planning stages or if it's a very active politician with frequent controversy, that would qualify as something that has significant expansion and reorganization. On the other hand, a building that's almost complete or a relatively non-controversial politician would probably not qualify as "significant reorganization". Otherwise I might get behind further clarifying the GA criterion. However, the FA criteria doesn't need to be clarified, because something like this would be automatically failed anyway. epicgenius (talk) 03:51, 12 September 2018 (UTC)
        • epicgenius: Would it really? Barack Obama not only was promoted, but made TFA on election day 2008. Curly "JFC" Turkey 🍁 ¡gobble! 04:12, 12 September 2018 (UTC)
          • @Curly Turkey: Yeah, and and also on August 18, 2004. That was a few days after Obama's article was promoted to FA status, and a few years before he was elected as POTUS. A more apt comparison would be Mitt Romney, whose article was promoted just a few days before the 2012 election. In any case, it's the maintenance of such articles that should be focused on, not the promotion. If the article doesn't meet the FA or GA criteria anymore, there's a review process for that. I also agree with Iridescent's comment below that being in the news often is not a sole indicator of being "ineligible". epicgenius (talk) 13:43, 12 September 2018 (UTC)
    • I have always taken the stability criteria to be for the reviewers benefit. It is very hard to review an article if it is constantly changing. I would maybe support the addition of something simple as long as the reviewer has some flexibility when applying the criteria. Especially as the scope for this could be very broadly interpreted. Any current sportsperson, writer, academic or similar biography would fall under it as well. I disagree with Barkeep49 below. Just because something is ongoing does not mean it should not be a Good Article. I do spend some time going through old GAs and cleaning them up and there are many from TV shows through to science topics that are not kept up-to-date. They then fail the broad criteria so are easy to delist. There are also many more that are updated. It is just the nature of writing a live encyclopaedia. I also dislike adding too much to the criteria as the process itself should be kept as lightweight as possible. AIRcorn (talk) 07:24, 12 September 2018 (UTC)
  • Support as I like the idea that the bulk of a topic should be complete before getting featured article status. Like Aircorn I can speak to GA but not FA. An example of a GA which bothers me which is not a BLP and is not prevented over any reasonable interpretation of stable as currently defined at GA but has potential for long term decline is The Resident (TV series). We have here a series like to run at least 3 seasons, if not many more, meaning that the content that was present on the page when it passed GA is only a small portion of what will eventually be there. Maybe through careful stewardship it will stay at GA level - but maybe not. But in any event that designation is likely to stay there. There is absolutely no policy justification in how stable is defined at GA or in the explanatory essays to say that articles which will inevitably need major future expansion based on ongoing events should be failed as not stable. Not only that I'm not aware of any GA in the last 5 months (when I've examined at some level a huge percentage of GA reviews) where any definition of stable beyond "no current edit warring" has been used - not even on articles under AP2 GS. I'm not a huge fan of the wording of this current proposal but I think the spirit behind it is correct and appropriate for the kind of content the encyclopedia should feature and recognize. Best, Barkeep49 (talk) 02:33, 12 September 2018 (UTC)
  • Support, agree that it needs to be formalized and put in review guidance and not left solely for "reviewer's discretion" in order to strengthen quality of promoted articles. Reviewer's discretion will be needed to determine when to (not) apply the rule. Current guidance talks about edit wars, but I found keeping an article updated and balanced if the topic is continuing to evolve and change is a much greater and often neglected challenge. Renata (talk) 06:28, 12 September 2018 (UTC)
  • Oppose "Being in the news" does not by default entail that an article is unstable and both FA and GA have "completeness" criteria that cover the other use cases. Jo-Jo Eumerus (talk, contributions) 07:48, 12 September 2018 (UTC)
  • Oppose: the GA criteria reflect the actual present state of the article, not some hypotheticals. Just like we don't protect pages pre-emptively, we shouldn't fail GAs if we merely think there is going to be a problem with the current stability or completeness criteria. Both criteria are easy to demonstrate: has it actually changed on a day-to-day basis? Is it really missing something right now? If it passes now, pass it. If it doesn't pass in the future, Wikipedia:Good article reassessment is that way. There is a common sense element of nominations that needs to be followed, of course, but is impossible to spell out in full: don't nominate an article about a Super Bowl before or during the game, don't nominate an article about a person who is on their deathbed... we deal with a lot of bad "newbie" nominations and always find a way even if there isn't a rule for it. Let me end by noting that what might work for Doug Ford of Canada doesn't work worldwide. Do people living in dictatorships have to wait until their president-for-life has ended the "height of their career" in order to access a quality encyclopedia article about them? Heaven forbid. – Finnusertop (talk ⋅ contribs) 09:35, 12 September 2018 (UTC)
  • Oppose. Would this have prevented e.g. United States of America from becoming GA? If the rule were restricted to people, it won't completely solve the problem Curly Turkey is talking about (which does exist): a GA on a minor politician will become very out of date if that politician becomes much more prominent. I assume we're not banning GAs on anyone, no matter how minor, who might fall under this rule at some point in the future? The same problem would happen with minor sports figures who are still active. The rule wouldn't prevent the article from being as good as a GA or FA; it would just prevent the award of the status, but that would be demotivating for the editors working on the article, and I don't see there'd be any benefit. It would be better to take these articles to GAR and FAR once they start to decay. Mike Christie (talk - contribs - library) 11:14, 12 September 2018 (UTC)
  • Oppose. Being in the news doesn't make articles inherently unstable. We have current FAs on high-profile biographies such as Hillary Clinton, Taylor Swift, Elizabeth II, John McCain and Bob Dylan, and on high-current-interest topics as varied as Earth (and Moon), Antarctica, Diamond, BAE Systems and Germany. Provided there are people willing and able to monitor the articles to keep out the POV-pushers and cranks, there's no reason a current event article is inherently less stable than any other—Barack Obama was a FA for the entire duration of his presidency and India has been a FA continuously for 14 years, and the world has not come to an end. ‑ Iridescent 12:52, 12 September 2018 (UTC)
  • Oppose as a blanket restriction - articles about subjects "in the news" are not inherently unstable; this criterion should be reviewed on a subject-by-subject basis. I am the editor who nominated Doug Ford for GAN more than two months ago, at a time when the article was reasonably complete based on information available at the time. Many discussions about the article's content and development had recently concluded, the article was in a good and stable state, and it seemed that all of the editors who had participated in those discussions (including Curly Turkey, and other than some blocked sockpuppeteers) were satisfied with its state. I proposed nominating the article, there were no objections, and then I went ahead. Curly Turkey is definitely correct that Ford is a divisive and controversial politician, and with the fall session of the government getting started he is in the news and certainly dominating national headlines (e.g. our news in Prince Edward Island is "shit Trump did", then "shit Ford did", then local stuff about potatoes and roundabouts), so almost by the day there is new information to add. I say this doesn't make the article unstable, as long as the information is added responsibly and editors talk through disagreements, which we've set a precedent for on Talk:Doug Ford. I think this case is actually a good reason why we should not have such an automatic disqualification. Also per what Iridescent said. Ivanvector (Talk/Edits) 14:01, 12 September 2018 (UTC)
  • Oppose This is a fantastically bad idea. Articles should be assessed for such promotions based solely on the article content itself, not upon some random, blindly applied criteria. And there should be NO restrictions upon people who have valid, evidence supported contributions to make to ANY consensus-based discussions. That is, we should not tell people ANY article is automatically ineligible for FA or GA discussions, because that implies that any earnest and honest assessment they would make about the article quality is automatically rejected. No, no, no, a thousand times no. That's not how we do things at Wikipedia. Start the discussion. Assess the article on its merits. If consensus for that one article, at that one time that the article does not pass the criteria because it is not stable, then fine, lets have that discussion, lets make that the consensus. But we should not presume anything, and we should not tell people what they are going to think before they think it. If an article is part of a current event or in the news, just let people look it over and assess it honestly. If consensus is that article stability is not a problem, then promote the article. Nothing bad has happened because of that, in fact, the process worked exactly as intended. I grow weary of all of these rulesy people trying to pass a whole bunch of restrictions designed at preventing discussions from moving forward. That's so antithetical to how Wikipedia works. We don't have rules. We don't have laws. We discuss and improve and make decisions based on consensus. I don't (despite the insistence below) recognize any problem. This is not an issue of a wording problem. I think this would be a shitty idea in any wording. --Jayron32 15:12, 12 September 2018 (UTC)
  • Oppose. In an ideal world every article in the whole encyclopedia would be an FA. And vital articles, such as those about prominent leaders, even more so. Barack Obama was a featured article (as indeed was John McCain) on the very day of his first presidential election. And still is to this day. If the rapid editing leads to a deterioration in quality, then WP:FAR is right over that way. If it doesn't deteriorate, then all well and good.  — Amakuru (talk) 22:44, 12 September 2018 (UTC)
  • Oppose per Amakuru. I will add that the definition of "in the news" is a flexible one that is difficult to clearly define, and is thus likely in my opinion to lead to a major gray area which it is best to avoid. Display name 99 (talk) 23:48, 12 September 2018 (UTC)
  • Oppose In principle it is right, but we have have GAs on topics that still get coverage. What should be avoided is GA/FA of articles on topics that are in the current news due to some controversial element. This may not lead to edit warring but we should wait for the controversy to die down to best just how to cover it, as to make the article of GA/FA quality. --Masem (t) 23:53, 12 September 2018 (UTC)

Reboot proposal wording?

  • I'm seeing a lot of people recognizing the problem but opposing on the wording. The way this is going, the proposal will be trashed while a recognized problem goes unsolved. Perhaps some input here on how to improve the proposal? Curly "JFC" Turkey 🍁 ¡gobble! 11:29, 12 September 2018 (UTC)
    I think the problem you've identified is in the decay or failure to update the article, and not in the original promotion (so long as the stability criteria as they currently stand are followed). To me, that means the right answer is more active reassessment of articles of this type. Perhaps an internal category that tracks GAs/FAs likely to decay? An interested group could periodically review the contents of the category to see if a reassessment is warranted. Mike Christie (talk - contribs - library) 11:45, 12 September 2018 (UTC)
    There's an external tool which "grades" articles (e.g. WikiProject Canada GA-class articles), though I have no idea what is the background of the grading algorithm. That tool also lists the articles' assessment dates, so I suppose that info could be used to create a list of promoted articles which might be due for reassessment, or maybe that can be coded into the WikiProject banners to automatically populate a maintenance category. The problem then is that we're short on reviewers. Ivanvector (Talk/Edits) 14:06, 12 September 2018 (UTC)
    I think the last sentence is key. We are short on reviewers for new nominations already (GAN is perma-backlogged for example with articles from more than 9 months ago still awaiting review), so who will reassess old articles? This sounds good in theory but does not work without far more people participating in these processes and I don't see that happening. Regards SoWhy 15:40, 12 September 2018 (UTC)
    The DYK people cleared their backlog by requiring that each new nomination be coupled with the review of an outstanding nom filed by another person. In theory, this could also work for GANs; but it has been suggested that the requirement has led to the rubber-stamping of sub-standard DYKs simply to get the new DYK nomination into the queue. That would not be good for GAN. --Redrose64 🌹 (talk) 20:41, 12 September 2018 (UTC)
    DYK also doesn't have to deal with articles going immediately out of date. Curly "JFC" Turkey 🍁 ¡gobble! 22:22, 12 September 2018 (UTC)
  • I'm seeing a grand total of one person "recognizing the problem but opposing on the wording", and near-unanimous consensus that unilaterally deciding that certain classes of articles should be excluded from Wikipedia's usual assessment processes just because you disagreed with the GA nomination of a single article is a terrible idea. Have you actually got any, like, evidence to support your core assertion that subjects actively in the news [are] inherently unstable, or are you just assuming that because you saw an edit war on one article you can extrapolate that to every other article? How are you even proposing to define "subjects actively in the news" in a way that wouldn't exclude every country and major city, every living artist, performer and writer, every active politician and probably every single BLP, every major animal species, every "broad concept" article like Sea or Planet, every scientific field in which new discoveries are being made (which is all of them)…? What you're essentially proposing, whatever form your final proposal takes, is that Wikipedia not cover anything that's the subject of any controversy, and whatever form that proposal takes it will be mutually contradictory at the most basic level with Wikipedia's key principles. ‑ Iridescent 17:05, 12 September 2018 (UTC)
    I agree with much of this, but it's not really fair to Curly Turkey to say they're proposing that Wikipedia not cover these topics; the proposal only says they cannot be FA or GA. Mike Christie (talk - contribs - library) 17:51, 12 September 2018 (UTC)
    Iridescent isn't the first to suggest that I'm saying we shouldn't cover these articles, and I don't know where this interpretation is even coming from.
    "just assuming that because you saw an edit war on one article ..."—again, nothing like what I've suggested, so how am I even supposed to reply?
    The issue isn't "controversy", but articles that are in a current state of rapid expansion. "In the news" wasn't the best way to express what I was trying to say—Led Zeppelin is "in the news", but obviously (I would hope) not what I'm driving at. The Doug Ford article will be undergoing significant changes in the coming months and years. Should it be subject to WP:GAR quarterly or something to ensure it's still up to snuff? And that's the difference—it's reasonable to assume Led Zeppelin will remain within spitting distance of the article that was promoted even years after its promotion. It's a matter of fact that Doug Ford cannot, because key features of the article's content are being generated right now and will continue for the foreseeable future. Curly "JFC" Turkey 🍁 ¡gobble! 20:23, 12 September 2018 (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.

A better way to handle headings with the same name

User:Amaury/sandbox/Test page.

As can be seen, sections A through Z all have the same sub-headings of 1, 2 and 3. If I make an edit to section 21.1 (Section U, Sub-Section 1), when I save it, it returns me to section 1.1 (Section A, Sub-Section 1). When there is more than one heading with the same name, from the second heading onward, there needs to be some way to make it unique within the URL or code—perhaps by adding additional characters or numbers in the URL, like the IDs on forums for posts, threads, etc.—go back to the right section. In addition to that, if I want to link someone to Sub-Section 1 on any section other than Section A, I can't, because User:Amaury/sandbox/Test page#Sub-Section 1 will just take people to section 1.1. Granted, my test is a little extreme, but for a more realistic example, see List of American Housewife episodes. Editing "Season 3" under "Ratings" will just take me to "Season 3" under "Episodes" once I submit the edit. Likewise if I link to "Season 3." Amaury (talk | contribs) 07:29, 7 September 2018 (UTC)

How about people start observing MOS:HEAD and not create headings with identical names? – Finnusertop (talk ⋅ contribs) 09:41, 8 September 2018 (UTC)
The MOS:HEAD point actually states exactly why the rule exists... which is because of technical limitations. (One might tease out that having no same headings is also a bit more accessible, but I don't know if that's per se true or not.) The ones Amaury is advocating could or should go away. However, it is not obvious to me that this would work to fill the contribution summary. --Izno (talk) 12:10, 8 September 2018 (UTC)
There already is a mechanism for making the section links unique - but it's invisible. Append a space and an integer from 2 upwards. Try out these links and compare their effects: User:Amaury/sandbox/Test page#Sub-Section 1 and User:Amaury/sandbox/Test page#Sub-Section 1 2 all the way down to User:Amaury/sandbox/Test page#Sub-Section 3 25 and User:Amaury/sandbox/Test page#Sub-Section 3 26. This is not really a VPR matter, more one for WP:HD. --Redrose64 🌹 (talk) 15:20, 8 September 2018 (UTC)
Or -- And I know that this is a radical proposal -- The WMF could take some of the 91 million dollars that they got on donations last year or the 113 million dollars they had left over from the year before and spend it fixing basic usability problems like the table of contents sending you to the wrong section. All it would take is a hidden variable; the first time someone names a header "Season 3" the software displays it as "Season 3" but stores it as "Season 3 0001" and stores the next occurrence of "Season 3" as "Season 3 0002", and the table of contents and the part of the software that returns you to a section after an edit would use the long version with the hidden variable. In my opinion, this would be a better use of the money than the 3.3 million they spent on travel expenses for Wikimania. I'm just saying. --Guy Macon (talk) 17:47, 8 September 2018 (UTC)
@Guy Macon: Please give an example of a page where the TOC takes you to the wrong section. --Redrose64 🌹 (talk) 20:27, 8 September 2018 (UTC)
I just tested it on my sandbox. I was wrong. Just using the table of contents works fine. Using the table of contents to go to a section and then editing the section brings you back to the wrong section, but that's not what I described above. Thanks for the correction. Also, posting a link to the second section doeasn't work. The reader ends up looking at the first section.
Still, coming back to the wrong section after an edit and not being able to correctly link to a section falls under "fixing basic usability problems". --Guy Macon (talk) 22:21, 8 September 2018 (UTC)
posting a link to the second section doeasn't work. The reader ends up looking at the first section. In my post of 15:20, 8 September 2018 (UTC), I gave four links. The second of these, User:Amaury/sandbox/Test page#Sub-Section 1 2 takes me to the Sub-Section 1 that is under Section B. It works as intended. --Redrose64 🌹 (talk) 09:38, 9 September 2018 (UTC)
phab:T2111 from 2004 is "Return to page after edit of section when section name occurs multiple times may point to wrong section". I agree MediaWiki should detect if it's the 2nd section by that name and automatically add _2 to the anchor like it already does in the TOC. PrimeHunter (talk) 11:17, 9 September 2018 (UTC)
@Guy Macon: That sounds... quite difficult. Mediawiki doesn't currently have the ability to store anything associated to a particular piece of content, afaict. It's all plain text, and when the user edits it, it's replaced by new plain text. Trying to attach permanent identifiers to headers would probably require making VisualEditor the only available editor and dropping wikitext, which I'm quite certain wouldn't be popular here. --Yair rand (talk) 19:51, 12 September 2018 (UTC)
As Redrose64 demonstrated above, Mediawiki already stores something that allows the table of contents to work correctly when two sections have identical names - identical in the wikitext and identical when the TOC is displayed.
Speaking as a person who spent years writing software and more years managing engineering project that included software, I am extremely dubious about arguments in the form of "yes, the behavior of the software sucks in this instance, but I just spent a whole 30 seconds thinking about it and concluded that it is too hard too fix because of our existing software". Many times, after I direct the person saying that to spend 4 hours writing up a plan for what it would take to fix the suckiness and a rough estimate of how many man-hours it would take, I get a completely different answer after the four hours is up.
There is an attitude around Wikipedia of putting up with minor annoyances and glitches rather than making the software excellent. This is a problem.
As of Saturday, 16 November 2024, 15:39 (UTC), The English Wikipedia has 48,273,142 registered users, 121,641 active editors, and 852 administrators. Together we have made 1,253,020,545 edits, created 61,849,800 pages of all kinds and created 6,911,448 articles.
If we made a tiny improvement to our software that, by removing an annoyance like coming back to the wrong section after an edit, reduced the time to spent creating the page (the total time, including every edit ever made to that page, every talk page comment, and all the time spent by multiple users checking the page for errors over its lifetime) by a single second per edit, that would be the equivalent of a single person working 40 hours a week for six and a half years.
As of the 2016-2017 fiscal year we had $91.3 million USD in revenue, $69.1 million USD in expenses, and $113.30 million USD in assets.[2] So we could easily afford to hire a few top-notch software developers to make improvements to our software.
Given the above numbers, in my considered opinion we should not put up with minor annoyances in our software. We should hire someone to fix them.
This of course assumes that fixing the suckiness is too hard for our staff developers to do, a claim that I find to be dubious. IMO They appear to be highly competent, but IMO hindered by management decisions (and we have had major changes in management since then, so this may no longer be the case). --Guy Macon (talk) 21:46, 12 September 2018 (UTC)
@Guy Macon: Mediawiki doesn't store anything about headers between revisions. The table of contents is regenerated from scratch after every edit. My point was not that this problem is unfixable or shouldn't be worked on (it really shouldn't be marked "Lowest" priority in Phabricator), just that your proposed solution really couldn't work. --Yair rand (talk) 22:53, 12 September 2018 (UTC)
The discussed issue only affects section edits to a section with the same name as an earlier section. That is a tiny part of edits at the English Wikipedia. It's more common at Wikivoyage according to Carlb at phab:T2111. Phabricator is the place to request changes to the MediaWiki software. T2111 shows this change has already been suggested many times. PrimeHunter (talk) 23:48, 12 September 2018 (UTC)
Please don't ask me to report anything at Phabricator. See User:Guy Macon/Discrimination against the visually impaired for what should be a high priority item that has sat unaddressed for 12 years. --Guy Macon (talk) 01:17, 13 September 2018 (UTC)

Wikipedia, a quatertiary source.

Closed as having a 0% chance fo succeeding and therefore repeated re-opening is disruptive. User warned not to re-open on their talk page. Beeblebrox (talk) 21:55, 28 September 2018 (UTC)
WP:SNOW due to suggesting a detrimental policy change that would rail against the mission of Wikipedia. This proposal would be akin to deleting the main page in terms of the collateral damage this could bring. Kirbanzo (talk) 21:04, 28 September 2018 (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.

Wikipedia guidelines call Wikipedia a tertiary source.

I dispute that claim.

Tertiary sources don't rely only on reliable sources.

Secondary sources rarely ever have any oversight. (besides economic)

Typically, tertiary sources like most encyclopedias have strict over-sight.

Wikipedia mostly cites tertiary sources, including meta-studies as well as academic reviews.

Overall Wikipedia mostly only accepts tertiary sources, including news which cites other news.

Secondary sources necessarily interpret information, generating helpfully extreme bias.

NPOV means neutral-POV not mythical "no-POV", so neutral-POV can't exist without POV.

The more extreme and diverse the biases tertiary sources absorb, the more reliable the information.

Wikipedia should not discourage secondary sources from generating extreme bias.

Instead wikipedia should encourage extreme bias from secondary sources and encourage tertiary sources to absorb that bias.

Then, wikipedians should combine and weigh tertiary sources against each other to decide what information achieves a minimum standard.

Wikipedians should do this by checking primary and secondary sources to ensure the tertiary perspective accounts for all said by them.

Wikipedia should change policy to allow unreliable sources only to make up for gaps in the accounts made by tertiary sources.

Gaps should include:

  • explained contradictions, in behavior or moral positions;
  • unaccounted details (about events) supported substantially by primary sources, or;
  • unaccounted novel justifications or novel moral positions supported substantially by secondary source.

Eaterjolly (talk) 09:48, 28 September 2018 (UTC)

  • Not happening. Reliable Sources is a core policy. Policy No Original Research prohibits novel or creative interpretations (edit: and subsection SYNTH prohibits "filling gaps" with arguments, reasoning, contradictions, justifications, observations, or anything else). Guideline Fringe is clear that views with little or no coverage in Reliable Sources will receive little or no coverage in articles. And I'd like to emphasize that our Policy on Biographies of Living Persons means that these requirements will be firmly enforced on regards to persons. There is no chance that we are going to overturn our entire standard of Encyclopedic content to accept all of the novel, fringe, strange, or creative views that float in on the internet. I support swift SNOW closure.
    P.S. Strangely formatted and largely-incomprehensible proposals are rarely successful. Alsee (talk) 11:02, 28 September 2018 (UTC)
Reply: Editors already WP:IAR, when including biased secondary and primary sources. Often when an obviously notable view doesn't get covered by any neutral sources, so wikipedians erroneously categorize that as WP:SELFSOURCE. Since wikipedia gets hailed as the only necessary tertiary source, tertiary sources often mascaraed as secondary sources while getting called meta-news as well as wilfully lacking oversight because they push the issue of scrutiny onto textbook authors, academics, or wikipedia.
  • First, I propose that details from platformed primary sources (having a significant audience) not accounted for by the journalism of any secondary or tertiary sources, get officially allowed on wikipedia which already happens by convention under WP:SELFSOURCE
  • Second, I propose notably biased or extremely biased secondary sources (i.e. the Daily Mail, Breitbart, BuzzFeed) for POV'es unaccounted for by neutral sources. This also happens by convention, yet much more contentiously. Often discussions go out into trial by verbal combat whether the source's articles completely irrelevant to the topic at hand give reliable information. Obviously different sources give reliable information on different topics, and sources which venture outside the narrow scope of their specialty typically make mistakes while outside that scope. I wouldn't trust Breitbart to report on gender, nor would I trust Buzzfeed to report on history, though I might trust Brietbart to report on history and Buzzfeed to report on gender.
Consequently I don't think this would change much except focus discussions more, and open up the possibility to incorporate multimedia sources in citations. I personally would like to find TED talks cited on wikipedia. The proposal would result in an official section in the guidelines which would state primary sources and secondary source can compensate for gaps in reporting by rigorous tertiary sources. Again, already the practice. Primary sources should give information suitable for wikipedia when the source has a platform (a significant audience), the particular details cited present minimal POV, the details have not gotten accounted for by tertiary or secondary sources, and the particular details cited have gotten corroborated by other platformed primary sources. Biased secondary sources should give information suitable for wikipedia when the source has a platform (a significant audience), the opinions cited form a remarkable POV (non-trivial and unique, in other words), the opinions haven't gotten accounted for in the reporting by any rigorous tertiary sources nor can get inferred false by evidence reported thereof, and the opinions cited have gotten corroborated as believe-able by other platformed secondary sources. This would also open up citing notable youtube vloggers for opinions not expressed, investigated, or otherwise accounted for in any way by mainstream news. This would also open up youtube news like the Philip DeFranco show for inclusion on wikipedia as a mostly reliable source.
I welcome further discussion about this.
Anyone, please comment!
Eaterjolly (talk) 19:48, 28 September 2018 (UTC)

@Kirbanzo: I don't believe the proposal recommends any particularly shocking change, just more an admission of already practiced convention and a slight expansion of cite-able sources purely based on the addition of a medium for citation not on a lower standard. Eaterjolly (talk) 19:52, 28 September 2018 (UTC)

  • Are you serious? This would throw a lot of policy that has worked very well out the window - not to mention railing against Wikipedia's goals. It would also create point of view pushing on a massive scale if unreliable sources could be used to defend such pushing. Overall, my "deleting the main page" analogy is correct - this proposal could and would drastically alter Wikipedia's reliability, neutrality, policy, etc. WP:SNOW applies to things like this - altering the mission of Wikipedia is taboo. Closing again, as there is no need for this to go through process. Kirbanzo (talk) 20:59, 28 September 2018 (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.

Non-admin 'delete' group

Nothing new is being proposed, and not happening for the same reasons. Alex Shih (talk) 18:54, 17 September 2018 (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.

This is my big proposal today. I have seen huge speedy deletion backlogs and AfD backlogs many times. Here is my proposal. My proposal is that non-admins are able to access the 'delete' tool. The 'delete' tool will only be available to highly-trusted users and can only be given at WP:PERM. This tool will also help fight vandalism in a way that bad pages will be deleted on sight on Huggle and when they enter the speedy deletion log. This 'delete' group and rollback together will help fight vandalism quickly. I had read Wikipedia:Requests for comment/Proposal to allow non-admin deletions for XfD and I was disappointed that it failed. Trusted non-admins should have the right to delete pages and clear speedy deletion logs without having to pass a RfA. Also, the speedy deletion backlog is sometimes huge. This is especially going on with things like drafts which are being deleted under CSD G13 and uncontroversial deletions under CSD G6. However, others also get big backlogs too as well. If this gets approved, users with this tool will be able to the following:

  • Delete pages (delete)
  • Mass delete pages (nuke)
  • View deleted history entries, without their associated text (deletedhistory)
  • View deleted text and changes between deleted revisions (deletedtext)
  • Undelete a page (undelete)

I feel users have to have 6 months to 1 year of editing, at least 3,000 edits and plenty of experience at any of the deletion noticeboards and speedy deletion. The user who is requesting the 'delete' right should not be a vandal. This right may be given through WP:PERM to trusted users by an administrator and it can be revoked if abused. I would like to know what you think. I don't expect this to succeed but there is no problem having a go with this proposal. I have a huge CSD log myself and I know many other users have big CSD logs that will certainly benefit from this tool. Pkbwcgs (talk) 18:23, 17 September 2018 (UTC)

Addition to this proposal - users with this right can view deleted pages. Pkbwcgs (talk) 18:40, 17 September 2018 (UTC)
  • Strong oppose for all the previously stated reasons why these tools cannot and should not unbundled, including but not limited to the WMF legal team requiring RFA or a similar process before access to delete pages and see deleted pages. This proposal does not address any of the previous objections. Regards SoWhy 18:31, 17 September 2018 (UTC)
    Also, and this is my strongest reason: I cannot think of any user who can both be trusted enough to delete pages and not be trusted enough to protect them or block users. But I can think of a lot of users who meet those requirements who I would never ever trust to delete pages. Regards SoWhy 18:44, 17 September 2018 (UTC)
    @SoWhy: Protect and block are core admin tools. Delete is also a core admin tool but users who have done loads of work in the deletion area should get this right. Obviously, it wouldn't make sense to have block and protect as separate rights. However, it makes sense for experienced non-admins to be able to access delete. Pkbwcgs (talk) 18:48, 17 September 2018 (UTC)
  • Oppose per SoWhy: the ability to view deleted text should not be unbundled from the ability to delete pages. That cannot happen without RfA, so therefore the ability to delete should not happen without RfA either. TonyBallioni (talk) 18:34, 17 September 2018 (UTC)
    Oppose the addendum as it doesn't get the point of these opposes: viewing deleted text and revisions is the core ability of sysops as far as the WMF is concerned and is the reason RfA is required before getting +sysop. TonyBallioni (talk) 18:43, 17 September 2018 (UTC)
  • Oppose allowing people to delete pages without being able to see deleted revisions strikes me as a very bad idea. --SarekOfVulcan (talk) 18:36, 17 September 2018 (UTC)
    (response to change in proposal) You can't view deleted revs without an RFA-equivalent process. --SarekOfVulcan (talk) 18:42, 17 September 2018 (UTC)
  • Oppose - generally speaking, the WMF will not allow access to view deleted content except for users who have gone through RfA or a community vetting process similar to RfA. AFAIK the Foundation hasn't said anything about allowing non-admins to delete pages without being able to view pages once they're deleted, but that creates an additional backlog problem for admins who would need to also scrutinize non-admin deletions, on top of scrutinizing CSD tags. This proposal doesn't reduce the backlog, it just splits the backlog into two separate queues. Ivanvector (Talk/Edits) 18:41, 17 September 2018 (UTC)
    Oppose the addendum as well - non-admin access to deleted content is a non-starter. It's not up to us. Ivanvector (Talk/Edits) 18:42, 17 September 2018 (UTC)
  • Oppose on legal grounds, as stated by others above. 331dot (talk) 18:51, 17 September 2018 (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.

bays/inlets

What is the difference between a bay and an inlet ? I suggest Category:Inlets by country should be merged and replaced by Category:Bays by country. This probably this needs to be discussed, but I don't know where to ask. --Io Herodotus (talk) 05:05, 17 September 2018 (UTC)

Our articles, bay and inlet describe them as mostly different. Rmhermen (talk) 06:58, 17 September 2018 (UTC)
OK And what is the difference between a gulf and an inlet ? A gulf is an inlet. It's often difficult to know where the differnce is. Is Khawr al Udayd a bay or a gulf ?--Io Herodotus (talk) 07:32, 17 September 2018 (UTC)
Try our article on gulf maybe? --Izno (talk) 12:02, 17 September 2018 (UTC)

Language is not mathematically precise so this causes problems for computers attempting to categorize along a boolean form (bay or not-bay). In these cases one typically maintains multiple categories and follow the cultural naming conventions. For example, Facebook has a few dozen options for gender choice (this list is outdated more have been added), but they generally don't have an "other" option as they can't do much with that in terms of targeted advertising. Likewise with bays and inlets, how its called depends on the end-user preference (the place name convention). -- GreenC 14:56, 17 September 2018 (UTC)

  • Not sure why this is here instead of WP:RDL or WP:RDH, but since we've started here, lets finish here. The difference is that Bays are those bodies of water that people have named "Bay" and that inlets are those bodies of water that people have named "Inlet". The names are not mutually exclusive or even self-consistent, that is there are very different kinds of bodies of water named "Bay", that share little in common except being "bodies of water". Consider the difference between Opechee Bay and the Bay of Biscay. There are some general trends; Bays are generally only partially enclosed, that is being surrounded by wide, long arches of coastline, with a headland on each end (see, for example Bay of Biscay or Onslow Bay). Particularly deep bays are sometimes called a "bight", see Heligoland Bight or Great Australian Bight. An inlet, by contrast, is usually a cut through a barrier island which connects a sound, lagoon, or estuary to the ocean, like for example Jones Inlet or Oregon Inlet. Gulfs are also just bays, some people try to say that gulfs are particularly narrower than Bays, but not always (compare Gulf of California to Gulf of Mexico. Ultimately, they are just words, they all mean "a body of water", and words are fuzzy. There's some trends you can learn, but with anything like this, you should never be surprised when you find outliers whose name does not match the expected definition that closely. --Jayron32 16:43, 20 September 2018 (UTC)

Proposal for bot-synced geonotices

A proposal to sync geonotices with a bot, which will allow all admins to edit geonotices again, is being discussed. Enterprisey (talk!) 19:04, 22 September 2018 (UTC)

Make Names Taken Names Usable for retired users

many Usernames are taken by users who did not edit in a long time i think new users should be able to get the usernames69.14.93.75 (talk) 20:48, 24 September 2018 (UTC)

Usurpations already exist; however, they are not available to new users for obvious reasons. Nihlus 21:12, 24 September 2018 (UTC)

Special:CreateAccount

At Special:CreateAccount a link labelled (help me choose) directs a person to the Username policy. I would like to know how many people have actually read through the page and or found it useful/helpful when they first registered an account. — fr + 08:07, 14 September 2018 (UTC)

I did not, for one.But, have anyone ever felt that the persons in these help-videos are a bit err........weird......? With all due respect to the prosucers and those in the videos, can't the video-makers choose folks from the median-class? ∯WBGconverse 08:48, 14 September 2018 (UTC)
Neither did I for that matter, which is why I asked. I did find the people in the video to be a bit weird but to be fair, those were probably not designed keeping the Indian middle class in mind. — fr + 11:26, 14 September 2018 (UTC)
@FR30799386:--Iridescent's opinion over here is interesting :-) ∯WBGconverse 12:46, 18 September 2018 (UTC)
I always found that link odd. It would be better if some guidance were offered directly on the account creation page. Regards SoWhy 16:50, 14 September 2018 (UTC)
I agree with SoWhy and their solution. It seems odd to have that there. A brief run-through on the page would probably draw more attention and make it easier to find that info. StarlightStratosphere (talk) 21:19, 25 September 2018 (UTC)

Deprecating GFDL

Wikimedia Commons has officially deprecated the GFDL and will no longer allow images licensed under just the GFDL after October 15. I'm not sure how I feel aboutt his change, but I think we should make the corresponding change here too - we should not accept a "free license" that is not accepted at Commons. (The only "free" files we accept that Commons does not are files that are public domain in the US, but not in their country of origin.) --B (talk) 13:42, 14 September 2018 (UTC)

  • Comment: we should not accept a "free license" that is not accepted at Commons begs the question – why not? Shouldn't we accept all licenses that meet WP:C? – Finnusertop (talk ⋅ contribs) 14:08, 14 September 2018 (UTC)
  • Comment: Please note that GFDL has been deprecated for most, but not all types of files. Copying stuff from a GFDL-licensed software manual to Commons is still possible, for example [3]. --El Grafo (talk) 14:11, 14 September 2018 (UTC)
  • This can lead to an absurd situation where the file that has been released under a free licence is being uploaded under fair use. Facepalm! Gone Postal (talk) 14:22, 14 September 2018 (UTC)
    Not really, any local Wikipedia could decide to continue to allow GFDL-only photos. {{PD-USonly}} isn't fair use either. If this passes, well yes, but that's theoretical. Most GFDL-only photos and the like are own work. That would hardly if ever meet the non-free content criteria. Alexis Jazz (talk) 14:24, 14 September 2018 (UTC)
    Let's say File:Reham Khan memoir.jpg were licenced under GFDL, are you telling me that magically it would no longer be allowed as fair use and would be disallowed because of the "deprecated" licence? How does any licence make fair use not legal? Gone Postal (talk) 20:41, 14 September 2018 (UTC)
    @Gone Postal: Commons allows an exception for things extracted from GFDL-published software manuals and the like. Is there anything else that you can think of that would be acceptable for fair use under our policy and would ever be published as GFDL? People out in the non-Wikipedia world occasionally publish things with Creative Commons license, but they never publish under the GFDL. The idea is that if we're uploading our own photos, we will upload them under something freer than the GFDL. Nobody outside of the wiki-universe is creating GFDL images. --B (talk) 15:10, 14 September 2018 (UTC)
    If people never publish under GFDL, then what is the purpose of discussion at all? To resolve the problem that doesn't exist (I actually agree with that assessment). The truth of the matter is that there are cases where GFDL is used, and any file that is under fair use right now could theoretically be published under GFDL by copyright holder. Gone Postal (talk) 20:41, 14 September 2018 (UTC)
    Aside from people publishing documents for GPL software (which is a permitted exception under the new Commons policy), the only people who publish anything under the GFDL are people who contribute to wikis. So we're going to simply say you can't do that any more - if you want to contribute to Wikipedia, you need to license your content under an acceptable Creative Commons license. Your concern that you expressed was what if there was something that might otherwise be acceptable under our non-free content policy but was published under the GFDL and my contention is that no such content exists or ever will exist. --B (talk) 21:29, 14 September 2018 (UTC)
    And that is my point as well, the anti-GFDL crowd seems to be hiding their head in the sand pretending that fair use is somehow better than GFDL. And simply disallowing somebody from uploading a file under GFDL and forcing them to upload it as fair use is not a proof that you are correct, in fact it is an admission that you know how wrong you are, since you would be forced to delete the free file just so that nobody is noticing the glaring problem. Gone Postal (talk) 12:44, 15 September 2018 (UTC)
    Well lets assume after October and if en Wiki followed Commons path, someone finds or has a photograph of a living person (or recent) licensed under a GFDL, then it can't be uploaded under fair-use (since it is assumed that a "free-use" photograph exists, since it does but just not recognised by a few contributors). Why is it that a few are so interested in "re-users" yet they totally disregard the uploaders who contribute, in fact excluding them from the policy discussion by not informing them of it, while GFDL is still recognised as a "free-use" license. Bidgee (talk) 14:17, 16 September 2018 (UTC)
    GFDL is virtually nonexistent outside of wiki and software manuals. And the same arguments can be used to advocate allowing CC BY-NC and BY-ND on Wikipedia. Alexis Jazz (talk) 15:31, 16 September 2018 (UTC)
    Could you stop including NC and ND into the GFDL which is just a FUD, yes a very small number of users had included NC but that is a different matter that should be discussed separately, GFDL is still a "free-use" license that I have seen used outside of Wikipedia/Wikimedia that wasn't text form. Bidgee (talk) 03:34, 17 September 2018 (UTC)
    @Bidgee: "GFDL is still a "free-use" license that I have seen used outside of Wikipedia/Wikimedia that wasn't text form." Pics Links or it didn't happen. And nothing that's over 10 years old. Alexis Jazz (talk) 13:09, 17 September 2018 (UTC)
  • Support (as the proposer of the proposal on Commons) GFDL for photos is/was mostly used as a Creative Commons NonCommercial backdoor. Textbooks, software manuals and (as El Grafo already mentioned) logos, diagrams and screenshots extracted from such a manual are still allowed. Alexis Jazz (talk) 14:24, 14 September 2018 (UTC)
  • Comment As background, the rationale for the change on Commons is that GFDL, as a sole licence, is now only used (and it is only occasionally used) as a backdoor "CC -NC" because of the burdens it imposes on reuse outside of Wikipedia. Wikipedia:Copyrights doesn't say anything about what licences are acceptable. Wikipedia:Image use policy simply links to Wikipedia:File copyright tags for "a list of possible licenses which are considered "free enough" for Wikipedia". That page offers two lists. One is a link to Wikipedia:File copyright tags/Free licenses and the other is titled "For image creators". Not entirely sure why we need both. Anyway, Wikipedia:File copyright tags/Free licenses list already discourages GFDL (because of the burden to reproduce the entire text of the GFDL when reusing) but it also states a falsehood: "If one include any of the content, the entire book/section goes under GFDL, unlike CC-BY-SA". That is garbage and should be removed. What might help here is for that section to have similar guidance to Commons about GFDL/GPL no longer being accepted. Further, the "For image creators" of Wikipedia:File copyright tags probably shouldn't list anything other than CC, FAL and PD. For PD it should suggest CC0 as well as PD-self as the former is more useful internationally and better thought out. I don't think obscure licences, licences designed for software and software manuals, and home-made ones like "Copyrighted Free Use" should be listed at all. But more generally, users should be more strongly encouraged to upload to Commons instead. -- Colin°Talk 14:43, 14 September 2018 (UTC)
  • Oppose if commons does not permit it, then it is good to have somewhere else to load it for use. The reason for not hosting on commons is extremely weak, as the licensing requirements are the problem for the reuser, and as long as we comply, which I believe happens, then it is OK, and potentially useful. We can discourage the license use, and encourage a CC license. But that can only be done if the material is not already under the GFDL. Graeme Bartlett (talk) 05:38, 15 September 2018 (UTC)
    This argument is also valid for CC BY-NC, BY-ND and promotional images that can be shared free of charge. Alexis Jazz (talk) 15:31, 16 September 2018 (UTC)
  • Comment I am on a fence here. If common is not gonna allow it then why we should allow? That argument is as strong as the argument of Graeme Bartlett that if commons is not allowing it then it should be uploaded somewhere else. I think that advantages and disadvantages should be laid out. If I ever plan to upload an image, I would use upload it to Commons. Kraose (talk) 05:44, 15 September 2018 (UTC)
  • Support as per Alexis above. --Yann (talk) 13:11, 15 September 2018 (UTC)
  • Support with same caveat from Commons (as explained in their discussion there): material taken/extracted from software/manual/textbooks already under GFDL can remain licensed GFDL, but users otherwise should not be submitting any other type of content as GFDL to the onus on reuse. --Masem (t) 13:22, 15 September 2018 (UTC)
  • Support per Alexis. Thanks. Mike Peel (talk) 13:34, 15 September 2018 (UTC)
  • Oppose We allow, without discrimination, licenses that meet the Definition of Free Cultural Works 1.0 (WP:C). GFDL meets this definition [4].
  • People who are calling it a "backdoor NC" license are missing something. There is nothing inherent in commercial activity that precludes reusers from observing the terms of the license. I can print a GFDL book – and either sell it or give it away. I can host a GFDL website – and have it either open to all or behind a paywall. Just because it costs some extra to print or host 7 pages does not make it a NC license any more than a BY license is NC because attribution requires some extra ink! – Finnusertop (talk ⋅ contribs) 14:07, 15 September 2018 (UTC)
    • It's more that it's a "strong copyleft" license. I write commercial software and, as most people do now, I have a desire to use open-source libraries from time to time. I can't use anything that is GPL because it would require that I, in turn, release my software under the GPL (which I'm not going to do). Does that mean that GPL isn't a free content license? Of course not - it just means that it isn't useful to me in my needs. For good, bad, or indifferent, Wikimedia Commons has decided that it is going to deprecate the "strong copyleft" GFDL and only allow licenses that would be useful to a wider variety of re-users. That doesn't mean the GFDL isn't a good license with a good purpose - it just means that Wikimedia Commons is looking to host media that is useful to a wider variety of re-users, including commercial users who don't create GFDL websites. I don't know that I agree with this decision, but I also don't think that it makes sense for the English Wikipedia to have a different definition of "free content" from what Commons has. --B (talk) 14:21, 15 September 2018 (UTC)
    @Finnusertop: I'm calling it a "backdoor BY-NC" (I think I was the one who came up with that, but I'm not sure) because GFDL-only for photos was afaik used exclusively to upload photos with a CC BY-NC license. But a BY-NC license is not allowed so the photographer also tacked on a GFDL license, knowing full well nobody will be interested in using that. Alexis Jazz (talk) 15:31, 16 September 2018 (UTC)
  • Oppose it is certainly free culture, just as a licence that requires attribution to all down-users is free. We should not handicap Wikipedia from being useful with free culture, because some down users (or Commons) may not find it useful. We do not handicap Wikipedia from being useful with even 'fair use/NFCC', we should be even more loath to do so here with something that is freely-licenced. Alanscottwalker (talk) 14:29, 15 September 2018 (UTC)
  • Oppose Given the caveats, I don't see this as having much effect, but per Graeme Bartlett it would be useful to allow upload here. Hawkeye7 (discuss) 02:23, 16 September 2018 (UTC)
    @Hawkeye7: dare Graeme Bartlett to present a real-life example that isn't over 10 years old or a photographer trying to hamper commercial re-use. Alexis Jazz (talk) 15:31, 16 September 2018 (UTC)
  • Oppose per Graeme Bartlett. Sadly the Commons GFDL restriction was part by a few who also want to remove CC-BY-SA as a default license and replace it with CC-BY, what next! Bidgee (talk) 07:04, 16 September 2018 (UTC)
  • Oppose per Graeme Bartlett. Having more licensing options is beneficial to Wikipedia as it encourages more people to upload images.  pythoncoder  (talk | contribs) 15:54, 16 September 2018 (UTC)
  • Comment I think a point to stress from the Commons argument is not to disallow GFDL but where users have a choice of licensing (such as their own photos) to disallow the use of GFDL as such a license. If there is material that already exists that is appropriate to use and it is only under GFDL, there's no reason to not accept it, but this is primarily only going to be software and related materials. GFDL is not a license people use for their photos or other works that are not software related. --Masem (t) 16:03, 16 September 2018 (UTC)
    • Well the decent and human response when someone gives something away, is just to say 'thank you.' Alanscottwalker (talk) 17:49, 16 September 2018 (UTC)
      • GDFL is a burden to re-users (as the whole 7 page license is supposed to be attached with any use), just as CC-*-NC or CC-*-ND does. We want our free media to be reasonably reused, so we want uploaders , if they have a choice, to use one that minimizes the "harm" for reusers. If the work to be added already pre-exists as GFDL, then we have to accept it, but most of our free works created by editors are photographs, drawings, or the like, and these clearly benefit better from being in PD, CC-BY, or CC-BY-SA. --Masem (t) 00:53, 17 September 2018 (UTC)
          • What we want is the best reference work possible. People should feel free from now on to upload whatever encyclopedic work of thier own they want to right here, using GFDL even, and avoid the ungracious others, who act as if they wish to shove people around about how they give things away, and we will use it because it makes the knowledge of the world better (at least, that's our mission). This proposal reminds me somewhat of the times one gets a few people who argue we should disallow books as references because they are not online or not free access online (no, that is not what we are here for, it's just wrong) -- Alanscottwalker (talk) 18:36, 17 September 2018 (UTC)
            • Ungracious? GFDL was simply never designed to license photos. How about I call you ungracious for not accepting CC BY-NC material? You would gain a lot if you did. GFDL on the other hand will get you pretty much nothing. In the future another photographer may stand up who doesn't want their photos to be used outside Wikipedia. That's all you can get. To my knowledge, there was only one really active photographer left on Commons (a few years ago we had more) who used GFDL (combined with CC BY-NC). And guess what, he was only doing it out of protest, going so far as to recommend this license to anyone who was looking for a noncommercial/Wikipedia-only license. That is what you are really voting for. No sane person uses GFDL-only for photos nowadays, unless they want to hamper commercial use. Alexis Jazz (talk) 20:08, 17 September 2018 (UTC)
              • There's still the case of illustrations from books that are GFDL. Hawkeye7 (discuss) 21:04, 17 September 2018 (UTC)
                • Which would still be allowed under this proposal. The way I read this proposal, assuming "you" are the person that wants to upload material.
                  • If "you" are not the creator of the material, and it already exists in a GFDL form (which 99.9% is going to only be software, manuals, textbooks, and materials extracted from those), then we'd still accept it (just as Commons would too)
                  • If "you" created the material, then you should not use the GFDL for that material, but instead PD or CC-BY/CC-BY-SA.
                • GFDL is not being banned, just only where we don't have an option to use something else that is less restrictive for our readers. --Masem (t) 21:44, 17 September 2018 (UTC)
  • Oppose per Graeme Bartlett and others. It's not uncommon that different projects use different standards, e.g. de-wiki does not allow FU at all despite German law not applying to a site hosted in the US. If there are problems with GFDL for newly created content, we can address this by asking people who upload their own works to do so at Commons where they will not have the option to select GFDL anymore. Oh, wait, we already do that. So what is the problem? If someone really creates something and wants to use a GFDL-license, we should allow them to do so because the alternative is not having that creation at all. Regards SoWhy 13:23, 17 September 2018 (UTC)
  • Why the Wikimedia projects should not use GFDL as a stand alone license for images. Why did I forget to link Notafish? This was written already back in 2005. All the opposers should read it. Some also referred to Freedom defined. https://freedomdefined.org/Licenses#Intended_scope is trying to tell you the scope is "Documentation", https://freedomdefined.org/Licenses/GNU_FDL_1.2 tells you the license was created "in order to be used for software documentation". It was never meant for photos. Alexis Jazz (talk) 23:53, 17 September 2018 (UTC)
Read it. Not persuasive. So, some down user may not like the licence, and some down user may not like an attribution licence, and some down user may not like fair use. None of what the down user may not like has anything to do with building the pedia -- the down user by definition is not building the pedia, they are doing something else with it. Furthermore, it remains an image is a document. Alanscottwalker (talk) 11:31, 18 September 2018 (UTC)
I'm so sorry, I'm a complete idiot! Thank you for sharing your wisdom. I'll contact Merriam-Webster, Collins and Oxford right away so they can update their definitions! Alexis Jazz (talk) 16:04, 18 September 2018 (UTC)
You think of yourself as an idiot? That's too bad, but no need to contact anyone about that. Alanscottwalker (talk) 16:12, 18 September 2018 (UTC)
The WMF's entire free content policy is aided to serve the downuser or repurposer in this case (that's why SS-BY-ND or -NC is not allowed as a "free" license). We do have certain expectations on content creators outside of licensing that we expect them to follow too, such as no watermarks on photographs or images that they freely provide (so that downusers can use these with even more freedom), there is no issue with telling content creators that want to provide material not already under a license to not use the GFDL to remove restrictions on downusers. --Masem (t) 16:19, 18 September 2018 (UTC)
We are not the WMF, Wikipedia's purpose is and always has been building the encyclopedia -- thus, Wikipedia allows even non-free content to be hosted, and GFDL is free content. Alanscottwalker (talk) 16:30, 18 September 2018 (UTC)
Limited non-free content, and where possible, using free content over non-free. That's a directive all WMF projects must comply by. Now granted, judging the GFDL to be less-freer than CC-BY (principally by placing an undue onus on reusers to include the full GFDL on reuses, but otherwise not restricting reuse/derivative rights) is probably up to the individual projects, but logic of why follows with the WMF's goals for all projects, to create works that can be reused and repurposed anywhere without restrictions. Non-free is only allowed where it meets the educational purpose and we don't have any other way to do that with free content. Asking users to use a more free-er license than the GFDL seems wholly appropriate to do within that purpose. --Masem (t) 17:09, 18 September 2018 (UTC)
  • Oppose - Commons is its own little cult with their own extremist rules about licensing (and a law-of-the-jungle culture of vendetta-motivated deletion). Their decisions are their own, and they can live with the consequences. English Wikipedia is not Commons, nor should it aspire to be. There is no legal defect with the GFDL and its acceptability should be maintained. Carrite (talk) 16:58, 20 September 2018 (UTC)
@Carrite: I'm not going to argue with your first points. A part of Commons is downright sick. Not gonna argue about that, you're just right. What I do argue about is "There is no legal defect with the GFDL". The GFDL is a perfectly fine license for books and manuals. It was never designed for individual photos. It wasn't even designed for anything on webpages! It causes huge problems if you want to comply with the license outside of the original scope: documentation for freely licensed software. Wikipedia:Licensing update wasn't just for kicks. Alexis Jazz (talk) 21:46, 21 September 2018 (UTC)
@Jonathunder: You're 9 years too late, GFDL-only text from third parties was already banned on Wikipedia in 2009. Alexis Jazz (talk) 21:46, 21 September 2018 (UTC)
  • Oppose per the PD-USonly precedent (en.wp treats files that are public domain in the United States but copyrighted in the their home country as free-content, even though Commons doesn't). Lojbanist remove cattle from stage 22:53, 25 September 2018 (UTC)
  • Support makes sense to me. Dual-licensing is ok. GFDL-only shouldn't be for images. Killiondude (talk) 00:00, 26 September 2018 (UTC)
  • Oppose - Most of what we host on en.WP (as opposed to Commons) is even copyrighted, so I don't see any harm in having GFDL images. In fact, I'm glad that by using strong copyleft we're giving a leg up to other copyleft users and organisations, as opposed to for-profits, and I kind of hope Wikipedia at large shares my attitude about this. Daß Wölf 02:26, 26 September 2018 (UTC)

CC-BY 4.0 as default license in upload forms

WITHDRAWN
The proposer has withdrawn their proposal. Kirbanzo (talk) 00:28, 27 September 2018 (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.

I suggest that CC-BY 4.0 should be the default suggested licensing when using the upload forms in Wikimedia projects for own works, instead of the current CC BY-SA 4.0 license (example at Commons), sometimes with dual GFDL licensing (example: here at Wikipedia). The main difference would be that derivatives are not required to have the same license. Reasons for changing to CC-BY 4.0 are:

  • It is a more permissive license.
  • It makes it much easier to combine and mix works. The combination of the two images at right, for example, would not have been possible at all if the images were licensed under let's say CC BY-SA 4.0 for the first one and CC BY-NC 2.0 for the other. However, if either was CC-BY 4.0 it would have been permitted. See WP:Adaptation for further information in this regard.
  • CC-BY is by far the most popular licensing for open access journals (see Directory of Open Access Journals - Journal license tab), and is similarly popular in databases (see CC: Data and CC licenses). CC BY-SA is therefore not compatible for inclusion in most open access journals, denying them free access to the sum of Wikimedia knowledge.
  • Most uploaders may very well be as willing to upload under CC-BY, but may not be familiar with the differences between having SA or not. The current upload form layouts thus make lots of works receiving a more restrictive licensing than necessary. Just because uploaders can upload under the most restrictive license Wikimedia has to offer doesn't mean they need to be presented with that option by default. Those who still want to put the additional SA restriction would still be able to actively choose so.
  • The currently suggested dual licensing with CC BY-SA 4.0 with GFDL such as here in Wikipedia (link to form) is actually incompatible in a strict sense (see Wikipedia section on this matter, and is also a lot of extra read for those who want to know what GFDL means, since it doesn't provide the short presentation as given in Creative Commons licenses (compare GFDL license page to the CC BY-SA 4.0 page. It would therefore be both easier for uploaders and more legally correct if we simply dropped GFDL from the default license suggestion. Again, those who do want to choose dual licensing for some reason would still be able to actively choose so.

I want to know if you agree with this suggestion, and we can then bring it to Wikimedia's legal team for review before implementation. I know the change is technically not that hard, since we only need to change the upload form layouts, not the licenses of any already uploaded works, nor the overall licensing of any wiki. I've started a vote on this issue in Wikimedia Commons. Please go to that page to join:

Mikael Häggström (talk) 20:38, 10 September 2018 (UTC)

  • Oppose: There are many great arguments against this proposal over at Commons that I recommend users read through. In fact, there was so much opposition that the nominator withdrew this from there. But there is a unique aspect of locally uploaded files here on Wikipedia that they didn't touch upon. Unlike Commons, which hosts educational content for all, Wikipedia hosts files for use on Wikipedia (unused files will be deleted, unlike necessarily on Commons). That's why, if I choose to upload locally, the default should be that my file remains free and can be used on Wikipedia even after someone has modified it. Under BY, I cannot include that condition.
A practical scenario: I upload a file on Wikipedia under CC-BY 4.0. Someone else downloads my file, edits it into a much prettier version, and uploads it on their website. I come across that enhanced version and would love to use it on Wikipedia instead of or alongside my original. I marvel at the picture – that even credits me by name – but to my astonishment I find out that it has been uploaded with the notice "All rights reserved, no re-use allowed". This can happen with a BY license, but not with BY-SA.
That's certainly not "the wiki way". While by contributing to Wikipedia I want re-users to benefit, I also want to accumulate a corpus of free works that stay free (after all, that's why text here is CC BY-SA and that's not going to change). At minimum, when I upload files locally, I want my files to also benefit Wikipedia in the event that derivatives are made. That's not too much to ask for, as the default position, which should also be intuitive for the casual contributor. If someone consciously wants to waive more rights, they are, of course, free to do so, but the default position should be that when you contribute to a free encyclopedia your contributions stay free. – Finnusertop (talk ⋅ contribs) 10:22, 12 September 2018 (UTC)
  • Oppose. One gives freedom to use derivatives, the other gives freedom to prohibit use. I think we have a valuable interest in the freedom to use. In particular we don't want someone cloning all of Wikipedia and making it difficult or impossible to bring improvements back here. Alsee (talk) 00:48, 17 September 2018 (UTC)
  • Oppose per Finnusertop. It's also wrong that contributors who use CC-BY-SA are not being asked. Bidgee (talk) 03:23, 17 September 2018 (UTC)

I have now withdrawn my proposal. Mikael Häggström (talk) 18:10, 24 September 2018 (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.

Removing genres from music infoboxes

There is an RFC on removing genres from music related infoboxes at WT:Manual of Style/Infoboxes#Request for comment on removing genres from musician, album, and song infoboxes — BillHPike (talk, contribs) 03:12, 28 September 2018 (UTC)

New proposal / Wikipedia:Naming conventions (books) / Standard disambiguation

In substitution of:

"To disambiguate, add the type of literary work in parentheses, such as "(novel)", "(novella)", "(short story)", "(short story collection)", "(dialogue)", "(essay)", "(play)", "(poem)", "(poetry collection)", etc. If none of these specific qualifiers applies, "(book)" can be used. Note, however, that this qualifier may be perceived as indicating a non-fiction type of writing.

If further disambiguation is needed, add the author's surname in parentheses: "(Orwell novel)", "(Asimov short story)", etc. In this case it is not advised to leave out the qualifier of which type of book it is, unless completely redundant, which may happen for some non-fiction books like Histories (Herodotus) and Histories (Tacitus). Additional examples:

I propose the following:

"To disambiguate two literary works add the author's name in parentheses.

Examples for Night and Day:

In case of the same autor has two works with the same title add, folowing of the author, the type of literary work, such as "(novel)", "(novella)", "(short story)", "(short story collection)", "(dialogue)", "(essay)", "(play)", "(poem)", "(poetry collection)", etc, or "(book)" if none of these specific qualifiers applies."

The reason of the proposal is because it is simpler, privilege the Author and work well in any circumstance (except in case of two works of the same Author). Then, there are works in which it becomes difficult to classify them as to their nature. And, if in the title of the article of an artistic work it isn't necessary, nor obligatory, the indication of its nature, why must its classification be included when it is a question of disambiguation?
I must note that I made a similar proposal at the Wikipedia in portuguese, and so far the six editors that had commented were against it. Namely, without being exaustive, because the focus should be at the art work, not at the author, because the proposal cause confusion, insted of the current explicative title type, because of the exception of two works with the same title by the same Author, because that could create confusion with other media, for instance in the case of Solaris (Stanislaw Lem) and Solaris (Andrei Tarkovsky), because of the need of standardization, and because if this proposal would be applied to the movies titles, for instance with the title The Three Musketeers, this would create a great confusion.
Nonethless, I don´t think these problems may occur, and I mantain that a title as Ulysses (poem), or Ulysses (novel), is less rich, less artistic, than the proposed Ulysses (Alfred Tennyson), or Ulysses (James Joyce).
At last, shouldn't it also be better for Wikidata, in general, have titles in the form of: Art work title (Name of the Author)? GualdimG/JMdosPerais 21:09, 15 September 2018 (UTC)
Other than concerns mentioned in the proposal itself, my main problem with this is that it makes the titles unnecessarily longer. TeraTIX 23:24, 20 September 2018 (UTC)
Also, specifying by media type gives more worthy information in an article's text, where many editors might rather omit a meaningless name from an article's link. If specifying art by author's name got more conventional, then sure. With more author's having longer and longer bibliographies, I don't envision that happening in any way foreseeable.
2600:1702:1740:2CA0:E999:AB0B:FB6E:FCC2 (talk) 09:26, 28 September 2018 (UTC)

11 years ago, I made a mistake

Frank Loria was a famous football player who later became a coach at Marshall and died in the Marshall plane crash in 1970. On July 3, 2007, I noticed that his article lacked a photo and so I dutifully uploaded his official bio photo from Virginia Tech and tagged it as fair use. It seemed reasonable. He was long dead so surely unless we were to engage in grave-robbing, we would not find a free replacement photo. Secure in the knowledge that I was complying with WP:NFCC#1 (which was then rather new), I uploaded the photo. But in reality, we have every reason to expect a free photo of him. All anyone ever had to do is go to the Virginia Tech library and there are plenty of photos of him from publications that bore no copyright notice and are thus public domain. I'm sure Marshall probably has photos of him as well. At some point, Virginia Tech digitized all of their old yearbooks - and in the ones I have looked at I have yet to see a copyright notice, so all of the photos - including ones of Frank Loria - are public domain. So what I would like to propose is that we tighten WP:NFCC#1. If someone was a public figure in the United States prior to January 1, 1978, we have every reason to expect that there exists a publication that published a photo of them without a copyright notice and until a search is performed that includes visiting a university library near their home location or some other equivalent offline source where one might expect to find a photo of them, we should not accept that WP:NFCC#1 has been met. (WP:NFCC#1 does not mean merely that we can't expect to find a photo in 30 seconds of googling.) --B (talk) 13:41, 2 October 2018 (UTC)

I think I would not want to "tighten", I think NFCC is also useful for situations where things are unclear, eg. where it is likely the photo hosted is out of copyright (especially because copyright is often byzantine), but we are unsure of all the details, thus out of caution we host as NFCC. The very purpose of encyclopedia is served thereby by having informative images (instead of none). Alanscottwalker (talk) 14:33, 2 October 2018 (UTC)
Why did you pick January 1, 1978? Presumably, the effective date of the 1976 copyright act.
However, your discussion talks about them being a public figure prior to that date. I don't think being a public figure or not a public figure is relevant (let me know if I'm missing something) but more importantly, the date is relevant in the context of the date of the publication of the photo. (If someone's a public figure in 1965 but has a photo published in 1985, then no copyright notice is needed.)
Two complications:
  1. Note that I said date of the publication of the photo not the date the photo was taken. If a photo was taken in 1977 and published in 1979, the copyright law in effect in 1979 applies, not 1977.
  2. In the time periods in which a notice was required it does not have to be on the front of the photo. This can cause annoying problems. Many photographs were taken with a copyright notice on the back of the photo. It is not uncommon for someone to send in a scan of a photo to OTRS and claim it is not subject to copyright because it did not have a copyright notice. This may or may not be true but we need to see a scan of the back of the photo to be sure. This problem should not arise in the case of the yearbook as it seems implausible that the yearbook would publish the photo on one side of the page and the copyright notice on the backside, but I want to be careful that your advice is not taken too literally. People can and do send in stands of loose photographs and presume they are out of copyright because there is no notice in the publication date was prior to the effective date of the 1976 copyright act.--S Philbrick(Talk) 14:45, 2 October 2018 (UTC)
Loose photos? How would you know if they were ever published? Alanscottwalker (talk) 14:50, 2 October 2018 (UTC)
Well, actually, if the photo was published in 1985 with no notice and there was not subsequent copyright registration, it's also public domain. But that isn't the point. The point is that if someone was a public figure in the United States prior to 1978, then is is highly likely that someone published (not just took, but published) a photo of them and there is a decent chance that they failed to comply with formalities. Obviously a loose collection of photos at a university library is probably not going to be public domain, but there are other things you can find there - school newspapers and other regional publications that frequently didn't bother with a copyright notice. --B (talk) 15:15, 2 October 2018 (UTC)
You made a mistake 11 years ago? Shame on you for not knowing all of the rules before you made your first edit! We must now block you for life and shun all appeals. --Redrose64 🌹 (talk) 20:33, 2 October 2018 (UTC)

Move references embedded in sub-section headings

This is a proposal for a bot (as bot writer). There are currently about 14,400 cases where a reference is embedded in a sub-section heading. The refs can be moved into the section body.

Before (from Belgium): 

=== [[Larger urban zone|Functional urban areas]]<ref name="europa">{{cite web|url=http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|publisher=appsso.eurostat.ec.europa.eu|title=appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|accessdate=6 January 2017}}</ref>===

After: 

=== [[Larger urban zone|Functional urban areas]]===
Source: <ref name="europa">{{cite web|url=http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|publisher=appsso.eurostat.ec.europa.eu|title=appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|accessdate=6 January 2017}}</ref>

MOS:HEADINGS (fourth bullet) should "Not contain citations on the same line" as the section title. They make a mess of TOCs and edit summaries and are unnecessary. Typically done to indicate that all the information in that section came from that source – because they don't know where else to put the ref. A Source: at the top resolves the MOS issues and retains the reference information. -- GreenC 14:23, 1 October 2018 (UTC)

Discussion

Three points. 1) More precisely, it should be "no space between terminal punctuation and a <ref>." (There are some cases where I think a space works, just not after punctuation.) 2) We should not confuse notes, created with <ref> tags, and citations, which notes generally contain. 3) Alternatively, would it be useful to have some kind of tag for "misformed heading"? ♦ J. Johnson (JJ) (talk) 23:58, 1 October 2018 (UTC)
This is drifting off-topic a little, since this doesn't apply here, but it's not just a matter of when there is a terminal punctuation mark. WP:REFPUNCT says "The ref tags should immediately follow the text to which the footnote applies, with no intervening space (except possibly a hair space, generated by {{hsp}})." Personally, I think it's a better idea to do something that fixes the problem than to do something that tags the problem, although I would hope that whoever is operating this bot would keep an eye on what it is doing and not just blindly let it do its thing. —BarrelProof (talk) 04:24, 2 October 2018 (UTC)
Of course I would. I'm used to running bots that make 100s of thousands of edits so 14,000 is no big deal. The way it's done is 1 edit. Then 2, 4 etc.. then a couple rounds of 100 .. manually checking all the way and stopping and fixing bugs. Then a couple 500s (manual check). 1000 (spot checks). 5000 (wait a few days for feedback). Then.. It's not like pressing "go" until 14,000 are done and clean up the mess after, much harder and uncomfortable that way :) -- GreenC 20:46, 2 October 2018 (UTC)
I don't see tagging as an end result, but as the start of a process. E.g., tagging could put an article into a special tracking category, and basically advise of a proposed change. There could be an option for anyone objecting to the proposed change to tweak a parameter, which would then shift the article to a different category for further discussion. Otherwise, after some period (two weeks?) the bot can be turned loosed on the articles remaining in the tracking category. While questioned bot edits doesn't seem to be a big problem re REFPUNCT, there are other areas where a process like this could reduce grief and drama by handling concerns with bot-edits proactively rather than retroactively. ♦ J. Johnson (JJ) (talk) 22:36, 3 October 2018 (UTC)

11 years ago, I made a mistake

Frank Loria was a famous football player who later became a coach at Marshall and died in the Marshall plane crash in 1970. On July 3, 2007, I noticed that his article lacked a photo and so I dutifully uploaded his official bio photo from Virginia Tech and tagged it as fair use. It seemed reasonable. He was long dead so surely unless we were to engage in grave-robbing, we would not find a free replacement photo. Secure in the knowledge that I was complying with WP:NFCC#1 (which was then rather new), I uploaded the photo. But in reality, we have every reason to expect a free photo of him. All anyone ever had to do is go to the Virginia Tech library and there are plenty of photos of him from publications that bore no copyright notice and are thus public domain. I'm sure Marshall probably has photos of him as well. At some point, Virginia Tech digitized all of their old yearbooks - and in the ones I have looked at I have yet to see a copyright notice, so all of the photos - including ones of Frank Loria - are public domain. So what I would like to propose is that we tighten WP:NFCC#1. If someone was a public figure in the United States prior to January 1, 1978, we have every reason to expect that there exists a publication that published a photo of them without a copyright notice and until a search is performed that includes visiting a university library near their home location or some other equivalent offline source where one might expect to find a photo of them, we should not accept that WP:NFCC#1 has been met. (WP:NFCC#1 does not mean merely that we can't expect to find a photo in 30 seconds of googling.) --B (talk) 13:41, 2 October 2018 (UTC)

I think I would not want to "tighten", I think NFCC is also useful for situations where things are unclear, eg. where it is likely the photo hosted is out of copyright (especially because copyright is often byzantine), but we are unsure of all the details, thus out of caution we host as NFCC. The very purpose of encyclopedia is served thereby by having informative images (instead of none). Alanscottwalker (talk) 14:33, 2 October 2018 (UTC)
Why did you pick January 1, 1978? Presumably, the effective date of the 1976 copyright act.
However, your discussion talks about them being a public figure prior to that date. I don't think being a public figure or not a public figure is relevant (let me know if I'm missing something) but more importantly, the date is relevant in the context of the date of the publication of the photo. (If someone's a public figure in 1965 but has a photo published in 1985, then no copyright notice is needed.)
Two complications:
  1. Note that I said date of the publication of the photo not the date the photo was taken. If a photo was taken in 1977 and published in 1979, the copyright law in effect in 1979 applies, not 1977.
  2. In the time periods in which a notice was required it does not have to be on the front of the photo. This can cause annoying problems. Many photographs were taken with a copyright notice on the back of the photo. It is not uncommon for someone to send in a scan of a photo to OTRS and claim it is not subject to copyright because it did not have a copyright notice. This may or may not be true but we need to see a scan of the back of the photo to be sure. This problem should not arise in the case of the yearbook as it seems implausible that the yearbook would publish the photo on one side of the page and the copyright notice on the backside, but I want to be careful that your advice is not taken too literally. People can and do send in stands of loose photographs and presume they are out of copyright because there is no notice in the publication date was prior to the effective date of the 1976 copyright act.--S Philbrick(Talk) 14:45, 2 October 2018 (UTC)
Loose photos? How would you know if they were ever published? Alanscottwalker (talk) 14:50, 2 October 2018 (UTC)
Well, actually, if the photo was published in 1985 with no notice and there was not subsequent copyright registration, it's also public domain. But that isn't the point. The point is that if someone was a public figure in the United States prior to 1978, then is is highly likely that someone published (not just took, but published) a photo of them and there is a decent chance that they failed to comply with formalities. Obviously a loose collection of photos at a university library is probably not going to be public domain, but there are other things you can find there - school newspapers and other regional publications that frequently didn't bother with a copyright notice. --B (talk) 15:15, 2 October 2018 (UTC)
You made a mistake 11 years ago? Shame on you for not knowing all of the rules before you made your first edit! We must now block you for life and shun all appeals. --Redrose64 🌹 (talk) 20:33, 2 October 2018 (UTC)

Move references embedded in sub-section headings

This is a proposal for a bot (as bot writer). There are currently about 14,400 cases where a reference is embedded in a sub-section heading. The refs can be moved into the section body.

Before (from Belgium): 

=== [[Larger urban zone|Functional urban areas]]<ref name="europa">{{cite web|url=http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|publisher=appsso.eurostat.ec.europa.eu|title=appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|accessdate=6 January 2017}}</ref>===

After: 

=== [[Larger urban zone|Functional urban areas]]===
Source: <ref name="europa">{{cite web|url=http://appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|publisher=appsso.eurostat.ec.europa.eu|title=appsso.eurostat.ec.europa.eu/nui/show.do?dataset=urb_lpop1&lang=en|accessdate=6 January 2017}}</ref>

MOS:HEADINGS (fourth bullet) should "Not contain citations on the same line" as the section title. They make a mess of TOCs and edit summaries and are unnecessary. Typically done to indicate that all the information in that section came from that source – because they don't know where else to put the ref. A Source: at the top resolves the MOS issues and retains the reference information. -- GreenC 14:23, 1 October 2018 (UTC)

Discussion

Three points. 1) More precisely, it should be "no space between terminal punctuation and a <ref>." (There are some cases where I think a space works, just not after punctuation.) 2) We should not confuse notes, created with <ref> tags, and citations, which notes generally contain. 3) Alternatively, would it be useful to have some kind of tag for "misformed heading"? ♦ J. Johnson (JJ) (talk) 23:58, 1 October 2018 (UTC)
This is drifting off-topic a little, since this doesn't apply here, but it's not just a matter of when there is a terminal punctuation mark. WP:REFPUNCT says "The ref tags should immediately follow the text to which the footnote applies, with no intervening space (except possibly a hair space, generated by {{hsp}})." Personally, I think it's a better idea to do something that fixes the problem than to do something that tags the problem, although I would hope that whoever is operating this bot would keep an eye on what it is doing and not just blindly let it do its thing. —BarrelProof (talk) 04:24, 2 October 2018 (UTC)
Of course I would. I'm used to running bots that make 100s of thousands of edits so 14,000 is no big deal. The way it's done is 1 edit. Then 2, 4 etc.. then a couple rounds of 100 .. manually checking all the way and stopping and fixing bugs. Then a couple 500s (manual check). 1000 (spot checks). 5000 (wait a few days for feedback). Then.. It's not like pressing "go" until 14,000 are done and clean up the mess after, much harder and uncomfortable that way :) -- GreenC 20:46, 2 October 2018 (UTC)
I don't see tagging as an end result, but as the start of a process. E.g., tagging could put an article into a special tracking category, and basically advise of a proposed change. There could be an option for anyone objecting to the proposed change to tweak a parameter, which would then shift the article to a different category for further discussion. Otherwise, after some period (two weeks?) the bot can be turned loosed on the articles remaining in the tracking category. While questioned bot edits doesn't seem to be a big problem re REFPUNCT, there are other areas where a process like this could reduce grief and drama by handling concerns with bot-edits proactively rather than retroactively. ♦ J. Johnson (JJ) (talk) 22:36, 3 October 2018 (UTC)

Show draft deletion log together with article deletion log at redlinked article

Someone clicking on Loella Haskew has no way of knowing whether Draft:Loella Haskew was previously deleted (e.g. by G13). Some people don't realize that and don't request a refund, instead wasting their time on writing the article from scratch. In order to verify that, we have to go to the draft page and check, but we aren't perfect and often forget that. Because we already have {{Draft at}} which serves an equally useful purpose, I am proposing that the deletion log for the draft (if it exists), is shown at the redlinked article. wumbolo ^^^ 14:58, 4 October 2018 (UTC)

Automated (synthetic) audio for IPA

I think it would be helpful to allow readers to listen to the pronunciation of words for which Wikipedia already has an IPA representation. I've created a quick proof of concept (see the Phabricator thread). This can be done client or server side. Client side will be much easier to implement, but means that users will have to fetch ~500 kB of JavaScript when they first try to play a word.

--Janschejbal (talk) 20:57, 2 October 2018 (UTC)

I absolutely would like this. However, how would it handle exceptions (characters without an IPA representation)? Discuss-Dubious (t/c) 13:56, 3 October 2018 (UTC)
Not sure what you mean with "characters without an IPA representation"? The feature would be very simple: If an IPA representation is provided in the article, you can click a button and hear it spoken. If nobody added an IPA representation, there will be no button to click. If the IPA representation is inaccurate (either because the author made a mistake or because the language cannot be properly represented by IPA), the tool will read it as it is written. The project does not cover speaking random words or automatically generating IPA from text, the IPA has to be added by authors. --Janschejbal (talk) 18:02, 4 October 2018 (UTC)
Wikimedia Sweden + more are developing this at mw:Wikispeech. Anyone with interest can join Wikimania 2019 in Sweden where this will be showcased or otherwise join online discussions. Blue Rasberry (talk) 19:07, 4 October 2018 (UTC)
Also check out Wikidata lexeme project - d:Wikidata:Lexicographical data. Blue Rasberry (talk) 19:16, 4 October 2018 (UTC)
That script you wrote is pretty neat. The generated pronunciations aren't as good as the hand crafted ones, but that's to be expected. Implementing this client-side would be cool to have, at least as a gadget or something. — AfroThundr (u · t · c) 03:03, 5 October 2018 (UTC)

IB Russian inhabited locality replacement

I created a new version of {{Infobox Russian inhabited locality}} based on Infobox settlement (test cases found here); feedback and comments on the template's talk page would be most welcome.--eh bien mon prince (talk) 07:28, 5 October 2018 (UTC)

Thank you, but we already have {{Infobox Russian rural locality}} and {{Infobox Russian town}} and {{Infobox Russian urban-type settlement}} which cover all possible varieties.--Ymblanter (talk) 07:30, 5 October 2018 (UTC)

Add remark to watchlist items

Maybe this has been proposed before, but anyway: I just found an article in my watchlist that has been sitting there for months, and I now have no idea why I added it. It would have been nice to have the ability to add a remark to every watchlist item. I don't watch that many pages, 30 or so, and I hear some people watch 1000+ pages, which must be unmanageable. This idea is similar to watchlist item grouping, but is easier to implement. GregorB (talk) 18:20, 5 October 2018 (UTC)

It is also easy to do yourself by keeping a text file containing notes as to why you watchlisted a page. --Guy Macon (talk) 19:45, 6 October 2018 (UTC)
Or a bookmark. Not quite the same, though. GregorB (talk) 22:16, 6 October 2018 (UTC)

Prevent new users from allowing search engine indexing of user pages

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
checkY It's a blizzard and there's unanimous consensus to restrict indexing-capabilities to Extended-Confirmed-Users.∯WBGconverse 04:38, 7 October 2018 (UTC)

Should we prevent new users from indexing pages in the user namespace?

Recently, a new edit filter was created which disallowed new users indexing pages in userspace. The filter was later set to log because there wasn't a custom warning, and also there has not been consensus for disallowing userpage indexing by new users. Something like this was suggested in the discussion of this (failed) proposal, so this proposal is to gather consensus on this. SemiHypercube ✎ 23:28, 24 September 2018 (UTC)

Also the main reason for disallowing page indexing in userspace for new users would be to deter spammers. I forgot to mention this. SemiHypercube ✎ 00:00, 25 September 2018 (UTC)
Also I'm perfectly fine if userpage indexing gets restricted to extended confirmed users or even new page reviewers, as suggested below. SemiHypercube ✎ 12:41, 27 September 2018 (UTC)

Comments

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.

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.

Result:

This discussion was well-attended but centred around questions that are complex in detail. Briefly: many articles currently use a template, eg {{commons category}}, to transfer readers inter-wiki to related content hosted by Wikimedia Commons. Those templates take a parameter that hardcodes the link to a given page at Commons. This proposal seeks to remove that parameter. Consequently, cataloguing of the connections between a given English Wikipedia page and the related content at other Wikimedia projects would be passed more fully over to the volunteers at Wikidata.

Some editors expressed doubts about more fully passing this responsibility over. The responsibility already exists in the form of the sidebar of all Wikipedia articles. These doubts are not new among the English Wikipedia community. I should clarify that personally, I am generally content to go along with the current editorial custom (about all matters of form or technique, eg citation format) on articles that I edit; I have no view either way on the issue.

The majority of editors in this discussion supported the proposal, which was presented in a clear, balanced manner. Nevertheless, a significant minority objected the proposal outright. Additional minorities objected (1) out of concerns about how most use cases would play out or (2) on the grounds that some detail around implementation was unclear.

On balance, I determine that there is consensus in this discussion to conditionally allow the proposal. Mike Peel and other editors may develop the proposed implementation – but are required to return to the community with the result of testing for further approval. AGK ■ 17:05, 7 October 2018 (UTC)

Should use Wikidata as our primary source for links to Wikimedia Commons in sister project templates? Mike Peel (talk) 18:07, 25 August 2018 (UTC)

Background

Wikidata provides nearly all of the interwiki links from enwp articles to other Wikipedias, and other sister projects, through the links in the sidebar. However, we still use manual links in the sister project templates. With Wikimedia Commons specifically, there are currently over 750,000 articles that use {{Commonscat}} and similar templates - and nearly all of them currently have manually-defined and -maintained category names.

Extensive work has taken place this year to improve Wikidata's interwiki links to Commons, and this is now the main place where Commons' interwiki links are managed, with around 2 million Commons categories now linked to Wikidata items. These are maintained by a combination of editors from Commons, Wikidata, and other language Wikipedia editors, as well as bots - and these links are automatically updated when categories are moved on Commons. However, while those changes appear in the sidebar, the templates don't automatically update, and we have an increasingly large number of broken links to Commons as a result (which are tracked in the subcategories of Category:Commons category Wikidata tracking categories). This proposal would fix that.

If we decide to migrate to using Wikidata by default for links to Wikimedia Commons in these templates, then the next steps would be to bot-remove the manually-defined links to Commons that are the same as on Wikidata, and to investigate (manually or by bot) the mis-matched links to find out if they have been moved or are no longer needed. The links would then be maintained on Wikidata in the future. Where we need to have links to multiple commons categories from one page (or where there are any other complications), then these would continue to be manually defined. This proposal is focused on Wikimedia Commons, other sister project should be considered separately.

Survey

  • Support as proposer. I am also the human-in-charge of Pi bot, which is responsible for adding quite a few Commons sitelinks of late - and could help the bot-migration of existing links here if desired (subject to a bot request here). Thanks. Mike Peel (talk) 18:07, 25 August 2018 (UTC)
  • Support as a user seting countless links to Commons on Wikidata and trying to convince individual users to do the same. --Robby (talk) 20:20, 25 August 2018 (UTC)
  • Support - Assuming the implementation does not alter (or require extra work) to retain existing templates where there is not yet a link via Wikidata (i.e. it should replace existing templates only when there's a clearly appropriate replacement). I'm curious to hear whether there are any downsides to this? — Rhododendrites talk \\ 20:36, 25 August 2018 (UTC)
  • Support. It seems to be a good idea to have everything in one place.— Alpha3031 (t • c) 05:24, 26 August 2018 (UTC)
  • Support as well. Done properly, this would improve the inter-project links and reduce maintenance overhead (always a welcome change for us WikiGnomes). — AfroThundr (u · t · c) 14:35, 26 August 2018 (UTC)
  • Strong Oppose As someone whose articles mostly include a Commons link, the correct commons category is often far from obvious, and far too many of the Wikidata links will be wrong (because far too much of everything on WD is wrong, not to mention Commons). That Commons seems to completely lack a mechanism for moving/renaming categories is much of the problem. Sorting this out will take forever and involve huge amounts of work - with very many wrong links sitting there indefinitely. Johnbod (talk) 17:55, 26 August 2018 (UTC)
    There is both a manual mechanism and a bot-based on-request one. Jo-Jo Eumerus (talk, contributions) 18:17, 26 August 2018 (UTC)
  • Oppose. Trusting Wikidata usually is a bad idea, vandalism there too often goes undetected for way too long (in my experience more so than is the case on enwiki). Furthermore, it would be better if the sister templates were simply removed and such links (at least those we want, which would be mainly commons) placed in the left side bar instead. Left side = Wikidata maintained, article = enwiki maintained. Mixing the two usually gives very unhappy results and many disputes. Fram (talk) 10:26, 27 August 2018 (UTC)
  • I am sympathetic to the aim of this RFC, and in that regard you could say I support it, but I would prefer to see these boxes and links removed entirely in favor of the links by Wikidata already provided in the sidebar. --Izno (talk) 12:10, 27 August 2018 (UTC)
  • Support - assuming the Wikidata value can be overriden for special editorial cases (when the WikiData value differs from the needed link and can't be changed on WikiData for whatever reason, or when multiple Commons category links would be useful). But the current handling via commonscat templates in the article itself should be kept (a removal is not proposed anyway, if I understood the OP correctly?). The template is better visible than a small link in an overloaded sidebar, and more flexible to use and change if needed. GermanJoe (talk) 11:33, 28 August 2018 (UTC)
  • Oppose. I'm not too involved in Wikidata integration, but what little discussion I've seen and what little actual activity I've paid attention to is far from flattering. And I'm not wagering that Wikidata has made tremendous strides in quality control since the relevant ArbCom discussion. There just isn't the manpower for that. —Compassionate727 (T·C) 01:05, 30 August 2018 (UTC)
  • Oppose. The number of problems with wikidata information that I have encountered means that this is not a good idea and that the existing instances where editors have selected a specific target should be retained. In fact I would go further and remove any pulling of data from wikidata in this template and just report differences. There are problems with wikidata entry been incorrect, the random selection of a wikidata entry when there is more than 1 instance of commons link against an item on wikidata. The need for the positional parameter in the template when there is a need for a second positional parameter to show the display name. The use of multiple entries on a page to show different specific images of a topic. The problems around the commons category not matching the wikipedia scope for the topic and a different commons link it more appropriate etc.. Keith D (talk) 09:34, 30 August 2018 (UTC)
  • Weak support provided, and these are vital provisos, that (a) it's easy to over-ride the Wikidata default and (b) it's made clear to editors that they need to check the default provided by Wikidata, then this seems relatively harmless, and avoids redundancy, and in particular discrepant links. Peter coxhead (talk) 10:04, 30 August 2018 (UTC)
  • Support Despite Wikidata's poor reputation, I always think it is a valuable project and (with support and patience) will do more benefit to Wikipedia than harm. I also agree the pulled value should be easily overridable here so as to fix edge cases or where simply something different is needed. –Ammarpad (talk) 16:16, 30 August 2018 (UTC)
  • Oppose at this point, per Fram and Keith D. Too many potential problems at this point. Killiondude (talk) 19:34, 30 August 2018 (UTC)
  • Oppose I support Wikidata, but I don't support this proposal. I would support, but [5] is not what the bot should be doing. What if there is a gallery for example? This is not good ontological organization. --Rschen7754 21:32, 2 September 2018 (UTC) edited 02:44, 3 September 2018 (UTC)
    • Compare that to for example, d:Q16, which links to a gallery page on Commons. Candidly, I am not sure the bot is doing the right thing and unless the rules on Wikidata have changed recently I am not sure the bot task to do this should have been approved. (In fact, support was begrudging at best [6] and loosely based off a not widely-advertised discussion and 1 quick RFD.) --Rschen7754 21:39, 2 September 2018 (UTC)
  • Oppose per Fram. We do not need Wikidata's unreliable help to handle this. Nihlus 22:15, 3 September 2018 (UTC)
  • Support interwiki data is what Wikidata does best, and what we shouldn't duplicate that information here locally. None of the identified problems pertain to this task, but related problems that persist regardless of how this issue is handled. – Finnusertop (talk ⋅ contribs) 07:43, 4 September 2018 (UTC)
  • Strong support - the way to get more eyes on Wikidata to fix some of the issues people raise is not refusing to use it in any way on WP. Plus, in general, Wikidata has built in protections for interwiki links, such as allowing only one link per project per entry, that make it difficult to casually vandalize, at least in this instance. ARR8 (talk) 04:40, 11 September 2018 (UTC)
  • Support per proposer, this is the obvious next step in a process that's already worked quite well. Gamaliel (talk) 01:22, 12 September 2018 (UTC)
  • Support per proposer. Bidgee (talk) 03:25, 17 September 2018 (UTC)
  • Support Wikidata integration with Wikipedia can mean lots of things. I discount all oppose votes that generally dismiss the reliability of Wikidata in all contexts without distinguishing what is higher quality, safer, and higher impact content, versus what could cause more problems for less benefit. For this proposal we are talking about a relatively small collection of matches for higher profile media sets. This will only go into effect when Wikidata matches a Commons category and a Wikipedia article covering the same topic. These conditions are only typical when multiple Wiki editors have collectively made a Wikipedia article, uploaded media, sorted the media into a Commons category, and structured data for the topic on Wikidata. The human attention which goes into this workflow this one of the better opportunities for aligning the content and leveraging the existing editor base which could detect problems on a Wikipedia of any language where this is used, or Commons, or Wikidata. This system provides for more content security than we currently have for this content, not less. It is an experiment and things could got wrong but among experiments this seems like low risk of harm, high potential of positive impact, and high potential for detecting challenges with integration when they occur. Blue Rasberry (talk) 13:40, 17 September 2018 (UTC)
  • I would prefer an implementation like that with Template:Official website, where if no parameter is specified, it defaults to WD, and if a parameter is specified it does not, at least for now. In the short term, I would rather see a bot adding the templates in cases where there is no sister link in ELs, but there is a sister link on WD. GMGtalk 19:21, 17 September 2018 (UTC)
    @GreenMeansGo: The first part is what this RfC is about (plus the bot edits to remove redundant information). The second part is possible, but is a different conversation/bot task. Thanks. Mike Peel (talk) 22:27, 23 September 2018 (UTC)
    @Mike Peel: Yes the second part was just banter. But is that the planned implementation? If we can manually override it by providing a parameter, the no one should have any worries, because the people who have worries about WD can just provide parameters in their article. GMGtalk 23:54, 23 September 2018 (UTC)
    @GreenMeansGo: WP:OWN ... but the plan would be to remove the parameter where it is the same as on Wikidata, and adding it back again would be kinda pointless. Thanks. Mike Peel (talk) 00:00, 24 September 2018 (UTC)
    Yes, OWN is a thing in the context of a single project. But if you don't think there is a great deal of OWNERSHIP, between projects I think you're kidding yourself. En.wiki in particular I've seen has been particularly hostile to encroachment by basically any other project. GMGtalk 02:01, 24 September 2018 (UTC)
  • Comment I have a problem understanding the first sentence of this rfc "Wikidata provides nearly all of the interwiki links from enwp articles to other Wikipedias, and other sister projects, through the links in the sidebar." I understand Wikipedias to mean language wikipedias is that what is meant? As to sister project all the linking I do is thorough the body of an article. EG links to articles on wikisource (usuall either as a citation or as an line link), links to pictures (Files) on wikicommons and to words on Wiktionary. So User:Mike Peel please explain to me what you mean. Because I am not clear on what this RfC is about. -- PBS (talk) 19:22, 17 September 2018 (UTC)
Example @PBS: Look at Statue of Liberty#External_links. See the Commons box which links to Commons:Statue of Liberty. This discussion is about whether that box should be set only for humans to edit on English Wikipedia or whether a mix of automation to post here and human/automated editing on Wikidata can manage the link. Right now we in English Wikipedia manually have to make that connection. We can automate that connection in the same way that the various languages of Wikipedia connections happen, so yes, you understand that correctly. The connection in Wikidata is at Statue of Liberty (Q9202). Look at the bottom of the Wikidata entry to see how Wikidata connects various languages of Wikipedias and other Wikimedia projects. For English Wikipedia I think these connects are very useful. For other languages without an editor base making these connections are more valuable because connecting to Commons images and other Wikimedia content may be the only way to access information. Part of this experiment is about improving Wikipedia, and part is about Wikipedia testing this out for other language Wikipedias which are likely to follow the English language lead. That is another reason why interlanguage links get mentioned in these discussions, because English tends to find solutions which work generally for other projects.
Mike mentioned {{Commons category}} but I am talking about the similar {{Commons}}. For the Statue of Liberty editors have curated a selection of good media so we have a Commons page. When there is no curation, a more typical case, the link would be to the top level category for the concept and all the media in the category. This proposal covers both of these cases. I am not sure about numbers, but maybe this is 1 million or 20% of English Wikipedia articles. Blue Rasberry (talk) 13:55, 18 September 2018 (UTC)
Two points from the clarification if all you are talking about is changing the behaviour of two templates then the background needs to be rewritten much more succinct: just to focus on the changes to the two templates. The second is that both templates take names to create links to wikicommons, indeed it is a bad idea at the moment to assume that the en.wikipedia name and the commons name are the same because, if the article titles is changed, then the link to wikicommons will be broken. I can understand that is a problem that would go away with this proposed change, but if an editor on en.wikipedia wishes to change the link to another area on commons, at the moment they simply do it by changing the link name. In the future how would a link change be done if this proposal is accepted? -- PBS (talk) 18:03, 18 September 2018 (UTC)
Any answer to my question on changing links? -- PBS (talk) 18:19, 22 September 2018 (UTC)
@PBS: Apologies for the slow reply. I deliberately wrote the proposal with background information, and also with wider scope than just two templates, as I think there are more templates out there that do something similar - see Category:Wikimedia Commons templates - and I didn't want to tie this down to a specific template change. I'm sorry that it wasn't succinct enough for you. The idea is that we use Wikidata where the links are empty, and bot-remove links where they are the same / need fixing. If they still need locally overriding, though, then that would still be possible in the same way as it currently is. Thanks. Mike Peel (talk) 22:25, 23 September 2018 (UTC)
Mike Peel regarding bot-remove links [which] need fixing, bypassing a commons-redirect is trivially appropriate regardless of whether Wikidata is involved. Any other interpretation of "fixing" must be clearly defined before even considering automated deletion of EnWiki values in favor of Wikidata values. If an existing value points anywhere else then I expect human examination will likely be needed to check how/why it needs fixing, even if the target is a non-existent page, nonsensical, or corrupt. Alsee (talk) 12:17, 28 September 2018 (UTC)
  • Oppose because of User:Mike Peel's comment "and also with wider scope than just two templates, as I think there are more templates out there that do something similar" as User:Mike Peel is asking for a blank cheque. I think that the wording of the RfC is complicated and misleading. If this RfC is closed and another one is started for just two templates ({{Commons category}} and {{Commons}}) then I will reconsider my opinion. -- PBS (talk) 06:44, 24 September 2018 (UTC)
@PBS: A possible outcome of this RfC is only support for experimentation with those two templates. How do you feel only about that? {{Commons category}} is used 680,000 times and template {{Commons}} is used 745,000 times, so we already are in blank check territory for fundamentally altering the Wikimedia cataloging standard for billions of user experiences. In your comments above you say that if the Wikidata link breaks then that would cause a break in the English Wikipedia experience, which is true. Can you say more about why that is a problem? We have no hard data about the efficacy of the current system or the Wikidata system. What kind of evidence or assurance would you expect to see in place to support a change? Blue Rasberry (talk) 18:13, 24 September 2018 (UTC)
@PBS: I don't see it as a blank cheque, but as permission to move this to the next steps of working on the template changes (with discussions about the changes on the talk pages), and any bot edits would have to go through a bot approval process. Plus course-correcting discussions as things go to tackle any issues/disagreements. This is the start of the discussions about this ("do we want to go in this direction"?), not the end. Thanks. Mike Peel (talk) 21:01, 24 September 2018 (UTC)
See the relevant ArbCom discussion that Compassionate727 mentioned, specifically the section "Crosswiki issues: Motion" and within that "(B) To allow the English Wikipedia community to decide the policy issues involved, the Arbitration Committee recommends that a request for comment (RfC) be opened". I will not support an RfC that could be interpreted as a blank cheque against that ArbCom discussion.-- PBS (talk) 07:49, 25 September 2018 (UTC)
If this RfC was closed and a new one raised to that specifically and clearly covers just {{Commons category}} and/or {{Commons}}, with the ability of manual override via a parameter, then I would be willing to consider supporting it. -- PBS (talk) 07:49, 25 September 2018 (UTC)
As an alternative you could consider using {{Interlanguage link}} "for experimentation" in place of the two currently specifically mentioned in this RfC, because it involves inter language links, which are already implemented. -- PBS (talk) 07:49, 25 September 2018 (UTC)
  • Strongly support, because it is indeed difficult to update links to moved categories, and if something is broken on Wikidata one can almost always as easily fix it there as in enwiki itself. Wikisaurus (talk) 17:36, 25 September 2018 (UTC)
  • Support per Robby, let's help the people who've been working tirelessly on maintaining the local template links. --Nemo 19:12, 3 October 2018 (UTC)

What were the recent changes made? I was under the impression that it was a huge mess with some items linking to the gallery and others linking to the category. Maybe things changed over my break though. --Rschen7754 04:18, 26 August 2018 (UTC)

@Rschen7754: On the Wikidata site, Commons sitelinks are now used much more, alongside Commons category (P373). Compare the statistics from September 2017 to June 2018. On the Commons side, Wikidata information is used a lot more in Commons categories (ahead of the arrival of Structured data on Commons that will affect the files). A lot of that has been done by Pi bot (talk · contribs) this year (see the list of tasks on the bot's user page), but it's also become the norm and there are a number of editors maintaining/adding more links manually. Thanks. Mike Peel (talk) 13:55, 26 August 2018 (UTC)
@Mike Peel: I am sorry for the late response, but this doesn't answer my question, and now I indeed see that the bot is doing what I feared it was and that this proposal does not address the inconsistency of some items linking to the gallery and others to the category (and in fact, the bot is making it worse). This has been a problem with Commons linking from day 1 and the WMDE team still has failed to fix this (it was raised to them but apparently it is not enough of a priority to them). Nevertheless, this proposal will make things worse as it stands. --Rschen7754 21:42, 2 September 2018 (UTC)
@Rschen7754: The bot adds/moves the sitelinks to category items where available, and if there is a better way of storing them in the future (dual sitelinks, mass-creation of category items, and end to commons galleries, etc.) then it will be straightforward to migrate to that system. The important thing in my mind is to have one main set of interwiki links between Commons and the other wikis (including enwp), which is then properly maintained, rather than N partial sets across all different projects. That's what this proposal is trying to move things towards. Thanks. Mike Peel (talk) 00:51, 3 September 2018 (UTC)
I'm afraid that this proposal is unclear and glosses over what will happen to a page like Canada. Will it link to the category or the gallery? Shouldn't we be consistent? What if someone specifically wants to link to one over the other? Are we just going to enforce the preference by bot and remove it from enwiki? --Rschen7754 02:41, 3 September 2018 (UTC)
@Rschen7754: That actually seems to link to commons:Special:Search/Canada. This RfC is not about whether the links go to galleries or categories, and the bot would not enforce a preference. Thanks. Mike Peel (talk) 10:45, 3 September 2018 (UTC)
So then what is this RFC about? --Rschen7754 20:04, 3 September 2018 (UTC)
@Rschen7754: E.g., at Academy Awards, changing {{commons category|Academy Awards}} to {{commons category}} so that, should the commons category be moved to "Oscars", the link will automatically update rather than needing a manual fix. Thanks. Mike Peel (talk) 22:11, 3 September 2018 (UTC)
This isn't specific enough. Where does the category come from? The sitelink? P373? The article title? The label? etc. --Rschen7754 22:13, 3 September 2018 (UTC)
Currently, Commons category (P373), which is bot-updated when the sitelink to a category changes. I'd personally prefer to use the sitelink directly, but that would need the gallery vs. category question answered, so that's something for the future. Thanks. Mike Peel (talk) 22:49, 3 September 2018 (UTC)
Why didn't you say that at the start of the RFC? Here I am, a Wikidata admin, and I couldn't even understand what the RFC is asking. While I would support using P373, I am reluctant to support the RFC as is, because it is too vaguely worded and feels like I am signing a blank check. --Rschen7754 23:08, 3 September 2018 (UTC)
The saying here is that you can't see the forest for the trees... We're arguing about the technical details here, while most oppose statements are focused on Wikidata's apparent unreliability. Mike Peel (talk) 23:27, 3 September 2018 (UTC)
  • One difficulty has been that editors seem to have been discouraged from linking different Wikidata items to the same Commons category. This causes particular problems, in my experience. with articles about organisms that have more than one currently used scientific name and hence have multiple taxon name items in Wikidata (and articles under different names in language wikis).
Linking information in separate Wikidata items that are synonyms, of whatever kind, needs to be automated. Thus Platanus × acerifolia (Q24853030) and Platanus × hispanica (Q161374) are correctly linked to the same Commons category, currently called commons:Category:Platanus × hispanica. (Platanus × hispanica is the most widely used name, but is now thought not to be correct, the right name being Platanus × acerifolia.) However, Platanus × acerifolia (Q24853030) and Platanus × hispanica (Q161374) only link to the same commons category because I inserted the link manually, even though they are correctly said to be synonyms. This process needs to be automated in some way. The problem isn't limited to organisms; it arises whenever there isn't a simple 1:1 relationship between Wikidata items, language wiki articles, and Commons categories. Far too often it seems to be assumed that all such relationships will be 1:1, but this is simply wrong. Peter coxhead (talk) 10:30, 30 August 2018 (UTC)
@Peter coxhead: I can help automate that, but it probably needs some discussion first (e.g., shouldn't those two Wikidata items be merged? Or should they use said to be the same as (P460) or exact match (P2888)), perhaps post some more examples on my talk page or start a discussion at d:Wikidata:Project chat. Thanks. Mike Peel (talk) 22:17, 3 September 2018 (UTC)
@Mike Peel: just a brief note here, because this has been thoroughly discussed at Wikidata. No, the two Wikidata items should not be merged; they are distinct taxon names with their own separate entries in taxonomic and other databases. The core problem, as noted above, is that Wikidata imposes 1:1 links when these are not present in the information it is supposed to be modelling, so its model is at best incomplete and at worst erroneous. For a non-taxonomic example, consider our Berry and Berry (botany), which should connect to one article in language wikis that don't make the same ordinary language/botanical language distinction. Peter coxhead (talk) 08:03, 24 September 2018 (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.

Why isn't mobile number and / or email required for new User Creation?

Duplicate of comment posted at the help desk, and elsewhere Ivanvector (Talk/Edits) 13:37, 8 October 2018 (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.

A lot of time is wasted in sockpuppet investigations and still they seem to have infested Wiki.My suggestion is to require email and / or mobile validation to create new accounts on Wiki. Existing users should also provide them to continue using their IDs. Email authentication is free of cost and easiest to set up, while mobile number verification may require sending an OTP to the number which can have a minuscule cost involved of sending an SMS. Email verification would be sufficient since to create new email IDs, the companies send OTPs to the mobile and user cannot register multiple email IDs linked to a single mobile number. Even small websites have these type of validations then why can't Wiki? Since sockpuppetry is becoming a nuisance on Wiki. Hopefully something gets done in this regard, if this is not the place for suggestion kindly let me know where to write it. Thanks! — Preceding unsigned comment added by 117.222.30.200 (talk) 13:21, 8 October 2018 (UTC)

Folks watching this page: there was a discussion about this same thing very recently, possibly still ongoing, which I read but didn't participate in and now I can't find it. If someone here knows what I'm talking about, could they ping the IP? Cheers. Ivanvector (Talk/Edits) 14:57, 8 October 2018 (UTC)
That would be the idea lab. --Izno (talk) 15:06, 8 October 2018 (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.

Bot to add external party originality flag to new pages feed

Hello all, a new bot request is open at Wikipedia:Bots/Requests for approval/EranBot 3 regarding adding a new attribute to Special:NewPagesFeed for suspected Wikipedia:New_pages_patrol#Copyright_violations_(WP:COPYVIO). Feedback on usage and verbiage is welcome at the BRFA. — xaosflux Talk 17:36, 10 October 2018 (UTC)

@Xaosflux:--Was the section-header-title constructed by you? ∯WBGconverse 05:01, 11 October 2018 (UTC)
@Winged Blades of Godric: for this section? Yes. Tried to keep neutral, as I have more specific opinions in the other discussion. This bot will read new submissions, submit them to a third party who will generate a rating related to the originality of the text, then if the rating response is unoriginal will insert a 'potential copyright violation' flag here for further review. Much more details in the BRFA. — xaosflux Talk 11:37, 11 October 2018 (UTC)

Following discussions at Wikipedia talk:Featured article candidates about the process for source reviews of featured article candidates, a request for comment has been opened about creating a new "featured quality source review" process. Please check out the proposal at Wikipedia:Featured article candidates/Featured quality source review RfC and add your feedback. --RL0919 (talk) 18:07, 17 October 2018 (UTC)

Change to election/referendum naming format

There was a recent RfC on changing the naming convention for elections and referendums to move the year to the start (in common with most other event naming formats). The RfC was advertised to numerous WikiProjects (Elections and Referendums, Politics, Politics of the United Kingdom, U.S. Congress, Pakistani politics, New Zealand/Politics, Indian politics, Chinese politics and Australian politics) and was closed with consensus in favour.

When I started the RfC, I said I would request a bot run to move the articles if the change succeeded; this has been done, and there is currently a live bot request, where it's been suggested that the change should also be flagged up here for any last comments, as it will involve moving around 35,000 articles. Cheers, Number 57 21:15, 17 October 2018 (UTC)

Oppose the bot, which is now being discussed at Wikipedia:Bots/Requests for approval/TheSandBot. (Why didn't @Number 57 link to the BRFA?)
Inadequate consensus at RFC, esp in relation to using a bot to bypass WP:RM on such a huge scale. The RFC was poorly attended (only 16 !votes), and I re-read the discussion several times before I spotted the mention of a bot in the last line of the RFC nomination.
No other participant in the RFC mentioned the bot, so it is unclear whether any of them had noticed it.
Also note that none of the WikiProject notifications I have checked mentioned using a bot to bypass WP:RM on >32k articles. And while nearly all countries have elections, only those countries with standalone politics projects were notified at all. The lack of a standalone politics project is no reason to deprive editors in other countries of any notification. E.g. I just used WP:AWB to count the Irish articles which are likely to be renamed: 860 of them under Category:Elections in Ireland matching (\d\d \(Ireland\)|\d\d)$. Same method found 118 in Brazil, and 211 in Germany.
So editors working on elections in Spain, Ireland, South Africa, Vietnam, Kenya, Peru and over 200 countries receive zero warning of this until their watchlist lights up as a bot starts renaming articles. There is even a suggestion at the RFA for the bot to be unthrotted[7], which would make impede the chances of other editors to raise objections.
So the consensus to change the guideline is weak. And I don't see a consensus to use the bot -- that is too big an issue to bury in the small print.
This needs a fresh RFC, with much better notification, in which the question of changing the guideline is clearly separated from a decision on whether to use a bot. --BrownHairedGirl (talk) • (contribs) 05:25, 19 October 2018 (UTC)
@BrownHairedGirl: The BRFA is linked, click on "live bot request". As for the rest of the statement, I am all for further consensus (and therefore a new RfC). That said, if there was a decision to uphold the current one, then it would be unrealistic to dump 35,200+ articles into WP:RM. That would probably turn some heads as being disruptive in nature and is also unrealistic to be done entirely by hand. Given this and the sheer number of pages involved, it could be logically implied that a bot was/would be intended to enact said consensus (if reached, whatever form that may be, assuming a large number need moving). --TheSandDoctor Talk 05:58, 19 October 2018 (UTC)
@TheSandDoctor: Ah, sorry - I didn't spot the link (low contrast on my screen). I have struck that comment.
Glad we agree about the RFC. But I wasn't suggesting a lump of 35k articles thrown into WP:RM. Instead, take time to allow scrutiny. E.g. run them through RM in clusters, or run RFCs on particular sets. Move involve a lot of manual work, so it may be appropriate to have some less far-reaching bot, e.g. a bot to hnadle making WP:RM listings for clusters. There are many possible solutions in between the poles of 35k individual RM nominations and a bot doing it all in one batch with no further notification or discussion. --BrownHairedGirl (talk) • (contribs) 06:24, 19 October 2018 (UTC)

Suggestion re IPA

As an English speaker not familiar with the IPA, it took me quite a while to find the "Pronunciation respelling for English" page. It would be most helpful if a link to a central directory of such help pages could be inserted in the left column of Wikipedia, Wiktionary, etc. — Preceding unsigned comment added by Gar*1746 (talk • contribs) 04:41, 15 October 2018 (UTC)

I think you have something here. I have long wondered at the actual utility of providing IPA translations as I don;’t believe most people understand how it works or are helped by their inclusion in articles. Phonetic translation seems much more accessible to a general audience. Beeblebrox (talk) 19:12, 15 October 2018 (UTC)
It is, they are, and it has come up before. I'm too tired to go look up the links now (I expect a search of the MOS archives will find them), but expect any attempt to remove/replace (it with something useful) to come up against strong opposition. The usual argument is 'phonetic isnt standard' - which is true to an extent due to dialect differences vs 'No one knows how to use IPA' - which is also substantially true if you consider the readers of articles. Only in death does duty end (talk) 22:01, 15 October 2018 (UTC)
Hovering over IPA does provide tooltips like "k in kind" which is helpful, but as the vast majority of people don't know IPA, so have I wondered at their inclusion.. Galobtter (pingó mió) 11:56, 16 October 2018 (UTC)
And “hovering” only works if you are using a mouse, which with the prominence of touchscreens an increasing number of users do not. I haven’t used one regularly since 2011. Beeblebrox (talk) 18:10, 19 October 2018 (UTC)
Maybe there is a case for making the respelling keys more visible. For example, the template that outputs them could be tweaked to display them after the IPA (rather than with tooltips) if it detects that the reader is using a mobile device or if their IP is located in the US. Generally, replacing IPA with something else isn't gonna happen: see the FAQ section at the top of Help talk:IPA. And back to the topic of the original post: the left column of wikipedia already has a link "Help", which goes to what in effect is a directory of our help pages. Specifically for the pronunciations given at the top of articles, they are most often formatted as blue links, which are pointed to the relevant IPA help page (for English, that is Help:IPA/English). – Uanfala (talk) 12:29, 22 October 2018 (UTC)

Redirect class

Background (redirect class)

WikiProjects uses Redirect-class (currently 1,452) assessment to keep track of redirects within their scope.

Proposal (redirect class)

This proposal is about whether this usage should be widened by making it one of the default assessment classes used by projects. There are 3 options:

  1. Status quo: projects can opt-in to using Redirect-class.
  2. Add Redirect-class to FQS: all projects currently using the "Full Quality Scale" (FA, A, GA, B, C, Start, Stub, FL, List, NA, Category, Disambig, File, Portal, Project, Template)
  3. Add Redirect-class to all: all projects using the standard quality scale (FA, A, GA, B, C, Start, Stub, FL, List, NA) (approximately 1900) will automatically have Redirect-class enabled, unless they choose to opt-out.

For more details (including how this would be done), see Wikipedia:Village pump (proposals)/Archive 114#Widen usage of Draft-class which this request is based on. — Preceding unsigned comment added by Eurohunter (talk • contribs) 11:35, 25 October 2018 (UTC) (Edited to correct trivial mistake - Alsee (talk) 16:39, 25 October 2018 (UTC))

@Eurohunter: You have clearly copypasted from that VPR thread and saved without reading what you posted.
@everybody else: this is related to Wikipedia:Village pump (technical)#WikiProject Template. --Redrose64 🌹 (talk) 11:45, 25 October 2018 (UTC)
@Redrose64: There is "which this request is based on" at the end. Eurohunter (talk) 12:06, 25 October 2018 (UTC)
The relevance of WikiProjects has diminished greatly over time. For this reason, I don't think forcing this technical change on all WikiProjects will bring any tangible benefit. Most redirects aren't even tagged with WikiProject banners. Mz7 (talk) 08:05, 27 October 2018 (UTC)

Extended confirmed user

WP:SNOW due to there being no need for this proposal. Kirbanzo (talk) 18:48, 28 October 2018 (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.

User who registered for 30 days with 500 edits will automatically upgraded to extended confirmed user. Should those extended confirmed user who were indefinitely blocked be revoked with this rights? I see we have this example: User:INeverCry. --219.79.96.206 (talk) 04:13, 20 October 2018 (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.

RfC: Notify pending-changes reviewers during large backlogs

Clear consensus that opt-in is fine, but there's a consensus against opt-out notifications. Galobtter (pingó mió) 11:28, 3 November 2018 (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.

Should random pending changes reviewers be notified when the backlog is too large? Enterprisey (talk!) 07:25, 18 September 2018 (UTC)

The pending changes backlog sometimes grows to over 20-30 pages, some of which have been waiting for over a day. This situation is not ideal because there are over eight thousand editors who could take care of them. Thus, a bot should be written to notify pending changes reviewers (PCRs) when the backlog gets too large. This RfC covers only opt-out methods of doing the notification. One proposed method: a bot pings a small number of random PCRs on a central page, to avoid spamming talk pages. A given user would only be pinged once every few months, also to avoid spam. PCRs who have recently reviewed changes wouldn't be pinged, because they presumably already know. There could be a maximum edit count/tenure of PCRs who get pinged. (Although a couple of experienced users noted on the idea lab discussion that they just forget S:PC exists, so that may not be the best idea.) The effect of the pings on reviewing activity will be recorded, and used to adjust how many PCRs are pinged.

This RfC is only for opt-out notifications. This idea was first discussed at the idea lab section. Enterprisey (talk!) 07:25, 18 September 2018 (UTC)

Survey (Notifying PCRs)

  • Support as proposer. Enterprisey (talk!) 07:25, 18 September 2018 (UTC)
  • Please no the watchlist banner is annoying enough to the point I had to beg someone to make a .css workaround so I don’t see it. I’d support getting rid of pending changes as a form of protection that solves nothing while creating more work for everyone involved. I know it will be opt-out, but we really shouldn’t have to opt out of something like this. TonyBallioni (talk) 07:29, 18 September 2018 (UTC)
    TonyBallioni, the odds that you personally get pinged as a result of this are very small. Backlogs don't happen that often, and there are 7,038 other PCRs. It doesn't even have to ping admins. Enterprisey (talk!) 08:04, 18 September 2018 (UTC)
    We should probably pare that number down to editors who've been active in the last 30 days. No point pinging inactive users. — AfroThundr (u · t · c) 08:11, 18 September 2018 (UTC)
    Yup, I'll keep it to recently active editors. Enterprisey (talk!) 08:18, 18 September 2018 (UTC)
  • Oppose - There is already a perfectly good template for reviewers who wish to remind themselves to work on the backlog when it grows a little too large. I fail to see the utility in implementing this. EclipseDude (talk) 07:43, 18 September 2018 (UTC)
    The template doesn't seem to be working very well. Enterprisey (talk!) 07:47, 18 September 2018 (UTC)
    It seems to work decently well for me (once I discovered it existed). I added a fork of it to my user page, where I'm more likely to notice it, since I kind of use my page as a home page. — AfroThundr (u · t · c) 08:11, 18 September 2018 (UTC)
    Yeah, the template itself works fine, but it doesn't seem to be driving enough traffic to S:PC - hence the backlogs. Enterprisey (talk!) 08:18, 18 September 2018 (UTC)
    Perhaps the template should be displayed more prominently on WP:PC instead of as a footnote. Many reviewers are likely unaware of its existence. — AfroThundr (u · t · c) 08:21, 18 September 2018 (UTC)
  • Comment This would be better suited (IMHO) as an opt-in process. After advertising on the Village Pump, there'd likely be plenty of active participants who would sign up for this (myself included). Benefits of making it opt-in:
    • ensures you don't annoy other users who don't want to be bothered by a bot
    • ensures a higher likelihood of an actual response from the users pinged
    • increased frequency of pings to users since they actually want the pings
    As I mentioned in the original discussion, having users opt-in via a template (or signing a central page) would be a good method of doing this, and could even allow for the editor to specify their ideal notification criteria. — AfroThundr (u · t · c) 08:07, 18 September 2018 (UTC)
    Yeah, if this doesn't pass I'll write an opt-in bot instead. I just figured an opt-out bot would be more effective. Enterprisey (talk!) 08:09, 18 September 2018 (UTC)
    Second this. I would be more supportive of an opt-in process. EclipseDude (talk) 08:11, 18 September 2018 (UTC)
  • I don't have problem with this, but please make it "opt-in." –Ammarpad (talk) 14:38, 18 September 2018 (UTC)
  • (Summoned by bot) Comment Would support an opt-in version of this and/or if the PERM page was changed to make it clear that this was opt-out going forward for people granted the PERM that would be OK with me too. In general I think there's value in people with PERMS being alerted to backlogs. Best, Barkeep49 (talk) 14:58, 20 September 2018 (UTC)
  • Oppose opt-out if this is going to include all sysops (who also have pending changes review access) - else, perhaps this could be a css controlled watchlist banner ("There are %somehighnumber% of backlogged pending changes")? — xaosflux Talk 15:06, 20 September 2018 (UTC)
    This will not include sysops. I considered a banner, but I only want to notify a very limited number of people about this, to reduce the overall level of annoyance. There's already a banner, I think, but it doesn't show count. Enterprisey (talk!) 22:06, 20 September 2018 (UTC)
    @Enterprisey: I think you get a banner if there are any PC's that are for pages on YOUR watchlist. I'm suggesting that IF (PC log>n)&&(usergroup in reviewer) => SHOW BACKLOG BANNER. — xaosflux Talk 22:18, 20 September 2018 (UTC)
    Ah, I get what you're saying. Enterprisey (talk!) 22:51, 20 September 2018 (UTC)
    I think this is an intriguing approach to the problem. Best, Barkeep49 (talk) 01:41, 21 September 2018 (UTC)
  • Oppose I don't see this as a major problem, and the tried-and-true approach of complaining on WP:AN if the backlog is severe enough (more than 75 articles to review or 48 hours) should be sufficient. There's no issue with a rate-limited opt-in reminder system if people want that. power~enwiki (π, ν) 22:03, 24 September 2018 (UTC)
  • (Summoned by bot) Oppose an opt-out system, but an opt-in system seems useful. I am guessing that enough editors would volunteer to be pinged once the backlog reaches a certain size. Pinging PCRs without their approval may cause more annoyance than it is worth. Hrodvarsson (talk) 00:09, 3 October 2018 (UTC)
  • Support if opt in - this would be seriously irritating to be notified of for random people making up the enormous pending changes user right. However an opt-in system has something to say for it. I'd suggest 60 articles/36 hours as a better point for this to occur. Nosebagbear (talk) 14:46, 6 October 2018 (UTC)
  • Support Opt in only per others. It would be incredibly annoying for a message to be sent to thousands of people just to resolve a very temporary 30-80 edit backlog. Moreover, with that many people, you'd probably have everybody jumping on the same examples, which would result in a lot of annoying duplicate work and edit conflicts. — Insertcleverphrasehere (or here) 14:20, 11 October 2018 (UTC)
  • Strong support opt-in and support on opt-out (if admins are not included). If you aren’t interested in PCR, why do you have the permission for it? There’s a backlog that needs to be addressed and it relates to editor retention - if a user’s first edit is to a PC page and they don’t see it go live soon after (or at least see it reverted with a reasonable explanation), they might get confused or give up with editing. — Bilorv(c)(talk) 10:50, 15 October 2018 (UTC)
I (and other PCs) can be interested in an aspect of Wiki and be beneficial without wanting to be pestered by it. On that logic, admins should receive help requests on all aspects because they went through the toil of RfA for all the admin rights. Nosebagbear (talk) 20:18, 16 October 2018 (UTC)
That's a false equivalency. PCR is a right which only grants you the right to... accept pending changes. Sysop tools are needed for a vast number of very different activities. — Bilorv(c)(talk) 01:44, 22 October 2018 (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.

Make "view-source" an optional tab for the left of the search bar.

This functionality is not available directly without new software development that could be requested as phabricator. However, User:FR30799386 has published a customer user javascript that may provide the requested capability to individual users. Should adoption become very high it could be converted to a WP:GADGET in the future. — xaosflux Talk 20:19, 3 November 2018 (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.

The view source tab would be good for the bar because it would make it easier if you want to look into wikicode and see how some formatting was used and borrow templates and citations that you need without the risk of accidentally ruining anything on the page in question. It already exists as a replacement for edit on protected pages.

What do you guys think? Discuss-Dubious (t/c) 13:55, 3 October 2018 (UTC)

@Discuss-Dubious: 'view-source' just goes to &action=edit, it is not a function to just call. — xaosflux Talk 15:58, 3 October 2018 (UTC)
Oh, okay then. Hmm. I wonder if making a new action for non-protected pages is a good technical fix. Where can I go to propose that? Discuss-Dubious (t/c) 19:49, 3 October 2018 (UTC)
phab: --Redrose64 🌹 (talk) 20:47, 3 October 2018 (UTC)
@Discuss-Dubious: Also, if you don't want to change the source, I think you can just click "edit source" and when you're done, leave without clicking "Publish changes", so that nothing happens. SemiHypercube ✎ 16:02, 3 October 2018 (UTC)
Yes, I know about that. That was what I did prior to creating this proposal. I thought the idea would better facilitate this by entirely removing the element of risk I perceive of accidentally publishing a page where you have casually pressed "cut" instead of "copy" entirely. Discuss-Dubious (t/c) 19:49, 3 October 2018 (UTC)
You could also use &action=raw to view the wikisource, but depending on your browser settings this may open a file download (or open) requester instead of displaying it... —PaleoNeonate – 20:39, 3 October 2018 (UTC)
This sounds like a good idea to implement the idea. We can call that. Discuss-Dubious (t/c) 17:56, 9 October 2018 (UTC)
@Discuss-Dubious: have you tried that option? On some browsers it prompts a file stream download, and on others it displays the HTML content section - this does not help achieve your original proposal at all. — xaosflux Talk 22:38, 9 October 2018 (UTC)
I haven't used it on a browser which prompted a download. However, I do think something could be made from it. Discuss-Dubious (t/c) 01:45, 14 October 2018 (UTC)
If you enable "Prompt me when entering a blank edit summary" in Preferences -> Edit, you won't save the changes you unintentionally made if you accidentally click "Publish" instead of "cancel". Unless you've also unintentionally added an edit summary, of course, but what's the odds of that? --RexxS (talk) 22:29, 11 October 2018 (UTC)
I don't always see reason to use an edit summary, though. That's a good idea, but not sure it's really for me. Discuss-Dubious (t/c) 01:45, 14 October 2018 (UTC)
Discuss-Dubious I just created User:FR30799386/readonly, maybe that will help. — fr + 09:35, 26 October 2018 (UTC)

This is awesome, the thread is over, we've found it, thank you @FR30799386:. Discuss-Dubious (t/c) 00:52, 29 October 2018 (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.

Browser friendly pages

This proposal isn't actionable as it is lacking details. For specific technical assistance feel free to bring examples up at WP:VPT. Close as there is nothing to do here. — xaosflux Talk 20:21, 3 November 2018 (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.

Please consider that change to Wikipedia. Make the margins change as the typeface is enlarged. Thanks.— Preceding unsigned comment added by Kloro2006 (talk • contribs)

It does this just fine on my browser (Win 7, both Firefox and Chrome). Can you give us details of your configuration? Shock Brigade Harvester Boris (talk) 03:40, 29 October 2018 (UTC)
Adding on, works fine over here too. (Arch Linux, Firefox). MoonyTheDwarf (Braden N.) (talk) 13:15, 29 October 2018 (UTC)
Same here, Windows 10/Google Chrome. ProgrammingGeek talktome 23:15, 29 October 2018 (UTC)
It occasionally does not work depending on non-text elements on the page, especially tables with hard-coded widths. Those should be corrected when we come across them. Otherwise, yeah, works fine for me in any non-mobile browser I've ever used. Ivanvector (Talk/Edits) 17:00, 30 October 2018 (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.

Lint Error repairs in respect of minor italicisation fixes..

I was wanting to work on resolving some of the missing end tag issues here: https://en.wikipedia.org/wiki/Special:LintErrors/missing-end-tag?namespace=0

and had made a batch of repairs here : https://en.wikipedia.org/w/index.php?limit=50&title=Special%3AContributions&contribs=user&target=ShakespeareFan00&namespace=0&tagfilter=&start=&end=

However, most of these are minor italicisation fixes, and thus before continuing I'd like a wider community consensus that a mass sweep of this kind is both acceptable and desirable. ShakespeareFan00 (talk) 11:51, 6 November 2018 (UTC)

Side disscusion about the need for a Bot flag Wikipedia:Bots/Noticeboard#Lint error repairs..

Linking to an edit

  • Sometimes people need to tell me to delete or undelete or move particular edits. The form often used is e.g "<span class="plainlinks">[https://en.wikipedia.org/w/index.php?title=Saaho&oldid=776932251 776932251]</span>", which displays "776932251". If the edit is not deleted, clicking on the link displays its date and time and editor's name and edit comment, OK. But if that edit is deleted at the time (as sometimes happens, e.g. because currently the only way to delete some edits of a page is to delete all edits of that page and then to undelete some edits), then clicking on the link gets no useful information, but only a fault remark. It would be useful if, at least for administrators, clicking this sort of link also displayed information if that edit is currently deleted.
    • Sometimes a page is edited 2 or more times in the same minute. When that happens, clicking on the abovementioned sort of link shows time only to the nearest minute, which is sometimes ambiguous, if 2 or more of those edits are by the same editor. It would help if in history displays, times of edits displayed the seconds in edit times. Anthony Appleyard (talk) 12:20, 8 November 2018 (UTC)

Change "Spouses" to "Table of Spouses"

Ain't happenin. As has already been pointed out, the existing infrastructure can handle multiple spouses. There doesn't seem to be any obvious reason to continue this discussion further given unanimous opposition. Let's all go edit an article instead. GMGtalk 00:20, 9 November 2018 (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.

For example, to people married to more than one person at a time, like Osama bin Laden, you could have a table of the people they were married to all at one time. Otherwise it could be discriminatory against these types of people and I'm sure its driving people away from the project. Braveberet (talk) 03:52, 6 November 2018 (UTC)

This seems patently ludicrous. —Jeremy v^_^v Bori! 03:43, 6 November 2018 (UTC)
Well if Wikipedia wants to be neutral like it claims to be, they shouldnt say that being married to more than one person is bad as that would be pushing a political view. Braveberet (talk) 03:52, 6 November 2018 (UTC)
the =spouse parameter is fairly flexible on most infoboxes already, and you can include dates in the text (e.g. Madonna_(entertainer)) - so you can already include overlapping dates if the reliable sources support it. — xaosflux Talk 04:05, 6 November 2018 (UTC)
Braveberet, What evidence makes you sure its driving people away from the project? · · · Peter (Southwood) (talk): 06:39, 6 November 2018 (UTC)
Pbsouthwood People won't use wikipedia if it is against them or their viewpoints, and you cant claim to be neutral without actually being neutral. Braveberet (talk) 08:15, 6 November 2018 (UTC)
1. We generally ignore claims made without evidence, particularly when they are subjective opinions presented as fact. Simply repeating them is not evidence. 2. At Wikipedia, neutrality doesn't mean whatever we want it to mean. It has a narrower definition which is laid out at Wikipedia:Neutral point of view, and is strongly connected to reliable sources. I see little to no connection between your arguments and that policy, and I Oppose your proposal. As indicated by Xaosflux above, infoboxes are already sufficiently flexible to handle cases of polygamy. ―Mandruss ☎ 09:13, 6 November 2018 (UTC)
Like Mandruss says above. No evidence, no claim. · · · Peter (Southwood) (talk): 09:34, 6 November 2018 (UTC)
How is it a subjective opinion that neutrality requires being neutral to all points of view? Braveberet (talk) 10:03, 6 November 2018 (UTC)
See Begging the question. Boing! said Zebedee (talk) 10:08, 6 November 2018 (UTC)
So you're implying that its fallacious to say that neutrality by definition has to be neutral? Braveberet (talk) 10:15, 6 November 2018 (UTC)
Already answered.
This page is not for education of (apparently zero-experience) users who are here to school experienced editors about Wikipedia editing and don't listen to the responses. I suggest a quick close. ―Mandruss ☎ 11:24, 6 November 2018 (UTC)
I'm more apt to say "alleged zero-experience users", since the only edits Braveberet has made are to this section and to bluelink his userpage. —Jeremy v^_^v Bori! 11:55, 6 November 2018 (UTC)
Oppose nonsense. There are zero relevant Google hits on "Table of Spouses". Nobody uses this silly term. The spouse field can already list multiple spouses whether or not they are at the same time. PrimeHunter (talk) 21:13, 6 November 2018 (UTC)
I think the intent was to deprecate the "Spouses" infobox parameter in favour of a table in the article, which is ludicrous on its face and unnecessary. —Jeremy v^_^v Bori! 01:36, 8 November 2018 (UTC)
Isn't the idea behind Wikipedia to provide a neutral environment, like an encyclopedia, in order to spread neutral and unbiased information? So whats the deal behind Wikipedia being openly against polygamy? Doesnt that actually defeat the purpose of the encyclopedia? Braveberet (talk) 08:38, 8 November 2018 (UTC)
In no way does the spouses parameter of the infobox represent being against polygamy. The issue is that making a table with the number of spouses is undue weight; there's little reason to devote what amounts to an entire section of an article to the number of spouses one has had (both current and past), especially if it's not a particularly notable aspect of that person. —Jeremy v^_^v Bori! 09:00, 8 November 2018 (UTC)
Oh cut the stupid accusations and the melodrama, Braveberet, there's absolutely no prejudice against polygamy in the suggestion that the current parameter can handle it perfectly well as it is. Boing! said Zebedee (talk) 08:44, 8 November 2018 (UTC)
Oppose. The current parameter can handle multiple simultaneous spouses just fine. Boing! said Zebedee (talk) 08:46, 8 November 2018 (UTC)
Not really, its unclear whether the person was married to multiple people or just one at a time with a list. With a table it makes it more clear. Braveberet (talk) 08:50, 8 November 2018 (UTC)
Dates can be included, as has already been explained to you, and that makes it clear. Boing! said Zebedee (talk) 08:55, 8 November 2018 (UTC)
Boing! said Zebedee See Osama bin Laden. No dates, and I doubt you will find one on any page of any notable polygamous marriage. Braveberet (talk) 08:58, 8 November 2018 (UTC)
Well put some in then! Improve it yourself instead of just whining about prejudice and non-neutrality. Boing! said Zebedee (talk) 09:02, 8 November 2018 (UTC)
Do you have sources that tell us when they were married? If you want the information, you have to do the work. —Jeremy v^_^v Bori! 09:03, 8 November 2018 (UTC)
But this is the point, Wikipedians as a whole have made it unclear whether it is a monogamous or polygamous marriage, which is breaking WP:NPOV. Providing inaccurate information is undesirable on any encyclopedia, especially one like Wikipedia which is accessed by millions of users every week. Thus, it would be benificial to the project to include a Table of Spouses which makes it clear whether it is a monogamous or polygamous marriage. Braveberet (talk) 09:07, 8 November 2018 (UTC)
No, it's not, as has been repeatedly explained to you. Putting irrelevant information into a table gives it importance disproportionate to everything else on the page; the spouses parameter of the infobox does the same thing without the UNDUE concerns. —Jeremy v^_^v Bori! 09:10, 8 November 2018 (UTC)
So you've been told how the current parameter can be used to show polygamy in a perfectly reasonable way, but you're too lazy or unwilling to do it and instead just carry on whining about other people not doing it? So far you have made no constructive contributions to our project whatsoever, and unless you are prepared to put in some effort yourself then you're very unlikely to find much sympathy for your proposals. Boing! said Zebedee (talk) 09:19, 8 November 2018 (UTC)
And have any other editors contributed to it? The answer is "no" because there is an idea among Wikipedia that polygamy is unnotable, which is blatantly untrue, as many of you refuse to admit. Braveberet (talk) 09:53, 8 November 2018 (UTC)
You really have no clue about how Wikipedia works, have you? When you see something that nobody has done yet, you do it! Show some willingness to actually contribute rather than just criticizing others, and people might start to listen to you. Boing! said Zebedee (talk) 10:05, 8 November 2018 (UTC))
You prove my point that it would make it easier for editors, myself included, to fix mistakes on Wikipedia pages by introducing this template. Braveberet (talk) 10:06, 8 November 2018 (UTC)
Are you really so incompetent that you are not capable of simply adding some dates, for example changing "Person's name" to "Person's name (19xx-20xx)" without having a new template made for you? Boing! said Zebedee (talk) 10:10, 8 November 2018 (UTC)
Maybe if you weren't resorting to ad hominem attacks then you could understand my point. My point isn't that I want to be able to do something, it's that the community as a whole would benefit from this template, as it is more clear and legible which enables readers to understand the content more and not have to go through multiple sources to find their info. Braveberet (talk) 10:13, 8 November 2018 (UTC)
In what way would including the parallel dates in the current list of spouses mean the reader would have to "go through multiple sources to find their info"? Boing! said Zebedee (talk) 10:23, 8 November 2018 (UTC)
It would be mistakingly misleading, as with lists, you assume them to be in a hierachical order. It is not clear, with polygamous marriages, that it is not hierachical. Braveberet (talk) 10:27, 8 November 2018 (UTC)
I think you mean sequential rather than hierarchical, and without dates I agree. But I don't see why a table without dates would be any different, and you have not answered my question of why adding dates would not solve the problem. Boing! said Zebedee (talk) 10:50, 8 November 2018 (UTC)
And there is sequence too, as polygamous marriages rarely all start at the same time. As you won't even make an effort to try it yourself, I've added the dates to the infobox at Osama bin Laden based on the dates already in the article (which already made it clear they were polygamous marriages). Can you see how that makes the sequence of marriages and the polygamous overlaps clear? Boing! said Zebedee (talk) 11:10, 8 November 2018 (UTC)
  • Oppose. Having a table of spouses makes the polygamy an outsized aspect of the article. It's rare that a polygamist is notable solely for being one; nine times of ten there are other things that make them notable (bin Laden, for example, has a far stronger claim for notability for being an extremist that founded an international network; the number of wives he had is statistical noise compared to this). This is especially so for cultures, both past and present, where polygamy was common practice. —Jeremy v^_^v Bori! 09:10, 8 November 2018 (UTC)
But shouldn't it be outlined that they are one? Instead of being entirely swept over? Braveberet (talk) 09:12, 8 November 2018 (UTC)
No. How many times are you going to keep hammering the same point ad nauseam that everyone else has rejected as absurd? —Jeremy v^_^v Bori! 09:15, 8 November 2018 (UTC)
I'm only repeating the point because you are refusing to acknowledge it as a notable fact. Someone could infer from what you're saying that you don't think polygamy is a notable fact, which is statistically and empirically untrue. Braveberet (talk) 09:44, 8 November 2018 (UTC)
That would be because you're displaying a sort of bias here. As I mentioned above, monogamy has never been universal practice; several societies past and present allow for and practise polygamy. This does not make every Thomas, Lucinius, and Ghulam coming from those societies notable by any stretch of the imagination. They become notable for things they have done that historians actually cared enough about to discuss at length in their writings. Your argument on its face is and has always been absurd, and has been roundly rejected by everyone here who has a lick of sense.
What is more interesting to me at this point is that literally every edit you have made has been either to this sterile discussion, to bluelink your userpage, or to troll the idea lab. As I mentioned before, I strongly suspect that you are not a new user and are doing this as some sort of breaching experiment or to wind people up. The only thing that keeps me from going to WP:SPI about this is the fact that I haven't the foggiest whose sockpuppet you actually are. —Jeremy v^_^v Bori! 21:53, 8 November 2018 (UTC)
Showing the spouses in a table instead of a list doesn't indicate whether they are concurrent. You still need to add that info somehow if you want it, and there are existing ways to do that without giving undue attention with a table. Osama bin Laden#Personal life makes it clear there were concurrent spouses. Years in the infobox could also make it clear there. The documentation for the main person infobox at Template:Infobox person#Parameters already recommends to add years for all spouses. PrimeHunter (talk) 10:39, 8 November 2018 (UTC)

Oppose. I imagine the wiki would be better served to say "[[Polygamous]] relationship" in the infoboxes in question. It thus wouldn't "sweep over" the concept. Discuss-Dubious (t/c) 17:30, 8 November 2018 (UTC)

Oppose This is one of those where the nuances are better off being explained in prose in the body of the article. MarnetteD|Talk 17:49, 8 November 2018 (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.
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_153&oldid=1086983148"