This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
Require consensus for candidate article edits through the election.
There is a consensus against the proposal. Participants tended to agree that the problems brought up by the proposer exist, but most participants agreed that solutions are already in place that manage them. Namely, the Arbitration Committee has already authorized discretionary sanctions in the topic area to address individual behavioral issues, and watchful editors, who carefully enforce all applicable policies and guidelines in the topic area, already make the situation manageable. Mz7 (talk) 20:41, 23 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.
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. bd2412T23:40, 10 October 2016 (UTC)
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)
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)
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)
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? Neutralitytalk01:51, 11 October 2016 (UTC)
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)
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. ~ Rob13Talk03:14, 11 October 2016 (UTC)
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)
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)
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)
[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)
@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)
@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)
@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.
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 - 2¢22:19, 12 October 2016 (UTC)
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(t•c)06:21, 14 October 2016 (UTC)
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. agtx23:35, 17 October 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)
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 76.65.159.166 (talk • contribs) 00:27, 24 October 2016 (UTC)
Proposal: Amend page title element to remove "Wikipedia, the free encyclopedia"
There is consensus with an overwhelming majority in favour of the change, and the proposal has been acted upon. It makes no sense to try and overturn it by throwing on more votes, especially when the newer votes also increasingly favour the proposal. This close should not be interpreted as prohibiting discussion. Instead discussion can continue outside the support/oppose section, and if needed a new Proposal can be started. The result is not likely to change by voting here and any new proposal is likely to be lost in the discussion. Carl Fredrik 💌📧11:12, 29 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.
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
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)
...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)
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)
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 78.143.206.161 (talk • contribs) 08:39, 11 October 2016 (UTC)
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)
@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 me13:53, 11 October 2016 (UTC)
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)
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 me14:08, 11 October 2016 (UTC)
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)
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. — Rhododendritestalk \\ 18:12, 11 October 2016 (UTC)
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)
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 - 2¢22:09, 12 October 2016 (UTC)
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)
@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. — billinghurstsDrewth03:56, 15 October 2016 (UTC)
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)
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)
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)
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)
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)
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 "Reddit.com", 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)
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)
"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)
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)
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 - 2¢10:33, 17 October 2016 (UTC)
Wikipedia title tag as an autocompleteThe 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)
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)
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)
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)
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 78.143.196.185 (talk • contribs) 11:14, 28 October 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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)
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)
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)
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? IazygesConsermonorOpus meum19:04, 29 October 2016 (UTC)
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). — xaosfluxTalk19:07, 29 October 2016 (UTC)
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)
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)
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)
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. bd2412T16:04, 30 October 2016 (UTC)
@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)
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). bd2412T18:13, 30 October 2016 (UTC)
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. 86.17.222.157 (talk) 18:46, 30 October 2016 (UTC)
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)
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)
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. ϢereSpielChequers19:40, 30 October 2016 (UTC)
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. --Jayron3200:22, 31 October 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
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.
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. 72.43.99.146 (talk) 01:03, 1 November 2016 (UTC)
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)
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)
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 Mishehu10:49, 1 November 2016 (UTC)
Oppose RFCs seek more than consensus. Sometimes, they are useful for idea-generating sessions, and not merely as a means to establish a !vote. --Jayron3202:48, 3 November 2016 (UTC)
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)
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)
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. bd2412T14:14, 23 October 2016 (UTC)
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)
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. — xaosfluxTalk17:33, 23 October 2016 (UTC)
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 - 2¢20:58, 23 October 2016 (UTC)
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 - 2¢23:30, 23 October 2016 (UTC)
While Special:ListGroupRights shows everything, the primary extra permissions that a normal new user get when confirmed are:
(upload) The ability to upload files here to enwiki , such as fairuse images that can't go to commons.
(skipcaptcha) Not have to enter CAPTCHA's for some things
(move) Ability to move pages
(editsemiprotected) Edit SPP pages
(autoconfirmed) Not be affected by IP-based rate limits
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)
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 - 2¢00:02, 24 October 2016 (UTC)
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). — xaosfluxTalk00:06, 24 October 2016 (UTC)
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)
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)
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)
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. — xaosfluxTalk04:20, 24 October 2016 (UTC)
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 - 2¢10:49, 24 October 2016 (UTC)
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 -- samtartalk or stalk08:26, 24 October 2016 (UTC)
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)
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)
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)
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. –Davey2010Talk19:11, 24 October 2016 (UTC)
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)
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 Mishehu21:33, 24 October 2016 (UTC)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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 - 2¢22:50, 24 October 2016 (UTC)
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)
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 - 2¢23:41, 24 October 2016 (UTC)
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)
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)
Here's a partial answer to your question: "What is a new gf editor prevented from doing before autoconfirmation?"
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).
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)
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 - 2¢23:51, 26 October 2016 (UTC)
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)
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 - 2¢10:00, 2 November 2016 (UTC)
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)
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
or
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)
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)
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)
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 notendemic 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.
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)
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.
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.
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? --Jayron3217:40, 3 November 2016 (UTC)
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!. –Davey2010Talk17:59, 3 November 2016 (UTC)
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)
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)
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)
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)
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)
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(talk•contribs)01:04, 5 November 2016 (UTC)
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)
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).
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·talk02:54, 9 November 2016 (UTC)
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)
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 (talk ⋅ contribs) 01:05, 14 November 2016 (UTC)
@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·talk04:59, 14 November 2016 (UTC)
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 (talk ⋅ contribs) 22:34, 14 November 2016 (UTC)
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)
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)
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. —HexafluoridePing me if you need help, or post on my talk21:33, 19 November 2016 (UTC)
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ölf01:32, 20 November 2016 (UTC)
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.
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)
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. Monty84503:32, 2 November 2016 (UTC)
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)
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)
"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)
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)
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.--JohnBlackburnewordsdeeds12:40, 4 November 2016 (UTC)
Opposeimmediate 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)
Oppose. Although Main -> Draft redirections create problems, Draft -> Main redirects are perfectly fine, and may be useful to new editors. Tony Tan·talk02:48, 9 November 2016 (UTC)
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)
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)
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)
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)
Support. Abandoned drafts are deleted per G13 after six months. It makes sense to apply the same to draft -> main redirects. Tony Tan·talk02:51, 9 November 2016 (UTC)
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).
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)
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)
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: RichFarmbrough, 15:05, 20 November 2016 (UTC).
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)
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)
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)
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)
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)
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)
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)
@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).
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)
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).
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).
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)
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)
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. --Jayron3217:15, 1 December 2016 (UTC)
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)
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:
Green (free to read): ,
Yellow (free, with conditions): , , , , , ,
Blue (free, with conditions): , , , , , ,
Red (not free): ,
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,
Dotted Green / Yellow / Red (DGYR)
/ / (DGYR-A)
/ / (DGYR-B)
/ / (DGYR-C)
Undotted Green / Yellow / Red (UGYR)
/ / (UGYR-A)
/ / (UGYR-B)
/ / (UGYR-C)
/ / (UGYR-D)
/ / (UGYR-E)
/ / (UGYR-F)
Dotted Green / Blue / Red (DGBR)
/ / (DGBR-A)
/ / (DGBR-B)
/ / (DGBR-C)
Undotted Green / Blue / Red (UGBR)
/ / (UGBR-A)
/ / (UGBR-B)
/ / (UGBR-C)
/ / (UGBR-D)
/ / (UGBR-E)
/ / (UGBR-F)
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)
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)
GYR
or
GBR
/ /
/ /
/ /
/ /
Keep in mind the shackles and bodies could differ depending on Choices A2 and A3.
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)
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)
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)
GBR per Headbomb's research with red-green colorblind people. Also like Steve above I get more of a muddy brown than yellow. — Scott•talk21:03, 31 October 2016 (UTC)
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. ~★ nmaiad15:47, 4 November 2016 (UTC)
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)
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ölf23:57, 13 November 2016 (UTC)
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)
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)
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)
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)
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. — JFGtalk21:26, 3 December 2016 (UTC)
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)
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.
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)
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 (talk ⋅dgaf)14:33, 30 October 2016 (UTC)
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)
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)
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·talk01:00, 9 November 2016 (UTC)
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ölf00:04, 14 November 2016 (UTC)
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)
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)
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)
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.
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.
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)
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)
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)
@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)
@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)
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·talk01:10, 9 November 2016 (UTC)
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)
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. WaggersTALK13:03, 18 November 2016 (UTC)
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)
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)
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)
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: RichFarmbrough, 22:58, 19 November 2016 (UTC).
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)
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)
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)
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)
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·talk01:12, 9 November 2016 (UTC)
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)
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)
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 - 2¢16:35, 29 October 2016 (UTC)
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. ‑‑YodinT09:11, 30 October 2016 (UTC)
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)
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)
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)
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). ‑‑YodinT09:15, 30 October 2016 (UTC)
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)
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 (talk ⋅dgaf)14:21, 30 October 2016 (UTC)
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 here02:25, 1 November 2016 (UTC)
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(talk•contribs)03:43, 31 October 2016 (UTC)
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. 72.43.99.130 (talk) 19:47, 31 October 2016 (UTC)
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)
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·talk01:21, 9 November 2016 (UTC)
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? ~★ nmaiad15:59, 4 November 2016 (UTC)
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)
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. 72.43.99.130 (talk) 19:52, 7 November 2016 (UTC)
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)
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)
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)
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)
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.
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:
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 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. PMC4309825.
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)
Citation Template Behaviour RFC !Vote
Please indicate your preference for each aspect of the behaviour below.
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)
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)
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)
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)
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)
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)
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)
No green locks: The locks are useful only to indicate non-free content and the default should be free access like this:
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)
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)
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)
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)
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)
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)
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)
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·talk02:16, 9 November 2016 (UTC)
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:
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.
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.
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)
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.
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)
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!). —HexafluoridePing me if you need help, or post on my talk12:35, 19 November 2016 (UTC)
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)
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)
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
Keep in mind the automatic flagging depends on choice B1. If we choose to restrict locks, then the second behaviour wins by default.
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)
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)
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)
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)
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 (talk ⋅dgaf)13:03, 8 November 2016 (UTC)
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·talk02:21, 9 November 2016 (UTC)
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)
Flag by default. Some sources are known to be (and have always been) paywalled, or require registration at least. There's no harm in assuming that an Elsevier link is (unless specified otherwise) paywalled. It's the default behavior of certain (and most) publishers. On the other hand, some publishers are built upon open access, such as PLOS, therefore the links coming from such sources are open access and there's no harm in automatically assigning them the green (un)lock. —HexafluoridePing me if you need help, or post on my talk12:40, 19 November 2016 (UTC)
Hexafluoride (talk·contribs) That's not quite what's being proposed. This sort of flagging can be done by bots. What we're talking about is the template automatically flagging guaranteed-to-be-non-free identifiers. That is, links like MR1129886 will always be non-free. Do we want to automatically flag them as such, possibly introducing an inconsistent style? For instance, a source can both have a non-free doi and a non-free MR, but the template would only automatically flag the non-free MR, since the doi can often be free. This would introduce an inconsistency that would need to be resolved by manually flagging the doi with |doi-access=subscription, or by manually suppressing the automatic flag. Headbomb {talk / contribs / physics / books}13:08, 24 November 2016 (UTC)
Do not auto-flag non-free sources. I presume here that the question refers to cs1|2 identifiers, most of which are not free-to-read. Because that not-free-to-read state is the norm, we should not allow the use of icons that say this normally-not-free-to-read is, yep, you guessed it, not free-to-read. Do not highlight the norm. Redundant; clutter; pointless. If the question is intended to also include non-free sources accessed through |url= and the like, I oppose that because cs1|2, without a very large database of urls, cannot know if this particular url is free-to-read or is restricted.—Trappist the monk (talk) 19:52, 24 November 2016 (UTC)
Do not auto-flag by default. Again from my staff account: Even among the most notorious paywalled publishers such as Elsevier, an increasing number of articles appear in "hybrid" journals which publish both open and closed content under the same publication. This is further complicated by embargoed content that is closed for its first 6-24 months and then becomes open later. We don't yet have the infrastructure to reliably tag closed access by default. It also reduces the effectiveness of the partially and fully open locks as signals of a better experience; they stand out more when they are not in a sea of closed locks, which is what would commonly happen in our highly paywalled world. Lastly, as not-free-to-read is unfortunately still the norm, it makes much less sense to "tag the norm". Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)
Aspect B3) Deprecate old system vs support both old and new systems
Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456. (registration required (help))Error: |registration= could apply to multiple links, use instead |url-access=registration or |doi-access=registration.
In call cases, there is currently no error messages being displayed. The ones shown above are mockups of what could be displayed in the next update.
Deprecate: This one is pretty clear cut – if someone's willing to go through and make the necessary changes then this should be reformed to make it clearer and easier to use. ‑‑YodinT08:59, 30 October 2016 (UTC)
Deprecate, but only once most of the occurrences of the old system have been migrated to the new one, possibly with a bot. − Pintoch (talk) 10:57, 30 October 2016 (UTC)
Sorry, I disagree. There is nothing prevents deprecation of these two parameters if the use of locks is limited to red and amber locks. The green lock is a complete red herring; there is no need to indicate an free access source, only to highlight on-line sources which are not free access. Nthep (talk) 10:47, 4 November 2016 (UTC)
Are you sure? It is not necessary for the cs1|2 templates to accept |url-access=free or any of the |<id>-access=registration and |<id>-access=subscription parameter values in order to deprecate |registration=yes and |subscription=yes. To deprecate, it is only required that we adopt some oter form of access signalling that can convey the same information, or, while it is outside the scope of thish rfc, that we agree to abandon access signaling in its entirety. All locks for all urls and identifiers is not a requirement for deprecation of |registration= and |subscription=.—Trappist the monk (talk) 11:12, 4 November 2016 (UTC)
One of Trappist's edit's seems to have deleted my reply but it is the same as Trappist's comment here. It is not necessary to signal all levels of access to deprecate the existing parameters. Nthep (talk) 11:23, 4 November 2016 (UTC)
You know, MediaWiki, or whatever code it is, is supposed to detect edit conflicts. This has been broken for I don't know how long. I have restored your answer to Editor Headbomb and also fixed the list markup of your most recent post so that the numbering below is correct.—Trappist the monk (talk) 11:32, 4 November 2016 (UTC)
It definitely is required, otherwise we cannot handle cases like
Fixed the indent and inserted a missing </span> tags.
As currently implemented, the convention that has been adopted is that dois and other identifiers are presumed to have access restrictions. As such, the inclusion of |subscription=yes in your example citation is superfluous.—Trappist the monk (talk) 13:43, 4 November 2016 (UTC)
We should not be perpetuating poor practice. The current convention is correct; adding a paywall signal icon to a specific identifier that is the kind of identifier typically requiring payment is mere redundancy and decoration. That editors have, in the past, added |subscription=yes to templates with these kinds of identifiers is not a reason for us to continue to support what amounts to meaningless decoration. Highlight the exception, do not highlight the norm.—Trappist the monk (talk) 00:19, 5 November 2016 (UTC)
Regardless of the first two aspects, I think this is a clear deprecate|registration=. I think the direction |subscription= goes depends on this entire RFC and so I can't support deprecating that parameter also. --Izno (talk) 12:18, 1 November 2016 (UTC)
I... I don't know what I was thinking then. Both registration and subscription presently exist, so that can't have been a reason. --Izno (talk) 14:24, 21 November 2016 (UTC)
Deprecate if most resulting errors could be fixed quickly. Having two systems would be too confusing to readers and editors alike. Tony Tan·talk02:25, 9 November 2016 (UTC)
Deprecate, presuming that |subscription= and |registration= are replaced with a new more specific system (not necessarily the one being contemplated in this series of RfCs) because these two parameters are non-specific and have been / are used where a cs1|2 template has both a url (perhaps in |url=) and one or more of the named identifiers. When this occurs, it is impossible to determine by inspection, to which the restriction notice applies. —Trappist the monk (talk) 20:24, 24 November 2016 (UTC)
Deprecate. Again from my staff account: I trust the judgement of Trappist and others that it's best not to have to redundant systems. Also, deprecate "fails gracefully" in that it allows for cleanup and informs the user what the new system entails. Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)
Aspect B4) Always autolink titles with free identifiers vs Autolink titles with PMC only vs Never autolink titles
Note we're talking about default behaviour only. If autolinking by default is not desired, title linking could always be done manually in individual articles. If autolinking by default is desired, autolinking could always be suppressed manually in individual articles.
Dunlop, J. 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.
Never autolink titles
Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC4309825.
Dunlop, J. 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.
A green lock could follow the title, depending on choice B1.
Never autolink title, always autolink identifiers, and suggest that |url= only be used for URLs not covered by identifiers. Links for identifiers are generated anyway, but duplicating them on the title adds nothing but a bit more complexity and blue text. If a reader sees a linked title, is it an explicit |url= or a copy from one of the identifiers? If there is more than one identifier, which URL was copied? Let's avoid all that, by not copying. And autolinking also clashes with the possibility of wikilinking the title of a notable work. Kanguole01:31, 30 October 2016 (UTC)
And the promised option of manual suppression would mean defining a new parameter for the template, resulting in more clutter in the markup. Kanguole15:29, 1 November 2016 (UTC)
Always autolink: usability and simplicity for readers should take priority over the complexity of code that this would cause. The ideal situation would be to link the title with the most open URL available (open > registration > subscription). Failing this, we should go with never autolink, and instead change the documentation to encourage editors to add the most open identifier based URL available to |url=. ‑‑YodinT09:53, 30 October 2016 (UTC)
(Comment: I have removed the green lock on the title in the "current behaviour" case, because this green lock is currently not produced for urls, even when they come from a |pmc=. Feel free to revert, but in that case, the fact that it differs from the current behaviour should be mentioned, I think.)
never autolink title; always autolink pmc parameter - and i will add that i am disturbed that none of the examples above include the pmid parameter which is the single most important parameter for citations used to support content about health (germane because PMC refs will always also have a pmid). the PMC parameter should behave exactly like the PMID parameter. People should be presented with ref examples that include the PMID parameter for consideration as it will always be there. Way more often than the doi parameter will be. Jytdog (talk) 21:22, 30 October 2016 (UTC)
The examples are minimalistic by design. That specific citation can also be access through doi and pmid, but they don't add anything to the example, or the proposed behaviour. That being said, why restrict this to PMCs only? Why shouldn't say, free bibcodes not autolink? Headbomb {talk / contribs / physics / books}21:30, 30 October 2016 (UTC)
The question is about PMC. It is not about bibcodes. People consider a lot of things when answering these questions. It is absolutely misleading to leave out the PMID which is almost always there (and should always be there) whenever a PMC parameter is used and PMC is what this question is about. The PMID gives entirely different information from the doi; i can't believe you are even mentioning them as though they are equivalent. Please fix the examples. Jytdog (talk) 22:49, 30 October 2016 (UTC)
Read the actual question here in B4:Always autolink vs Autolink PMC only vs Never autolink. note that it says PMC. Pose a question about bibcodes and i will answer it. I have added pmid to the examples above in this Section B4. I also noticed that some of the examples above in this section don't even use the PMC parameter but use doi instead. What a mess. Oy. Jytdog (talk) 03:26, 1 November 2016 (UTC)
Quoting "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 ...[examples]" Always autolinking means "whenever we have a free identifier (e.g. bibcode, doi, pmc, whatever) that links to a free official version, the primary link should be automatically generated". Autolinking PMC only means we'd only automatically generate a primary link if we have a PMC identifier, but not in the case of other free identifiers. Never autolinking means we'd remove the automatic general of URLs when PMCs are specified. The examples above are showing what the options mean in the case of a free doi, and a (free) pmc, but those would equally apply to other free identifiers.Headbomb {talk / contribs / physics / books}03:36, 1 November 2016 (UTC)
I can only read what is written at the top of this section which is "Aspect B4) Always autolink vs Autolink PMC only vs Never autolink". i have no idea where you are getting that other stuff. And you removed the PMIDs. Insane. This RfC is bogus. You are asking people to give a judgement that is partly aesthetic without a key parameter present, that will always be there in the real editing environment. bogus. Jytdog (talk) 06:40, 1 November 2016 (UTC)
@Jytdog: You are arguing over a point (PMID is present with most PMC), which is either irrelevant or at-best tangential, to the question. It's as simple as that. Move along if that's your only concern with this section. --Izno (talk) 12:24, 1 November 2016 (UTC)
word search this page for the word "clutter" and "blue link". people are evaluating things on aesthetics as well as functionality. you are giving poor examples that don't reflect citations as they will appear in practice; people cannot judge clutter when the normal full citation isn't there. the examples include parameters like author and the date of publication that are also not directly relevant to the question being asked. You included them because they are normal and expected and that is what citations have "in the wild". So too is pmid. Jytdog (talk) 15:31, 1 November 2016 (UTC)
I'm perplexed. You wrote: germane because PMC refs will always also have a pmid. Is that true? Right now, cs1|2 templates with |pmc= are not required to have an accompanying |pmid=. Are you arguing off topic here for a function in the cs1|2 template that would throw an error when a template has |pmc= without a matching |pmid=? You wrote: the PMC parameter should behave exactly like the PMID parameter. At present, the |pmid= parameter causes Module:Citation/CS1 to link the assigned identifier value to PubMed. The Module links the value assigned to |pmc= to PubMed Central and it also links the template's |title= parameter to the same PubMed Central page. On the one hand you write: always autolink pmc parameter and on the other hand you write: the PMC parameter should behave exactly like the PMID parameter. Are these not incompatible statements? —Trappist the monk (talk) 11:03, 1 November 2016 (UTC)
User:Trappist the monk of course there is no "requirement" to use pmid. What I wrote was that in WP:MED the pmid is the most important parameter in a template and everybody in WP:MED uses it. It is essential in practice and you will find it ubiquitous in articles about health. Yes, the pmid paramater links to the pubmed abstract, like this PMID18425890. With regard to the pmc parameter - yes, it is the identifier for the free full text article (it is different from the pmid). my answer is that it should act like the pmid parameter - there should be a link only at the pmc parameter. I am well aware that the Wiki-software currently also creates a link at the title as well as at the pmc parameter. I am saying it should not do that (what is the point of having two links to the same webpage in a single ref?) - instead it should create a link only at the pmc parameter. Jytdog (talk) 15:24, 1 November 2016 (UTC)
I think that the point of having two links to the same webpage in a single ref is to help people who have no idea what "PMC" means or why they might want to click on it. Linking the title to a free (gratis) copy helps people go to the "right" page. WhatamIdoing (talk) 21:14, 11 November 2016 (UTC)
If that were the case, "PMC" should link to PubMed Central, and any other identifier to their respective Wikipedia page. But the point of citations is not provision of encyclopedic knowledge. That happens in the article body. The citations exist to provide a path to verification. One free link is easiest, all that is required for verification, and can be inserted without any flags. I think most people would expect a free link in a free encyclopedia. If there is no free full-text link, add a constricted (partial/limited text) access link, including to previews, abstracts etc. If that is unavailable, add a link to the next least-restrictive/constricted level of access, and so on. But two or more similar links to the same material are superfluous and potentially confusing (apart from the clutter). Additionally, I think it is obvious that a link to an abstract when there is also a link to full-text, adds exactly nothing as far as verifying sources goes. 72.43.99.138 (talk) 17:25, 20 November 2016 (UTC)
Well I was responding to a posting that seemed to justify different links to the same material on the assumption that people might want to know what the background of the identifier is. 64.134.97.60 (talk) 00:00, 21 November 2016 (UTC)
Per Kanguole, "Never autolink title, always autolink identifiers, and suggest that |url= only be used for URLs not covered by identifiers". I see nil reason, if we are highlighting links elsewhere with locks, to provide autolinking anywhere but in the context of the identifiers. The software complexity also isn't worth it. --Izno (talk) 12:24, 1 November 2016 (UTC)
Always autolink It's obviously a usability benefit to have the title always link to a free-to-read source if one is available. All of this stuff about PMIDs seems completely beside the point; the PMID never leads directly to a free-to-read source. Opabinia regalis (talk) 20:38, 4 November 2016 (UTC)
Always autolink identifiers: Linking the title is a good design feature, because it establishes a very simple, user-friendly pattern: follow the title's link to be taken to the best available way to access the source. Using autolinks is a good pattern because it lets us use reliable identifiers for those title links rather than duplicating data (e.g. supplying a URL to dx.doi.org) or using a potentially non-permanent URL when it's ultimately equivalent to the (nominally permanent) DOI. That said, I also think that we should not autolink identifiers that only lead to index entries, e.g. PMIDs—they don't match the pattern of the title linking to the source itself. {{Nihiltres |talk |edits}}21:44, 4 November 2016 (UTC)
Always autolink title for better usability if the links always lead to free, official, and full versions according to Headbomb. Tony Tan·talk02:33, 9 November 2016 (UTC)
Always autolink. It's a design that the user has been accustomed to (click on the title if there's a URL). The link and PMC might be different and don't always lead to the same site. —HexafluoridePing me if you need help, or post on my talk12:48, 19 November 2016 (UTC)
Never autolink. This will require Module:Citation/CS1, the code that underlies the cs1|2 templates, to make judgements that may not accord with an editor's preference. When there is no value assigned to |url= and only one free-to-read identifier, while it will be a pain, it is not too difficult to imagine how the code would accomplish this task. As soon as there are two or more free-to-read identifiers, then somehow, the code must select one or the other to apply to |title=. Which shall it be? What if the code does not choose the one that the editor prefers? Sure, we could add yet more parameters to tell cs1|2 how to resolve the dilema; we could overload |url= so that an editor could tell the Module to create a url for |title= from a particular identifier. There may be other 'solutions'. In the end, if an editor must have |title= linked, it is simplest to simply place the url in |url= and be done. cs1|2 is complex and confusing enough as it is, don't make it worse. —Trappist the monk (talk) 20:55, 24 November 2016 (UTC)
Comment Also from my staff account: My personal opinion is that the correct method is that the title link should be to the paper/version of record, whether it is closed or open. Free-to-read versions may be preprints or another pre-publication manuscript. I don't think we yet live in a world where we can reliably autolink the title, especially as Trappist mentions, if that means deciding which version should be the "primary" one. Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)
Citation Template Behaviour RFC discussion
As described, both choices for the "First aspect" regarding "allowed and disallowed behavior" (also identified as "Aspect B1") seem to confuse rendering with annotation. My personal preference would be for it to be always acceptable for a citation to be annotated "|url-access=free" and "|doi-access=registration / subscription", but the rendering behavior should continue using the current convention that reduces visual clutter by only displaying locks when expectations are broken (i.e. the default expectation is that the main link is free while "doi" doesn't have a free full versions available). I think the correct behavior is a third option for Aspect B1, call it "allow all annotations, but display lock symbols only if annotations differ from the default expectation". In this third option it would always be allowed for an editor to individulaly annotate the subscription status of all parts of the citation, but the citation code would only display the lock symobls if an annotation differs from the default expectation (i.e. if a citation is annotated with "|url-access=free" no green lock should be shown for the title, as that is the expected behavior). —RP88(talk)16:35, 29 October 2016 (UTC)
Hchc2009, from what I can determine the code what was rolled out today uses the "Restrict locks" option. For example, code rolled out today produces the following...
Is there any reason why we're not giving people a choice in the RfC of sticking with the 28 October status quo? I'm not seeing any compelling argument (or indeed consensus) from making any change from that position. Hchc2009 (talk) 17:41, 29 October 2016 (UTC)
I don't see that the limited choices presented here actually represent the best behaviour for readers and inexperienced editors. My belief is that there is little or no value in flagging a link as free. Whom does that benefit? Is the average reader going to think "I'll follow that link because it's free"? Of course not. The only value in having visual indicators is to warn readers when links point to content that is not free, which may save some time for some readers. Secondly, I disagree strongly with having a "mixed bag" of unofficial conventions. There is no use assuming that one type of link is free and another type is non-free. Only those already very familiar with pmid/pmc/doi/arxiv will know which is which type and we're not writing the encyclopedia just for them. Pick one convention and stick to it - I'd recommend always marking all links requiring subscription/registration and never marking links that are free. That benefits readers and is simple enough for inexperienced editors to grasp quickly. Finally, I think the new system of moving to corresponding parameters for |url-access=, |doi-access=, etc. and deprecating the old system of |registration= and |subscription= is an improvement, giving proper flexibility and should be implemented. --RexxS (talk) 18:42, 29 October 2016 (UTC)
No locks. I see no compelling reason to clutter citations with little dingbats. The locks are a political statement, not a tool for readers. The reader is not helped in the slightest by their presence. The reader either wants to read the source or doesn't. No reader is going to look at a little icon and say, "I really wanted to read the whole thing, but I can't, so I'm not even going to look for the free abstract or first page that the publisher might provide." And what do you plan to do when a journal changes its access policy? If the journal is important and frequently cited, someone will need to update hundreds, maybe even thousands of citations scattered all over the encyclopedia. I realize that interested editors have invested a lot of effort into this proposal, but I see no way in which it helps the encyclopedia. Ozob (talk) 18:45, 29 October 2016 (UTC)
What most often happens to me is that I click on a link which is not free (beer)-to-access and end up wasting time in doing so, because my desire is to access the information at low-cost. $40 a paper is decidedly not low-cost. It is most certainly not a political statement. You should review the option above regarding auto-icon-ing sources which are always non-free, since I am unsure you read the proposals to any degree. --Izno (talk) 13:04, 1 November 2016 (UTC)
If I am reading you correctly, you are claiming that if you read a publisher's website and are provided with a free abstract, then you have "wast[ed] your time" because you cannot "access the information at low-cost." Even for papers that are not free, I can't interpret your claim as anything other than exaggeration.
To be clear, I did read the whole proposal. It assumed that Wikipedia editors wanted some kind of locks. Well, I don't. For the reasons I gave above, I don't want any locks at all. I still don't see a compelling argument in their favor, and certainly not one that outweighs the clutter they create. Ozob (talk) 23:55, 1 November 2016 (UTC)
Explanation of the rationale behind this new system. Citation templates often embed one or more identifiers, and possibly a |url=. For scholarly papers, the access restrictions can vary a lot among these sources. While clicking on the |url= seems quite natural (as it spreads on the title of the work), the list of identifiers can look quite cumbersome to readers (not everyone understands what a DOI is, or what is the difference between a PubMed ID and a PubMed Central ID). So, we thought it would be useful if editors had the possibility to indicate which identifiers lead to a free full text, and warn when the |url= is closed, so that readers can avoid going back and forth to try all the links in a citation. As a reader, I do find this very useful! (for instance when I look up a paper in Google Scholar, I crucially need to know which one offer a free full text: I do not want to try all sources). The previous system using |subscription= and |registration= is very ambiguous: in the presence of multiple links in a citation, which link does the access restriction apply to? There are various examples in the wild showing that editors have very different interpretations of these features. It is also quite verbose. Our new system is very compact, it replaces the external link icon with a more informative one. And of course it is optional; editors are free to do what they want. − Pintoch (talk) 22:12, 29 October 2016 (UTC)
Keep the locks - I disagree with User:Ozob, as I have found these lock icons very useful in the past. For instance, when completing a research project I have used the locks to determine which journal articles are free to access. One of the five pillars of Wikipedia is "Wikipedia is free content that anyone can use, edit, and distribute" - I believe that in line with this ethos, readers should be able to determine at a glance which references they are able to access. LoudLizard (📞 | contribs | ✉) 22:15, 29 October 2016 (UTC)
The locks have nothing to do with content. They are an adjunct to a mechanism for content verification. And such verification is needed exactly because most (not all) users can edit most (not all) Wikipedia content freely. 17.255.236.9 (talk) 23:39, 29 October 2016 (UTC)
I believe the anon's point is that access to sources is important for verifying the correctness of Wikipedia. This is true, but I don't see it as an argument for (or against) locks. Articles are permitted to cite sources that are not freely available. They are even permitted to cite sources that are not online at all. It may be that some editors are unable to verify the correctness of the citation with a single mouse click, but such convenience is not and has never been the standard set by Wikipedia:Verifiability. The policy says, "Do not reject reliable sources just because they are difficult or costly to access." (WP:PAYWALL). Putting colored locks next to citations encourages editors to think exactly the opposite, and that would be a major and extremely undesirable backdoor change to Wikipedia:Verifiability. Ozob (talk) 03:18, 30 October 2016 (UTC)
There is no such implication of rejection of sources because they aren't free. However, imagine you live in a place where internet access is quite limited. You want to verify something on your phone, but decide against it because the source is probably closed access, since most scientific journals will charge you 40$ to read a paper, and you don't want to waste the bandwidth on something pointless. You miss out on knowledge because that specific article was actually available for free, but you just didn't know and the risk of wasting bandwith wasn't worth it to you. Headbomb {talk / contribs / physics / books}10:30, 30 October 2016 (UTC)
No, there is such an implication. The different colored locks suggest that Wikipedia views some sources as superior to others. A red, closed lock icon conveys the message, "Wikipedia says this source is no good! Stay away!" while a green open lock icon suggests, "Wikipedia says this source is okay. It's for people like you and me." You might not intend them that way, but they will have that effect nonetheless. For that reason I can't ever see myself supporting lock icons in any form. Ozob (talk) 13:35, 30 October 2016 (UTC)
Do you also consider that adding PDF icons after external links ending in .pdf is a partisan advertisement of PDF files over, say, HTML or DJVU files? Or if you do not oppose using icons, but rather the general principle of flagging access restrictions, would you like to forbid |registration= and |subscription= too? Maybe the locks would be more acceptable if they were all of a neutral color (say blue)? − Pintoch (talk) 13:58, 30 October 2016 (UTC)
Not only is downloading a PDF different than reading a web page, the PDF icon isn't emotional. A red closed lock is. And yes, I do object to |registration= and |subscription=. I don't believe they offer the reader any utility, they are clutter, and they are impossible to maintain.
I would like to note [3], in which Headbomb implicitly agrees with my thesis that a green open lock says, "Go here" and a red closed lock says "Avoid". Ozob (talk) 14:32, 30 October 2016 (UTC)
Green/red doesn't say "go here" and "avoid", it says "You can read this one for free" and "You can read this one, if you have a subscription to the journal, or are willing to pay". The reader decides if they are willing to pay or not. And if they decide they don't want to pay, that is their decision. "Here's a link, but we're not going to tell you if you can read it or not" sends the reader on a wild goose chase. Worse, if they click on DOIs a few times and they happen to be taken to paywalled sources everytime, they may conclude DOIs are always paywalled and will just stop bothering clicking on DOIs in general. Headbomb {talk / contribs / physics / books}14:41, 30 October 2016 (UTC)
Pardon me while I return to a previous point. I believe the anon's point is that access to sources is important for verifying the correctness of Wikipedia. This is true, but I don't see it as an argument for (or against) locks. Indeed. Imo, LoudLizard was overreaching by implying that the presence of icons in citations is essential to the Wikipedia content the citations verify, or to verification in general, invoking the pillars of Wikipedia etc. which (again imo) makes it sound like a religious argument. However I do believe that readers should know a source has access requirements before they click the link. Whether the proposed scheme is the best way to do that is an open question. Oh, and by the way, pdf icons are useless and possibly redundant. Most browsers have pdf capability, or load pdf plugins in default configuration. 72.43.99.138 (talk) 14:50, 30 October 2016 (UTC)
(ec) I realize that "go here" and "avoid" aren't the intent, but nonetheless that's what they convey. Imagine for a moment that you have not been thinking about journal access for years. You are a high school student who has come to Wikipedia for the first time. How could you possibly interpret a fiery red closed lock except as no? Ozob (talk) 14:56, 30 October 2016 (UTC)
For comparison, Headbomb, when editors on the English Wikipedia cite a source in a non-English language, we often highlight this for the convenience of those whose editors can only read English. For example, I might cite a work like this:
Amalvi, Christian. "La Bastille dans l'historiographie républicaine du XIXe siècle", in Dutray-Lecoin and Muzerelle (eds) (2010). (in French)
It is, generally, helpful to editors who can't read French. Again, purely for comparison, I find it hard to imagine that citing it like this would encourage editors to click on it:
Amalvi, Christian. "La Bastille dans l'historiographie républicaine du XIXe siècle", in Dutray-Lecoin and Muzerelle (eds) (2010). (French)
Many normal people would avoid clicking on that. I want readers and editors to click on the links I use for citations, whether to find out and learn more about the subject, or simply to check my work and citations. I don't want to deter them from clicking on links to high quality journals - and automatically putting rather silly big red padlocks on the citations are often going to have just that effect.
I'd strongly advise that we take this RfC back a step, and first of all address whether we want coloured padlocks on the Wikipedia - and only then work through the detailed questions here. Hchc2009 (talk) 16:29, 30 October 2016 (UTC)
No locks - Adding this in here for clarity (to avoid any potential double-counting, I've made the same point above in the previous section with my justification). Hchc2009 (talk) 07:09, 30 October 2016 (UTC)
Keep locks and make changes rather than keeping to some abstract "status quo" – when people who don't use them say "no-one uses them", and others who do say "we do", the argument sort of collapses – thanks to whoever rolled these out, and let's keep tinkering to make sure they're as useful as possible. ‑‑YodinT09:20, 30 October 2016 (UTC)
Conditional support of all locks I think this is a wonderful proposal, and I fully support the intent. However, if implemented it needs to be fully automated with no human intervention required. It needs to support delayed open access. I realize this may be a large issue, but if it doesn't support that I prefer omitting the red lock. Carl Fredrik 💌📧10:58, 30 October 2016 (UTC)
Delayed open access can certainly be added to the list. We've been talking of having an icon like for PMCs, and there's no reason why this couldn't be extended to other identifiers. The color could differ, however. Could you add your opinion under B1?Headbomb {talk / contribs / physics / books}12:32, 30 October 2016 (UTC)
No green lock I'm with RexxS on this. There is no need for an indicator for the preferred (or actual) default of free access and the green lock is a bit of a solution looking for a problem. Nthep (talk) 14:38, 30 October 2016 (UTC)
Support locks — on the basis that they are useful for readers and editors. No one in their right mind would think that a source is forbidden because there is a red lock, and we save them time that might be wasted being hit by a paywall. Or we prepare readers to ready their credentials to look up the source — in no way can this scare away readers — the only type of people that are likely to be scared away are those that wouldn't have had access to the source anyway, and are very unlikely to pay for it. In essence we can ignore the idea that anyone would pay to view a source, that just isn't done. (There are studies on this, so vanishingly few access sources like this.) Carl Fredrik 💌📧21:54, 30 October 2016 (UTC)
No locks. I'm with Ozob. While I am supportive of open access publishing -- my last umpteen papers were all in open access papers -- the point of a citation in Wikipedia is to show evidence for a statement. It has never been Wikipedia policy that such evidence has to be freely available or even online. Bondegezou (talk) 09:52, 31 October 2016 (UTC)
No locks. A previous poster stated that the locks mean that readers would "be able to determine at a glance which references they are able to access." They won't do any such thing. They'll be able "at a glance" to tell if the resource appeared free/paid to the editor that added the ref at whatever time/place/other set of circumstances they added it. Whether its free/paid to you, today is a different matter entirely. These things are going to go out of date all the time, so I don't think we should add them in the first place. Chuntuk (talk) 14:55, 31 October 2016 (UTC)
That is clearly wrong. The locks aren't to be used to flag if it's free to you, they are there to flag if it's free to everyone. If you have a subscription to say Time magazine, you'd need to use the suscription lock because a susbcription was required to access the source. As for things 'changing over time', this is no different than with the current situation. If a journal retroactively changes it access policy from subscription based to free to read (or vice-versa), it is a very simple matter to update the locks accordingly. Headbomb {talk / contribs / physics / books}15:21, 31 October 2016 (UTC)
I've heard you say multiple times that bots will make it easy to keep the locks up to date. But Wikipedia:Bots/Requests for approval/OAbot suggests that it's extremely hard to automatically keep locks up to date. There are errors in data sources; publishers and types of citations that need to be blacklisted; and special cases for some sites, like ResearchGate and Academia.edu. OABot's task is difficult even with its limited scope of "only add free locks when absolutely sure". I would not be surprised if there are more lurking problems. Keeping locks current across all citations will be more burdensome and less amenable to automation. Ozob (talk) 02:48, 1 November 2016 (UTC)
That's mostly because OABot tries to do many things at once, including finding links to (often) non-official sources. Maintaining DOIs and the like based on official journal policy / official databases is much more straightfoward with much fewer cornercases. Headbomb {talk / contribs / physics / books}03:14, 1 November 2016 (UTC)
If I understand you correctly, you believe that it would be simple to maintain the lock icons using a bot. Yes? I would like to see this demonstrated. The part where the bot edits articles is easy; but I think the part where the bot disentangles publishers' websites will be hard. Ozob (talk) 23:59, 1 November 2016 (UTC)
No locks. I find these dingbats small, hard to visually parse, and the message isn't immediately apparent, at least to me. I guess these would be invisible to visually impaired readers, too. If we must annotate accessibility, make it in clear English rather than inscrutable glyphs. The red also sends a bad message: stop, dangerous link ahead! Also in practice, not all paywalled sites are the same. Some might just display title and author, some add an abstract, and some might display the first page or two of an article. Red stop icons may dissuade readers from otherwise investigating partially available paywalled sources. --Mark viking (talk) 21:53, 31 October 2016 (UTC)
No locks. The only justification for icons over text is in a multilingual situation. Fine for the Gent's loo at an airport, but a right pain when you have to spend time searching to find out what the blessed things mean. Those that use them daily may remember, but unless they are documented on the page they just add obfuscation; and if they are documented on the page what is the point of them? Martin of Sheffield (talk) 11:12, 1 November 2016 (UTC)
No locks isn't an option, really. Green locks have already been deployed, and there's clear consensus to deprecate |registration= and |registration= in favour of this new system because of the issues with the old system. These could probably be hidden via user preferences, however.Headbomb {talk / contribs / physics / books}13:31, 1 November 2016 (UTC)
Just looking at this section there have been the following votes:
No locks. Ozob
Keep the locks LoudLizard
No locks Hchc2009
Keep locks Yodin
[ see below Conditional support of all locks Carl Fredrik]
No green lock Nthep
Support locks Carl Fredrik
No locks. Bondegezou
No locks. Chuntuk
No locks. Mark viking
No locks. Martin of Sheffield
No locks Doug Weller
That is No locks: 7, Keep: 3, No green lock 1. Most of the 64% majority supported text in place of locks, so within this section there is clearly not a "clear consensus to deprecate |registration= and |registration= in favour of this new system". Martin of Sheffield (talk) 13:48, 1 November 2016 (UTC)
@Martin of Sheffield: Your qualifier "Just looking at this section" is important. Some users who have participated in sections above have not participated in this section, and while it is not definitive what their opinion is regarding having locks at all, I might suggest that they are open to the idea of locks above and beyond "No locks". --Izno (talk) 13:53, 1 November 2016 (UTC)
"We should have locks" does not follow from "we should deprecate |registration= [in favor of...]". Deprecating |registration= can be done using a text-substitute and the same parameters. The locks are not the only implementation. As for "we've already deployed green locks", I might suggest this RFC is a wider input than that which was had at WT:CS1. --Izno (talk) 13:52, 1 November 2016 (UTC)
An RFC is not a vote. You need to judge the strength of the arguments, and so far it's pretty much WP:IDONTLIKEIT for those against. The benefits to the reader are clear and obvious, and putting a "(free to read (help))" "(registration required (help))" or "(subscription required (help))" next to each of these links is not viable. Having had zero objections to these locks for more than 2 months shows wide acceptance, and we would would need a viable alternative to deprecate the locks. And there is plenty of support for these locks in other sections (and past discussions). Headbomb {talk / contribs / physics / books}13:58, 1 November 2016 (UTC)
Claiming "The benefits to the reader are clear and obvious" is just another way of saying WP:ILIKEIT; I don't see a policy-based reason for lock icons here. Putting a "(free to read (help))" "(registration required (help))" or "(subscription required (help))" next to each of these links is obviously viable in the sense it can be done. Both icons and text equivalents clutter up the references and have the ambiguity problems mentioned above. But the text has the advantage of being immediately understandable and doesn't have the problematic color semantics of the icons. I do appreciate all your work in this and we both want references to be as clear and as helpful as possible for the readers. I just don't think the suggested lock dingbats are the way to go. --Mark viking (talk) 18:26, 1 November 2016 (UTC)
We live in an icon-based digital world. If you go at Tim Berners-Lee, you'll see a lock on the corner of the article. That it's not immediately clear that you can edit the article if you have an account that's been autoconfirmed isn't an issue, because you can hover the lock and find out that way. Having an explicit "Autoconfirmation required to edit this article" messaged displayed instead of the semi-protection icon would not be an improvement. Likewise, having hundreds of "subscription required" per articles like Quark, often multiple times per citation is not an improvement. That's why we need an icon-based solution. Headbomb {talk / contribs / physics / books}19:28, 1 November 2016 (UTC)
You are making many assumptions, starting with the kind of world we live in. Slogans are a turn off. We also don't need any icons; we may or may not agree to use icons as a signal, but nothing is set in stone. Whether icons are an improvement (for the average Wikipedia reader) relative to explicit text is a matter of opinion. I haven't seen the Quark article, but why would anyone use more than one link per citation for the same material (archive links excluded) is a mystery. If there is one or more free links, cite this/these link(s) only, without explanation. If there is one or more non-free links, pick the one(s) that are least onerous (ex. registration instead of limited access instead of subscription), and add the relevant access requirement once. 72.43.99.138 (talk) 00:27, 2 November 2016 (UTC)
As someone who would prefer icons, No Locks is still definitely an option! That said, the numbers given (No locks: 7, Keep: 3, No green lock 1) miss out Headbomb; taking them into account gives 58% against all icons. Not a clear consensus, but in my opinion it's shown the questions we need to address directly in another RFC, to answer A: do people want consistency (e.g. in Cite Journal, plus Cite News, Cite Web etc. as discussed below, but also Closed access, Subscription & Registration as well as Arxiv, Bibcode & doi), and if so would they be willing to be bound by a !vote B: should we use icons or text. If icons are decided on, the above RFC has pretty strong consensus on the specifics (e.g. visual style, deprecate old parameters, etc.), if not, at least it's decided in a clear cut way, rather than tucked away in the discussion of an RFC that bypasses the question. I don't envy whoever closes this! ‑‑YodinT09:57, 2 November 2016 (UTC)
No locks. I'm late to the party, but I agree with Ozob's views about clutter and subtle political statement. Yes, I prefer free sources, but authors and publishers need to make a living, so I'm not bummed by pay sources. I've had to pay DTIC money not because the content is copyrighted but rather somebody had to physically copy the document. I'll probably pay the National Archives $40 to dig another document out of a dusty box in its basement. Most readers are not going to be consulting the references, so the figures would be clutter. Yes, I do consult sources, but I often AGF, too. I spent an hour yesterday trying to track down an obscure 1991 source. Turns out 1993 to present is available online to me for free, but there are only physical copies before 1993. Several nearby libraries carry the journal, but they have unfortunate holes in their collection. That brings me to another point. Isn't there also friction with OpenURL resolvers? Some source may not be free/locked to John, but Sally's institution may have a subscription, so it is free/unlocked to her. Glrx (talk) 17:32, 5 November 2016 (UTC)
OpenURL access is similar to any other subscription/registration access; I don't think that is relevant. However, OpenURL implementations have been indeed inconsistent in my experience, and sometimes result in unexpected access. The latter, though unintentional, may or may not be a copyvio issue. 65.88.88.69 (talk) 20:20, 5 November 2016 (UTC)
No Locks. Changing text into icons is making things less clear to the reader - the icons are tiny and much less understandable than the current text. However, from the documentation of the cite templates that the decision has already been made and this has been implemented. So much for consensus.Nigel Ish (talk) 20:36, 5 November 2016 (UTC)
[This opinion was previously added to § Visual Design RFC discussion] 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. 72.43.99.138 (talk) 14:46, 9 November 2016 (UTC)
No locks: Clutter that does not help with the core task of citation templates, i.e. to locate the sources of cited information. As others have noted, there is no policy-related reason to inform the reader about the (free) availability of sources. In practice, emphasizing availability might contribute to preference of free sources over good sources that have access limitations, which is not a favorable development. – Finnusertop (talk ⋅ contribs) 23:05, 12 November 2016 (UTC)
Can someone speak to the maintenance burden that this creates? Here's a simple example: Articles in Blood are defaultly paywalled for 12 months and gratis (but not libre) after that. So it's October 2016, and I cite something that was published in January 2016. It presumably deserves to be flagged as having a paywall, right? But in January 2017, it's free to read it. So the "costs money" lock is wrong at that point. Who is (realistically) going to update the status? (About 250 such articles from this one journal can be found via Special:LinkSearch on the journal's domain name, but it's probably cited thousands of times with only PMID or DOI links.)
At first glance, if the answer is "the same somebody else that updates every other trivial little maintenance burden", then my first thought is that we should not be posting citation information that we are certain will become wrong/outdated. On the other hand, if the answer is that somebody's got a bot that can search through citations and identify dead URLs, URLs that redirect to paywalls, etc., and update the refs accordingly, then this might be okay. WhatamIdoing (talk) 04:50, 30 October 2016 (UTC)
@WhatamIdoing: the use of locks is optional, and bots will be able do a lot of that maintenance. It'll be relatively straightforward to maintain a list of journals by embargo date. We don't currently have a |doi-embargo-date=, but that could certainly be implemented. We already have that for |PMC=. Headbomb {talk / contribs / physics / books}10:25, 30 October 2016 (UTC)
What about delayed open access journals? If I add a reference to an article published two months ago in a delayed open access journal with a 12-month moving wall and mark it as access=subscription, should I make a note in my diary to change it to access=free in 10 months' time? Or do we need a separate icon, e.g. a lock with a clockface? Or will a bot change the icon for me? If so, do we need a moving-wall=12 months parameter to tell the bot when to act? —Qwfp (talk) 09:14, 30 October 2016 (UTC)
Good point: you could also add |url-access-free=date article becomes free here (and |doi-access-free= etc.), with |url-access= as the current, default setting, which would change after |url-access-free= is reached. |url-access-registration= and |url-access-subscription= could be added later if necessary. Editors or bots could then simplify the markup when they noticed, but it would be visible to readers as soon as it becomes free. EDIT: Visually, I would keep the standard icons, but add a clock just after it, with the date as the hover-text, and linking to a page that explains that it's delayed open access. The padlock icons should also link to explanations of what they mean (see CC0 point made above). ‑‑YodinT09:32, 30 October 2016 (UTC)
The problem with access levels that vary over time is not new: it also applies to |subscription= and |registration=. I don't think adding a bazillion of new parameters for embargoes on all identifiers would be very helpful (but |pmc= already supports it though, so it does not sound completely impossible). But as our access parameters are now more precise, this opens the door to automated updates by bots. The task you describe (removing restricted locks when a resource becomes free) is not currently in the scope of action of User:OAbot (currently submitted for approval) but this is typically something we could consider adding. − Pintoch (talk) 10:08, 30 October 2016 (UTC)
From my understanding based on what others have mentioned above, using bots, parameters, or both should relieve this maintenance burden. Is this accurate to say? Tony Tan·talk02:40, 9 November 2016 (UTC)
Phrasing for the last aspect
Regarding the last question in this omnibus RFC (third aspect / aspect B4):
It is confusing to phrase it as whether or not to "autolink". As the example shows, the URL implied by an identifier is always automatically generated and attached to the identifier. The question is the same URL should also be attached to the title if |url= is not set.
The proposal says this is only about default behaviour and that linking the title could be suppressed manually, but this is not possible with anything that has been proposed so far. Are you proposing an additional parameter to control this?
I think the examples make it clear what #1 is about. However, concerning #2, since this isn't implemented and we're trying to see what the community wants, no parameter currently exists. We want to know if this feature is desired, if it is the technical details are fairly easy to sort out.
If autolinking is desired by default, we could have a hierarchy of identifiers (e.g. doi>pmc>bibcode>jstor) and the first free identifier on that hierarchy autogenerates the link, with no need for user input save the flagging of an identifier as free. If a link to an identifier lower on the hierarchy is desired, then the default autolink could be overridden via something like |autolink=bibcode. And in the cases where this isn't desired, it could be suppressed via something like |autolink=no. Whatever is put in |url= would of course take precedence over autolinking.
The examples do make the behaviour clear, but this is a long and complex RFC, and people may not read all of it in detail, so headlines matter. I object to the continued description of this feature as "autolinking", because automatic generation of links is not in question. The question is whether these automatically generated links should be duplicated.
The proposal does not include |autolink= or the like, so if it is accepted as is there will be no way to prevent all these duplicated links, unless we later add such a parameter, and then add |autolink=no to all our citations. Kanguole12:53, 30 October 2016 (UTC)
Extra parameters are part of the editing interface, not the implementation, and ought to be mentioned. To return to the lack of clarity, it might help if you replaced each "autolink" with "autolink title". (Adding bullets to the examples woudl also make them clearer.) Kanguole01:37, 31 October 2016 (UTC)
DOI behavior
An earlier discussion (which I found here) pointed out that DOIs do not correspond to a single URL and hence do not have a well-defined access policy. According to the DOI handbook, a DOI may resolve to multiple URLs. For example, a DOI could resolve to an open access repository in some countries (perhaps due to legal requirements in those countries) and to a closed access repository elsewhere.
Representing this kind of indeterminacy with a single icon is impossible. I am not even sure how easy it is to recognize that such indeterminacy is present. The present proposals seem intended to cover DOIs, but what is supposed to be done about such situations? Ozob (talk) 00:18, 31 October 2016 (UTC)
No. It's a theoretical concern. If others are willing to attest that this does not happen in practice then I would be satisfied. Ozob (talk) 02:31, 31 October 2016 (UTC)
Doesn't it happen all the time? Researcher publishes journal article that ends up behind publisher's paywall. Journal policy allows author to publish article on website author controls, so author posts free copy. Same document, two URLs, different access. Government employee pens article on government's dime, so the article is public domain. Journal publishes article but keeps it behind publisher's paywall. Anybody can republish the article. Same document, arbitrary number of URLs, different access. Bell Telephone Labs researcher pens article, submits to Bell System Technical Journal and to IEEE rag (which knows it will be published in BSTJ); same text exists in two places; for a time, Lucent made BSTJ open access, same content had free access and available behind IEEE paywall. Nobel Laureate Irving Langmuir publishes his work in the General Electric Journal and in the IEEE during 1914; it's public domain now; Google digitizes and publishes the GE Journal online for free, but PD IEEE article stays behind pay wall. Glrx (talk) 21:27, 5 November 2016 (UTC)
All this is true, but also not pertinent to these RFCs. If I may, what you are describing applies more to the function of the citing contributor. It is up to her/him to find the most accessible source for the material that supports the related claim in wikitext. Readers don't need more than one link. The need one link, or one class of links, (the least onerous) that will help them verify the related claims in the article. Do the present proposals make this task easier? Imo, this also implies that free links should be the expected norm in a freely accessible encyclopedia; any access requirements need be only signaled once if only a single such link or a single such class of links is present. This encyclopedia is supposedly freely editable; if the state of access changes, interested editors can make changes. But that aspect is also not pertinent to these RFCs. 72.43.99.138 (talk) 15:04, 6 November 2016 (UTC)
Scholarly versus popular
Open access has since the inception of the concept in 2002 referred to access to scholarly publications in academic journals. The proposed system above is designed to flag perhaps all citations to academic journals in Wikipedia. The discussion above is framed to invite comment from contributors who use academic citations.
If this system gets adopted in Wikipedia, then soon enough, someone is going to raise the issue of whether the same locks could be used on citations to popular sources. For example, someone might want to know if links to subscription newspapers or magazines are free to read or paywalled. Is there anyone here who is willing to speculate how this likely potential use could play out?
Would people here who support this icon's use for academic content also support its use for popular content? Would anyone here oppose that use, and the application of the "open access" concept to non-scholarly works?
If this concept is something that might be used by people who use any citation, then perhaps all sorts of people should comment on this proposal. If this proposal is something that would restrict non-academic use, then again, perhaps all sorts of people should be invited to comment. I am thinking about what I might say to people who do not use academic citations to explain the extent to which this discussion might be relevant to them. Blue Rasberry (talk)17:01, 1 November 2016 (UTC)
For 'popular media', the locks would be used pretty much the same way. For example, for a source with subscription required, we'd have something like
Smith, J. (2010). "Title of article". Time Magazine: 47. Retrieved 2016-11-01.
This would replace the current (via |subscription=yes)
Smith, J. (2010). "Title of article". Time Magazine: 47. Retrieved 2016-11-01.
or (via placing {{subscription}} at the end of the citation)
Smith, J. (2010). "Title of article". Time Magazine: 47. Retrieved 2016-11-01. (subscription required)
or (via placing {{closed access}} at the end of the citation)
Smith, J. (2010). "Title of article". Time Magazine: 47. Retrieved 2016-11-01.
As far as Wikipedia is concerned, I don't think that the distinction between "popular" and "academic" is relevant. The citation system does not exist as a helper to academic research. It is a result of policy (WP:V), which itself is necessitated by the fact that the provenance of wikitext added by Blue Rasberry , for example, or by my IP address signature, is at best, inscrutable. Academic research and publishing involves reputations, careers, and funding; it has its own well-developed verifiability systems and processes, that an anonymous/pseudonymous encyclopedia model cannot and should not match. Especially, because it is geared to a much wider audience. The utility of the proposed schemes have to be judged on that basis, not on the type of reader who is already familiar with citing sources and who uses citation systems as a matter of course. 72.43.99.146 (talk) 14:29, 3 November 2016 (UTC)
More useful, instead, would be some sort of totally different indicator showing that a source is not scholarly, since such sources are typically less reliable; we shouldn't be making it seem that Time or subscription newspapers are comparable to the Journal of American History or the Sociological Quarterly. Nyttend (talk) 23:06, 3 November 2016 (UTC)
While agreeing with that, note that "scholarly" and "not scholarly" should not be taken as synonyms of "good" and "bad". "Scholarly" sources are superior for references specific things, but are not good at all for weighing whether a topic is notable. There are too many "scholarly" looking journals accepting nearly anything, with payment. Time or subscription newspapers are not good sources for surprising things, but they are very good for indicating the topic is of general interest. Very often, Time or subscription newspapers are good as reputable secondary sources, while scholarly journals are good as reliable primary sources (for the facts concluded by their articles). --SmokeyJoe (talk) 23:58, 3 November 2016 (UTC)
However, these RFCs are not about reliability or notability of sources. Let's not complicate things. Being completely agnostic about sources, would the proposed schemes give the average reader proper citation information? or would they be confusing? and, secondly, how do these changes impact editing? if citations are to be encouraged, do the proposals make the task of editors easier or at least more complete? finally, do they make the CS1 programmatic application harder to maintain relative to the supposed merits? Is the increased complexity worth it? Afaic, up to now the RFCs are ambiguous as far as these questions are concerned. 72.43.99.138 (talk) 15:28, 4 November 2016 (UTC)
This does raise the question of papers which allow limited access - e.g. 10 articles per day (and use clickbait to make you go over!).. These should be noted too, and hence some kind of indirection is probably in order. E.G. access=open, access=paid subscription, access = New York Times : here New York Times can be a virtual redirect to "(10 free pages per day, then subscription)" which could be changed if the newspaper's policy changes. All the best: RichFarmbrough, 00:53, 20 November 2016 (UTC).
Proper closure?
Is this a proper closure? I reverted Editor Headbomb's closure of this RFC (and would have reverted the other had not another editor beaten me to it) not for the conclusions that Editor Headbomb reached but because that editor is not an uninvolved editor. My revert was reverted by another with the claim that there is no 'policy' stating that closures can only be done by uninvolved editors. That is probably correct, however, closure of an RfC by the originator seems to me to be much less desirable than the ideal because we presume (I think) that when an uninvolved editor closes an RfC, it is closed without bias. Better, I think, to revert this closure and allow an uninvolved editor to close it.
—Trappist the monk (talk) 00:15, 1 December 2016 (UTC)
Just my thoughts as the other editor to undo the close. The policy is here: WP:RFCEND, in particular “It can be formally closed by any uninvolved editor.", with the other possibilities (withdrawn if unlikely to succeed, moved to another venue, closed by agreement) being far more restrictive and not applying here. This seems particularly appropriate here as such a complex and involved discussion – it is the sort of discussion that might be better closed by an admin.--JohnBlackburnewordsdeeds10:15, 1 December 2016 (UTC)
I think it is not a proper closure. Headbomb should have respected the undo of his first closure and not gone ahead and redone it. That is overruling behaviour. The close is a poor one, since it's based too heavily on vote counts (see WP:RFCEND for that as well), and not on strength of arguments. Headbomb not only created the RFC but also replied to !votes. That's fine, but doing it disqualifies any editor from taking a neutral view of the strength of arguments. Your reversion was fine, Trappist the monk, and I think it would be fine to do it again. --Stfg (talk) 11:56, 1 December 2016 (UTC)
@Stfg: For the record, Editor Headbomb did not revert my revert of the closure; Editor Amaury reverted me.
Sorry, but that is just not true. Look at this page's history from 15:45 30 November 2016 onward. Editor Headbomb made two edits: one a 15:45 and the second at 16:18; neither of those edits revert Editor JohnBlackburne's revert.
I stand corrected. The 16:18 was a close of the second RfC, and he may have been typing it and not noticed the revert of the first before saving. --Stfg (talk) 17:50, 1 December 2016 (UTC)
The close is improper and will likely lead to more drama. Better to wait until someone uninvolved closes it. User:Amaury deserves a trout. I will revert the closure if no one else does. — Martin (MSGJ · talk) 12:31, 1 December 2016 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Stand-alone lists being nominated as Good Articles
Note that one of the three proposals in this RfC involves creating a separate "Good Lists" rating and process independent of the GA process. BlueMoonset (talk) 18:15, 5 December 2016 (UTC)
Hi – it has always bothered me that the Contents box on every page results in a large whitespace to the right. I have found that the template:TOCleft directly beneath the introduction, (above the first subheading), allows the first sub-paragraph to wrap around the contents box, making for a much neater presentation. Examples are Sibsey Island, Barry Egan (hurler) and Justin Lefkovitch. It does not work in every case for some reason, (the first sub-paragraph occasionally wraps above the contents box). I propose that TOCleft be written into the code of the automatically generated contents box so the Contents box is always wrapped around. MarkDask13:24, 2 December 2016 (UTC)
Absolutely not. The advice given at Template:TOC left#Cautions and Help:Section#Floating the TOC exists for a reason; floating the TOC wrecks the formatting on narrow screens, on bulleted lists, on articles containing infoboxes which have the potential to display longer than the lead (which is the majority of articles), and in any instance when it causes the TOC to overrun the first section heading. Don't assume that every reader is using the same screen setup as you. Wikipedia's layout rules may appear arbitrary, but they're the product of fifteen years of experimentation. ‑ Iridescent14:34, 2 December 2016 (UTC)
So would I be correct in assuming that you're withdrawing your original proposal? I'd close it, but I just want to make sure that we're all on the same page before doing anything. Kurtis(talk)02:55, 6 December 2016 (UTC)
Proposal: Subpages tool in userspace, and possibly other namespaces
In 2013, I made a proposal to add a "subpages" link in the tool section of the Wikipedia sidebar. The idea is that this would allow easier access to subpages created by a given user. It's been almost four years since I made that post, and no such feature has been implemented on the English Wikipedia as of yet. I've decided to resurrect this proposal, which received unanimous support at the time, in the hopes that it actually gains some genuine traction towards becoming a reality. Is there anybody who would object? If not, then how can we get the subpages link added to the toolbox? Kurtis(talk)02:40, 6 December 2016 (UTC)
@Kurtis:WP:MOREMENU has a subpages link. If you want to add it to your toolbox you can add something like
mw.loader.using('mediawiki.util').done(function(){// Subpages of current pagemw.util.addPortletLink('p-tb',mw.util.getUrl('Special:PrefixIndex/')+mw.util.wikiUrlencode(mw.config.get('wgPageName')+'/'),'Subpages','t-subpages','Subpages of this page',null,'#t-recentchangeslinked');});
And an easy way to get that link is to look at the contributions for a user, and click "Subpages" in the box at the very bottom. That works at enwiki and commons, but may not work at other projects. Johnuniq (talk) 02:11, 8 December 2016 (UTC)
I just think a subpages toolbox link would be more convenient than the alternatives. It's a hassle to go through the process of clicking their contribution history, and scrolling down to get to a less accessible link. Kurtis(talk)16:21, 10 December 2016 (UTC)
Change implemented, 
/ 
/ 
, 
, 
, 
, 
, 
, 
, 
, 
, 
, 
. 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 
and 
, but smaller and monocolour. Adrian J. Hunter(talk•contribs) 03:43, 31 October 2016 (UTC)
/ 
). Headbomb {talk / contribs / physics / books} 17:54, 25 November 2016 (UTC)
/ 
maybe? I think I'll try a two-tone (grey/green) middle lock. Headbomb {talk / contribs / physics / books} 18:08, 25 November 2016 (UTC)
/ 
and 
after the primary link), but disallow 
for PMCs, and there's no reason why this couldn't be extended to other identifiers. The color could differ, however. Could you add your opinion under B1?Headbomb {talk / contribs / physics / books} 12:32, 30 October 2016 (UTC)
