Wikipedia:Village pump (proposals)/Archive 135

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 an RFC to decide on the visual appearance of the access locks of citation templates. Headbomb {talk / contribs / physics / books} 15:50, 29 October 2016 (UTC)

What the Visual Design RFC is about

Hi all,

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

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

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

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

A few considerations for accessibility need to be taken into account

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

The current set of locks is

• / /

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

• 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,

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.

1. Mild preference for yellow over blue While I prefer GYR myself as a more intuitive scheme, I've asked a few red-green colorblind people and they all agreed RBG was clearer. They could tell the middle lock apart much more easily, and the shapes of the Red vs Green locks were they felt distinct enough they could tell them apart easily. Headbomb {talk / contribs / physics / books} 00:08, 30 October 2016 (UTC)
2. Mild preference for yellow over blue, because streetlights, but nbd.   ~ Tom.Reding (talk ⋅dgaf)  14:33, 30 October 2016 (UTC)
3. GBR Seems much clearer, visually. Yellow is a better intermediate color between red and green connoting access level but blue stands out so much better. Chris Troutman (talk) 19:58, 30 October 2016 (UTC)
4. GBR: Pastel blue is more soothing than dark yellow, which is important especially if many sources are to have these symbols. Esquivalience (talk) 23:45, 30 October 2016 (UTC)
5. GBR On my monitor the yellow doesn't look yellow, but seems like a muddy brown; it therefore lacks an intuitive connection with a yellow streetlight. For that reason I'd go with blue. --SteveMcCluskey (talk) 12:53, 31 October 2016 (UTC)
6. GBR per Headbomb's research with red-green colorblind people. Also like Steve above I get more of a muddy brown than yellow.  — Scott • talk 21:03, 31 October 2016 (UTC)
7. GBR per Steve. --Izno (talk) 11:26, 1 November 2016 (UTC)
8. GYR. GBR looks nice, but it doesn't send me the yellow-caution-signal. Perhaps if the yellow contrast against black was heightened, this option would get more support. ~★ nmaia ^d 15:47, 4 November 2016 (UTC)

   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)

9. GYR. Blue indicates existing links. 4nn1l2 (talk) 16:57, 6 November 2016 (UTC)
10. GBR per Scott's rationale (colorblindness and muddy brown effect). Tony Tan · talk 00:54, 9 November 2016 (UTC)
11. GYR per above. Also could the yellow be made brighter so it looks more like yellow and less like brown? --TerraCodes ^{(talk to me)} 20:52, 12 November 2016 (UTC)
12. GYR per nmaia. Perhaps we could add more red to the yellow lock to make it stand out better. I don't like GBR because it produces the wrong association; if anything I'd much rather keep this yellow-green as registration-only and put blue for open access. Daß Wölf 23:57, 13 November 2016 (UTC)
13. GBR. Blue is easier to differentiate against the other colors. NinjaRobotPirate (talk) 07:49, 16 November 2016 (UTC)
14. GBR. I'm not color blind and I had to adjust my monitor to properly distinguish between the green and yellow beyond shape. Ian.thomson (talk) 08:03, 16 November 2016 (UTC)
15. GYR. Blue doesn't mean anything in a "traffic light" contest. WaggersTALK 12:57, 18 November 2016 (UTC)
16. GYR, as there's no way to intuit if green or blue is "freer". (Addendum: I'd support the unlisted option BGR, which avoids the yellow that seems unpopular but also allows the natural color spectrum do its thing rather than trying awkwardly to force blue into the the place of yellow. 03:31, 26 November 2016 (UTC)) —jameslucas (" " / +) 03:24, 24 November 2016 (UTC)
17. GBR Were it possible to have yellow that is yellow and not some bilious color reminiscent of the content of a bay's diaper, then perhaps, I would choose that yellow. As that is not possible given the white/black background contrast requirements, I must choose the blue option. Were the question phrased to allow !voters to suggest alternate schemes here, I would choose a scheme where the icons are all of the same color and so avoid perhaps inappropriate 'traffic' semaphore color conventions: GO here; proceed to this link with caution; STOP! don't read this link. The purpose of the icon is to simply indicate that a source is free-to-read or, partially- or fully-restricted. Color is not really required to do that so long as the chosen color meets the contrast requirements and the shapes are sufficiently distinct.—Trappist the monk (talk) 15:46, 24 November 2016 (UTC)
18. GBR It's unfortunate that yellow wouldn't show up well –– the muddy color presented is no more intuitive than blue. The blue seems clearly visible. DIY Editor (talk) 03:44, 25 November 2016 (UTC)
19. GYR. From my staff account as head of The Wikipedia Library: I feel pretty strongly that blue isn't the right call here, precisely because it stands out too much. Blue is the 'default' color for all links on the internet, so using it here suggests that it is most common, best, most open, or simply most noticeable. A more intuitive scheme is using Green-Yellow-Red, where yellow does not overly stand out and where it for many connotes an in-between state, as in a traffic light. I do think we should use a different tone/shade of yellow since this one does look muddy, but I prefer it to the consequences of blue, and for registration-required, muddy is at least kind of consistent with the status. Ocaasi (WMF) (talk) 18:56, 29 November 2016 (UTC)
20. GYR – This particular shade of yellow is close to green, so gives a natural association with the desired message "free, with limitations", whereas blue has two disadvantages: it is the default link color, so might be considered the most natural option, and it has stronger contrast, making it more attractive to the eye whereas the green and red options should be more clear-cut. — JFG ^talk 21:26, 3 December 2016 (UTC)
21. GBR but I would actually prefer BBB (blue everywhere) because red and green stick out too much from the page. The information they convey is not more important than the rest of the article. − Pintoch (talk) 22:18, 3 December 2016 (UTC)
22. GBR for those who are colorblind also for more aesthetically pleasing in my mind. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 20:00, 10 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.

1. 50% > 25% > 100%. Although 100% dashed is the biggest difference, it looks pretty bad when printed. 50% is a good compromise, and it's, I feel, a cleaner design since it matches the body of the DHF/EHF options below, which I favour. 100% dashed is better for the EDF bodies, however.Headbomb {talk / contribs / physics / books} 00:08, 30 October 2016 (UTC)
2. 50% > 25% > 100% 25% > 50% > 100% if printing is both a strong determining factor and 100% looks bad on a lot of printers. If either of those are false, then 100% > 50% > 25% 100% > 25% > 50%.   ~ Tom.Reding (talk ⋅dgaf)  14:33, 30 October 2016 (UTC)
3. 100% > 25% > 50%. 50 looks most-like a fully closed shackle, oddly enough, and for some reason 25 is marginally better. I'm less concerned about the printworthiness of these icons and in fact might suggest they aren't printed, ever. They serve no use in print form IMO. --Izno (talk) 12:01, 1 November 2016 (UTC)

   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)

   Er, my failing at English: aren'tshouldn't be would be more correct. --Izno (talk) 12:07, 1 November 2016 (UTC)

4. 100% > 25% > 50%. Per Izno; also at 9x I can't make out the dashes in 25% and 50%. ~★ nmaia ^d 15:47, 4 November 2016 (UTC)
5. 100% > 25% > 50%. Per Izno. 4nn1l2 (talk) 17:02, 6 November 2016 (UTC)
6. 100% > 25% > 50% per Izno. However, I am concerned about the potential for 100% to look bad when printed. Nonetheless, 50% looks like a fully closed shackle. Tony Tan · talk 01:00, 9 November 2016 (UTC)
7. 50% > 25% > 100% 100% doesn't look like a lock to me, and 25% looks to much like unlocked. --TerraCodes ^{(talk to me)} 20:52, 12 November 2016 (UTC)
8. 100% > 25% > 50%. From my normal viewing distance 50% looks closed and 25% is just about discernible. Agree with Izno that we should make sure they look good on the screen, where they're most useful. If they look good in print that's just an added bonus. Daß Wölf 00:04, 14 November 2016 (UTC)
9. 100% is the easiest to differentiate. I have some trouble differentiating between 25%, 50%, and a closed shackle, but most people probably have better eyesight than me. NinjaRobotPirate (talk) 08:06, 16 November 2016 (UTC)
10. 100% > 50% > 25%. From my normal viewing distance, 25% looks like a smudged version of the open lock. Looks like 100% has it, though: a wholly dashed lock is clearer than a partially dashed one. Ian.thomson (talk) 08:09, 16 November 2016 (UTC)
11. 50% > 100%. I agree with the others that 25% is too hard to differentiate. WaggersTALK 12:59, 18 November 2016 (UTC)
12. 50% The dashed portion of any of these options, especially at these sizes, 'grays' that section by emulating the halftone printing process. At larger scales, the dashed shackles appear dashed so the meaning is rather more clear. If any meaning is to be extracted from a dashed shackle at the 9px width, there must be enough visible distinction between the 'gray' and the solid so that the eye can detect it at a glance. The best chance for that is with the 50% version.—Trappist the monk (talk) 16:24, 24 November 2016 (UTC)
13. 100% seems the clearest to me. DIY Editor (talk) 03:42, 25 November 2016 (UTC)
14. 50% > 100% > 25% From my staff account: 50% is clearly a lock and clearly in some in-between state of openness. After that I think 100%% is reasonably ok, but 25% doesn't work for me.
15. 25% or 50%, definitely not 100% which is too fuzzy and loses the "solid metal" connotation. — JFG ^talk 21:26, 3 December 2016 (UTC)
16. 100% is best. I can't differentiate between 25% and 50% so I won't comment on which I prefer. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 20:03, 10 December 2016 (UTC)

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

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

1. DHF > EHF > EDF. The empty green lock can be confused with a stylized lowercase a, especially when printed or when viewed in black and white.Headbomb {talk / contribs / physics / books} 22:49, 10 October 2016 (UTC)
2. DHF: This is the clearest visual representation imo. ‑‑Yodin^T 09:04, 30 October 2016 (UTC)
3. EDF >> DHF > EHF.   ~ Tom.Reding (talk ⋅dgaf)  14:33, 30 October 2016 (UTC)
4. DHF > EHF > EDF Chris Troutman (talk) 20:02, 30 October 2016 (UTC)
5. Prefer the empty green lock and have a slight preference for the half-filled middle lock, so EHF > EDF > DHF. Per my comments above, I don't think the print case is large enough such that it should influence our decision making in these regards. --Izno (talk) 12:13, 1 November 2016 (UTC)
6. Keep the current style. The full red icon looks like a purse, not a lock. How come there's no option to keep the current style? Kaldari (talk) 02:39, 3 November 2016 (UTC)

   @Headbomb: Is there going to be another vote to decide whether or not the current icons should be replaced with the winner of this vote? Kaldari (talk) 19:30, 4 November 2016 (UTC)

   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)

   Imagine you're colorblind for a second here. Or that you're printing things in black and white. Additional reasons are outlined in WP:COLOUR. Headbomb {talk / contribs / physics / books} 13:03, 7 November 2016 (UTC)

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

7. DHF > EHF > EDF. DHF looks more like a lock icon to me. ~★ nmaia ^d 15:47, 4 November 2016 (UTC)
8. EDF > EHF > DHF empty for free; semi-empty for semi-free; and full for non-free. 4nn1l2 (talk) 17:08, 6 November 2016 (UTC)
9. DHF > EHF > EDF. Although 4nn1l2's rationale for EDF > EHF > DHF makes intuitive sense, the empty green lock looks like a stylized lowercase a when viewed without color. Tony Tan · talk 01:10, 9 November 2016 (UTC)
10. DHF per Yodin. --TerraCodes ^{(talk to me)} 20:52, 12 November 2016 (UTC)
11. DHF looks best to me. The others are a bit confusing between of the stylized-A problem. If the open lock could be made to look less like a stylized A, I probably wouldn't have any preference. NinjaRobotPirate (talk) 08:14, 16 November 2016 (UTC)
12. EDF > EHF. To my eyes DHF is just odd, a mishmash of filling from the centre and filling from one side. EDF and EHF are consistent in design approach; filling from the centre isn't side-ist and I find it more pleasing to look at. WaggersTALK 13:03, 18 November 2016 (UTC)
13. DHF as per Headbomb (#1). —jameslucas (" " / +) 03:26, 24 November 2016 (UTC)
14. DHF The dotted lock body reflects its Open Access heritage (the dotted green lock is the orange OA lock except that the green uses narrower line widths and has a slightly more open shackle). That may or may not be a good thing because these icons are not intended to indicate readability in the open access free-to-reuse sense. However, even though I know that the empty-lock-body icon is the same size as dotted, the openness makes it look larger. For that reason, dotted is best. For the registration and subscription lock, half is best because, well, that's my contribution to this mess.—Trappist the monk (talk) 16:36, 24 November 2016 (UTC)
15. DHF seems the most clear. DIY Editor (talk) 03:40, 25 November 2016 (UTC)
16. DHF From my staff account: DHF is best because each one is clearly a lock of some sort and yet they are unique and distinct from eachother. E-first risks the green icon not looking like a lock but just some kind of weird letter. Ocaasi (WMF) (talk) 18:56, 29 November 2016 (UTC)
17. DHF gives the most differentiation between the three possible states. Also would approve a DHD option per Kaldari's comment. — JFG ^talk 21:26, 3 December 2016 (UTC)
18. no filled red lock Like others above, I think a full red lock is not very helpful. It has a very negative connotation, feels aggressive, and as someone above said, looks kinda like a purse. I think an empty, half, dot scheme would be a good solution, but would also support a DHD like Kaldari and JFG have suggested. Wugapodes [t^hɔk] [ˈkan.ˌʧɻɪbz] 20:06, 10 December 2016 (UTC)

Aspect A4) Just don't do it

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

The subscription required template is ambiguous, and our icons differ well enough from page protection that they could not possibly be misconstrued for that. Headbomb {talk / contribs / physics / books} 16:20, 2 November 2016 (UTC)

• I have to agree. Icons are bad, colour coding is bad. Even though I just read the proposal I have already forgotten what the "middle one" (blue/yellow) means. Use your words. All the best: Rich Farmbrough, 22:58, 19 November 2016 (UTC).
  

Visual Design RFC discussion

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)

You can always hover the icons with your mouse, but the point should be clear enough from the icons alone. However, {{reflist}} could certainly be modified to include a legend as well.Headbomb {talk / contribs / physics / books} 16:19, 29 October 2016 (UTC)

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 · talk 01: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)

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

Maybe so, but it's not an icon, and would take a much more of horizontal space. Headbomb {talk / contribs / physics / books} 16:19, 29 October 2016 (UTC)

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. ‑‑Yodin^T 09:11, 30 October 2016 (UTC)

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

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 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). ‑‑Yodin^T 09: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)

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

@Piotrus: You vote in each of the vote's subsection (A1/A2/A3, and B1/B2/B3/B4). Headbomb {talk / contribs / physics / books} 10:25, 31 October 2016 (UTC)

Thanks, but it is too much trouble. I am sorry to say but the designers of the vote overcomplicated it to the extent that, well, we are seeing almost nobody bothering to vote. Through I think we still have community support for... something. With such a bad vote, I am not sure for what, unfortunately. I strongly suggest you restart the vote in a simplified way. Use this one to narrow the choices to 2-3 max. --_{Piotr Konieczny aka Prokonsul Piotrus| reply here} 02:25, 1 November 2016 (UTC)

@Piotrus: It's three simple choices. Color, shackle, body style. Headbomb {talk / contribs / physics / books} 03:19, 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)

• The use of colors suggest a potential accessibility issue. See the guidelines at WP:COLOR. Praemonitus (talk) 16:04, 31 October 2016 (UTC)

  That's already been taken into account in the current options. The shapes differ, and the contrast is 4.5:1 on both black and white backgrounds. Headbomb {talk / contribs / physics / books} 17:08, 31 October 2016 (UTC)

• 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 · talk 01: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? ~★ nmaia ^d 15: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)

That fails the black background requirement.

—Trappist the monk (talk) 17:56, 25 November 2016 (UTC)

It sadly does, yes. Trying to wonder what's possible along that vein. Headbomb {talk / contribs / physics / books} 17:58, 25 November 2016 (UTC)

@Trappist the monk: / / maybe? I think I'll try a two-tone (grey/green) middle lock. Headbomb {talk / contribs / physics / books} 18:08, 25 November 2016 (UTC)

Got it, I think / / . We could also consider schemes like / / . I really like that last one. Headbomb {talk / contribs / physics / books} 18:15, 25 November 2016 (UTC)

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)

Disagree there. We'd lose the clearest distinction between the locks available to most people, and they'd get buried in the sea of blue. Headbomb {talk / contribs / physics / books} 18:29, 25 November 2016 (UTC)

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 an RFC to decide on the behaviour of citation templates concerning when/how to deal with access locks, and free-to-read articles. Headbomb {talk / contribs / physics / books} 15:50, 29 October 2016 (UTC)

What the Citation Template Behaviour RFC is about

Hi all,

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

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

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

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

First aspect

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

That is, do we want to allow all locks anywhere

• 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 .

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.

• 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.

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

Second aspect

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

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

but is ambiguous if more than one link is given:

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

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

• Smith, J. (2016). "Fictitious title" . Fictitious Journal. 1 (2): 3. doi:10.1234/123456.
• Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456 .

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

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

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

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

or as

• 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. PMC 4309825 .

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

Citation Template Behaviour RFC !Vote

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

Aspect B1) Allow all locks vs Restrict locks

Allow (not mandate) all locks

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

Restrict locks (current behaviour)

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

1. Allow all locks if someone wants to comb through all identifiers and flag them as free/non-free, I don't see that as a bad thing. This would then allow us to deprecate |registration= and |subscription= in B3.Headbomb {talk / contribs / physics / books} 00:09, 30 October 2016 (UTC)

   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)

2. Restrict locks if there is an assumption that sources are free to access then there is no need to indicate the default position of free access. A green lock on every free access source is going to be a lot of clutter. Nthep (talk) 14:31, 30 October 2016 (UTC)
3. No green locks: The locks are useful only to indicate non-free content and the default should be free access like this:
   • 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 .

   — Preceding unsigned comment added by RexxS (talk • contribs)

4. restrict locks so that any lock symbol that is used expresses actual information and not sloppy guesswork. am disturbed by the assumption that doi parameters are treated by default as not free. none of these symbols should be used based on assumptions Jytdog (talk) 21:31, 30 October 2016 (UTC)

   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)

   It's not my idea. However, it was the rationale behind the current implementation. Headbomb {talk / contribs / physics / books} 22:24, 30 October 2016 (UTC)

5. Restrict locks (and no green locks) per Nthep. Researchers are mainly going to be interested in the primary link. Adding icons to all the links is unnecessary clutter and confusing. I also agree with RexxS that open access should be the assumed default and we don't need to add green locks. Kaldari (talk) 17:22, 31 October 2016 (UTC)

   Open access is clearly not the default for the vast majority of bibcodes, dois, pmids, etc. Headbomb {talk / contribs / physics / books} 17:52, 31 October 2016 (UTC)

6. Allow all locks. The fact that there's disagreement about this is itself evidence that we should allow flagging of both free and non-free sources, because the nature of the "default" expectation depends on the topic area. It must be nice to live in a world where the default expectation is open-access (or at least free-to-read), but that's certainly not the case in the topic areas I work in. Most journal publications are paywalled, many of those will have an alternative source (like PMC) which is free-to-read, and there's no particular reason we should expect readers to know how that works. Opabinia regalis (talk) 20:32, 4 November 2016 (UTC)
7. Allow all locks. This supposed convention that DOI (etc) links are assumed non-free, and other links are assumed free, is completely reader-unfriendly. I don't know how readers are supposed to pick up on this convention. Therefore, we need to be consistent across all the links. Ideally, we would flag only those links which are not 100% open access, by the logic that virtually all links in Wikipedia articles (internal links in the article text, external links in the "external links" section, and so on) are assumed to be freely accessible, so we should mark those links that violate this convention. However, this raises the issue of how to deal with links whose subscription/registration-required status is not known. To solve that problem it seems necessary to show locks on all links within journal references when the subscription/registration-required status is known, and to show no lock when no information is available. — This, that and the other (talk) 00:33, 5 November 2016 (UTC)

   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)

8. Allow all locks, to convey more, useful, information in a compact way. More information is ok, if it's organized & easy to see.   ~ Tom.Reding (talk ⋅dgaf)  12:57, 8 November 2016 (UTC)
9. Allow all locks, per "This, that and the other"'s rationale. However, I am concerned about potential clutter and think there should be a better system, such as the one mentioned by the aforementioned user. Tony Tan · talk 02:16, 9 November 2016 (UTC)
10. Oppose general proposal. Hell if I can figure out where to oppose the entire idea here, or if that ship has already sailed. I understand the problem with the subscription-required tags, but I think there are other ways to solve the ambiguity issue than this. There are several concerns that I have with the entire proposal:
    1. First, universality. Although its been a little bit since I've been active there, I'm very proud of my work at FAC, where I often focus on reference quality and citation formatting. The proposers here say that this is about scholarly publications and not all sources, but let me be very clear here: consistency in reference formatting is a Featured Article requirement; if you're going to implement this here, you're going to need to implement this elsewhere, too, and I do not think the ramifications of applying these standards to books or non-scholarly periodicals have been fully considered. The idea that newspaper-article access levels can be tracked by bot, in particular, strikes me as naive. In fact, I'm dubious that bots can do the things that have been handwaived here as a problem for bots to solve, and I'd like to see some controlled-environment testing of that assertion.
    2. Second, implied bias. In the "real world" outside Wikipedia, I agree that open access is "better" than closed access, especially in scholarly publications (which are often, at least in part, publicly funded). But there is no obligation to base articles here on open-source content. Indeed, if the best quality sources are less-easily available, those remain the best quality sources. Cutesy icons that make paywalled material look like it is "bad" (and make no mistake, bright red padlocks look bad, in part because they look like citation error text), imply that paywalled or restricted-access material is inferior. Further, I specifically oppose the idea floated somewhere above by an IP editor who I shan't track down, suggesting that editors have an obligation to provide links to the most-free source of their references. Specifically, this places republication sites like ResearchGate as "preferably" to journals' actual official digitization sites; such cases are clearly more accessible, but I question whether they are innately better. I'm here to write open-access articles for an open-access encyclopedia, but I don't necessarily believe that extends any obligation on me to support open-access sourcing in my references.
    3. Third, this proposal has not in any way discussed how an editor is intended to interact with the system when working from a print source. I know, I know, paper, right? But I do a lot of my article research at libraries, including (at times) specialist and reference collections. Frequently, I have no idea what sources are available online, if any. I link comparatively little. Still, sometimes I have the doi for an article, even if I'm not working from an online copy. I include that doi in my citations because I assume it is of use to editors. I am not interested in auditing its open-access level. I trust that no aspect of this proposal will make use of these locks mandatory? Squeamish Ossifrage (talk) 15:59, 11 November 2016 (UTC)

    RE a few things.

    "The proposers here say that this is about scholarly publications and not all sources".

    No one says that. The system is universal, and would cover all such sources.

    "The idea that newspaper-article access levels can be tracked by bot, in particular, strikes me as naive."

    Again, no one claimed that. Bots can do a lot, and will mostly be helpful with sources that have identifiers. Humans will need to get involved as well, just like they are involved now with |subscription=yes.

    "But there is no obligation to base articles here on open-source content."

    That hasn't changed. The idea to let the reader know what type of source it is before hand, so they aren't surprised with a paywall/40$ fee, saving both their time and bandwidth. This is already done via parameters like |subscription=yes or templates like {{subscription required}}. There is no implication of inferiority.

    "Third, this proposal has not in any way discussed how an editor is intended to interact with the system when working from a print source."

    That's because print sources don't have links. If you have the doi, you can still put it. If you're not interested in finding out the access level, leave it blank. Others can find out and flag it.

    "I trust that no aspect of this proposal will make use of these locks mandatory?"

    The system is optional, just like the current system is.

    For an example of the current version (following the "restrict locks" convention) on one of your FAs, see Calostoma_cinnabarinum#References. Headbomb {talk / contribs / physics / books} 17:09, 11 November 2016 (UTC)

11. Allow all. There are fair arguments for both sides. However, if someone wants to label the links, I think they should be able to do so. The locks can produce unnecessary clutter in some Wikipedia articles, but in less technical articles, labeling the various links could resolve a lot of confusion. Not everyone is familiar with this or has an idea of what the default is for each type of link. NinjaRobotPirate (talk) 08:48, 16 November 2016 (UTC)
12. Allow all locks. A few years back, HTTPS links used to have a blue lock next to them. I think this idea is similar, and that soon we'll have an icon to indicate that a link is not secure. Just because the default behavior is to paywall information and knowledge, doesn't mean we need to follow that behavior. I feel that in a few years paywalled access is going to shrink, because the issue is being highlighted more. Having locks to indicate how much of the information we rely on is walled off on one of the major sources of knowledge on the internet is definitely helpful (maybe we'll even see a headline on the clickbait sites like "oh snap! Wikipedia's just paywalls to shame" or whatever!). —Hexafluoride ^{Ping me if you need help, or post on my talk} 12:35, 19 November 2016 (UTC)
13. Restrict. Broadly, cs1|2 identifiers link to paywalls and registration gates so these sources are not free-to-read. That is the norm for cs1|2 identifiers. There are, of course, exceptions: PMC, arXiv, RFC, etc. cs1|2 knows that these are not the norm so automatically highlights these identifiers with the green free-to-read icon. There is no need to add little red or yellow locks to identifiers that normally link to sources that are in someway restricted; that is the normal and so the expected state for these links. When an identifier links to a free-to-read source, that is novel, so we should highlight that identifier so that readers know that that particular identifier is different. In the similar but opposite case, most urls in |url= and |chapter-url=, and external links elsewhere throughout Wikipedia whether part of cs1|2 citations or not, refer to free-to-read sources. Marking these free-to-read sources as free-to-read conveys no new or useful information to the reader so these sources should only be marked when there is a registration or subscription cost to the reader. Do not highlight the norm. —Trappist the monk (talk) 19:40, 24 November 2016 (UTC)
14. Allow all locks. I'm commenting from my staff account as head of The Wikipedia Library, because I support and have worked on implementing this feature--so it's simply transparent to do so. If closers want to discount this as an out-of-place staff opinion that's fine of course. Fundamentally, locks allow readers to make decisions about whether and how to verify a source. It is very non-trivial that many sources are closed access--not free to read--since one of the core strengths of Wikipedia is the ability to and benefit from "checking the source". I'm well-aware that WP:PAYWALL doesn't preferences open sources over closed ones and have always supported that line. Yet this is not a comment on which sources to use, but how to indicate to the user what experience they will have when they click through. As a fundamental principle of usability, it's good to let the reader know what to expect, and these locks do so in a predictable and lightweight way. Second, links with open locks will be clicked on more, as readers without institutional access come to associate a positive experience with them. This provides added incentive for publishers to make sure there are free-to-read versions of their content available in ways consistent with copyright. This is not a political stance (although open access is undoubtedly better for readers than closed access); it's a simple win-win that encourages a good experience for readers while increasing the intelligent consumption of Wikipedia's content. Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)

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

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

Automatically flag non-free sources

• Artin, M. (1991). Algebra. Prentice Hall. ISBN 0-13-004763-5. MR1129886 .
  

Don't flagged by default (current behaviour)

• Artin, M. (1991). Algebra. Prentice Hall. ISBN 0-13-004763-5. MR1129886.

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

1. Don't flag by default as it would create an inconsistent look in articles that contain possibly sometimes not-free identifiers which haven't been flagged as not being free. Headbomb {talk / contribs / physics / books} 00:09, 30 October 2016 (UTC)
2. don't flag by default consistent with my !vote above. these symbols should not be based on assumptions. Jytdog (talk) 21:32, 30 October 2016 (UTC)

   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)

3. Don't flag by default per Headbomb as this could cause confusion, and because I voted for restricting locks above. Kaldari (talk) 17:27, 31 October 2016 (UTC)
4. Per Headbomb, don't flag by default, though it sure would be nice to avoid needing to set the access state for everything. --Izno (talk) 12:31, 1 November 2016 (UTC)
5. Flag by default Best to provide as much information as we have available. Inconsistency seems like a very minor issue. Opabinia regalis (talk) 20:35, 4 November 2016 (UTC)
6. Conditional: Flag by default if/when sometimes not-free identifiers which haven't been flagged as not being free are all (mostly) identified/worked-around/etc. Until then, Don't flag by default.   ~ Tom.Reding (talk ⋅dgaf)  13:03, 8 November 2016 (UTC)
7. Flag by default per "Opabinia regalis". We have to start somewhere, so we should flag sources by default when they are 100% confirmed to be non-free. Tony Tan · talk 02:21, 9 November 2016 (UTC)
8. Flag by default. I can see the argument that this could be confusing, but if we know what the access level is, we should probably provide that information. NinjaRobotPirate (talk) 08:52, 16 November 2016 (UTC)
9. 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. —Hexafluoride ^{Ping me if you need help, or post on my talk} 12: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)

10. 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)
11. 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

Deprecate

Supported

• Smith, J. (2016). "Fictitious title" . Fictitious Journal. 1 (2): 3.
• Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456
• Smith, J. (2016). "Fictitious title" . Fictitious Journal. 1 (2): 3. doi:10.1234/123456.
• Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456
• Smith, J. (2016). "Fictitious title" . Fictitious Journal. 1 (2): 3. doi:10.1234/123456

Unsupported

• Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. (registration required (help)) Error: |registration= is deprecated, use instead |url-access=registration.
• Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456. (registration required (help)) Error: |registration= is deprecated, use instead |doi-access=registration.
• Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456. (registration required (help)) Error: |registration= is deprecated, use instead |url-access=registration or |doi-access=registration.

Support both systems (current behaviour)

Supported

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

Unsupported

• 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.

1. Deprecate. Too many problems with the old system, no sense in supporting it. One system to rule them all is clearer to everyone. Headbomb {talk / contribs / physics / books} 00:09, 30 October 2016 (UTC)
2. 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. ‑‑Yodin^T 08:59, 30 October 2016 (UTC)
3. 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)
4. Deprecate per Headbomb. Nthep (talk) 14:33, 30 October 2016 (UTC)

   @Nthep:, you're aware that to deprecate these parameters we need to allow for all locks to be used, right? Because your vote in B1 would prevent deprecation from happening. Headbomb {talk / contribs / physics / books} 10:38, 4 November 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

   Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456. (registration required (help)) Headbomb {talk / contribs / physics / books} 12:46, 4 November 2016 (UTC)

   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)

   It is nonetheless how the parameter is currently used in many cases. Deprecating without allowing for yellow/red locks on dois would mean losing that information. Headbomb {talk / contribs / physics / books} 23:25, 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)

   I suppose marking doi-only works are required subscription could be deprecated as well. After using locks in the wild, I'm coming around to that option myself. Headbomb {talk / contribs / physics / books} 20:12, 7 November 2016 (UTC)

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

   @Izno: how so? What's different about subscriptions than the above examples/votes don't apply to them? Headbomb {talk / contribs / physics / books} 10:39, 4 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)

6. Deprecate Opabinia regalis (talk) 20:36, 4 November 2016 (UTC)
7. Deprecate, per above votes.   ~ Tom.Reding (talk ⋅dgaf)  13:07, 8 November 2016 (UTC)
8. Deprecate if most resulting errors could be fixed quickly. Having two systems would be too confusing to readers and editors alike. Tony Tan · talk 02:25, 9 November 2016 (UTC)
9. Deprecate. The locks are cleaner and alleviate the problems caused by the old system. —Hexafluoride ^{Ping me if you need help, or post on my talk} 12:43, 19 November 2016 (UTC)
10. 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)
11. 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.

Always autolink titles with free identifiers

• Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC 4309825 .
• 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 .

Autolink titles with PMC only (current behaviour)

• Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC 4309825 .
• 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. PMC 4309825 .
  
• 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.

1. Always autolink would be a super useful feature that would also have a side benefit of greatly reducing clutter in the edit window. Headbomb {talk / contribs / physics / books} 00:09, 30 October 2016 (UTC)
2. 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. Kanguole 01: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. Kanguole 15:29, 1 November 2016 (UTC)

3. 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=. ‑‑Yodin^T 09:53, 30 October 2016 (UTC)
4. (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.)
5. Always autolink — clear benefit to readers and editors. Carl Fredrik 💌 📧 11:02, 30 October 2016 (UTC)
6. 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)

   The question is about all free identifiers. You said you want to autolink pmc, but not autolink free bibcode/doi etc. Why this inconsistency? Headbomb {talk / contribs / physics / books} 23:47, 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)

   You don't edit much on health content, do you. Jytdog (talk) 15:15, 1 November 2016 (UTC)

   That is irrelevant. The nothing in those examples depend on PMID being there on not. No one is proposing to remove PMIDs from articles, they just aren't needed here. Headbomb {talk / contribs / physics / books} 15:22, 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)

   While the majority of articles with PMCs will have PMIDs, many won't. See e.g. PMC 1122408. So throwing an error here would be inappropriate. Headbomb {talk / contribs / physics / books} 14:42, 7 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 PMID 18425890. 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)

   In cs1|2, PMC (and the other identifier labels) do link to their respective articles.—Trappist the monk (talk) 17:54, 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)

7. 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)
8. 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)
9. 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)

   Yes, autolinking has always been about free official full versions. PMIDs and other non-free identifiers are not up for autolinking. Headbomb {talk / contribs / physics / books} 22:23, 4 November 2016 (UTC)

10. Always autolink title for better usability if the links always lead to free, official, and full versions according to Headbomb. Tony Tan · talk 02:33, 9 November 2016 (UTC)
11. 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. —Hexafluoride ^{Ping me if you need help, or post on my talk} 12:48, 19 November 2016 (UTC)
12. 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)
13. 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)

Which option keeps the current status quo unchanged? Hchc2009 (talk) 17:06, 29 October 2016 (UTC)

There's no real 'status quo' since we just rolled out the update and the current behaviour is tentative. The current behaviour is indicated above, however. Headbomb {talk / contribs / physics / books} 17:10, 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...

• {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456}} →

Author (2010). "Title". doi:10.1234/123456. {{cite journal}}: |author= has generic name (help); Cite journal requires |journal= (help)

• {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=free |doi-access=subscription}} →

Author (2010). "Title". doi:10.1234/123456. {{cite journal}}: |author= has generic name (help); Cite journal requires |journal= (help); Invalid |doi-access=subscription (help); Invalid |url-access=free (help)

• {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=subscription |doi-access=free}} →

Author (2010). "Title". doi:10.1234/123456. {{cite journal}}: |author= has generic name (help); Cite journal requires |journal= (help)

...while I think it should do the following (which doesn't match either of the two offered options):

• {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456}} →

Author. (2010). "Title" . doi:10.1234/123456.

• {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=free |doi-access=subscription}} →

Author. (2010). "Title" . doi:10.1234/123456.

• {{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=subscription |doi-access=free}} →

Author. (2010). "Title" . doi:10.1234/123456 .

—RP88 ^(talk) 17:43, 29 October 2016 (UTC)

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)

• Comment It looks like you have three images here. File:Lock-red.svg and File:Lock-green.svg are CC0, which is good, but File:Lock-yellow.svg for some reason is CC BY-SA which will give you trouble if someone wants to not have these locks have to be linking to the image description pages. Anomie⚔ 18:50, 29 October 2016 (UTC)

  I've marked it as CC0. That was an oversight/misclick. Headbomb {talk / contribs / physics / books} 12:51, 30 October 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)

These locks have nothing to do with editing, and everything to do on whether or not you can access the source in question. Headbomb {talk / contribs / physics / books} 00:06, 30 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. ‑‑Yodin^T 09: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 per Ozob, Mark Viking and Martin of Sheffield above. Please don't do this. Doug Weller talk 13:17, 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! ‑‑Yodin^T 09:57, 2 November 2016 (UTC)

There wasn't a consensus to put locks in citation templates, just a bunch of bored editors adding code. KATMAKROFAN (talk) 02:49, 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)
• No locks: As I said above, use words. All the best: Rich Farmbrough, 00:47, 20 November 2016 (UTC).
  

Maintenance burden

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)

@WhatamIdoing and Headbomb: Perhaps just use |access={{show by date|2017|1||subscription|free}} (or whatever the right parameter and value are)? Anomie⚔ 16:42, 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). ‑‑Yodin^T 09: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 · talk 02:40, 9 November 2016 (UTC)

Phrasing for the last aspect

Regarding the last question in this omnibus RFC (third aspect / aspect B4):

1. 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.
2. 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?

Kanguole 10:51, 30 October 2016 (UTC)

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.

If autolinking isn't desired by default, then it could always be enabled on a per-citation level via something like |autolink=yes/|autolink=bibcode. Headbomb {talk / contribs / physics / books} 12:25, 30 October 2016 (UTC)

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. Kanguole 12:53, 30 October 2016 (UTC)

The RFC is to see if such a feature is desired or not. The exact implementation will come later. Headbomb {talk / contribs / physics / books} 14:48, 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.) Kanguole 01: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 doi has ever been shown to resolve to two different levels of access pages. Do you have a real example of such a case? Headbomb {talk / contribs / physics / books} 00:24, 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)

I have never witnessed that in the wild. − Pintoch (talk) 09:39, 31 October 2016 (UTC)

Wonderful! So this is not something to worry about. Ozob (talk) 00:15, 2 November 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.

Headbomb {talk / contribs / physics / books} 17:25, 1 November 2016 (UTC)

This would be entirely logical. It was not the intent of the founders of the open access social movement but it seems practical to me. Thanks for mocking this up. Blue Rasberry (talk) 17:51, 1 November 2016 (UTC)

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: Rich Farmbrough, 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.--JohnBlackburne^words_deeds 10: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.

—Trappist the monk (talk) 13:51, 1 December 2016 (UTC)

Trappist the monk: I know. But he did revert JohnBlackburne's original undoing of his first close. --Stfg (talk) 16:22, 1 December 2016 (UTC)

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.

—Trappist the monk (talk) 16:35, 1 December 2016 (UTC)

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)

Agreed per JohnBlackburne and Stfg. GenQuest ^{"Talk to Me"} 13:19, 1 December 2016 (UTC)