Wikipedia:Village pump (proposals)/Archive 135

Require consensus for candidate article edits through the election.

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.

We're in the midst of the silly season, where people imagine they can influence the outcomes of various elections by editing the Wikipedia articles of the candidates. This leads to a tremendous amount of edits attempting to add or remove content believed to be helpful or harmful - whether this material is poorly sourced or not sourced at all, non-notable, overly newsy, presented incompletely, etc. I therefore propose that until the conclusion of the voting which these edits seek to influence, all edits to Donald Trump, Hillary Clinton, Mike Pence, Tim Kaine, and, frankly, any other political candidate likely to be subject to this sort of treatment should require consensus for inclusion before any edit is made to the article on that subject. I would remind editors that we are writing a long term project, not an election flyer. I would further note that our articles on these subjects are alreday very well-developed and informative, so there is no rush to repair real deficiencies. bd2412 T 23:40, 10 October 2016 (UTC)Reply[reply]

I think first we should try to address the root of the problem. News media for better or worse has portrayed Clinton in a better light than her competitors - Sanders, Trump, Johnson and Stein, and therefore we should expect that the relevant articles do as well, per neutrality. But some supporters of Clinton's opponents think we should redress what they see as media bias, which is against policy. Similarly, some Clinton supporters think we should remove negative information covered in the media because they do not think it is "relevant." Is there any way we can ensure that policies are followed in editing these articles? TFD (talk) 00:22, 11 October 2016 (UTC)Reply[reply]
  • Oppose - Discretionary sanctions are in place at all articles mentioned. I haven't visited others in a while, but the DS appear to be working adequately at Trump. If they fail to work adequately, it can only be because they are not being adequately enforced. ―Mandruss  00:26, 11 October 2016 (UTC)Reply[reply]
Some of the candidate articles are not under the same restrictions as other candidate articles. --Elvey(tc) 06:21, 14 October 2016 (UTC)Reply[reply]
  • Thanks, but Oppose any prior restraint. If people have to get advance consent before any article edits then article improvement would grind completely to a halt, if it hasn't already. Might as well just edit protect all the articles. I think a little more vigilance is in order for tendentious edits: editors must obtain consensus before any significant edit they know or ought to know to be disputed. If they keep doing it, then warnings and sanctions apply. Also, clarify that whereas BRD are okay, BRRD is not. - Wikidemon (talk) 00:37, 11 October 2016 (UTC)Reply[reply]
  • Oppose. I do genuinely appreciate the spirit behind the proposal, but discretionary sanctions + a rigorous adherence to BLP, RS, V, and BRD should be sufficient here. In other words, we should rigorously enforce the content policies we already have. I also find "all edits" to be very broad - what about ref fixes, general copy edits, typo fixes, adding wikilinks, and so forth? Neutralitytalk 01:51, 11 October 2016 (UTC)Reply[reply]
  • Oppose- I can only speak for editing patterns at the Donald Trump article. Not needed. Sanctions and watchful editors are in place. Buster Seven Talk 02:49, 11 October 2016 (UTC)Reply[reply]
  • Oppose There is no need for this. Semi-protection eliminates most of the silly stuff; discretionary sanctions (eventually) take care of POV warring. The articles I am active at (mostly Trump related) are closely watched and they seem to be operating fairly civilly, with the talk page in use for anything controversial. Routine editing, updating, correcting etc. is being done responsibly. A few timely topic bans have also been helpful. A look at the Clinton article suggests it is a little more problematic, but people seem to be dealing with the problems efficiently. --MelanieN (talk) 03:03, 11 October 2016 (UTC)Reply[reply]
  • Oppose. Our typical WP:BRD process works fine here, and why turn away potential new editors when they could learn something and begin to edit productively? I created an account over a year ago because I saw a TfD notice within the infobox of a random comedian article and I disagreed with it at the time. It wouldn't be that weird for someone to come here for political reasons and choose to stick around productively. ~ Rob13Talk 03:14, 11 October 2016 (UTC)Reply[reply]
  • Oppose — I have been watching the Donald Trump article and his campaign article for months and there have been only minor problems. There is no reason to hamper editors who are trying to make legitimate edits.--Jack Upland (talk) 04:42, 11 October 2016 (UTC)Reply[reply]
  • Oppose. I appreciate the user's frustration, but I quite often make a series of changes to improve the Mike Pence article, all during within a few minutes of each other, and it would be harmful to the project to have to wait between them. So far, none of my changes have been reverted. BeenAroundAWhile (talk) 17:41, 11 October 2016 (UTC)Reply[reply]
  • Mixed support. How many subjects with $125M in brand value at stake have made a point of showing how (overly?) litigious they are? True, the project doesn't worry about editors "influencing the outcomes of elections" -- nor should it -- but it does worry about editors accidentally influencing a subject's brand value. Let's start with the infobox. Citing Forbes, it says Trump's net worth decreased last year. Bloomberg says it increased. If people vote based on what they read here, that's their problem; what if they invest based on it? Can I propose a friendly amendment? --Dervorguilla (talk) 08:05, 12 October 2016 (UTC)Reply[reply]
[Supplement]: A (modest) majority of editors at Donald Trump do appear to agree with TFD that the article should proportionately represent views published by the media they trust. Only a minority would appear to discount views published by objectively disreputable or non-mainstream media. To illustrate: BBC, WSJ, ABC, USA Today, and Economist have been shown to be reputable and ideologically mainstream; New Yorker, Guardian, HuffPo, Politico, and Fox have been shown to be neither. Donald Trump lists 51 references from the first group, 54 from the second (25 from Politico alone). The article may be tagged for verifiability.
[Proposed friendly amendment]: That all questionable claims in the lead sections of these four articles be sourced and vetted, for the duration. --Dervorguilla (talk) 23:52, 12 October 2016 (UTC)Reply[reply]
@Dervorguilla: How does that differ from WP:V? ―Mandruss  07:24, 13 October 2016 (UTC)Reply[reply]
@Mandruss: I'm proposing that we (and others) tag or remove material that fails WP:V because the source isn't a respected mainstream publication. We could conveniently start with the known nonmainstream sources listed above. --Dervorguilla (talk) 10:12, 13 October 2016 (UTC)Reply[reply]
@Dervorguilla: - Interesting concept, but I don't know how much agreement there is on the definition of "mainstream". I'm an old guy so "mainstream" is pretty much a synonym for "traditional, old school, establishment, plus the big three cable news channels". Someone half my age might feel very differently about that, and some solid journalism is occurring on the web. I have my strong opinions about Fox, but I've never actually seen anyone challenge them as a reliable source. But I'm all for tightening up sourcing requirements in principle. ―Mandruss  10:30, 13 October 2016 (UTC)Reply[reply]
@Mandruss: Actually, the current WP:V sourcing requirements already seem rather tight:
"Editors may use material from reliable non-academic sources, particularly if it appears in respected mainstream publications. [Such] other reliable sources include: ... * Mainstream newspapers". (WP:SOURCE.)
"Red flags that should prompt extra caution include: * ... apparently important claims not covered by multiple mainstream sources." (WP:REDFLAG.)
"The label "Mainstream media" [is] generally applied to publications, such as newspapers and magazines, that contain the highest readership among the public." (Mainstream.)
"mainstream. Used or accepted broadly rather than by small portions of a population or market." Wiktionary.
If you look up "Trust Levels of News Sources by Ideological Group", in Political Polarization and Media Habits, you can actually confirm which of these are mainstream: WSJ, TheBlaze, Guardian, or Politico. --Dervorguilla (talk) 02:09, 14 October 2016 (UTC)Reply[reply]
  • Oppose The best analog is an article on breaking news, like the Sandy Hook shooting. I've actually worked the talk page for those kinds of articles, which are arguably more intense but for just a week or two. What I've found is that the non-admin do a pretty good job of policing the page and working together so the article only needs a little admin oversight to use the tools when consensus is being ignored. If it gets overwhelmed with problematic edits, we can always temporarily full protect and have an admin copy over from the talk page to the main page, after a consensus is found. Forcing a verbal consensus is a burden and will mean uncontentious and worthwhile edits will get left out. Dennis Brown - 22:19, 12 October 2016 (UTC)Reply[reply]
  • Support I PROPOSE: uniform protection on (i.e. edit notices on) all candidate articles. (In particular Basic discretionary sanctions + 1RR.) Oppose the BD proposal; we already have people deleting good stuff based on WP:IDONTLIKEIT, and it staying deleted because gaming is so common. --Elvey(tc) 06:21, 14 October 2016 (UTC)Reply[reply]
  • Oppose. Our standard way of doing things has worked for many other contentious topics. I see no reason to create more bureaucracy for this particular one. agtx 23:35, 17 October 2016 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Hungarian Revolution of 1956 article writing contest

Dear Colleagues, I would like to inform you, that Wikimedia Hungary offers prizes for the best articles of the contest in English (submitted until 15 November using the {{Hungarian Revolution of 1956}} template). Let me know if you have any question. Is there any (better) place where this kind of information/announcements can be available for the next days (weeks) (without SiteNotice or CentralNotice)? – Samat (talk) 15:44, 26 October 2016 (UTC)Reply[reply]

Use blink instead of librsvg to render svg to png

Since librsvg has many bugs but none of those bugs appear when viewed in latest version of Google Chrome, wouldn't it make sense for Wikipedia to render these images using Blink (web engine)? The point of pre-rendering SVGs is to make sure they display correctly on all browsers, not to make them break on browsers that would otherwise be able to render them. — Preceding unsigned comment added by (talkcontribs) 00:27, 24 October 2016 (UTC)Reply[reply]

Looks like a good idea to me, but the place to propose this would be at Phabricator - see WP:BUGS for instructions. עוד מישהו Od Mishehu 21:30, 24 October 2016 (UTC)Reply[reply]
What about performance? Do we have any statistics on rendering rates for the two engines? Praemonitus (talk) 21:31, 28 October 2016 (UTC)Reply[reply]

Proposal: Amend page title element to remove "Wikipedia, the free encyclopedia"

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.

  Change implemented, but still under discussion
 – See Special:Diff/743970452 MediaWiki:Pagetitle by MSGJ (talk · contribs). Mz7 (talk) 02:19, 13 October 2016 (UTC)Reply[reply]

A discussion on VPP [1] notes that when a wikipedia page is saved, the default filename, derived from the page's <title></title> value, will be in the form Article Name - Wikipedia, the free encyclopedia. The suggestion is that this is a bit of a pain, and that Article Name - Wikipedia would better suffice.

This proposal is to amend MediaWiki:Pagetitle such that Wikipedia pagenames are amended as follows:

  • from: Article Name - Wikipedia, the free encyclopedia
  • to: Article Name - Wikipedia

Please indicate support/opposition below and/or discuss. thanks --Tagishsimon (talk) 00:01, 11 October 2016 (UTC)Reply[reply]

  • Strong Support. We already have "Wikipedia, The Free Encyclopedia" on every page (look at the globe at the upper left). Adding it to other places feels sort of spammy. --Guy Macon (talk) 01:15, 11 October 2016 (UTC)Reply[reply]
  • ...and keep the hyphen as being standard ASCII and thus more friendly to operating systems and screen readers for the blind. --Guy Macon (talk) 22:25, 12 October 2016 (UTC)Reply[reply]
  • Support - for conciseness, and because most of the world already knows by now that Wikipedia is the (a?) free encyclopedia. ―Mandruss  05:02, 11 October 2016 (UTC)Reply[reply]
  • Strong Support. - and not only for conciseness, but also for consistency -- Wikipedia articles in most other languages manage well without the extra-long tag. — Preceding unsigned comment added by (talkcontribs) 08:39, 11 October 2016 (UTC)Reply[reply]
  • Support These titles end up in browser tabs. Short titles are much more workable. The free encyclopedia doesn't really add information, so no need to repeat it in every tab title. Jahoe (talk) 11:03, 11 October 2016 (UTC)Reply[reply]
  • Support, but change the hyphen - to an en dash as well. (Hyphen is stylistically inappropriate here.) Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me
    11:26, 11 October 2016 (UTC)Reply[reply]
Jc86035 — en-dashes are not allowed in file-names on a number of operating systems, so we cannot do that. Carl Fredrik 💌 📧 13:47, 11 October 2016 (UTC)Reply[reply]
@CFCF: French Wikipedia uses an em dash Article — Wikipédia… In addition, there are quite a number of articles which already use en- or em-dashes in their titles. How is en-dashes not being allowed in filenames an issue? Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
13:53, 11 October 2016 (UTC)Reply[reply]
Well, one of the rationales is based on the user saving a page to their computer. I'm generally not in favor of fixing one thing and simultaneously breaking another... Wouldn't a comma be even more stylistically accurate? Carl Fredrik 💌 📧 13:59, 11 October 2016 (UTC)Reply[reply]
A comma makes it sound like a place name… I guess if it's really that problematic (are there that many people who download Wikipedia articles?), it's probably better to just keep the hyphen until Windows XP dies. Jc86035 (talk) Use {{re|Jc86035}}
to reply to me
14:08, 11 October 2016 (UTC)Reply[reply]
  • Support, and keep the hyphen. Ideally file names should be basic 7-bit ASCII for portability and long term storage. Keep the typographically correct fancy formatting for inside the articles. Martin of Sheffield (talk) 14:23, 11 October 2016 (UTC)Reply[reply]
  • Support in general. Indifferent to the hyphen. It's an annoyance I've encountered and I'm glad someone thought to propose an actionable change. — Rhododendrites talk \\ 18:12, 11 October 2016 (UTC)Reply[reply]
  • Support. As stylistically redundant. GenQuest "Talk to Me" 23:31, 11 October 2016 (UTC)Reply[reply]
  • Support. - my "devil's advocate" failed to find any solid reason for the longer version. Staszek Lem (talk) 01:46, 12 October 2016 (UTC)Reply[reply]
  • Support. It's unlikely that any reader of citations would not know what Wikipedia is. S a g a C i t y (talk) 06:23, 12 October 2016 (UTC)Reply[reply]
  • Based on the unanimous support shown here, I have made the change — Martin (MSGJ · talk) 09:11, 12 October 2016 (UTC)Reply[reply]
  • Definitely not trying to change the decision already made, but I wanted to offer some additional information, for those of you interested. After deep research with potential readers in Mexico, India, and Nigeria, we learned that there's a huge lack of awareness/understanding of Wikipedia (for example, 75% of respondents in India had never heard of Wikipedia). This means that people are reading Wikipedia content without knowing where it came from - a great use of the content, but it doesn't let them distinguish the value of neutral POV, un-commercially biased content from the rest of the internet. And people who don't know Wikipedia have no ability or opportunity to become editors. We also know that most of our traffic in these countries (particularly in Nigeria and India) are in English because of the lack of local language content on the internet (not just Wikipedia). I don't think the old page title had much to contribute to this, but figured you might want to know. AGomez (WMF) (talk) 21:26, 12 October 2016 (UTC)Reply[reply]
  • Support The portion "the free encyclopedia" is what Wikipedia is, saving a page only need tell you what the article is and where it came from. The full tag isn't helpful for saved pages. Dennis Brown - 22:09, 12 October 2016 (UTC)Reply[reply]
  • Support Current form is redundant. Couldn't care less about the dash v hyphen debate. -Ad Orientem (talk) 22:20, 12 October 2016 (UTC)Reply[reply]
  • Comment – Has the change already been made? I notice that when I hover my cursor over Wikipedia tabs, they now just display "Wikipedia" instead of "Wikipedia, the free encyclopedia". Dustin (talk) 22:42, 12 October 2016 (UTC)Reply[reply]
    Ah, I see that my question has already been answered above. The change has indeed already been made. Dustin (talk) 22:44, 12 October 2016 (UTC)Reply[reply]
@MSGJ: A consensus in a day? Since when we just close a discussion that lasts 24 hours when it affects every page? I question that this is an adequate decision and any requirement for a SNOW call or a speedy close. <sigh> There is a courtesy that should be extended to the general populace to allow opinion to be expressed. — billinghurst sDrewth 03:56, 15 October 2016 (UTC)Reply[reply]
You honestly think that leaving it open would have resulted in a different outcome? --Guy Macon (talk) 06:04, 15 October 2016 (UTC)Reply[reply]
It would have given time to examine some more potential issues. This discussion is all about saved filenames and browser tabs (with some votes possibly being made on the assumption that this would only affect filenames), and doesn't explicitly touch on search engine results, which is a huge part of how Wikipedia fits into the web. A link titled Goldfish - Wikipedia, the free encyclopedia makes it clear to an uninformed searcher that this clicks through to an encyclopedia article, but Goldfish - Wikipedia doesn't. I don't know how much we can safely assume that everyone searching for information on the web will know what Wikipedia is, but as User:AGomez (WMF) observes, "75% of respondents in India had never heard of Wikipedia". --McGeddon (talk) 07:56, 15 October 2016 (UTC)Reply[reply]
I agree with this. The discussion was not open long enough for enough people to get a say on something that everyone will notice. I've had to find this thread after seeing the title change because I want to oppose it, but I can't because that tiny discussion period is apparently adequate. As such I would ask that the change is undone for now and this matter is opened to the wider community as an RfC. Rcsprinter123 (face) 12:06, 15 October 2016 (UTC)Reply[reply]
You are free to erect an RfC, Rcsprinter. There doesn't seem a good reason for the change to be undone whilst you're about that. On you go. --Tagishsimon (talk) 12:13, 15 October 2016 (UTC)Reply[reply]
I think the fact that the discussion was snowballed before touching on the serious topic of how Wikipedia appears in inbound links is big enough that the discussion should continue here. We certainly have a snowball consensus for the new title being, as proposed, an easy fix for how saving articles as HTML can be "a bit of a pain", but there's been no discussion of whether it's a good or bad idea for Wikipedia links to stop describing themselves as being from "the free encyclopedia" in search engine results and social media shares. --McGeddon (talk) 18:34, 15 October 2016 (UTC)Reply[reply]
I agree that there wasn't sufficient time for people to comment on this before it was implemented. I'd second the issues brought up above, and another annoying outcome of this change is that people who like to save copies of web pages they find useful in preparation for them disappearing or being destructively changed in the future suddenly find that when they save an updated version of any Wikipedia page, it no longer overwrites the old copy and they have to go manually delete the old one to prevent confusion and avoid wasting disk space. --Dan Harkless (talk) 11:37, 16 October 2016 (UTC)Reply[reply]
Now that the change has been made, changing it back would cause copies to no longer overwrite the old copy if the old copy was saved after the change. --Guy Macon (talk) 20:08, 16 October 2016 (UTC)Reply[reply]
  • Comment: Having the words "the free encyclopedia" in incoming links is unnecessary and a bit spammy (as in "that which low quality sites that are desperate to get high rankings in the search engines tend to do"). Even if someone doesn't know what Wikipedia is, the link takes them to a page with a cute little globe that says "Wikipedia, the Free Encyclopedia" under it. When a non-spammer cites something (here or on other sites) that comes from the NYT, they make the text of the link "The New York Times", not "The New York Times - Breaking News, World News & Multimedia". Links to Reddit should say "Reddit" or perhaps "", not "reddit: the front page of the internet". (examples taken from the actual page titles of those two sites). Simpler is better. --Guy "when you want help from someone with a three letter name that starts with 'G' but don't want to bother any actual deities" Macon (talk) 01:36, 16 October 2016 (UTC)Reply[reply]
Somebody looking at a page of ten "Title - Website" results is unlikely to click through every result to see how each website describes itself before deciding which one to read - they're just going to pick one based on what they can see of it. And sure, Wikipedia is probably fine here in most cases because it'll be the top result and have an encyclopedia-toned snippet. It just seems reckless that we've changed this across the entire site apparently on the grounds that saved filenames are "a bit of a pain", with only two editors (yourself and the proposer) explicitly saying at any point that they think the new title is okay in search engine results, social media shares and any other external contexts that use a site's <title> tag. --McGeddon (talk) 09:30, 17 October 2016 (UTC)Reply[reply]

Tagishsimon, Mandruss, Jahoe, Jc86035, CFCF, Martin of Sheffield, Rhododendrites, GenQuest, Staszek Lem, Saga City, AGomez (WMF), Dennis Brown, Ad Orientem, Dustin V. S., billinghurst: would you mind looking at McGeddon's comments above and confirming whether you still support this change? It is possible you commented without realising the full impact of this change. — Martin (MSGJ · talk) 10:04, 17 October 2016 (UTC)Reply[reply]

"Wikipedia" is a household word for most of the Internet-enabled world, becoming more so every day, and I don't think it needs to be clarified in this manner. Similarly, page titles at YouTube show the title of the video followed by "- YouTube", not by "- YouTube, the most popular video upload site". ―Mandruss  10:13, 17 October 2016 (UTC)Reply[reply]
Based on my own experiences in my region (United States), I would agree with you. However, AGomez (WMF)'s note above is a little concerning. If it is true that a significant portion of potential readers in Mexico, India, and Nigeria aren't aware what Wikipedia is (i.e. a free online encyclopedia), it likely isn't such a household term everywhere in the world. I'm not entirely convinced by the argument that the tagline "the free encyclopedia" is spammy, because in search engine results, it truly is the first thing that a potential reader sees that gives any clue to the reader what "Wikipedia" is, assuming they don't figure out the "-pedia" ending. Mz7 (talk) 22:07, 18 October 2016 (UTC)Reply[reply]
I remember a few years back they used "(video title) - YouTube - Broadcast Yourself". - CHAMPION (talk) (contributions) (logs) 07:11, 24 October 2016 (UTC)Reply[reply]
  • My opinion is the same as previously posted. The reason we are listed in the top spots is due to relevance and Google's obvious choice to weigh all content here more heavily, not a tag in the title. Continuing the discussion here is probably a good idea regardless. Dennis Brown - 10:33, 17 October 2016 (UTC)Reply[reply]
      Wikipedia title tag as an autocomplete
      The concern raised isn't that Wikipedia might slip down the Google rankings, more that readers seeking information online without knowing what Wikipedia is might (in cases where Wikipedia is the second or lower result, or when their smartphone browser suggests "Pluto - Wikipedia" in its autocomplete suggestions) not realise that it's an encyclopedia and click something else. The title tag has been static for eleven years prior to this change, and we need to think about how it's being used by other sites and software. --McGeddon (talk) 10:37, 23 October 2016 (UTC)Reply[reply]
  • same. Yes, good re-open. Let's consider this an A/B test to see if name recognition improves as a result of cutting the promotional tagline from search-engine results. --Tagishsimon (talk) 11:14, 17 October 2016 (UTC)Reply[reply]
    • Actual A/B testing would need some technical work to serve and record different titles, and it's going to be hard to measure impact when caching is a factor (I can't actually find any examples where Chrome autocomplete has started using the shorter title), but we should at least try to see if we can detect any meaningful drop in article traffic (from any particular country) since the change was made on the 12th. And if so, decide whether we care or not. --McGeddon (talk) 10:54, 29 October 2016 (UTC)Reply[reply]
  • Support the change to "- Wikipedia". The longer version was needlessly wordy, and the large majority of Wikipedia languages default this shorter version. Alsee (talk) 10:40, 24 October 2016 (UTC)Reply[reply]
  • Comment: Thankfully, Wikipedia joins Wikiquote in losing its unnecessary long tag. That leaves 'Wikibooks, open books for an open world' and 'Wikisource, the free online library', which, for the sake of brevity and consistency, should now be shortened.— Preceding unsigned comment added by (talkcontribs) 11:14, 28 October 2016 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Has the result changed?

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.

Since the snow close was reverted,[2] has the result changed? Is there anyone who honestly believed that reverting the snow close would change the outcome? The purpose of a snow close is to avoid endless discussion that has zero chance of changing the result. It was a good close and should not have been reverted. --Guy Macon (talk) 12:49, 28 October 2016 (UTC)Reply[reply]

Yes, I believed there was a chance it might well have changed the outcome, because the discussion had been solely about the obscure use case of saved HTML filenames, and considered none of the more prominent ways in which the title tag is used. --McGeddon (talk) 10:43, 29 October 2016 (UTC)Reply[reply]
Being rather oblivious to whether this change goes through or not I have not voted. However, it is extremely clear that the result will not be changed. I suggest it be reclosed, and may do so per WP:SNOW unless there are any convincing arguments why the change was wrong (not just arguments against doing it, but that it was wrong). Frankly, this has run long enough to achieve consensus, and we shouldn't waste time debating whether or not to do it (it's been done). This doesn't mean we shouldn't continue discussing, but if the result is to be overturned it will need a new discussion and new consensus. Voting on something that has been decided just ins't productive. Carl Fredrik 💌 📧 11:06, 29 October 2016 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Delete user accounts for 1 year dormant accounts with no edits beyond their user page.

It appears to be snowing. I might suggest the proposer take their idea, if they have a belief that some amendment to that idea would be fruitful for the community, over to WP:VPI. --Izno (talk) 12:03, 31 October 2016 (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.

Basically, there are a lot of accounts out there that have never made edits, but still exist, while I understand fully that accounts that have made any degree of useful contribution should never be deleted, those that have never made any can be. Do you agree with this? Iazyges Consermonor Opus meum 19:04, 29 October 2016 (UTC)Reply[reply]

Opus meum we don't really have "delete account" capability at all - what do you want to accomplish with this - freeing up the username? If so, with Global usernames this would have to be addressed over on meta: (beyond the scope of the English Wikipedia). — xaosflux Talk 19:07, 29 October 2016 (UTC)Reply[reply]
Not just a meta issue but a legal one at that. Accounts are not deleted due to attribution reasons. One valid edit makes that attribution necessary. So WMF-Legal would have to be looped into the conversation as well. If the account has not made an edit and you want to take it over that is what we have WP:USURP for. Just having a username taken with no one looking to usurp it doesn't harm anything. --Majora (talk) 19:13, 29 October 2016 (UTC)Reply[reply]
If an account has never made a single edit, I wouldn't expect the attribution issue to arise. Dustin (talk) 06:19, 30 October 2016 (UTC)Reply[reply]
No, because some readers create accounts purely so that they can set preferences, or watchlist pages, or similar. Hence, even accounts with 0 contributions shouldn't be deleted en-mass. Quiddity (talk) 20:23, 29 October 2016 (UTC)Reply[reply]
What he said... GenQuest "Talk to Me" 22:56, 29 October 2016 (UTC)Reply[reply]
Interesting tidbit from some recent research: We've assumed in the past that if you don't edit the same day that you create your account, then you probably never will. (I'm a counter example, of course.) But it appears that this isn't the case. Creating an account in "January" and making your first edit in "February" is not very unusual. WhatamIdoing (talk) 04:53, 30 October 2016 (UTC)Reply[reply]
As is Steel1943, who created his account in 2006, but didn't edit until 2011. Pppery 15:06, 30 October 2016 (UTC)Reply[reply]
What problem is this proposal designed to solve? (talk) 10:48, 30 October 2016 (UTC)Reply[reply]
  • Support in principle, but limit it to accounts that have zero edits for which attribution would be required, and which also have no watchlists and no other changes from default settings. bd2412 T 16:04, 30 October 2016 (UTC)Reply[reply]
    @BD2412: The problem with that is that accounts are global now. I have dozens of accounts on other projects that I have never edited nor do I plan on changing any of my preferences on. So your requirements would have to be global. And the IP comment above makes a great point. What exactly would this solve? --Majora (talk) 17:53, 30 October 2016 (UTC)Reply[reply]
    The accounts being global, the conditions would also need to be - accounts registered but never used for anything (including watchlist creation) anywhere in Wikimedia. In theory, people could create Wikipedia accounts just to reserve a username that they use elsewhere, but we're not a username reservation service. We could post a mass alert on the talk pages of all affected users and give them a month to respond (by definition, any response would remove them from the category of accounts to be deleted). bd2412 T 18:13, 30 October 2016 (UTC)Reply[reply]
In the rare cases where that might cause a problem we have the usurpation process. This looks very much like a solution in search of a problem. (talk) 18:46, 30 October 2016 (UTC)Reply[reply]
  • Oppose good faith proposal. I briefly considered supporting this but Quiddity is correct. Members of the community employ accounts for more than just editing. -Ad Orientem (talk) 16:14, 30 October 2016 (UTC)Reply[reply]
  • Oppose per Quiddity. So long as accounts may facilitate other legitimate uses beyond editing, there is no justification for penalizing accounts that do not edit regularly, or even at all. The Big Bad Wolfowitz (aka Hullaballoo). Treated like dirt by administrators since 2006. (talk) 18:31, 30 October 2016 (UTC)Reply[reply]
  • Question - What is the proposed reason for deleting the accounts? It seems so obvious that this has no purpose that I have to wonder whether we have all missed something. Robert McClenon (talk) 18:59, 30 October 2016 (UTC)Reply[reply]
  • Oppose Why? There are so many downsides to this (cf Quiddity), what possible advantage does it convey? Andy Dingley (talk) 19:24, 30 October 2016 (UTC)Reply[reply]
  • Oppose As others have pointed out this looks like deletionism simply for the sake of deletionism and even where there is not problem and the current usurpation arrangements work fine. Even if this proposal was amended, as some have suggested, to acknowledge SUL and respect that an account can be reserved here if people edit any of the thousand Wikis of the Wikimedia group, and that an account can be legit if all the user does is have a watchlist; It rather ignores that our purpose is to make the sum of all knowledge available to everyone not just those who edit. If someone prefers reading Wikipedia with the categories at the top or with a custom default for image size or a different date format then that is fine by me and I don't understand why we would be proposing taking those preferences away from those of our readers who use that. There is also a copyright/attribution issue if you ignore deleted edits as this proposal seems to do. Deleted edits do sometimes get restored on wikis, we have a whole policy of doing so on commons re files currently in copyright. ϢereSpielChequers 19:40, 30 October 2016 (UTC)Reply[reply]
  • Oppose Accounts exist for more reasons than editing, as noted by many already. I see no good reason to shut down accounts merely because they don't edit. --Jayron32 00:22, 31 October 2016 (UTC)Reply[reply]

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

New adminbot request - AWB access management

There is a new adminbot request open at WP:BRFA. Please see Wikipedia:Bots/Requests for approval/MusikBot II for details. — xaosflux Talk 04:18, 1 November 2016 (UTC)Reply[reply]

New adminbot proposal - blocking spambot IPs

Administrators are currently manually blocking IPs that hit certain URLs on the spam blacklist. It has been requested that a bot perform these blocks to allow for faster response time. Please comment at Wikipedia:Bots/Requests for approval/AnomieBOT III 3. Anomie 22:20, 1 November 2016 (UTC)Reply[reply]

Amend RFC name, change it from Request for Comments to Request for Consensus

And this one also is snowing. --Izno (talk) 14:22, 3 November 2016 (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.

While RFC may be called request for comments, in reality it is a !vote to establish consensus, so logically the name would be changed to avoid confusion, thoughts? Iazyges Consermonor Opus meum 23:33, 31 October 2016 (UTC)Reply[reply]

  • Oppose "Consensus" will perhaps be arrived at after comments have taken place; requesting "consensus" is tricky as such request may be easily viewed as prejudicial; nevermind that in Wikipedia the term "consensus" is at best ill-defined. (talk) 01:03, 1 November 2016 (UTC)Reply[reply]
  • Oppose good faith proposal. This is not an improvement. Rather it seems to be a solution in search of a problem that I don't think exists. -Ad Orientem (talk) 01:20, 1 November 2016 (UTC)Reply[reply]
  • Oppose. A request is made for comments so that a consensus can be established based on those comments. One cannot request a consensus, because a consensus is formed, not granted; one can only request comments in the hopes of gaining a consensus. Thus, a request is made for comments, not consensus. Colonel Wilhelm Klink (Complaints|Mistakes) 02:23, 1 November 2016 (UTC)Reply[reply]
  • Oppose - while one can certainly expect individual users to place their comments, there is no reasonable guarantee that there will be a consensus. The request is actually for those comments which will subsequently be looked at by the closer of the discussion to determine if there is a consensus and what it is. עוד מישהו Od Mishehu 10:49, 1 November 2016 (UTC)Reply[reply]
  • Oppose RFCs seek more than consensus. Sometimes, they are useful for idea-generating sessions, and not merely as a means to establish a !vote. --Jayron32 02:48, 3 November 2016 (UTC)Reply[reply]
  • Oppose as comments and discussion are required to reach consensus: I don't see the point in changing the name. Rubbish computer (HALP!: I dropped the bass?) 13:50, 3 November 2016 (UTC)Reply[reply]
  • Oppose - I've often used an RFC to invite comments on an issue prior to drafting a proposal, and others I've participated in frequently result in initial proposals being amended due to comments in the conversation. There are also varying interpretations of consensus among individual editors. I think 72.43 makes a good point, this change may invite RFCs of the "do you agree consensus is this?" sort, which isn't the point. Ivanvector (Talk/Edits) 14:03, 3 November 2016 (UTC)Reply[reply]

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

Limit auto-confirmation edit counter to content space edits, not userspace.

Autoconfirmed settings on other projects
Project Age (d) Edits
Default 4 0
arwiki 4 50
ckbwiki 4 10
dewikibooks 7 0
enwiki 4 10
eswiki 4 50
eswikivoyage 4 25
fawiki 4 10
itwiki 4 10
itwiktionary 4 10
jawiki 4 10
kowiki 4 10
plwiki 4 10
ptwiki 4 10
ruwiki 4 15
simplewiki 4 10
tenwiki 0 0
wikidata 4 50
wuuwiki 7 10
zh_yuewiki 4 10
zhwiki 7 50

Auto-confirmation is a good idea, but largely useless as 10 edits is nothing. Additionally, the experienced sockmaster (see Special:Contributions/Rockypeter for today's latest) gets round this by jabbering away unnoticed in their user sandbox, then blanking it, and then proceeding to mischief through page moves.

Pages moves should not be available to a user who has done nothing outside their userspace.

A limit of "a small number" of mainspace edits (possibly categories too) is a good idea for autoconfirmation status. However this is being abused and ought to be tightened. Maybe more than 10. IMHO definitely requiring content space work, rather than just self-editing in userspace. This makes trollery slightly harder work, slightly more obvious to spot (most of our trolls are such monomaniacs) and if all they do is fix a handful of real typos in mainspace, then at least we've had those typos fixed. Andy Dingley (talk) 14:03, 23 October 2016 (UTC)Reply[reply]

  • Support. Edits counted for determining an editor's capacity to handle additional capabilities should be edits that matter to the project, and are unlikely to be out of sight. bd2412 T 14:14, 23 October 2016 (UTC)Reply[reply]
  • Seems optimistic to think that trolls would turn their hands to honestly fixing typos, if forced to make their ten edits in mainspace - any arbitrary punctuation or lazy synonyms would do, at best making no difference to an article and more likely reducing its quality. If someone's only here to become autoconfirmed, do their regular vandal routine and get blocked, then the fewer edits they make to Wikipedia articles in the process (particularly since their autoconfirmed sprinkles will be four days deep in edit histories when they get blocked), the better. --McGeddon (talk) 17:02, 23 October 2016 (UTC)Reply[reply]
  • Has anyone looked in to the technical support for this (e.g. is it something developers will support?) Most of the other wikis with more complex systems are doing it via the flavors of flagged revisions that has had a contentious past here. — xaosflux Talk 17:33, 23 October 2016 (UTC)Reply[reply]
    You'd need to write new code in MediaWiki, I believe. And McGeddon's argument is difficult to counter. Jo-Jo Eumerus (talk, contributions) 18:16, 23 October 2016 (UTC)Reply[reply]
  • A simple way around this is to just raise the number of edits it takes for autoconfirmed. That makes it easier to detect patterns (for reasons I won't disclose via WP:BEANS) and catch socks and trolls alike. 50 seems reasonable, although 30 is more likely to get support. Bumping up to two weeks is also a good idea, imho. This isn't such a burden and is more likely to affect trolls and socks than real editors. This should only require some minor changes in the software, one would think. Dennis Brown - 20:58, 23 October 2016 (UTC)Reply[reply]
    Dennis Brown - yes, changing the days or edits is trivial from a software side - here is a table for comparison on other WMF wikis — xaosflux Talk 23:21, 23 October 2016 (UTC)Reply[reply]
  • Thank you. My two weeks might seem long, but I see my original 50 edits wouldn't make us the first. I don't want to stop anyone from editing, but enwp is a large target for a lot of trolls, spammers, money making socks and the like. It is my opinion that if enwp had a policy that was more strict, it would solve more problems than it would cause. We have had to go to Extended Confirmed due to some of these problems, this would just bridge a tiny portion of that gap and make it harder for the bad guys, while most good guys will never notice. Even 50 edits / 7 days would be beneficial, and those already exist in other wikis. The environment here is changing, we need to bend in the wind a little. This isn't a full solution, but it is a start and as xaosflux points out, rather simple to implement from a technical standpoint. Dennis Brown - 23:30, 23 October 2016 (UTC)Reply[reply]
    While Special:ListGroupRights shows everything, the primary extra permissions that a normal new user get when confirmed are:
    1. (upload) The ability to upload files here to enwiki , such as fairuse images that can't go to commons.
    2. (skipcaptcha) Not have to enter CAPTCHA's for some things
    3. (move) Ability to move pages
    4. (editsemiprotected) Edit SPP pages
    5. (autoconfirmed) Not be affected by IP-based rate limits
    xaosflux Talk 23:45, 23 October 2016 (UTC)Reply[reply]
    Marking new articles as patrolled, I believe. Dennis Brown - 00:00, 24 October 2016 (UTC)Reply[reply]
    That is going to be going away very soon. — xaosflux Talk 00:04, 24 October 2016 (UTC)Reply[reply]
  • Support change to 14 days, 50 edits In addition to editing semi-protected articles, and autoconfirmed user can also upload images. However, while I've seen many requests for confirmed status or help with uploading images by someone who is not yet confirmed, in almost all cases, they want to upload an image that ought to be uploaded to Commons (or not at all). The rare exceptions are the need to upload logos (or other fair use images) but there are many people willing to help upload logos. So I see little downside to expanding the criteria a bit. Almost all semi-protected articles are in that's that isstate because of contentious issues and I'm not convinced there are many editors with a handful of edits and a few days of experience that ought to be editing these articles. I'm also an agreement that the edit count should not be based on mainspace partly because I think it might be technically difficult but partly because I think the argument by @McGeddon: is solid. Let's not add a rule that encourages sock puppets to make crappy edits to mainspace.--S Philbrick(Talk) 23:55, 23 October 2016 (UTC)Reply[reply]
    • Changing to article only is hard, increasing is easy, this is kind of a compromise. If we see someone doing 50 user space edits to get past the limit, we will know there is a problem. You can't always tell with just 10. Dennis Brown - 00:02, 24 October 2016 (UTC)Reply[reply]
      • And for good faith editors, there is always WP:PERM to request early confirm - it is usually given out liberally if the requester has clue (it is also usually given out liberally at editathons to brand new editors). — xaosflux Talk 00:06, 24 October 2016 (UTC)Reply[reply]
        • Including those that have edited other language Wikis with no problems. Dennis Brown - 00:10, 24 October 2016 (UTC)Reply[reply]
        • That's an excellent point, and help covers the rare examples of editors who might have legitimate need for confirmed status.--S Philbrick(Talk) 00:18, 24 October 2016 (UTC)Reply[reply]
          • And who happen to know that the status exists, which I'd venture to say is very few of the people with a legitimate, good-faith interest in being able to edit semi-protected articles. WhatamIdoing (talk) 18:23, 24 October 2016 (UTC)Reply[reply]
            • Echoing WAID's concerns: this venue is frankly rather pointless because it arguably requires far more than what actually achieving auto-confirmed does. If people are expected to ask for permission we break the entire premise of Wikipedia. Carl Fredrik 💌 📧 18:58, 24 October 2016 (UTC)Reply[reply]
  • Support change to 14 days, 50 edits per above. Dennis Brown - 00:00, 24 October 2016 (UTC)Reply[reply]
  • Did anyone read the actual proposal here? I'd support increasing the counts, but my main point here is to require those counts to be made in content space, not userspace. Andy Dingley (talk) 02:30, 24 October 2016 (UTC)Reply[reply]
    I think they are looking for some options due to existing technology limits - changing the days/total edits is a simple parameter tweak; creating an edits-by-namespace routine would require software development or the conversion to different systems for managing this (like flagged revisions). The former can be resolved by community consensus and a change ticket that will get turned around quickly - the later could be a while to actually implement. — xaosflux Talk 04:20, 24 October 2016 (UTC)Reply[reply]
    Exactly. It isn't to undermine the original idea, it is to supplement it until the other idea can be realized, which will take time. This is a bit of a common sense stop gap until then.Dennis Brown - 10:49, 24 October 2016 (UTC)Reply[reply]
  • Support change to 14 days, 50 edits as alternative to proposal. I agree the proposal was a nice idea, and would cut down on vandals literally counting down their edits in the sandbox, but the technical implementation seems to be the kicker. The increaed edits would at least help us combat vandals in the long run, as Dennis Brown states above -- samtar talk or stalk 08:26, 24 October 2016 (UTC)Reply[reply]
  • Support change to 14 days and whatever number of edits we decide on (25–50 seems fair), as long as they are main-space content edits, per the proposal. GenQuest "Talk to Me" 09:46, 24 October 2016 (UTC)Reply[reply]
  • Oppose per McGeddon. In my opinion you would get far more bang for your buck by creating a large pool of trusted users with the ability to remove autoconfirmed from a user where cause is shown. Administrators can invoke the harder criteria when considering adding confirmed to a user whose autoconfirmed had been revoked. Don't penalize the masses who deserve an assumption of good faith because a small group of belligerents do not.--John Cline (talk) 15:10, 24 October 2016 (UTC)Reply[reply]
  • Oppose — While the proposal seems sound at first we have to ask ourselves what adverse effects it could have. From my experience the amount of articles we have that require auto-confirmed increases, especially so for the most important articles — the ones where there is highest likelyhood someone will try to edit. So put this trend against increasing the barrier that has to be vaulted before doing what you want and we may end up with a chilling effect on new users that outweighs any potential benefits. If new users both find it harder to start editing and at the same time need more edits to work on the articles they want — we risk losing them before they even get started.
    Don't get me wrong, sockpuppetry is problematic, but this solution risks doing more harm than good. At the same time experienced sock-puppeteers can simply get around this hurdle by performing more useless maintenance tasks in article space, so we don't even address that problem.
    Not all maintenance tasks are useless, but you can very easily hit 50 edits in around 2 minutes by replacing all 25% with 25 % while arguably doing "useful" edits in article space.
    More generous application of IP-blocks as well as actually trying to root out the most common public proxy addresses is far more likely to be helpful. Carl Fredrik 💌 📧 18:50, 24 October 2016 (UTC)Reply[reply]
  • Support change to 14 days, 50 edits - Ideally I'd prefer 20 days and and 100 edits however I'm probably the minority on that, Anyway at the moment the current autoconfirmed is extremely lenient and it's not hard to make stupid edits/useless edits in sandboxes etc so IMHO this should be tightened. –Davey2010Talk 19:11, 24 October 2016 (UTC)Reply[reply]
  • Question Andy, can you clarify whether you want the edits restricted to articles per se, or do article talk pages also count? One of the most common frustrating patterns of new editors is to that some of them jump into editing articles and don't engage when their edits are questioned. I wouldn't want the rules to inadvertently encourage that. --Trovatore (talk) 19:17, 24 October 2016 (UTC)Reply[reply]
Support only counting article space - inoorder for a user to be autoconfirmed, they should have to edit in the encyclopedic content, not off in their own userspace. עוד מישהו Od Mishehu 21:33, 24 October 2016 (UTC)Reply[reply]
  • Support the original proposal, but, taking technical matters into account, also support a tightening of autoconfirmed qualifications. In terms of the former, anyone who is seriously here to contribute will have no trouble making sufficient edits to article space; anyone who isn't will be easier to spot. As for raising the autoconfirmed bar, it is currently disturbingly low, to the point that semi-protection is oftentimes ineffective. At least one week (preferably two) and 20 edits seems like a good choice to me. (Though a change to the autoconfirmed requirements will probably require its own independent RFC, it can't hurt to discuss a bit now and lay out the groundwork.) Colonel Wilhelm Klink (Complaints|Mistakes) 21:55, 24 October 2016 (UTC)Reply[reply]
  • Strongly oppose both proposals. Making it more difficult in any way to obtain autoconfirmed status will deter dedicated sockpuppeteers exactly zero point zero zero (0.00) percent, but will make it that much more difficult for new users to participate in the project. Some may ask, "there's only a small subset of pages that are semiprotected, wouldn't the tiny increase in barrier to new users editing that small subset be worth the deterrence to sockpuppets?" but there is no deterrence here at all. Not any. None. Zero. Nada. It's raising the bar for new editors for no real benefit at all. I've been through a few (not one but several) SPI cases just this week where a dedicated abuser creates dozens of idle accounts and makes ten inconsequential edits with each one (hundreds of manual edits overall), and they're going to be autoconfirmed in the background while whichever account is the active one this week hasn't been blocked yet, then the next one pops out, and so on, and so on, and so on. A user dedicated enough to make hundreds of non-automated edits via multiple accounts is one who's not going to be deterred one bit by having to make a few hundred more, and with so many sleeper accounts the extra waiting period is entirely meaningless. And also per McGeddon: if we restrict the confirmation bar to edits to mainspace, then these hundreds of useless edits will be to articles, and I swear by His Noodly Appendage that is not a consequence we wish to incur. Ivanvector (Talk/Edits) 23:20, 24 October 2016 (UTC)Reply[reply]
I just noticed Dennis Brown's comment below: he has been a clerk longer than I have and has more experience, and I completely agree that the vast majority of sockpuppeteers don't go to the bother of creating many accounts to circumvent autoconfirmation and semiprotection. But the vast majority who don't create sleepers are equally deterred by semiprotection regardless of whether it's 4/10 or 14/50, while the tiny few who do raise sleeper farms will not be any more deterred by this. Thus I see this as raising the bar for new editors with no actual benefit. Ivanvector (Talk/Edits) 23:32, 24 October 2016 (UTC)Reply[reply]
  • Neutral on requiring content edits, which wouldn't change much either way. Oppose increasing number of edits or time required. Determined sockpuppets will not be deterred, unless we set it to a level comparable to extended confirmed which would defeat the purpose of having two autopromotion levels. The current level for semi-protection works well, it's a just balance between the need to be open enough to new editors and the need to repel abuse. Semi protection is efficient in almost every cases. As for page moves, with the edit filter and other progress this is no longer a pressing counter vandalism issue. Only template vandalism remains a serious concern, but this wouldn't help against that. Cenarium (talk) 04:30, 25 October 2016 (UTC)Reply[reply]
  • oppose increasing to 14 days/50 edits. 50 edits doesn't sound like much to most of us; it is never attained by most editors, including those who come to edit-a-thons and then for instance work on the articles they started at home. Agree that though socking may be a problem, throwing up barriers for new editors is a much bigger one. (For context, I have been running many edit-a-thons lately, and have been following the trajectory of the new editors who participate; there are many folks who have come back consistently -- sometimes over years! -- but still don't edit much by a "heavy Wikipedia editor" standard). -- phoebe / (talk to me) 15:18, 29 October 2016 (UTC)Reply[reply]
    Phoebe, I don't know where I stand on the proposal as a whole, but responding specifically to the edit-a-thon part, don't edit-a-thons get run by WP:Event coordinators, who have the ability to grant their thonees confirmed status? So I'm not too concerned about thon attendees being unable to meet the higher bar for earning the confirmed bit. -- RoySmith (talk) 01:35, 4 November 2020 (UTC)Reply[reply]
  • Oppose the 50-edit requirement primarily because the CAPTCHA-related effect will discourage new editors who cite their sources (while not having a similar deterrence against the ones who fill articles with uncited material). WhatamIdoing (talk) 19:33, 30 October 2016 (UTC)Reply[reply]
  • Oppose per McGeddon. I don't think this will actually make any difference. Vandals don't seem to have any problem making edits in mainspace vs. user space in order to reach auto-confirmed. Raising the limit numbers might be a better idea, but we should also be careful about making legitimate contribution too difficult. Kaldari (talk) 19:41, 4 November 2016 (UTC)Reply[reply]

Wrong focus

We risk driving of a cliff here by not asking what semi-protection and autoconfirmed are for. They are there to prevent excessive vandalism on highly visible pages. They are not there to prevent sock-puppets. In fact raising the bar will only make it marginally more difficult to get a sockpuppet to autoconfirmed, while it will be far more difficult for new editors to get started.

Someone who knows how to accrue edits has no problem getting 10-50 article space edits (without actually improving the encyclopaedia), while someone who is new and wants to correct a simple error will be very much burdened by this before they can edit.

  • Sockpuppeteers in general have many accounts, and there is nothing that stops them from creating new ones, performing pointless main-space edits — and having more at the ready once a prior account is blocked.
  • Legitimate newbies on the other hand will instead be discouraged from contributing. For someone who does not know Wikipedia very well 50 edits may seem impossible. I often meet beginners who think of an edit as writing a whole new article — and the very idea of 50 edits is frightening to them.

Hence, implementing this change will do nothing to discourage sockpuppetry, while discouraging legitimate beginners (of which we have far too few as it is). This change only impacts those who actually follow the rules, not those who don't. Carl Fredrik 💌 📧 22:17, 24 October 2016 (UTC)Reply[reply]

Part of the interface for semi-protecting a page is specifically for sockpuppetry. As someone who has somewhere between 1000-1500 sockpuppet blocks under his belt, I can only say my experiences are different than yours, and I think you see the purpose of semiprotect and autoconfirm in a much more narrow frame of mind than most. You say that most sockpuppeteers have many puppets, but what is this based on? The claim that most have more ready is patently false. The overwhelming majority do NOT have sleeper accounts, and again, this is based on my real world experience as an admin and SPI clerk for a year.
The overwhelming majority of our articles can be edited by anyone on their first edit. Overwhelming. In those cases, this change means nothing to them. You seem to be blowing this up to be a huge problem for new users, when the (again) overwhelming majority will never notice the difference. You are blowing the downside completely out of proportion. Dennis Brown - 22:50, 24 October 2016 (UTC)Reply[reply]
I don't think I'm less adverse to sockpuppets than you are really. However, I think it is extremely important that we do everything we can to avoid discouraging new editors. There are many things that can be done to stop sockpuppetry besides this proposal — many of which have much lower risk of collateral damage. Working harder to block open proxies and VPNs from editing is one thing (not without collateral damage, but arguably far less), being more lenient with IP-blocks for persistant sockpuppeteers, and easing the requirements for initiating a SPI (or at least making it less dependant on the clerk). We really could do a whole lot by easing off on our extreme IP-block-excempt policy for seasoned users, while enforcing stronger policing of editing from known VPNs — editors refrain from reporting proxies/VPNs that work because that would stop them working for them as well. Carl Fredrik 💌 📧 23:03, 24 October 2016 (UTC)Reply[reply]
You say "work harder to block open proxies and VPNs" but that isn't a solution, that is a problem. It's easy to say "we need to work harder". The proposal above solves several issues, and it is a solution. We already have one of the most lax policies on new users. Easing the requirements to file an SPI? All you need is a registered account to file one, couldn't be easier, and it already stays backlogged. You make it sound so easy, but I've worked on proxies, I've worked SPI, it isn't so easy, there is a shortage of tools and manpower, and you can't just "wish it away". This proposal would actually make it easier for reasons I would rather not disclose, but it is also good for combatting many other problems, like hot topic article vandalism and POV editing. Dennis Brown - 23:41, 24 October 2016 (UTC)Reply[reply]
Yes, those are problems, but they are far more central to the issue of sock-puppets than autoconfirmation is. They are also problems which can be solved without massive adverse effects. My experiences of SPI's are not at all like what you describe. While filing one may be trivial, actually having anyone look into it is far from it. I find we are so afraid of potentially looking into a case of a non-sockpuppet that we allow real sockpuppets to go unpunished. The investigations I've taken part in have required so much evidence of wrongdoing that SPI/use of checkuser privileges is essentially pointless, the evidence is so overwhelming that they can be blocked on the spot. This makes any even remotely proficient sock immune to investigation and can go on undeterred. Carl Fredrik 💌 📧 16:14, 26 October 2016 (UTC)Reply[reply]
  • Whilst it's impossible to disagree with CFCF's principles here, I do dispute the conclusions.
  • What is a new gf editor prevented from doing before autoconfirmation?
  • What does a new gf editor have to do to become autoconfirmed?
  • What anti-abuse benefits do we derive from autoconfirmation?
I don't see "highly visible pages" as the problem here. They're widely watched, we will fix vandalism quite effectively. Quality stays high. "Highly abused pages" can be locked down further - we do need to reduce the vandalism cleanup costs on Trump / Obama / Gamergate trollmagnets. Why is it a problem is new editors cannot edit quite so widely ? You learn to drive a car on the back roads, not the motorways. Highly visible pages don't generally offer the low-hanging fruit edits or greenfield topics that are the best place for new editors to practice. If that's discouraging to new editors, then we should address that problem more specifically. After all, it's a positive message - a "countdown timer" for "editing apprenticeship"?
Making a sock work harder has little advantage in further discouraging the sock, but it does leave more space for them to show their distinctive footprint. I see that as useful. Andy Dingley (talk) 10:41, 25 October 2016 (UTC)Reply[reply]
Here's a partial answer to your question: "What is a new gf editor prevented from doing before autoconfirmation?"
  1. They have to enter CAPTCHAs when they add URLs (=sources) to articles. If you want to know how much of a deterrent that is, then you need to look at the stats for edits to the Portuguese Wikipedia, when their aggressive CAPTCHA rules, which required CAPTCHAs for every single edit rather than merely when adding URLs to sources or external links, were removed (December 2014, if memory serves).
  2. They cannot edit semi-protected pages.
  3. They cannot move pages.
  4. They cannot upload files to the English Wikipedia (e.g., logos, album artwork, or book covers). WhatamIdoing (talk) 02:10, 26 October 2016 (UTC)Reply[reply]
Then it's a good thing that no-one is advocating following the Portugese model and requiring CATCHAs for every edit. I'm not seeing the downside to any of these four restrictions. Andy Dingley (talk) 02:15, 26 October 2016 (UTC)Reply[reply]
Frankly, I don't see this as a downside either. New users shouldn't be moving pages to start with. New users that have experience with other wikis can usually get confirmed status in a few hours. Same for uploading files. They can request to have it uploaded. Most often, those requests are copy vios anyway, so it is helpful that we have the chance to educate them early on instead of a copyvio staying in file space until we just happen to catch it. Really, that is a huge plus, not a downside. Dennis Brown - 23:51, 26 October 2016 (UTC)Reply[reply]
Andy, I'm glad that nobody's advocating CAPTCHAs for every edit. But please note that people actually are advocating for having CAPTCHAs for nearly "every edit that cites a source". The effect is to make it much easier for a new editor to add uncited information than for that editor to add material with URLs to reliable sources. Implementing this will discourage people from citing sources.
Dennis, the reason new accounts can't move pages here is because of a problem many years ago with a particular page-move vandal. It's not an inherently bad thing for a new editor to do. WhatamIdoing (talk) 19:29, 30 October 2016 (UTC)Reply[reply]
Any new user who starts by moving pages is probably going to make mistakes, at the very least. I would imagine most moves that could take place within a user's first dozen edits would be problematic, or the user isn't "new". Dennis Brown - 10:00, 2 November 2016 (UTC)Reply[reply]

Does "Part of the interface for semi-protecting a page is specifically for sockpuppetry" in the comment above only supposed to mean "An admin added socking to the list of pre-filled edit summaries back in 2010"? (The entire list is visible in MediaWiki:Protect-dropdown, for the curious, or you can override it by typing your own.) WhatamIdoing (talk) 01:55, 26 October 2016 (UTC)Reply[reply]

What we can't forget is that while the count of articles under semi-protection is low — the count of articles that get substantial readership is also low. And the articles with substantial readership are the ones most likely to be edited, because they are on the most important topics (or at least the most popular). This proposal risks one of two effects:

  • It will make it harder for new editors to edit what they want to edit


  • It will make semi-protecting a page be a bigger deal, hence decreasing the number of pages that are semi-protected and the viability of using semi-protection to ward off vandalism

I don't know of anyone who has looked into it, but I hope people no-one supports this proposal before considering what % of the most popular articles are semi-protected. If we force beginners to edit 50 edits on Pterygia pudica or similarly unread articles before moving onto a single edit on popular articles we may as well ask them to bugger off.
(Yes I will admit to some degree of hyperbole here, but I see a clear trend towards an increase in semi-protection, and on the whole think it is good. This may instead wreck semi-protection entirely.)
Carl Fredrik 💌 📧 16:22, 26 October 2016 (UTC)Reply[reply]

I'm much more concerned about the "it will make it harder for new editors to cite their sources" part of the proposal. WhatamIdoing (talk) 19:29, 30 October 2016 (UTC)Reply[reply]

Request for comment on PC protection

Hello. You are invited to comment on this RfC regarding (1) the streamlining of the pending changes reviewing process and (2) the proposed protection of certain articles with Level 1 Pending Changes protection. Please do not comment here—your support or opposition to the proposals should be indicated in the relevant sections, and general discussion should be occur in the "General discussion" section at the bottom of the RfC page. Thank you. Biblio (talk) Reform project. 21:14, 6 November 2016 (UTC)Reply[reply]

The RfC has snow-closed as oppose. Gestrid (talk) 05:29, 7 November 2016 (UTC)Reply[reply]

2016 Community Wishlist Survey

The submission period for the 2016 Community Wishlist Survey is now live on Meta!

Disclaimer: I'm not from the WMF, and I'm not posting this on behalf of them or anyone.

Gestrid (talk) 07:01, 7 November 2016 (UTC)Reply[reply]

Content translation tool to Draft: space

A proposal for advertising that WP:CXT can be used in Draft: space is under discussion at Wikipedia_talk:Content_translation_tool#Advertise_DRAFT:_use. If you are interested, please join in there. Thank you. — xaosflux Talk 00:28, 9 November 2016 (UTC)Reply[reply]

Add HTML5 autofocus attribute to improve Wikipedia search user experience

Moved to WP:VPT#Add HTML5 autofocus attribute to improve Wikipedia search user experience. --Izno (talk) 14:45, 16 November 2016 (UTC)Reply[reply]

Information about diseases that could be eradicated!

Since a disease that absolutely need humans or human controlled animals to propagate, I propose that on all diseases there should be mentioned if it can propagate outside human control.

I propose this because I think that a big failure is that the richer peoples do not finance eradication of diseases that could be eradicated. The payback period is probably on the order of years, seldom decades if a disease is eradicated. The profit is both from less treatment of sick people AND not having to keep up defence against imported cases. The first target I think should be tuberculosis since the loss in workability is big and long duration because sick people usually survive for a long time. (Since I am making a money proposal I ignore the problem with pain etc.)

I Have been searching for information about which diseases that cant be eradicated since they propagate in the wild (like yellow fewer) but find it difficult to find facts.Seniorsag (talk) 14:34, 16 November 2016 (UTC)Reply[reply]

Disease eradication is certainly a noble cause, but you're pushing into advocacy territory if you are proposing this solely because of that. Keep Wikipedia's purpose in mind.
With that said, by "propogate in the wild" do you refer to the disease as being not endemic to humans? Because even for those, like malaria, there is still hope for eradication by killing the vectors of transmission (mosquitos). So potentially all infectious diseases are eradicable. If you mean "viably" eradicable, then I'm pretty sure the Eradication of infectious diseases articles covers those already.
And with that said, you are welcome to start an article titled, for example, List of eradicable diseases. And I would recommend not making it a complete copy of List of infectious diseases. Brightgalrs (/braɪtˈɡæl.ərˌɛs/)[1] 00:01, 17 November 2016 (UTC)Reply[reply]
Might I suggest that if you do make such a list, that a distinction be made between 1. diseases which are treatable once contracted ; 2. diseases for which a vaccine exists; 3. diseases that have both a cure and a vaccine; and 4. eradicated through other methods (such as Sterile insect technique). This could be made into a table with 3 columns. If you're really gung-ho you could find the cost of the treatment/vaccine, treatment length, the number of vaccine innoculations, method of treatment (oral, parenteral, suppository), etc, etc.Dig Deeper (talk) 02:12, 17 November 2016 (UTC)Reply[reply]
Reservoir species are perhaps what you refer to here. For example the red squirrel is a reservoir species for leprosy. However leprosy has been eradicated in the human population of the British Isles.
Tuberculosis can be caught from unpasteurized cows milk - and is present in badgers, nonetheless it is a very controllable disease, primarily by public health measures.
All the best: Rich Farmbrough, 23:23, 19 November 2016 (UTC).Reply[reply]

Have an explicit (Re-use) link on image thumbnails

Currently, when you have a thumbnail, we are presented with

Example image

To curb problems with the improper re-use of media, I propose we add a small "re-use" link that links to to Commons:Reusing content outside Wikimedia. Or alternatively, we could link to the description (or permission) section of the image (File:Example.svg#Description) or File:Example.svg#Permission (those anchors would need to be created in the commons template however).

See for example (.jpg because I don't know how to make an html mockup of this)


This would be a very small unobtrusive change, and would solve one of the long standing problem concerning the improper attribution of images to "Wikipedia" or to no one at all. Non-thumbnails images would be unaffected, but they are also much less likely to be re-used given their lesser prominence (save in infoboxes). The only non-thumbnailed images likely to be casually re-used would be those from infoboxes, but {{infobox}} could be edited to display a similar "re-use" link when non-thumbnails images are used.

Headbomb {talk / contribs / physics / books} 16:52, 3 November 2016 (UTC)Reply[reply]

Pointless. There are basically two classes of people here:
  • People who understand that image attribution is necessary for reuse, and who know to look for it whenever they want to reuse an image. Those people are not likely to have any problem finding the necessary information, since clicking the image takes them right there.
  • People who absolutely don't give a shit at all, and can't be bothered to give proper attribution.
The first group doesn't need any help, and the second group doesn't care. I don't see who this change is supposed to help at all. Are there really large numbers of users who really want to give proper attribution, but just can't find it? --Jayron32 17:40, 3 November 2016 (UTC)Reply[reply]
  • Strong oppose per Jayron32, Anyone with a shred of sense would click the image and go from there - It's not rocket science!, Don't fix what isn't broken!. –Davey2010Talk 17:59, 3 November 2016 (UTC)Reply[reply]
  • That's the thing. People don't know even know that attribution is required beyond "Image taken from Wikipedia". And that's not just students writing reports, you see this all the time in mainstream and print media. These people want to give credit, but they don't know anything about licenses and terms of reuse because they're not even aware they exist. Even if you click on the image, you don't see that unless you scroll down. Most people will just "right-click > save as" and never even see the terms of reuse. You can't fault people for not following rules they don't even know exists. Will that fix everything? No of course not. But it will greatly curb the problem, especially in high-visibility sources. Headbomb {talk / contribs / physics / books} 22:23, 3 November 2016 (UTC)Reply[reply]
  • Oppose. Thin end of a sucky wedge. Yet another solution in search of a problem. A minority of a minority of a minority of users are interested in re-use. Some proportion of them are too clueless to understand how re-use works. To assist the very small fraction of this infinitesimally small group who might despite their cluelessness grok what the re-use word means and leads to, you intend that every image on every page must sport the "re-use" phrase. I suggest you might want to mock this up more honestly than your example, above, shows. My go-to article for image UI is (I know not why) Winston Churchill. Consider especially the font size of the captions (much larger than your font size) and the number of words used in each caption (many more than your example). Slot a "re-use" into each and every one of them. Obviously it'll completely bollocks up each and every caption. To take one example, the caption "A young Winston Churchill and fiancée Clementine Hozier shortly before their marriage in 1908" will now read "A young Winston Churchill re-use and fiancée Clementine Hozier shortly before their marriage in 1908" or perhaps "A young Winston Churchill and fiancée Clementine Hozier shortly before their marriage in 1908 re-use". It'll detract from each and every caption as the user tries to sythesise their understanding of the caption with this odd "re-use" word. "Re-use" will make absolutely no sense to the vast majority of users. Yours is a proposal for single-issue user-interface vandalism of the first water, which will noticably detract from the aethetics of each and every page on which there are thumbnailed images. Yours has to be one of the single worst proposal I've seen in a very long time on this board. Over my dead body. --Tagishsimon (talk) 23:07, 9 November 2016 (UTC)Reply[reply]
    Over your dead body? Take a chill pill man. Headbomb {talk / contribs / physics / books} 23:45, 9 November 2016 (UTC)Reply[reply]
    Presumably, once they don't have any idea what "re-use" means, they'll be taken to a page that explains it to them, so that if and when they do need to reuse an image for professional or academic purposes, they know how to do so. Free content is one of our five pillars – one of the fundamental principles for the project's existence – and this would spread the word about that pillar. As for font size, this is something that should be implemented directly in the MediaWiki interface, as opposed to adding it into the space for the caption. If Headbomb's mockup is technically possible, I don't think it would clutter much at all, and opposing on the grounds of adding "re-use" in the same font size as the caption strikes me as a straw man. Mz7 (talk) 04:04, 13 November 2016 (UTC)Reply[reply]
  • Oppose: the only way to get a larger-sized reusable version is to click through. It might be a good idea to change the default hover text for that corner icon, though, to mention that it leads to details of attribution and reuse - it currently just says "Enlarge". --McGeddon (talk) 14:14, 4 November 2016 (UTC)Reply[reply]
  • Support – There is, in fact, a third class of people: people who would care, but are not aware that the terms exist. Headbomb's sources show that members of professional media aren't quite sure all the time where to find reuse terms (clicking the image nowadays leads not to the file description page, but to Media Viewer, which abbreviates licensing to an inconspicuous "CC-BY" in the bottom right corner). This addresses that third group of people and gives us an opportunity to educate users about the principle of free content. Mz7 (talk) 15:04, 4 November 2016 (UTC)Reply[reply]
  • Support per Mz7. I've seen plenty of intelligent people make some attempt to provide attribution, but do it incorrectly. The educational and convenience benefits would easily justify the small increase in clutter. Adrian J. Hunter(talkcontribs) 01:04, 5 November 2016 (UTC)Reply[reply]
  • Comment: instead of adding a "reuse" text, we could instead use the Creative Commons and/or copyleft icon, depending on the image's licence. --NaBUru38 (talk) 15:17, 6 November 2016 (UTC)Reply[reply]
  • Support per Mz7. I have met people who seem to think that everything on Wikipedia is free to re-use without attribution, (i.e., in the public domain) and such people would be likely to use this information if they knew it existed. Gluons12 | 20:45, 6 November 2016 (UTC).Reply[reply]
  • Strong support per Mz7. The "third" class of people, who want to do the right thing but are simply unaware of terms, do exist. This should help to educate them. Tony Tan · talk 02:54, 9 November 2016 (UTC)Reply[reply]
  • Support No reason this simple, yet helpful, change should not occur. Many people editing here may think this is not needed, I would suggest otherwise. (Please see KISS.) Many people reading/using WP need to have their hands held through the attribution process, including many editors here. GenQuest "Talk to Me" 23:51, 9 November 2016 (UTC)Reply[reply]
  • Oppose: "Re-use" is not what clicking on the image does; it enlarges the image and shows information that is useful to other ends as well. Furthermore, re-users are expected to be familiar with Wikipedia:Reusing Wikipedia content which explicitly describes what to consider, including where to find license terms. The TOS makes it clear that it's the re-users' obligation to figure out on their own which terms apply and we do not provide legal advice for them. While I'm not suggesting that a "re-use" caption implies such advice, it would almost certainly attract inquiries that mistake it for such an invitation. – Finnusertop (talkcontribs) 01:05, 14 November 2016 (UTC)Reply[reply]
@Finnusertop: I believe that this RFC is proposing the addition of "a small 're-use' link that links to Commons:Reusing content outside Wikimedia," hence clicking on it would lead to the right place. While I agree that it is the re-users' obligation to comply with terms, most re-users are simply not aware of this requirement. The WMF will not prosecute everyone who does not abide, so anything to improve the awareness of and compliance with attribution and other terms would be beneficial. Tony Tan · talk 04:59, 14 November 2016 (UTC)Reply[reply]
I stand corrected with regards to the link target, Tony Tan. Though that is not necessarily good since not all of our images are hosted on Commons, and some of them (not only fair use, but also PD in US only, etc.) cannot be re-used with the same considerations (though the page does mention this in a footnote). I don't agree that anything to improve awareness about this issue is welcome. Something would be, but I don't think this is it. – Finnusertop (talkcontribs) 22:34, 14 November 2016 (UTC)Reply[reply]
  • Oppose: I don't fully understand your proposal. I see a value in helping people who might be interested in more carefully attributing images from Wikipedia (academics, business people, etc). That being said, on the main page of Wikimedia commons it has a box saying
Using? To fulfill the free license requirements, please read our Reuse guide. You can also request a picture.

Which then links to Reusing_content_outside_Wikimedia. So it seems excessive to reinvent the wheel, when an instruction page is readily available for those who need it and will likely search for it and find it. Thanks for your effort. Sorry to burst a bubble.Dig Deeper (talk) 02:00, 17 November 2016 (UTC)Reply[reply]

People don't search for things they don't know exists. I can't recall the last time I even went on the Commons' main page, because there's never any reason to be on it. If you're on Wikipedia, you click on the image, and then you save it. You're never presented with credits, or terms of attribution. And that's how you end up with 'Taken from Wikipedia' in both mainstream and print media, rather than actual compliance with terms of re-use. Headbomb {talk / contribs / physics / books} 08:09, 17 November 2016 (UTC)Reply[reply]
  • Oppose. What's the point of this? If someone is trying to properly re-use the file, they would click on it and see clearly the "sharing" buttons. Getting the higher resolution file still requires the user to go to the media page, then if they truly want to follow the re-use conditions under the license they would use the "use on web" button. Another thing is that the "re-use" link under the thumbnail icon is really small, and is barely visible. —Hexafluoride Ping me if you need help, or post on my talk 21:33, 19 November 2016 (UTC)Reply[reply]
@Hexafluoride: Many clearly don't. See mainstream and print media. Headbomb {talk / contribs / physics / books} 00:47, 20 November 2016 (UTC)Reply[reply]
  • Comment - How about labeling files that are not for re-use? People tend to assume that everything is for re-use; a warning will be more conspicuous then the absence of affirmative signage. DaßWölf 01:32, 20 November 2016 (UTC)Reply[reply]
I suppose that could also be done, but that wouldn't fix the issue of improper attribution. Headbomb {talk / contribs / physics / books} 10:45, 20 November 2016 (UTC)Reply[reply]

Draft Namespace Redirects

There is a clear consensus against deletion of draft namespace redirects. There is a rough consensus against the alternative proposal to delete draft namespace redirects after six months. Cunard (talk) 05:32, 19 December 2016 (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.

Two recent discussions at Wikipedia:Redirects_for_discussion/Log/2016_October_12#Draft:Stephen_V._Cameron and Wikipedia:Redirects_for_discussion/Log/2016_September_9#Draft:Arrow_.28season_2.29 were both closed as keep pending consensus on what ought to be done about Draft namespace redirects from page moves. My proposal is that all such redirects should be deleted, as I feel they are largely unnecessary. Of course, the main argument against this is that article creators might be looking for their article in this space only to find that it had been deleted. Even so, I feel that this concern is unlikely, since most article writers are aware when their article gets moved to the article namespace. Gluons12 | 13:32, 1 November 2016 (UTC)Reply[reply]

Support deletion

  1. Support As proposer. Gluons12 | 13:32, 1 November 2016 (UTC). Retracted for clarity to support 6 month deletion proposal. Gluons12 | 16:58, 9 November 2016 (UTC).Reply[reply]
  2. Support These cross-namespace redirects should be deleted. They cause unwanted links between the article and draft namespaces. Ivanvector notes that an admin doesn't have to leave these unwanted links behind and can delete them under G6 or G7; I am forced to accept his argument that ideally non-admins should not be creating articles, or moving from the draft to the mainspace; but one of the functions draft space is to allow such users to create articles. We should not be forced to create redirects we don't want. Hawkeye7 (talk) 21:56, 3 November 2016 (UTC)Reply[reply]
    I certainly didn't say non-admins shouldn't create articles. That's an absurd argument. Ivanvector (Talk/Edits) 20:43, 9 November 2016 (UTC)Reply[reply]

Oppose deletion

  1. Oppose Redirects are cheap, and while the reason to keep them is pretty minimal (Creators not realizing what happened) I see no reason at all to delete them. Tidying up draft space, at least when it comes to redirects of currently existing articles, does not seem like a useful thing to be doing. Monty845 03:32, 2 November 2016 (UTC)Reply[reply]
  2. Oppose - redirects don't need to be deleted unless there's some pressing need to delete them, like they're misleading, implausibly incorrect, or a BLP violation, as examples. Leaving redirects from page moves in order to aid navigation is one of the primary uses of redirects. Leaving a redirect from a draft article when it's moved to article space is a useful message to the draft's creator that it's been accepted to article space (instead of deleted, as they might otherwise reasonably assume when they load their draft and instead get the "this page has been deleted" message), and a useful message as well to other editors who might come to create a draft on that subject that the article already exists. In the vast majority of cases the draft creator can probably then request G6 or G7 deletion if they so desire. And, of course, redirects are cheap and there's no pressing need to "clean up" draft space. Ivanvector (Talk/Edits) 13:53, 3 November 2016 (UTC)Reply[reply]
  3. Oppose. There are a variety to reasons to keep the redirects. Offsite bookmarks, editors' memories of where a page was, a pointer for a newcomer intending to draft to tell them that the article already exists. The redirect is particularly important if the mainspace title doesn't exactly match the drafting title. For the rest, they may be "unnecessary", but "unnecessary" is a very very low test, far below problematic. Wanting to delete them wholesale generates considerable collateral costs. For each one, an investigation is required to determine whether one of the variety of reasons applies. This is, immediately and obviously, textbook busywork. This means the proposal is for a net negative benefit to the project. No, only delete the redirects if you can articulate a reason to do so. --SmokeyJoe (talk) 21:20, 3 November 2016 (UTC)Reply[reply]
    "They cause unwanted links"? Special:WhatLinksHere sorts the links by namespace, and you can select namespaces, so there is no issue with links from draftspace cluttering your investigations of links, and, it is no different from user and the many talk namespaces that may freely and excessively link to articles. Also, they included wanted links to articles. When working to expand, or consider the possibilities of expansion, one useful thing to do is to examine all incoming links. Each is presumable there for a reason, and helps paint a picture of a history of editor interest in the article. Wholesale deletion of redirects is needlessly destructive of this resource.
    CSD#G7 may be used by sole authors. Non-admins may be forced to create redirects on page moving, but they may have them immediately deleted per CSD#G7. Perhaps some would like to make the option more obvious? I oppose CSD#G6 being used on anything with a non-trivial version history, or on redirects created by others' page moves from either draftspace or userspace to mainspace. Within draftspace, using G6 to delete redirects created from moving a page from a typo-error title would be fine. --SmokeyJoe (talk) 22:56, 3 November 2016 (UTC)Reply[reply]
  4. Oppose. Pointless exercise. Agathoclea (talk) 21:54, 3 November 2016 (UTC)Reply[reply]
  5. Oppose as they are useful and do no harm. Redirects of this nature streamline the process for those returning to the former draft, by taking them directly to where the content now resides, as opposed to adding the extra step of them having to click there through the deletion log.— Godsy (TALKCONT) 05:11, 4 November 2016 (UTC)Reply[reply]
  6. Oppose per the above. Redirects like this are useful, and I can see no real reason to delete them. — Mr. Stradivarius ♪ talk ♪ 07:55, 4 November 2016 (UTC)Reply[reply]
  7. Oppose for reasons above plus WP:DWAP. ⁓ Hello71 12:23, 4 November 2016 (UTC)Reply[reply]
  8. Oppose per above. FWIW I normally create articles in my own userspace before moving them to mainspace when I think they are done, and the redirects left behind are a reminder that they started out there. I have never thought of deleting them, there is no reason to do so, and the same applies to draftspace redirects.--JohnBlackburnewordsdeeds 12:40, 4 November 2016 (UTC)Reply[reply]
  9. Oppose per my comments in the discussion section below. Mz7 (talk) 20:06, 4 November 2016 (UTC)Reply[reply]
  10. Oppose immediate deletion, as we would end up with a lot of new editors wondering where their article went. (Trust me. I volunteer at the Teahouse.) Some may end up just recreating it, leaving more work for administrators. However, I would not be opposed to deleting them a week or two after the page move, similar to the how a successful PROD or a speedy deletion of a file without licensing information works. Gestrid (talk) 04:34, 7 November 2016 (UTC)Reply[reply]
  11. Oppose. Although Main -> Draft redirections create problems, Draft -> Main redirects are perfectly fine, and may be useful to new editors. Tony Tan · talk 02:48, 9 November 2016 (UTC)Reply[reply]
  12. Oppose - No apparent benefit to deleting redirects into mainspace, and obvious drawback. Draft creator or editors of draft may want to look at it and may be satisfied that it has been approved (or may even want to AFD it). Robert McClenon (talk) 00:02, 12 November 2016 (UTC)Reply[reply]
  13. Oppose There is no cost, and preserving the obvious redirect history is a benefit. Steven Walling • talk 19:33, 16 November 2016 (UTC)Reply[reply]
  14. Oppose Also stops people accidentally creating drafts when the article title differs form the draft. All the best: Rich Farmbrough, 15:04, 20 November 2016 (UTC).Reply[reply]
  15. Oppose Deleting a redirect without reason is pointless. Much easier just to point out the problems with individual redirects.--NetworkOP (talk) 22:29, 21 November 2016 (UTC)Reply[reply]
  16. Oppose. As an AfC reviewer, I think the assertion that "most" editors know when their draft is moved to mainspace is underestimating how unintuitive Mediawiki can be for new users. I'd expect a flood of confused new editors at WP:AFC/H if this was implemented. Besides, as others have pointed out, redirects are cheap and no pressing need to delete these has been articulated. Joe Roe (talk) 13:04, 23 November 2016 (UTC)Reply[reply]
  • Oppose  These things exist for a reason.  Being cross-space doesn't change that, and moving them to delete-space only adds to the logs.  Unscintillating (talk) 02:04, 28 November 2016 (UTC)Reply[reply]

Alternative proposal: Delete after six months

Here's my thought process: the draft space isn't meant to be permanent, that's why we have WP:G13 to delete abandoned drafts. I agree that we should keep draftspace redirects for some time, so those who worked on the draft have the bookmark. However, after some time, I don't think that bookmark is necessary. I envision this as an expansion of G13 as it would follow the same logic as G13. A potential exception would be if there are incoming links that would be broken. -- Tavix (talk) 21:55, 5 November 2016 (UTC)Reply[reply]

  • Support as proposer. -- Tavix (talk) 21:55, 5 November 2016 (UTC)Reply[reply]
  • Support. Abandoned drafts are deleted per G13 after six months. It makes sense to apply the same to draft -> main redirects. Tony Tan · talk 02:51, 9 November 2016 (UTC)Reply[reply]
  • Support By same rationale as my original proposal, as this proposal is more specific in the time frame and accomplishes the same end. Gluons12 | 16:59, 9 November 2016 (UTC).Reply[reply]
  • Oppose just as I oppose the WP:G13 criterion entirely. Age is not a qualifier for deletion. Ivanvector (Talk/Edits) 20:44, 9 November 2016 (UTC)Reply[reply]
  • Oppose - There is very little to no benefit in deleting these redirects, while there is no harm and benefit in retaining them. One is more likely to realize there is already an article on a topic they may wish to start a draft about if the redirects are retained. Furthermore, even if all links to the draft were removed, someone may still go to, stumble across, or return to the former title at any time in the future.— Godsy (TALKCONT) 03:34, 11 November 2016 (UTC)Reply[reply]
  • Oppose per Godsy. There is little harm in having these redirects around, and they also have the benefit of informing users that an article already exists about a subject, in case they jumped straight to drafting without first searching for the title. Mz7 (talk) 04:53, 20 November 2016 (UTC)Reply[reply]
  • Oppose same reasons as above. I regret this tendency to want to "tidy up" in cases where the glorious chaos is an exact match for the behaviour of human editors. All the best: Rich Farmbrough, 15:05, 20 November 2016 (UTC).Reply[reply]
  • Oppose there simply is no reason for wholesale deletion at all per the consensus at "version 1" of this proposal, waiting six months (or even six years) makes no difference. Redirects from draft to mainspace do absolutely no harm at all, they are useful for the reasons already explained by others. They are not comparable to links from mainspace to other spaces. Roger (Dodger67) (talk) 16:56, 23 November 2016 (UTC)Reply[reply]
  • Oppose  These things exist for a reason.  Being cross-space doesn't change that, and moving them to delete-space only adds to the logs.  Unscintillating (talk) 02:06, 28 November 2016 (UTC)Reply[reply]


  • Comment - I don't think deleting straight away is good idea if thats being sugested due to the reason given by others that authors may not realise and it acts as a helpful bookmark. However I agree that I don't see why they should be kept indefinetly as they after a while are mostly pointless. I would think deleting x months after they have been redirected would be a good idea. Cheers KylieTastic (talk) 14:46, 1 November 2016 (UTC)Reply[reply]
I second KylieTastic's point: after 6 months perhaps? Rubbish computer (HALP!: I dropped the bass?) 13:45, 3 November 2016 (UTC)Reply[reply]
@KylieTastic and Rubbish computer: I have offered a proposal for six months. -- Tavix (talk) 21:55, 5 November 2016 (UTC)Reply[reply]
  • The counterargument that the proposer brought up—that the page creator might be looking for the article—hasn't really been refuted. Sure, it may be unlikely, but it's a possibility, and redirects are cheap. There's no demonstrated need to delete the redirects. Mz7 (talk) 15:19, 1 November 2016 (UTC)Reply[reply]
    • As all creators should have had a nice big green article acceptance notice (i.e. Template:AfC talk) I would hope creators would not be confused as to what happened to their article. It could be argued that it's a good thing to make them look as I have come accross users editing inapropiately for the mainspace who thought they were still in draft (as people often fail to notice when redirected). However as you said redirects are cheap so I remain neutral as it makes no difference either way. KylieTastic (talk) 19:38, 1 November 2016 (UTC)Reply[reply]
      • Your assumption is invalid. Firstly, your claim that Template:AfC talk "should" be posted only applies to the fraction of drafts that are submitted via AFC (my quick check of 20 pages in draftspace yielded 50% in AFC and 50% not), and secondly, there's no guarantee that it will get used. I've moved a few pages out of draftspace, and I've never used that template. WhatamIdoing (talk) 21:05, 1 November 2016 (UTC)Reply[reply]
  • When a page is moved and afterwards deleted, it leaves a log entry of the deletion but also of the move including the move target, e.g User:Jo-Jo Eumerus/Kari-Kari (caldera). It does not display for non-logged in users, but if the log entry could be made to display it may address the issue mentioned by Mz7. May be a performance issue to search for a log entry for every page view, though. Jo-Jo Eumerus (talk, contributions) 16:03, 1 November 2016 (UTC)Reply[reply]
    That could work. I can see how these redirects aren't strictly speaking "necessary", but I also don't see why it is strictly speaking necessary to spend the time to delete them. Perhaps the existence of a blue draft link might mislead users to think that an article is a draft, but since it would redirect to the article, that doesn't strike me as a huge issue. @Gluons12: Did you mean for this proposal to be retroactively applied to existing draft to mainspace redirects, or did you mean for the proposal to only affect future cases? Mz7 (talk) 20:30, 1 November 2016 (UTC)Reply[reply]
    @Mz7: I meant for it to be retroactively applied, although the problem of how much work this could produce could be difficult to deal with, as there are likely thousands of such redirects. I'm not sure what the technical challenges would be to design a bot to do this, but that would probably be the best course of action if there is consensus to make this change. Gluons12 | 20:37, 1 November 2016 (UTC).Reply[reply]
Hmm. I'm not sure then if it would be worth the effort for administrators and bot writers. WP:CHEAP sums up my thoughts pretty neatly: they might be unnecessary, but if there's no harm in having them, and there is a plausibility that they might be useful, then there's no reason to delete them. If there are concrete examples where the redirects have actually harmed Wikipedia—KylieTastic brought up an interesting one above that I personally haven't seen, but is plausible—then the proposal would be stronger. Personally, when I move drafts from my userspace, I don't mind leaving the redirects behind. In one case, I actually manually created a redirect, User:Mz7/Draft extended confirmed RfC, in order to keep it a blue link at Wikipedia:Village pump (idea lab)/Archive 20#Draft RfC, so that users browsing the archives would know what eventually became of the draft. (Again, I see how that's not strictly speaking "necessary", but I don't know if it's harmful enough to justify the effort of deleting it.) Mz7 (talk) 20:59, 1 November 2016 (UTC)Reply[reply]
  • To clarify, I am not proposing that the redirect be deleted immediately after it is moved to the article namespace. I was thinking that after a period of a week or two, it could be deleted, which would probably be enough time for the writer to realize that the article has been moved in the vast majority of cases. I don't really see the issue with non-logged in users not being able to see the log, because non-logged in users can't create articles in the first place. Gluons12 | 16:28, 1 November 2016 (UTC).Reply[reply]
  • Sorry, I didn't realize that, because I knew that non-logged in users can't create article space articles, I assumed the same was true for draft space. I guess we can disregard that sentence above, so I've struck through it. Even with this in mind, I think that a week or two before deletion would provide plenty of time for these users to realize the change had occurred, so I will stand behind the rest of the argument above, although a few months instead of a few weeks would work just as well, if that is what the consensus is for. Gluons12 | 18:46, 1 November 2016 (UTC).Reply[reply]
  • Comment - When a proposal like this one is offered that has no obvious benefit and an obvious drawback (removing useful navigation for the article creator), I wonder whether the proposer had an idea that has been very poorly stated. Will the proposer please explain what the benefit is? If so, I will change my !vote. Robert McClenon (talk) 00:00, 12 November 2016 (UTC)Reply[reply]

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

UI design flaw with watchlist and alert list

I unwatched Lomography and was told: The page "Lomography" has been removed from your watchlist. I then dropped down my alerts list (the bell icon) and wanted to mark the topmost item as read (by clicking the blue ball, which does this). I could not click the ball because it was still covered by the unwatch message. I also could not find any way to clear/remove the unwatch message without reloading the page: clicking it, or outside it, or pressing Esc, does nothing. Equinox 07:14, 26 November 2016 (UTC)Reply[reply]

Van Halen's Running With The Devil

I know I hear it in the background but have never heard or found any information about the background wording that David Lee Roth is saying in verse 2 and the break of Eddie's first solo. He says, and I quote, "Down with the Navy and all you lifers too, I'm only going to tell you one time" ooh ya

Anyone else hear this and if so have any background information about it. I don't see where David ever served in the Navy but it would make a great story if he was and for some reason was kicked out of the Navy for being a radical 1970's kid.-----Dave

According to This (not a reliable source), the line is actually "Goddamn it lady, you know I ain't lyin' too ya, I'm gonna tell you one time." This also broadly agrees, with a slight variation (baby, instead of lady) Other websites confirm your version is a clear Mondegreen; the original lyric said nothing about the Navy, that's a common misinterpretation. --Jayron32 17:15, 1 December 2016 (UTC)Reply[reply]

Access locks: Visual Design RFC

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
Breaking it down by section: On the colors, consensus for Green-Blue-Red (GBR) is narrow, but backed by display and color-blindness accessibility issues noted below. On the "free with conditions" shackle, there is a clear preference for 100% dotted. On the body, there is a preference for the Dotted-Half-Full scheme. (non-admin closure) Eggishorn (talk) (contrib)

This is an RFC to decide on the visual appearance of the access locks of citation templates. Headbomb {talk / contribs / physics / books} 15:50, 29 October 2016 (UTC)Reply[reply]

What the Visual Design RFC is about

Hi all,

Over the past few months, a bunch of us have been working (see announcement) on designing so called "access locks" for the citation templates (see Help:CS1/Help:CS2) and for the various identifier templates (such as {{arxiv}}, {{bibcode}}, {{doi}}, etc.). See the upcoming Signpost article on the topic for details, both technical and non-technical. Some of you may have noticed the green lock in citations such as

  • Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD". Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234. doi:10.1007/JHEP03(2010)094.

which has been rolled out at the end of July of this year.

We are currently at an impasse in terms of the final design and behaviour of the locks. To make things simpler, let's keep this RFC purely about the visual design. A second RFC about the behaviour and technical implementation of the locks will follow this one.

A few considerations for accessibility need to be taken into account

  • Any colour has to contrast at least 4.5:1 vs both black and white backgrounds.
  • The visual design of each lock needs to be clear and distinct at a small size
  • The visual design of each lock should convey "always free to read" "free, subject to some conditions" and "not free"

The current set of locks is

but it is unsatisfactory for a few reasons, namely the non-colour changes are only done in the shackle. Many other versions of the locks have been proposed:

Many combinations exist, but in the interest of having the greatest possible distinction between the locks, the following combinations will have 3 visual changes per level of access: Different colour, different lock body, different shackle.

In the interest of structuring the possibilities,

With that in mind, please indicate your preference for which design you prefer below. Due to the great deal of aspects we need to cover, let's vote on each aspect separately. Headbomb {talk / contribs / physics / books} 15:30, 29 October 2016 (UTC)Reply[reply]

Visual Design RFC !Vote

Please indicate your preference for each aspect of the design below.

Aspect A1) Colour: Green–Yellow–Red (GYR) vs Green–Blue–Red (GBR)

  /   /     /   /  
  /   /     /   /  

Keep in mind the shackles and bodies could differ depending on Choices A2 and A3.

  1. Mild preference for yellow over blue While I prefer GYR myself as a more intuitive scheme, I've asked a few red-green colorblind people and they all agreed RBG was clearer. They could tell the middle lock apart much more easily, and the shapes of the Red vs Green locks were they felt distinct enough they could tell them apart easily. Headbomb {talk / contribs / physics / books} 00:08, 30 October 2016 (UTC)Reply[reply]
  2. Mild preference for yellow over blue, because streetlights, but nbd.   ~ Tom.Reding (talkdgaf)  14:33, 30 October 2016 (UTC)Reply[reply]
  3. GBR Seems much clearer, visually. Yellow is a better intermediate color between red and green connoting access level but blue stands out so much better. Chris Troutman (talk) 19:58, 30 October 2016 (UTC)Reply[reply]
  4. GBR: Pastel blue is more soothing than dark yellow, which is important especially if many sources are to have these symbols. Esquivalience (talk) 23:45, 30 October 2016 (UTC)Reply[reply]
  5. GBR On my monitor the yellow doesn't look yellow, but seems like a muddy brown; it therefore lacks an intuitive connection with a yellow streetlight. For that reason I'd go with blue. --SteveMcCluskey (talk) 12:53, 31 October 2016 (UTC)Reply[reply]
  6. GBR per Headbomb's research with red-green colorblind people. Also like Steve above I get more of a muddy brown than yellow.  — Scott talk 21:03, 31 October 2016 (UTC)Reply[reply]
  7. GBR per Steve. --Izno (talk) 11:26, 1 November 2016 (UTC)Reply[reply]
  8. GYR. GBR looks nice, but it doesn't send me the yellow-caution-signal. Perhaps if the yellow contrast against black was heightened, this option would get more support. ~nmaia d 15:47, 4 November 2016 (UTC)Reply[reply]
    If you increase the contrast against black, you'll decrease the contrast against white. This shade is balanced on both black and white backgrounds. Sadly, this is the yellowest yellow we can make while meeting contrast guidelines. Headbomb {talk / contribs / physics / books} 22:30, 4 November 2016 (UTC)Reply[reply]
  9. GYR. Blue indicates existing links. 4nn1l2 (talk) 16:57, 6 November 2016 (UTC)Reply[reply]
  10. GBR per Scott's rationale (colorblindness and muddy brown effect). Tony Tan · talk 00:54, 9 November 2016 (UTC)Reply[reply]
  11. GYR per above. Also could the yellow be made brighter so it looks more like yellow and less like brown? --TerraCodes (talk to me) 20:52, 12 November 2016 (UTC)Reply[reply]
  12. GYR per nmaia. Perhaps we could add more red to the yellow lock to make it stand out better. I don't like GBR because it produces the wrong association; if anything I'd much rather keep this yellow-green as registration-only and put blue for open access. DaßWölf 23:57, 13 November 2016 (UTC)Reply[reply]
  13. GBR. Blue is easier to differentiate against the other colors. NinjaRobotPirate (talk) 07:49, 16 November 2016 (UTC)Reply[reply]
  14. GBR. I'm not color blind and I had to adjust my monitor to properly distinguish between the green and yellow beyond shape. Ian.thomson (talk) 08:03, 16 November 2016 (UTC)Reply[reply]
  15. GYR. Blue doesn't mean anything in a "traffic light" contest. WaggersTALK 12:57, 18 November 2016 (UTC)Reply[reply]
  16. GYR, as there's no way to intuit if green or blue is "freer". (Addendum: I'd support the unlisted option BGR, which avoids the yellow that seems unpopular but also allows the natural color spectrum do its thing rather than trying awkwardly to force blue into the the place of yellow. 03:31, 26 November 2016 (UTC)) —jameslucas (" " / +) 03:24, 24 November 2016 (UTC)Reply[reply]
  17. GBR Were it possible to have yellow that is yellow and not some bilious color reminiscent of the content of a bay's diaper, then perhaps, I would choose that yellow. As that is not possible given the white/black background contrast requirements, I must choose the blue option. Were the question phrased to allow !voters to suggest alternate schemes here, I would choose a scheme where the icons are all of the same color and so avoid perhaps inappropriate 'traffic' semaphore color conventions: GO here; proceed to this link with caution; STOP! don't read this link. The purpose of the icon is to simply indicate that a source is free-to-read or, partially- or fully-restricted. Color is not really required to do that so long as the chosen color meets the contrast requirements and the shapes are sufficiently distinct.—Trappist the monk (talk) 15:46, 24 November 2016 (UTC)Reply[reply]
  18. GBR It's unfortunate that yellow wouldn't show up well –– the muddy color presented is no more intuitive than blue. The blue seems clearly visible. DIY Editor (talk) 03:44, 25 November 2016 (UTC)Reply[reply]
  19. GYR. From my staff account as head of The Wikipedia Library: I feel pretty strongly that blue isn't the right call here, precisely because it stands out too much. Blue is the 'default' color for all links on the internet, so using it here suggests that it is most common, best, most open, or simply most noticeable. A more intuitive scheme is using Green-Yellow-Red, where yellow does not overly stand out and where it for many connotes an in-between state, as in a traffic light. I do think we should use a different tone/shade of yellow since this one does look muddy, but I prefer it to the consequences of blue, and for registration-required, muddy is at least kind of consistent with the status. Ocaasi (WMF) (talk) 18:56, 29 November 2016 (UTC)Reply[reply]
  20. GYR – This particular shade of yellow is close to green, so gives a natural association with the desired message "free, with limitations", whereas blue has two disadvantages: it is the default link color, so might be considered the most natural option, and it has stronger contrast, making it more attractive to the eye whereas the green and red options should be more clear-cut. — JFG talk 21:26, 3 December 2016 (UTC)Reply[reply]
  21. GBR but I would actually prefer BBB (blue everywhere) because red and green stick out too much from the page. The information they convey is not more important than the rest of the article. − Pintoch (talk) 22:18, 3 December 2016 (UTC)Reply[reply]
  22. GBR for those who are colorblind also for more aesthetically pleasing in my mind. Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 20:00, 10 December 2016 (UTC)Reply[reply]

Aspect A2) 'Free with Conditions' Shackle: 100% dashed vs 50% dashed vs 25% dashed

  (100%) vs   (50%) vs   (25%)
or, depending on Choice A1
  (100%) vs   (50%) vs   (25%)
Keep in mind the bodies could differ depending on Choice A3.

  1. 50% > 25% > 100%. Although 100% dashed is the biggest difference, it looks pretty bad when printed. 50% is a good compromise, and it's, I feel, a cleaner design since it matches the body of the DHF/EHF options below, which I favour. 100% dashed is better for the EDF bodies, however.Headbomb {talk / contribs / physics / books} 00:08, 30 October 2016 (UTC)Reply[reply]
  2. 50% > 25% > 100% 25% > 50% > 100% if printing is both a strong determining factor and 100% looks bad on a lot of printers. If either of those are false, then 100% > 50% > 25% 100% > 25% > 50%.   ~ Tom.Reding (talkdgaf)  14:33, 30 October 2016 (UTC)Reply[reply]
  3. 100% > 25% > 50%. 50 looks most-like a fully closed shackle, oddly enough, and for some reason 25 is marginally better. I'm less concerned about the printworthiness of these icons and in fact might suggest they aren't printed, ever. They serve no use in print form IMO. --Izno (talk) 12:01, 1 November 2016 (UTC)Reply[reply]
    Use in print would be marginal, but to say they wouldn't be used at all, I don't buy that. People print Wikipedia articles all the time. I agree that online clarity is more important, however. Headbomb {talk / contribs / physics / books} 12:04, 1 November 2016 (UTC)Reply[reply]
    Er, my failing at English: aren'tshouldn't be would be more correct. --Izno (talk) 12:07, 1 November 2016 (UTC)Reply[reply]
  4. 100% > 25% > 50%. Per Izno; also at 9x I can't make out the dashes in 25% and 50%. ~nmaia d 15:47, 4 November 2016 (UTC)Reply[reply]
  5. 100% > 25% > 50%. Per Izno. 4nn1l2 (talk) 17:02, 6 November 2016 (UTC)Reply[reply]
  6. 100% > 25% > 50% per Izno. However, I am concerned about the potential for 100% to look bad when printed. Nonetheless, 50% looks like a fully closed shackle. Tony Tan · talk 01:00, 9 November 2016 (UTC)Reply[reply]
  7. 50% > 25% > 100% 100% doesn't look like a lock to me, and 25% looks to much like unlocked. --TerraCodes (talk to me) 20:52, 12 November 2016 (UTC)Reply[reply]
  8. 100% > 25% > 50%. From my normal viewing distance 50% looks closed and 25% is just about discernible. Agree with Izno that we should make sure they look good on the screen, where they're most useful. If they look good in print that's just an added bonus. DaßWölf 00:04, 14 November 2016 (UTC)Reply[reply]
  9. 100% is the easiest to differentiate. I have some trouble differentiating between 25%, 50%, and a closed shackle, but most people probably have better eyesight than me. NinjaRobotPirate (talk) 08:06, 16 November 2016 (UTC)Reply[reply]
  10. 100% > 50% > 25%. From my normal viewing distance, 25% looks like a smudged version of the open lock. Looks like 100% has it, though: a wholly dashed lock is clearer than a partially dashed one. Ian.thomson (talk) 08:09, 16 November 2016 (UTC)Reply[reply]
  11. 50% > 100%. I agree with the others that 25% is too hard to differentiate. WaggersTALK 12:59, 18 November 2016 (UTC)Reply[reply]
  12. 50% The dashed portion of any of these options, especially at these sizes, 'grays' that section by emulating the halftone printing process. At larger scales, the dashed shackles appear dashed so the meaning is rather more clear. If any meaning is to be extracted from a dashed shackle at the 9px width, there must be enough visible distinction between the 'gray' and the solid so that the eye can detect it at a glance. The best chance for that is with the 50% version.—Trappist the monk (talk) 16:24, 24 November 2016 (UTC)Reply[reply]
  13. 100% seems the clearest to me. DIY Editor (talk) 03:42, 25 November 2016 (UTC)Reply[reply]
  14. 50% > 100% > 25% From my staff account: 50% is clearly a lock and clearly in some in-between state of openness. After that I think 100%% is reasonably ok, but 25% doesn't work for me.
  15. 25% or 50%, definitely not 100% which is too fuzzy and loses the "solid metal" connotation. — JFG talk 21:26, 3 December 2016 (UTC)Reply[reply]
  16. 100% is best. I can't differentiate between 25% and 50% so I won't comment on which I prefer. Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 20:03, 10 December 2016 (UTC)Reply[reply]

Aspect A3) Body: Dotted–Half–Full (DHF) vs Empty–Half–Full (EHF) vs Empty–Dotted–Full (EDF)

  /   /   (DHF) vs   /   /   (EHF) vs   /   /   (EDF)
or, depending on Choice A1
  /   /   (DHF) vs   /   /   (EHF) vs   /   /   (EDF)
Keep in mind the shackles could differ depending on Choice A2.

  1. DHF > EHF > EDF. The empty green lock can be confused with a stylized lowercase a, especially when printed or when viewed in black and white.Headbomb {talk / contribs / physics / books} 22:49, 10 October 2016 (UTC)Reply[reply]
  2. DHF: This is the clearest visual representation imo. ‑‑YodinT 09:04, 30 October 2016 (UTC)Reply[reply]
  3. EDF >> DHF > EHF.   ~ Tom.Reding (talkdgaf)  14:33, 30 October 2016 (UTC)Reply[reply]
  4. DHF > EHF > EDF Chris Troutman (talk) 20:02, 30 October 2016 (UTC)Reply[reply]
  5. Prefer the empty green lock and have a slight preference for the half-filled middle lock, so EHF > EDF > DHF. Per my comments above, I don't think the print case is large enough such that it should influence our decision making in these regards. --Izno (talk) 12:13, 1 November 2016 (UTC)Reply[reply]
  6. Keep the current style. The full red icon looks like a purse, not a lock. How come there's no option to keep the current style? Kaldari (talk) 02:39, 3 November 2016 (UTC)Reply[reply]
    @Headbomb: Is there going to be another vote to decide whether or not the current icons should be replaced with the winner of this vote? Kaldari (talk) 19:30, 4 November 2016 (UTC)Reply[reply]
    Why would there be a 2nd vote? That's the whole purpose of this one. As for why keeping the current lock isn't an option, it's because the only non-colour changes in the locks are in the shackles. Having the body change as well makes the icons much more visually distinct for those with impaired colour vision (or when you print things in black and white).Headbomb {talk / contribs / physics / books} 19:52, 4 November 2016 (UTC)Reply[reply]
    @Headbomb: I'm sorry, but I don't really see what the point is. The difference between the locks is clear from the color difference. Personally, I don't think even the shackle changes are necessary. Was there a previous discussion where it was decided that the icons themselves needed to be substantially different? Kaldari (talk) 08:18, 7 November 2016 (UTC)Reply[reply]
    Imagine you're colorblind for a second here. Or that you're printing things in black and white. Additional reasons are outlined in WP:COLOUR. Headbomb {talk / contribs / physics / books} 13:03, 7 November 2016 (UTC)Reply[reply]
    @Headbomb: So the solution is to make the icons confusing to everyone (rather than just the 1% of people who are red-green color blind)? First of all, no one is going to know what the blue icons signify regardless (especially now that they have no resemblance to a lock whatsoever). We should get rid of them completely. If we do that, it's pretty clear what the open shackle and closed shackle represent. How are those confusing to anyone? Kaldari (talk) 03:02, 16 November 2016 (UTC)Reply[reply]
  7. DHF > EHF > EDF. DHF looks more like a lock icon to me. ~nmaia d 15:47, 4 November 2016 (UTC)Reply[reply]
  8. EDF > EHF > DHF empty for free; semi-empty for semi-free; and full for non-free. 4nn1l2 (talk) 17:08, 6 November 2016 (UTC)Reply[reply]
  9. DHF > EHF > EDF. Although 4nn1l2's rationale for EDF > EHF > DHF makes intuitive sense, the empty green lock looks like a stylized lowercase a when viewed without color. Tony Tan · talk 01:10, 9 November 2016 (UTC)Reply[reply]
  10. DHF per Yodin. --TerraCodes (talk to me) 20:52, 12 November 2016 (UTC)Reply[reply]
  11. DHF looks best to me. The others are a bit confusing between of the stylized-A problem. If the open lock could be made to look less like a stylized A, I probably wouldn't have any preference. NinjaRobotPirate (talk) 08:14, 16 November 2016 (UTC)Reply[reply]
  12. EDF > EHF. To my eyes DHF is just odd, a mishmash of filling from the centre and filling from one side. EDF and EHF are consistent in design approach; filling from the centre isn't side-ist and I find it more pleasing to look at. WaggersTALK 13:03, 18 November 2016 (UTC)Reply[reply]
  13. DHF as per Headbomb (#1). —jameslucas (" " / +) 03:26, 24 November 2016 (UTC)Reply[reply]
  14. DHF The dotted lock body reflects its Open Access heritage (the dotted green lock is the orange OA lock except that the green uses narrower line widths and has a slightly more open shackle). That may or may not be a good thing because these icons are not intended to indicate readability in the open access free-to-reuse sense. However, even though I know that the empty-lock-body icon is the same size as dotted, the openness makes it look larger. For that reason, dotted is best. For the registration and subscription lock, half is best because, well, that's my contribution to this mess.—Trappist the monk (talk) 16:36, 24 November 2016 (UTC)Reply[reply]
  15. DHF seems the most clear. DIY Editor (talk) 03:40, 25 November 2016 (UTC)Reply[reply]
  16. DHF From my staff account: DHF is best because each one is clearly a lock of some sort and yet they are unique and distinct from eachother. E-first risks the green icon not looking like a lock but just some kind of weird letter. Ocaasi (WMF) (talk) 18:56, 29 November 2016 (UTC)Reply[reply]
  17. DHF gives the most differentiation between the three possible states. Also would approve a DHD option per Kaldari's comment. — JFG talk 21:26, 3 December 2016 (UTC)Reply[reply]
  18. no filled red lock Like others above, I think a full red lock is not very helpful. It has a very negative connotation, feels aggressive, and as someone above said, looks kinda like a purse. I think an empty, half, dot scheme would be a good solution, but would also support a DHD like Kaldari and JFG have suggested. Wugapodes [thɔk] [ˈkan.ˌʧɻɪbz] 20:06, 10 December 2016 (UTC)Reply[reply]

Aspect A4) Just don't do it

We have the "subscription required" template, and lock icons already have a meaning on Wikipedia. KATMAKROFAN (talk) 02:32, 2 November 2016 (UTC)Reply[reply]

The subscription required template is ambiguous, and our icons differ well enough from page protection that they could not possibly be misconstrued for that. Headbomb {talk / contribs / physics / books} 16:20, 2 November 2016 (UTC)Reply[reply]
  • I have to agree. Icons are bad, colour coding is bad. Even though I just read the proposal I have already forgotten what the "middle one" (blue/yellow) means. Use your words. All the best: Rich Farmbrough, 22:58, 19 November 2016 (UTC).Reply[reply]

Visual Design RFC discussion

like this

How will the meaning of the indicators be discovered by readers? Will there be a legend incorporated into the references section? isaacl (talk) 16:01, 29 October 2016 (UTC)Reply[reply]

You can always hover the icons with your mouse, but the point should be clear enough from the icons alone. However, {{reflist}} could certainly be modified to include a legend as well.Headbomb {talk / contribs / physics / books} 16:19, 29 October 2016 (UTC)Reply[reply]
Depending on hovering is problematic for those who have difficulty with fine motor control, plus it isn't necessarily obvious to even those who have the ability to hover. In accordance with Wikipedia's guidance on the use of colour, it's desirable to have a legend to identify the meaning of each symbol. isaacl (talk) 21:26, 29 October 2016 (UTC)Reply[reply]
Plus, hovering is not an option on mobile. But in this case, it's easily replaced with a hyperlink. Clicking on the symbol should lead to an explanation page with the legend. Diego (talk) 10:04, 5 November 2016 (UTC)Reply[reply]
Requiring a reader to navigate to another page to find out what an icon means isn't really in keeping with the spirit of discoverability, though. Keeping the legend on the same page is in line with what is done for any table legend in an article. isaacl (talk) 21:58, 5 November 2016 (UTC)Reply[reply]
I agree that there should be some type of legend on the same page for readers. Otherwise the icons may be ignored or misunderstood. Tony Tan · talk 01:12, 9 November 2016 (UTC)Reply[reply]

The standard open access icon is orange, not green. So the locked icon should be black. Also, the open lock should be very open, some of the icons don't look like. --NaBUru38 (talk) 16:06, 29 October 2016 (UTC)Reply[reply]

The PLOS orange icon is actually for free to re-use, and certainly not universally adopted. If you have an alternate color scheme, you can certainly propose it, but the scheme should be able to convey "Always free/Free with condition/paywalled". Headbomb {talk / contribs / physics / books} 16:19, 29 October 2016 (UTC)Reply[reply]

The example to the right is much less ambiguous, and someone universal to mean "unlocked". Dennis Brown - 16:14, 29 October 2016 (UTC)Reply[reply]

Maybe so, but it's not an icon, and would take a much more of horizontal space. Headbomb {talk / contribs / physics / books} 16:19, 29 October 2016 (UTC)Reply[reply]
I guess it boils down to priorities: a small amount of extra space or being easy to understand. If the goal is to convey information, it seems logical to use the extra space if it removes all doubt as to intent. Dennis Brown - 16:35, 29 October 2016 (UTC)Reply[reply]
I'm also against using a picture like this in citation templates: see the discussion in the Behaviour section for typical use scenarios – it's going to be useful for people who are already aware that a link may or may not be behind a paywall, and want to know in advance which of the links is best for them to use – the padlock pic doesn't help for this, while coloured icons make it much easier. ‑‑YodinT 09:11, 30 October 2016 (UTC)Reply[reply]

I'd prefer to have no graphic icons at all for this- they're a pain to read on a mobile device, and unnecessary. Hchc2009 (talk) 17:42, 29 October 2016 (UTC)Reply[reply]

I would prefer if we could use the default orange OA icon for open, black/gray for those that require registration, and red for closed.

The default OA icon.
What we currently use at {{Closed access}}.

The default orange icon has been cemented pretty well in the collective consciousness of scientists as far as I'm concerned. Celebrations of Open Access Week (24th to 30th October, so right now) proudly displayed the orange logo at my university, and probably at far more places as well – so I think it's a bad idea to use something else. In fact we use the orange icon already at {{OA}}.

However I can only applaud the initiative (and vehemently oppose using a larger or wider "open lock" as the one given in the example.) Carl Fredrik 💌 📧 17:51, 29 October 2016 (UTC)Reply[reply]

Same comment as above, the idea of not including the original lock was that purists consider it should only be applied to sources that are free to reuse (so, appropriately licensed). But yeah I agree the orange one is better known. Personally I am happy with any colour, really. (But it should be an icon, not like the big lock image above.) − Pintoch (talk) 22:22, 29 October 2016 (UTC)Reply[reply]
AIUI, the "default orange" means libre (=you can copy and re-use this source), not gratis (=you can read this source without paying $40). What we're trying to signal here is gratis. I think we would do the libre community a disservice by trying to teach our millions of readers that the orange padlock that originated in the libre community means "free as in beer". WhatamIdoing (talk) 04:19, 30 October 2016 (UTC)Reply[reply]
It's a fair point, and OA is great project, but as pointed out above, keeping our icon colours separate is a good thing, as it doesn't muddy the waters – we're only concerned with whether the article can be read freely (gratis), not if it has an open license (libre). ‑‑YodinT 09:15, 30 October 2016 (UTC)Reply[reply]
Hmm, in one sense I agree. The green icon is far more clear in that it shows something positive than the orange one. However, we need to keep in mind that we can have a very large impact, especially if this goes live on nearly all our articles. The situation is further complicated by the fact that we talk about "gold open access", "silver open access" etc., and now all of a sudden we are launching three new colours? I don't have any clear solution, but I think we should consider the OA-movement at large before we implement anything. Carl Fredrik 💌 📧 09:28, 30 October 2016 (UTC)Reply[reply]

There are many citation style conventions much less intuitive than any of these icons, i.e. volume # and issue #, yet we use them. I fail to see how any of these icon combinations are less intuitive than these; if anything, they are more. An intuitive icon design, plus hover text, plus a description in every CS1/doc will be enough to satisfy the vast majority of, if not all, readers.   ~ Tom.Reding (talkdgaf)  14:21, 30 October 2016 (UTC)Reply[reply]

This vote is a mess. After two minutes I couldn't figure out where or how to vote. Seems like a nice project, sadly, the vote is very much designed by engineers too :( For what it's worth, I favor DGBR. --Piotr Konieczny aka Prokonsul Piotrus| reply here 03:33, 31 October 2016 (UTC)Reply[reply]

@Piotrus: You vote in each of the vote's subsection (A1/A2/A3, and B1/B2/B3/B4). Headbomb {talk / contribs / physics / books} 10:25, 31 October 2016 (UTC)Reply[reply]
Thanks, but it is too much trouble. I am sorry to say but the designers of the vote overcomplicated it to the extent that, well, we are seeing almost nobody bothering to vote. Through I think we still have community support for... something. With such a bad vote, I am not sure for what, unfortunately. I strongly suggest you restart the vote in a simplified way. Use this one to narrow the choices to 2-3 max. --Piotr Konieczny aka Prokonsul Piotrus| reply here 02:25, 1 November 2016 (UTC)Reply[reply]
@Piotrus: It's three simple choices. Color, shackle, body style. Headbomb {talk / contribs / physics / books} 03:19, 1 November 2016 (UTC)Reply[reply]

Oppose all current suggestions. Sorry but all the above seem to be based on or inspired by the open access logo,  . This is unfortunate as this has a very specific meaning (free to re-use) that is distinct from what we're trying to convey here (free to access). The distinction already causes confusion among Wikipedians and the general public, and I don't want us to make it worse. Icons like   and   are especially problematic, as readers might infer they indicate sources that are "more free" than  . Instead, I suggest using icons that are visually very distinct from  . Perhaps a solid red padlock with a square or rectangular base for not free to access, and the same in green but with the shackle pointing to the right for free to access. So icons along the lines of   and  , but smaller and monocolour. Adrian J. Hunter(talkcontribs) 03:43, 31 October 2016 (UTC)Reply[reply]

  • The use of colors suggest a potential accessibility issue. See the guidelines at WP:COLOR. Praemonitus (talk) 16:04, 31 October 2016 (UTC)Reply[reply]
    That's already been taken into account in the current options. The shapes differ, and the contrast is 4.5:1 on both black and white backgrounds. Headbomb {talk / contribs / physics / books} 17:08, 31 October 2016 (UTC)Reply[reply]
  • Although I agree that the current design may obfuscate the two levels of Open Access, I think that the distinction (OA gratis vs. OA libre) is irrelevant for verification purposes. For the latter, free access is important; freedom to re-use is immaterial. (talk) 19:47, 31 October 2016 (UTC)Reply[reply]
    Well, no one has proposed square bodies, but there's nothing saying those couldn't be used. Would likely need to be Empty / Half / Full bodies, since a 'dotted body' wouldn't make any sense. However, square bodies would likely lead to confusion with secure vs non-secure urls. Headbomb {talk / contribs / physics / books} 22:36, 4 November 2016 (UTC)Reply[reply]
  • I believe that Adrian has a legitimate concern here, though I cannot suggest a better alternative myself. Like Headbomb said, a square body could lead to confusion with https security, which would be undesirable. Tony Tan · talk 01:21, 9 November 2016 (UTC)Reply[reply]

Suggestion: use emojis as fallback. I'm not sure if this is feasible, but it could be interesting to use the emojis 🔓 — 🔐 — 🔒 in cases where images can't be displayed, as a fallback mechanism. What do you think? ~nmaia d 15:59, 4 November 2016 (UTC)Reply[reply]

  • Avoid red. Red indicates a problem that needs to be addressed, or something that is invalid. Closed access is surely not good, but it is not something that can be addressed in reading the article. The standard OA icon was designed to highlight that at least some material was available OA--and was designed when very little material was actually OA, & was meant to be conspicuous for the purpose of advocacy. We could make a case for using it, because it is still the standard. There's no point is designing our own visual language when there is already an accepted version--we might as well abandon the English WP for Esperanto. DGG ( talk ) 18:04, 7 November 2016 (UTC)Reply[reply]

Withdraw both RFCs. This is way too complicated, and some (non-mutually exclusive) proposed options conflict with each other. For complex proposals such as this I believe the mandate to go either way should be far clearer; but because of this complexity, a fair-to-middling "support" consensus is worth less than a poor-to-fair "oppose" consensus. The onus is on the supporters. Show better cause, and renominate. (talk) 19:52, 7 November 2016 (UTC)Reply[reply]

I've thought about our color schemes and went back to the design board. I figured a lot of objection is that RED is too-in-your face, and that yellow is not yellow enough. So I think may we ought to consider a Green/Gray/Black scheme like (  /   /  ). Headbomb {talk / contribs / physics / books} 17:54, 25 November 2016 (UTC)Reply[reply]

That fails the black background requirement.
Trappist the monk (talk) 17:56, 25 November 2016 (UTC)Reply[reply]
It sadly does, yes. Trying to wonder what's possible along that vein. Headbomb {talk / contribs / physics / books} 17:58, 25 November 2016 (UTC)Reply[reply]
@Trappist the monk:   /   /   maybe? I think I'll try a two-tone (grey/green) middle lock. Headbomb {talk / contribs / physics / books} 18:08, 25 November 2016 (UTC)Reply[reply]
Got it, I think   /   /  . We could also consider schemes like   /   /  . I really like that last one. Headbomb {talk / contribs / physics / books} 18:15, 25 November 2016 (UTC)Reply[reply]
From my staff account: Of the 3 you just suggested I like 1 and 3, but not 2 (mixed color is confusing). These are solid choices you added! Ocaasi (WMF) (talk) 18:56, 29 November 2016 (UTC)Reply[reply]

I think Trappist's all-blue proposal (where all locks are of the same colour, the same as the external link icon) would be very nice (much more neutral). − Pintoch (talk) 18:26, 25 November 2016 (UTC)Reply[reply]

Disagree there. We'd lose the clearest distinction between the locks available to most people, and they'd get buried in the sea of blue. Headbomb {talk / contribs / physics / books} 18:29, 25 November 2016 (UTC)Reply[reply]
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Access Locks: Citation Template Behaviour RFC

The following discussion is an archived record of a request for comment. Please do not modify it. No further edits should be made to this discussion. A summary of the conclusions reached follows.
This is somewhat complex due to the nature of the RfC, so I'm breaking this down into sections:
  • Aspect B1 (Allowability of the lock icons): There is a narrow preference for Allowing all locks. There are good strong arguments against this, but weighing WP:IAR and WP:EDIT in the balance suggests that the editorial discretion of individual Wikipedians should be allowed and supported.
  • Aspect B2 (Automatic flagging of non-free sources): There is no consensus for automatic flagging.
  • Aspect B3 (Deprecating/eliminating/supporting old and new systems): There is a clear preference to Deprecate the old system.
  • Aspect B4 (Autolinking titles with free identifiers): There is no consensus for autolinking identifiers.
There is,however, a greater issue: A significant body of opinion has been expressed below that the entire visual status indicator idea is not acceptable. The above assessment must be interpreted in light of this. I would urge that this close is treated as a tentative indication of how the Citation Template processing would work in a new RfC to see if there is significant buy-in to proceed forward. To move forward with the shaky consensus established below would not comport with WP:CONS. Overall, there is not yet significant consensus on implementation of these citation template behaviors. (non-admin closure) Eggishorn (talk) (contrib) 02:42, 10 February 2017 (UTC)Reply[reply]

This is an RFC to decide on the behaviour of citation templates concerning when/how to deal with access locks, and free-to-read articles. Headbomb {talk / contribs / physics / books} 15:50, 29 October 2016 (UTC)Reply[reply]

What the Citation Template Behaviour RFC is about

Hi all,

Over the past few months, a bunch of us have been working (see announcement) on designing so called "access locks" for the citation templates (see Help:CS1/Help:CS2) and for the various identifier templates (such as {{arxiv}}, {{bibcode}}, {{doi}}, etc.). See the upcoming Signpost article on the topic for details, both technical and non-technical. Some of you may have noticed the green lock in citations such as

  • Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD". Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234. doi:10.1007/JHEP03(2010)094.

which has been rolled out at the end of July of this year.

We are currently at an impasse in terms of the final design and behaviour of the template when it comes to the locks. To make things simpler, let's keep this RFC purely about the behaviour of the locks. A first RFC about visual design of the locks precedes this one. For purpose of the discussion and examples, I'm using the current original locks.

First aspect

First, there is the matter of the templates' allowed and disallowed behaviour. Currently, we're enforcing the unofficial convention that links in |url= should be free, and flag those that are not completely free via |url-access=registration and |url-access=subscription (which respectively display   and   after the primary link), but disallow |url-access=free (which would respectively display   after the primary link, if allowed). Likewise, we're treating identifier links (like doi:10.1007/JHEP03(2010)094 in the above example) as non-free by default, and flag only those that are free via |doi-access=free (which displays   after the doi link), but disallow |doi-access=registration and |doi-access=subscription (which would respectively display   and   after the doi link, if allowed). The point (currently at least) is to reduce the amount of 'visual' clutter. However, we need to decide if that convention is one we want to make official, or if we want to allow more flexibility in the system.

That is, do we want to allow all locks anywhere

or do we consider that our non-official convention conveys clearly enough that the main link is free, while the doi doesn't have free full versions available that we can make it official and enforce it.

Likewise, if we allow all locks, do we want to automatically flag identifiers links we know are subscription-only, like MR0123456  , or let such flagging be an editorial decision?

Second aspect

Second, this concerns whether or not we should deprecate |registration= and |subscription= in favour of the new system. The problem with the current use is the message is ambiguous when many links are present. See for example, the current style works well enough if only one link is present:

  • Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. (registration required (help))

but is ambiguous if more than one link is given:

The new style would make it clearer to which link registration applies

However, we can only deprecate |registration= and |subscription= if we support locks everywhere. In either scenario, this will create a backlog of errors, which bots can fairly easily take care of in ~90% of cases. However, if we support both systems, many users and bots inadvertently keep creating errors when they add a doi to a previously doi-less reference, or a url to a previous url-less reference, as they would need to also change |registration=yes to |url-access=registration or |doi-access=registration at the same time.

Third aspect

Third, this concerns the "automatic linking" of titles, based on the presence of free identifiers. Currently, a citation with a PMC (which is always free), automatically links the title

This is considered desirable behaviour by some, but redundant by others. The question is, do we extend this behaviour to other identifiers which link to full official free versions as well? That is, if we have a free doi, do we want to present this citation as

  • Dunlop, . A.; Apanaskevich, D. A.; Lehmann, J.; Hoffmann, R.; Fusseis, F.; Ehlke, M.; Zachow, S.; Xiao, X. (10 October 2016). "Microtomography of the Baltic amber tick Ixodes succineus reveals affinities with the modern Asian disease vector Ixodes ovatus". BMC Evolutionary Biology. 16 (1). doi:10.1186/s12862-016-0777-y  .

or as

or do we remove the autolinking from the PMC identifier?

  • Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC 4309825  .

With that in mind, please indicate your preference for which behaviour you prefer below. Due to the great deal of aspects we need to cover, let's vote on each aspect separately. Headbomb {talk / contribs / physics / books} 15:30, 29 October 2016 (UTC)Reply[reply]

Citation Template Behaviour RFC !Vote

Please indicate your preference for each aspect of the behaviour below.

Aspect B1) Allow all locks vs Restrict locks

Allow (not mandate) all locks
Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD"  . Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234  . doi:10.1007/JHEP03(2010)094  .
Restrict locks (current behaviour)
Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD". Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234  . doi:10.1007/JHEP03(2010)094.
  1. Allow all locks if someone wants to comb through all identifiers and flag them as free/non-free, I don't see that as a bad thing. This would then allow us to deprecate |registration= and |subscription= in B3.Headbomb {talk / contribs / physics / books} 00:09, 30 October 2016 (UTC)Reply[reply]
    After seeing some cases in the wild, many people add {{closed access}} to citations without urls, but dois only. Allowing locks would mean being able to take care of those citations in a much, much better way. If they aren't desired, they can always be removed manually. Headbomb {talk / contribs / physics / books} 12:37, 24 November 2016 (UTC)Reply[reply]
    Restrict locks After using the locks in a few articles (e.g. Urca process, Quark), I gotta say I don't really see the point of flagging paywalled identifiers. Flagging the good stuff is enough. We don't really need to draw attention to the fact that something is paywalled. Headbomb {talk / contribs / physics / books} 07:43, 7 November 2016 (UTC)Reply[reply]
    What didn't you like about using both locks? Flagging free stuff was my first instinct, but you convinced me otherwise ;) Now that I've thought it over I'm just fine with the idea of paywalled resources being told "every time your stuff gets cited on Wikipedia you're getting a scary red icon next to your link" - but then, in my usual editing it will mostly be scientific journals affected, and there's an ongoing debate about that topic that maybe doesn't generalize well to sources in other fields. Opabinia regalis (talk) 20:42, 7 November 2016 (UTC)Reply[reply]
    Mostly, when I was done flagging the free stuff with Quark, I wondered what yellow/red locks would really add. The green locks catch the eye enough to say "this one is free", and the others implicitly aren't. Combine this with autolinking (which the community seems to favour), and I do think the unofficial convention of flagging non-free primary links, and flagging free identifiers is very sensible. The burden of putting |doi-access=subscription on each of those citations seems truly pointless in face of the benefits. What looks good on one example doesn't look so good when you're dealing with a reference sections with 100 sources, each with 2-4 identifiers. For quark, we'd have 21 redlocked dois , and 1 redlocked pmid. No one ever has guaranteed any of these links would be free, so the assumption that they would be seems unwarranted in the first place.
    But it also made me think of the contrast between 'neutral' links such as when the ADSABS (via bibcode) doesn't have a free version, but also doesn't require subscription, since it's not a subscription-based repository. In many cases, we'd have a green arxiv, a plain bibcode, but a redlocked doi, suggesting that the arxiv or bibcode is somehow a better way of accessing the source. Headbomb {talk / contribs / physics / books} 21:36, 7 November 2016 (UTC)Reply[reply]
    I guess it depends a lot on whether people look over the references section as a whole (in which case the visual clutter matters) or use it piecemeal to get to the specific source they're interested in (in which case it doesn't matter what reference #64 looks like if you're interested in clicking through to #25). I feel like most people who care one way or another about the sources (a pretty small minority of readers) would do the latter, but I don't know of any evidence. As for your second point, isn't it the case that the free version is a better way of accessing the source?
    On a side note, why would there ever be a redlocked PMID? PubMed doesn't provide full-text access; it's just a database, and the PubMed entry itself (usually the abstract) is always free to read. Opabinia regalis (talk) 23:44, 7 November 2016 (UTC)Reply[reply]
  2. Restrict locks if there is an assumption that sources are free to access then there is no need to indicate the default position of free access. A green lock on every free access source is going to be a lot of clutter. Nthep (talk) 14:31, 30 October 2016 (UTC)Reply[reply]
  3. No green locks: The locks are useful only to indicate non-free content and the default should be free access like this:
    — Preceding unsigned comment added by RexxS (talkcontribs)
  4. restrict locks so that any lock symbol that is used expresses actual information and not sloppy guesswork. am disturbed by the assumption that doi parameters are treated by default as not free. none of these symbols should be used based on assumptions Jytdog (talk) 21:31, 30 October 2016 (UTC)Reply[reply]
    Currently we only flag a doi when it's free. The default is we say nothing about the doi. The restriction (no yellow/red locks allow on dois), however, was chosen because of an unofficial convention that is more or less 'flag what is unusual', and sources linked through dois tend to be closed sources, and thus don't need to be flagged as such according to this convention. I'm not quite sure why you consider those locks as 'sloppy guesswork'. They wouldn't be added based on guesswork, or even by default. The default is blank, save for those guaranteed to be free (or non-free, assuming consensus allows for such flagging). Headbomb {talk / contribs / physics / books} 21:38, 30 October 2016 (UTC)Reply[reply]
    Then it's time we started treating doi's the same as other links. You need to fix your idea of 'convention' so that it matches reality. The average reader has no idea what is "unusual", and we do no favours by marking free doi links (how does that help anybody?). Any convention needs to be useful; and the only useful convention is to mark links to articles that are non-free. --RexxS (talk) 22:06, 30 October 2016 (UTC)Reply[reply]
    It's not my idea. However, it was the rationale behind the current implementation. Headbomb {talk / contribs / physics / books} 22:24, 30 October 2016 (UTC)Reply[reply]
  5. Restrict locks (and no green locks) per Nthep. Researchers are mainly going to be interested in the primary link. Adding icons to all the links is unnecessary clutter and confusing. I also agree with RexxS that open access should be the assumed default and we don't need to add green locks. Kaldari (talk) 17:22, 31 October 2016 (UTC)Reply[reply]
    Open access is clearly not the default for the vast majority of bibcodes, dois, pmids, etc. Headbomb {talk / contribs / physics / books} 17:52, 31 October 2016 (UTC)Reply[reply]
  6. Allow all locks. The fact that there's disagreement about this is itself evidence that we should allow flagging of both free and non-free sources, because the nature of the "default" expectation depends on the topic area. It must be nice to live in a world where the default expectation is open-access (or at least free-to-read), but that's certainly not the case in the topic areas I work in. Most journal publications are paywalled, many of those will have an alternative source (like PMC) which is free-to-read, and there's no particular reason we should expect readers to know how that works. Opabinia regalis (talk) 20:32, 4 November 2016 (UTC)Reply[reply]
  7. Allow all locks. This supposed convention that DOI (etc) links are assumed non-free, and other links are assumed free, is completely reader-unfriendly. I don't know how readers are supposed to pick up on this convention. Therefore, we need to be consistent across all the links. Ideally, we would flag only those links which are not 100% open access, by the logic that virtually all links in Wikipedia articles (internal links in the article text, external links in the "external links" section, and so on) are assumed to be freely accessible, so we should mark those links that violate this convention. However, this raises the issue of how to deal with links whose subscription/registration-required status is not known. To solve that problem it seems necessary to show locks on all links within journal references when the subscription/registration-required status is known, and to show no lock when no information is available. — This, that and the other (talk) 00:33, 5 November 2016 (UTC)Reply[reply]
    Ideally we'd have a system like this: Known to require a subscription: red lock; Known to require registration: yellow or blue lock; Known to be free: no lock; Status not known; silver lock with silver question mark beside it. But that is not what is being proposed here, unfortunately, so I am not going to !vote for it. — This, that and the other (talk) 08:16, 5 November 2016 (UTC)Reply[reply]
  8. Allow all locks, to convey more, useful, information in a compact way. More information is ok, if it's organized & easy to see.   ~ Tom.Reding (talkdgaf)  12:57, 8 November 2016 (UTC)Reply[reply]
  9. Allow all locks, per "This, that and the other"'s rationale. However, I am concerned about potential clutter and think there should be a better system, such as the one mentioned by the aforementioned user. Tony Tan · talk 02:16, 9 November 2016 (UTC)Reply[reply]
  10. Oppose general proposal. Hell if I can figure out where to oppose the entire idea here, or if that ship has already sailed. I understand the problem with the subscription-required tags, but I think there are other ways to solve the ambiguity issue than this. There are several concerns that I have with the entire proposal:
    1. First, universality. Although its been a little bit since I've been active there, I'm very proud of my work at FAC, where I often focus on reference quality and citation formatting. The proposers here say that this is about scholarly publications and not all sources, but let me be very clear here: consistency in reference formatting is a Featured Article requirement; if you're going to implement this here, you're going to need to implement this elsewhere, too, and I do not think the ramifications of applying these standards to books or non-scholarly periodicals have been fully considered. The idea that newspaper-article access levels can be tracked by bot, in particular, strikes me as naive. In fact, I'm dubious that bots can do the things that have been handwaived here as a problem for bots to solve, and I'd like to see some controlled-environment testing of that assertion.
    2. Second, implied bias. In the "real world" outside Wikipedia, I agree that open access is "better" than closed access, especially in scholarly publications (which are often, at least in part, publicly funded). But there is no obligation to base articles here on open-source content. Indeed, if the best quality sources are less-easily available, those remain the best quality sources. Cutesy icons that make paywalled material look like it is "bad" (and make no mistake, bright red padlocks look bad, in part because they look like citation error text), imply that paywalled or restricted-access material is inferior. Further, I specifically oppose the idea floated somewhere above by an IP editor who I shan't track down, suggesting that editors have an obligation to provide links to the most-free source of their references. Specifically, this places republication sites like ResearchGate as "preferably" to journals' actual official digitization sites; such cases are clearly more accessible, but I question whether they are innately better. I'm here to write open-access articles for an open-access encyclopedia, but I don't necessarily believe that extends any obligation on me to support open-access sourcing in my references.
    3. Third, this proposal has not in any way discussed how an editor is intended to interact with the system when working from a print source. I know, I know, paper, right? But I do a lot of my article research at libraries, including (at times) specialist and reference collections. Frequently, I have no idea what sources are available online, if any. I link comparatively little. Still, sometimes I have the doi for an article, even if I'm not working from an online copy. I include that doi in my citations because I assume it is of use to editors. I am not interested in auditing its open-access level. I trust that no aspect of this proposal will make use of these locks mandatory? Squeamish Ossifrage (talk) 15:59, 11 November 2016 (UTC)Reply[reply]
    RE a few things.
    "The proposers here say that this is about scholarly publications and not all sources".
    No one says that. The system is universal, and would cover all such sources.
    "The idea that newspaper-article access levels can be tracked by bot, in particular, strikes me as naive."
    Again, no one claimed that. Bots can do a lot, and will mostly be helpful with sources that have identifiers. Humans will need to get involved as well, just like they are involved now with |subscription=yes.
    "But there is no obligation to base articles here on open-source content."
    That hasn't changed. The idea to let the reader know what type of source it is before hand, so they aren't surprised with a paywall/40$ fee, saving both their time and bandwidth. This is already done via parameters like |subscription=yes or templates like {{subscription required}}. There is no implication of inferiority.
    "Third, this proposal has not in any way discussed how an editor is intended to interact with the system when working from a print source."
    That's because print sources don't have links. If you have the doi, you can still put it. If you're not interested in finding out the access level, leave it blank. Others can find out and flag it.
    "I trust that no aspect of this proposal will make use of these locks mandatory?"
    The system is optional, just like the current system is.
    For an example of the current version (following the "restrict locks" convention) on one of your FAs, see Calostoma_cinnabarinum#References. Headbomb {talk / contribs / physics / books} 17:09, 11 November 2016 (UTC)Reply[reply]
  11. Allow all. There are fair arguments for both sides. However, if someone wants to label the links, I think they should be able to do so. The locks can produce unnecessary clutter in some Wikipedia articles, but in less technical articles, labeling the various links could resolve a lot of confusion. Not everyone is familiar with this or has an idea of what the default is for each type of link. NinjaRobotPirate (talk) 08:48, 16 November 2016 (UTC)Reply[reply]
  12. Allow all locks. A few years back, HTTPS links used to have a blue lock next to them. I think this idea is similar, and that soon we'll have an icon to indicate that a link is not secure. Just because the default behavior is to paywall information and knowledge, doesn't mean we need to follow that behavior. I feel that in a few years paywalled access is going to shrink, because the issue is being highlighted more. Having locks to indicate how much of the information we rely on is walled off on one of the major sources of knowledge on the internet is definitely helpful (maybe we'll even see a headline on the clickbait sites like "oh snap! Wikipedia's just paywalls to shame" or whatever!). —Hexafluoride Ping me if you need help, or post on my talk 12:35, 19 November 2016 (UTC)Reply[reply]
  13. Restrict. Broadly, cs1|2 identifiers link to paywalls and registration gates so these sources are not free-to-read. That is the norm for cs1|2 identifiers. There are, of course, exceptions: PMC, arXiv, RFC, etc. cs1|2 knows that these are not the norm so automatically highlights these identifiers with the green free-to-read icon. There is no need to add little red or yellow locks to identifiers that normally link to sources that are in someway restricted; that is the normal and so the expected state for these links. When an identifier links to a free-to-read source, that is novel, so we should highlight that identifier so that readers know that that particular identifier is different. In the similar but opposite case, most urls in |url= and |chapter-url=, and external links elsewhere throughout Wikipedia whether part of cs1|2 citations or not, refer to free-to-read sources. Marking these free-to-read sources as free-to-read conveys no new or useful information to the reader so these sources should only be marked when there is a registration or subscription cost to the reader. Do not highlight the norm. —Trappist the monk (talk) 19:40, 24 November 2016 (UTC)Reply[reply]
  14. Allow all locks. I'm commenting from my staff account as head of The Wikipedia Library, because I support and have worked on implementing this feature--so it's simply transparent to do so. If closers want to discount this as an out-of-place staff opinion that's fine of course. Fundamentally, locks allow readers to make decisions about whether and how to verify a source. It is very non-trivial that many sources are closed access--not free to read--since one of the core strengths of Wikipedia is the ability to and benefit from "checking the source". I'm well-aware that WP:PAYWALL doesn't preferences open sources over closed ones and have always supported that line. Yet this is not a comment on which sources to use, but how to indicate to the user what experience they will have when they click through. As a fundamental principle of usability, it's good to let the reader know what to expect, and these locks do so in a predictable and lightweight way. Second, links with open locks will be clicked on more, as readers without institutional access come to associate a positive experience with them. This provides added incentive for publishers to make sure there are free-to-read versions of their content available in ways consistent with copyright. This is not a political stance (although open access is undoubtedly better for readers than closed access); it's a simple win-win that encourages a good experience for readers while increasing the intelligent consumption of Wikipedia's content. Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)Reply[reply]

Aspect B2) Automatically flag non-free sources vs Don't automatically flag non-free sources

Note we're talking about default behaviour only. Locks could always be added manually in individual articles, assuming choice B1 allows for them

Automatically flag non-free sources
Don't flagged by default (current behaviour)

Keep in mind the automatic flagging depends on choice B1. If we choose to restrict locks, then the second behaviour wins by default.

  1. Don't flag by default as it would create an inconsistent look in articles that contain possibly sometimes not-free identifiers which haven't been flagged as not being free. Headbomb {talk / contribs / physics / books} 00:09, 30 October 2016 (UTC)Reply[reply]
  2. don't flag by default consistent with my !vote above. these symbols should not be based on assumptions. Jytdog (talk) 21:32, 30 October 2016 (UTC)Reply[reply]
    As a point, again, no assumption would be made. Under this proposal, only known-to-be-X would be automatically marked as |id-access=X. Mathematical Reviews links (shown above), always require a subscription to view, exactly like arXiv links are always free. We already automatically flag the always free identifiers. The question is should we automatically flag always non-free identifiers. Headbomb {talk / contribs / physics / books} 22:35, 30 October 2016 (UTC)Reply[reply]
  3. Don't flag by default per Headbomb as this could cause confusion, and because I voted for restricting locks above. Kaldari (talk) 17:27, 31 October 2016 (UTC)Reply[reply]
  4. Per Headbomb, don't flag by default, though it sure would be nice to avoid needing to set the access state for everything. --Izno (talk) 12:31, 1 November 2016 (UTC)Reply[reply]
  5. Flag by default Best to provide as much information as we have available. Inconsistency seems like a very minor issue. Opabinia regalis (talk) 20:35, 4 November 2016 (UTC)Reply[reply]
  6. Conditional: Flag by default if/when sometimes not-free identifiers which haven't been flagged as not being free are all (mostly) identified/worked-around/etc. Until then, Don't flag by default.   ~ Tom.Reding (talkdgaf)  13:03, 8 November 2016 (UTC)Reply[reply]
  7. Flag by default per "Opabinia regalis". We have to start somewhere, so we should flag sources by default when they are 100% confirmed to be non-free. Tony Tan · talk 02:21, 9 November 2016 (UTC)Reply[reply]
  8. Flag by default. I can see the argument that this could be confusing, but if we know what the access level is, we should probably provide that information. NinjaRobotPirate (talk) 08:52, 16 November 2016 (UTC)