Policy   Technical   Proposals   Idea lab   Miscellaneous  
Shortcuts:

New ideas and proposals are discussed here. Before submitting:
« Older discussions, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135
Centralized discussion
Proposals: policy other Discussions Ideas
For a listing of ongoing discussions, see the dashboard.

Access locks: Visual Design RFC

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.1234Freely accessible. 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

  • Freely accessible / Free registration required / Paid subscription required

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): Freely accessible, Freely accessible
  • Yellow (free, with conditions): Free registration required, Free registration required, Free registration required, Free registration required, Free registration required, Free registration required, Free registration required
  • Blue (free, with conditions): Free registration required, Free registration required, Free registration required, Free registration required, Free registration required, Free registration required, Free registration required
  • Red (not free): Paid subscription required, Paid subscription required

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
Freely accessible / Free registration required / Paid subscription required Freely accessible / Free registration required / Paid subscription required
Freely accessible / Free registration required / Paid subscription required Freely accessible / Free registration required / Paid subscription required

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)

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

Free registration required (100%) vs Free registration required (50%) vs Free registration required (25%)
or, depending on Choice A1
Free registration required (100%) vs Free registration required (50%) vs Free registration required (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)

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

Freely accessible / Free registration required / Paid subscription required (DHF) vs Freely accessible / Free registration required / Paid subscription required (EHF) vs Freely accessible / Free registration required / Paid subscription required (EDF)
or, depending on Choice A1
Freely accessible / Free registration required / Paid subscription required (DHF) vs Freely accessible / Free registration required / Paid subscription required (EHF) vs Freely accessible / Free registration required / Paid subscription required (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. ‑‑YodinT 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)

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

like this

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

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. ‑‑YodinT 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 OA icon.
What we currently use at {{Closed access}}.

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

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

Same comment as above, the idea of not including the original lock was that purists consider it should only be applied to sources that are free to reuse (so, appropriately licensed). But yeah I agree the orange one is better known. Personally I am happy with any colour, really. (But it should be an icon, not like the big lock image above.) − Pintoch (talk) 22:22, 29 October 2016 (UTC)
AIUI, the "default orange" means libre (=you can copy and re-use this source), not gratis (=you can read this source without paying $40). What we're trying to signal here is gratis. I think we would do the libre community a disservice by trying to teach our millions of readers that the orange padlock that originated in the libre community means "free as in beer". WhatamIdoing (talk) 04:19, 30 October 2016 (UTC)
It's a fair point, and OA is great project, but as pointed out above, keeping our icon colours separate is a good thing, as it doesn't muddy the waters – we're only concerned with whether the article can be read freely (gratis), not if it has an open license (libre). ‑‑YodinT 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, open access publication - free to read. 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 Lock-green.svg and Lock-green-alt.svg are especially problematic, as readers might infer they indicate sources that are "more free" than open access publication - free to read. Instead, I suggest using icons that are visually very distinct from open access publication - free to read. 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 Padlock-closed and Padlock-open, 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)

Access Locks: Citation Template Behaviour RFC

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.1234Freely accessible. 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 Free registration required and Paid subscription required after the primary link), but disallow |url-access=free (which would respectively display Freely accessible 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 Freely accessible after the doi link), but disallow |doi-access=registration and |doi-access=subscription (which would respectively display Free registration required and Paid subscription required after the doi link, if allowed). The point (currently at least) is to reduce the amount of 'visual' clutter. However, we need to decide if that convention is one we want to make official, or if we want to allow more flexibility in the system.

That is, do we want to allow all locks anywhere

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

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

Second aspect

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

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

but is ambiguous if more than one link is given:

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

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

Third aspect

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

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

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

or as

or do we remove the autolinking from the PMC identifier?

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

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" Freely accessible. Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234 Freely accessible. doi:10.1007/JHEP03(2010)094 Paid subscription required.
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 Freely accessible. 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)
    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:
    — 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)

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. MR 1129886 Paid subscription required.
Don't flagged by default (current behaviour)
  • Artin, M. (1991). Algebra. Prentice Hall. ISBN 0-13-004763-5. MR 1129886.

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)

Aspect B3) Deprecate old system vs support both old and new systems

Deprecate

Supported

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

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. ‑‑YodinT 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)

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

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=. ‑‑YodinT 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)

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=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.  Invalid |url-access=free (help); Invalid |doi-access=subscription (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"Paid subscription required. doi:10.1234/123456Freely accessible. 
...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" Paid subscription required. doi: 10.1234/123456 Freely accessible.
—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 [1], 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 there 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). (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) Lock-red.svg

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. ‑‑YodinT 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 Freely available on 20 July 2020 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! ‑‑YodinT 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). ‑‑YodinT 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
This would replace the current (via |subscription=yes)
  • Smith, J. (2010). "Title of article". Time Magazine: 47. Retrieved 2016-11-01. (subscription required (help)). 
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)
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).

Draft Namespace Redirects

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

Support deletion

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

Oppose deletion

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

Alternative proposal: Delete after six months

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

  • Support as proposer. -- Tavix (talk) 21:55, 5 November 2016 (UTC)
  • Support. Abandoned drafts are deleted per G13 after six months. It makes sense to apply the same to draft -> main redirects. Tony Tan · talk 02:51, 9 November 2016 (UTC)
  • Support By same rationale as my original proposal, as this proposal is more specific in the time frame and accomplishes the same end. Gluons12 ☢|☕ 16:59, 9 November 2016 (UTC).
  • Oppose just as I oppose the WP:G13 criterion entirely. Age is not a qualifier for deletion. Ivanvector (Talk/Edits) 20:44, 9 November 2016 (UTC)
  • Oppose - There is very little to no benefit in deleting these redirects, while there is no harm and benefit in retaining them. One is more likely to realize there is already an article on a topic they may wish to start a draft about if the redirects are retained. Furthermore, even if all links to the draft were removed, someone may still go to, stumble across, or return to the former title at any time in the future.— Godsy (TALKCONT) 03:34, 11 November 2016 (UTC)
  • Oppose per Godsy. There is little harm in having these redirects around, and they also have the benefit of informing users that an article already exists about a subject, in case they jumped straight to drafting without first searching for the title. Mz7 (talk) 04:53, 20 November 2016 (UTC)
  • Oppose same reasons as above. I regret this tendency to want to "tidy up" in cases where the glorious chaos is an exact match for the behaviour of human editors. All the best: Rich Farmbrough, 15:05, 20 November 2016 (UTC).

Comments

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

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

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

Example image

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

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

Re-use mockup.jpg

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

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

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

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

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

Content translation tool to Draft: space

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

Add HTML5 autofocus attribute to improve Wikipedia search user experience

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

Information about diseases that could be eradicated!

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

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

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

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

RfC: AWB bot ref reordering

Should an AWB bot reorder refs? ―Mandruss ☎ 21:12, 19 November 2016 (UTC)

This dispute has apparently been ongoing for seven (7) years, starting when Wikipedia:AutoWikiBrowser (AWB) was modified to support the reordering of a consecutive string of refs into ascending citation number sequence. This function is being used by bot(s) to do these edits on a large scale. I am not going to go into the history of the dispute, as (1) I am not very familiar with it, and (2) I don't think that is relevant or useful to this discussion. Let's pretend that this is 2009, an AWB developer has added reordering per WP:BOLD, and that has been challenged per WP:BRD. This RfC is the D phase of that BRD process. Most recent related discussion: Wikipedia talk:Citing sources#Reference re-ordering.

I am framing this as a question rather than a proposal, but I still think this page (Wikipedia:Village pump (proposals)) is the best venue for this. It could have been done on AWB's talk page with discussion notices here and elsewhere, but those notices don't seem to attract much attention. If someone strongly disagrees with that, they are free to move this.

Suggested !votes are:
Yes - AWB bots should reorder refs
No - AWB bots should not reorder refs
Reforder - Compromise solution described at #Compromise proposal: AWB bot ref reordering. ―Mandruss ☎ 21:12, 19 November 2016 (UTC)

Survey: AWB bot ref reordering

(no threaded discussion)
  • Comment - Note to closer: I strongly feel that a no-consensus result here should mean no AWB reordering; i.e. the consensus burden is on those who wish to reorder. Consensus should be required to make a controversial change, and that change occurred in 2009. ―Mandruss ☎ 21:18, 19 November 2016 (UTC)
  • Comment I don't think a "let's pretend" (as in "Let's pretend it is 2009") RFC is a good idea. I would rather discuss either the substantive issue or a way forward. All the best: Rich Farmbrough, 22:47, 19 November 2016 (UTC).
  • No. There should be no automated re-ordering of refs to retain the chronological appearance of footnote numbers, particularly not over objections. Previous discussion: Nov 2016, Nov 2016, May 2015, Feb 2015, Feb 2014, July 2010, May 2010, April 2010. The feature was added to AWB in 2009 with very little input. It should have been discussed more widely, because editors may add refs in a particular order for editorial reasons. A simple example:
Mary likes cake, but John doesn't.<ref name=Mary/><ref name=John/>
Someone will argue that we could place the Mary ref inside the sentence, but when there are lots of refs and several clauses, it looks cluttered to do that. And there may be other reasons for the order, including that the first ref is a primary source and the second a supporting secondary one; that the first discusses the issue more clearly than the second; or that the first is the source most experts in the field will expect to see.
According to WP:AWBRULES, "If challenged, the onus is on the AWB operator to demonstrate or achieve consensus for changes they wish to make on a large scale". Study 329 is one example of what happens instead: AWB reordered refs on 4 May 2015. I moved them back. A second AWB editor reordered them on 5 May. I added bots deny to stop it. The second AWB editor removed bots deny on 9 May. A third AWB editor reordered the refs again on 9 May. SarahSV (talk) 00:15, 20 November 2016 (UTC)
  • Yes/Reforder Like I said before, refs should be in order. If you have [2][1][14][4], you're telling the reader to jump around a list of reference for no good reason. [1][2][4][14] is the natural way of presenting things. Now if some specific article warrants deviation from this for some obscure reason, then deny AWB on that specific article, but this is a legit fix in 99% of cases. The usual workaround is to use {{R}}, which AWB will leave alone. The <1% of articles that warrants a deviation from this behaviour shouldn't block efforts to improve the presentation on the >99%. I've cleanedup thousands of articles making those fixes for the last 6 or so years, and I've had 2 complaints. A fail rate of 2/10,000+ is more than acceptable. Headbomb {talk / contribs / physics / books} 00:35, 20 November 2016 (UTC)
I wonder, Headbomb, if there is some misunderstanding here as to how cite numbers are used as cites are in order until someone using AWB comes along and changes them. The cite numbers relate to the order the cites were placed in the article as a whole, not necessarily in the sentence in question. When a cite is used more than once, the number remains the same throughout the article, so the numerical order of cites may appear disjointed in places. Sometimes there may be several cites in one sentence, and if placed next to the information they are citing (which is often done) then the sentence may read "Splot was born in Swansea,[13] on 13 March 2000,[7] to parents John Splot, an organ grinder,[5] and Mary Splot, a Suffragette.[14]" This is appropriate usage, and no AWB would change the sequence order, and the reader could check each item they were interested in by clicking on the number, and going to the relevant citation. However, in order not to inhibit reading flow unnecessarily, we encourage editors to place all the cites at the end of the sentence if none of the statements are likely to be contentious. When placing them at the end of the sentence or paragraph we keep them in order per WP:CITEFOOT: "it is usually sufficient to add the citation to the end of the clause, sentence, or paragraph, so long as it's clear which source supports which part of the text." When someone using AWB shuffles the cites, they are no longer logical or natural, and the reader may well end up confused as to which cite belongs to which part of the sentence, because the natural order has been disturbed. It seems that at the moment when cites are grouped at the end of a sentence some well-meaning AWB user will shuffle the order without realising what they are doing. We should either stop AWB reshuffling the cites, or change our guidance on grouping cites at the end of sentences. SilkTork ✔Tea time 13:57, 21 November 2016 (UTC)
[Since SilkTork has repeated this in the #Clarification please section I have moved my reply there.] All the best: Rich Farmbrough, 20:24, 21 November 2016 (UTC).
  • Yes As I said earlier, whatever purpose the non-chronological ref order serves may not be clear to the reader. The benefits of doing so, as stated by headbomb above, are clear. Pppery 00:54, 20 November 2016 (UTC)
Poppery, I have replied to Headbomb's comment, making reference to our existing guidance on how cites are placed at the end of a sentence. Does that make it clearer? SilkTork ✔Tea time 13:57, 21 November 2016 (UTC)
  • Yes per my discussion below, especially noting that article editors (assuming a consensus) can override the reordering. Ultimately there is no harm and having cites in chronological order should be seen as naturally more convenient for the reader. Stevie is the man! Talk • Work 01:01, 20 November 2016 (UTC)
  • Yes - numerical ordering seems almost universal, if not universal, in modern publishing. The "John and Mary" example above is bad referencing. In the rare case that someone insists on out-of-order referencing they have the means to achieve it simply. All the best: Rich Farmbrough, 01:03, 20 November 2016 (UTC).
Hi Rich, see my reply to Headbomb's comment. I wonder if there is some misunderstanding on how the cite numbering system is being used in an article, because nearly every article will have cite numbers appearing in non numerical order as some are being re-used. Perhaps what is needed is a piece of software that identifies when a cite is used more than once, so people could understand that the number relates to an earlier placing in the article rather than the current one. SilkTork ✔Tea time 13:57, 21 November 2016 (UTC)
It is not a question of non-numerical order, but of adjacent cites in non-numerical order. I don't think people have an issue with understanding that a footnote has been referred to again, indeed there is meta-data conveyed by seeing [3][43][128] - albeit unreliable and unintentional.
I suppose that the superscripts could be of the form[2a] and[2b], but I don't think this solves any real issues.
All the best: Rich Farmbrough, 20:34, 21 November 2016 (UTC).
  • No. If an editor reviews the refs and decides they should be reordered, that's fine, but since there are occasionally reasons to have non-ascending order, this ought not to be done by bots or by semi-automated edits. Mike Christie (talk - contribs - library) 01:04, 20 November 2016 (UTC)
  • No, but (see comment below) I think the wrong question is being asked here. And aside from personal preferences, why should it matter so much that ascending order should be mandatory? ~ J. Johnson (JJ) (talk) 03:04, 20 November 2016 (UTC)
  • No Editors can, and do, arrange adjacent references to put to the most relevant one first, followed by more secondary ones; it is not "universal" for citation numbers to always appear in increasing order when they are adjacent. The usual rule in WP:CONTEXTBOT, part of the bot policy, is that bots should avoid making changes (such as changing spelling or rearranging references) which would require a human to review the context and determine whether a change is appropriate. That is the case here - only human review can determine the best order of the references. Given that the references are hyperlinked and numbered, there is no difficulty in finding them in the reference list regardless what order they appear in the body text. — Carl (CBM · talk) 04:34, 20 November 2016 (UTC)
  • No I frequently arrange references in a particular order: sometimes most relevant first, sometimes in date order. (An example of the latter would be when writing something like: "Many studies between 2004 and 2016 have shown ..." – the references supporting this need to show clearly the time span involved.) Bots should not make context-sensitive changes, over-riding editors' choices. Peter coxhead (talk) 07:54, 20 November 2016 (UTC)
  • Yes because it looks messy. In any given article, the ordering of the reference numbers could be accidental, or could be trying to signal some subtle distinction between the references. But readers cannot tell the difference. If editors intend the ordering of the reference numbers to mean something to the reader, then it would be better to find a different way to express that meaning. -- John of Reading (talk) 08:11, 20 November 2016 (UTC)
  • Yes Having references appear in numerical order in the text is part of basic proofreading. Not doing it gives the appearance of a typed term paper prepared by a schoolboy for whom arranging for such niceties is real work, requiring the retyping of the entire paper. this is one of the many points of good style which were difficult to achieve with a typewriter but were the mark of professional work; they're now easy, and we should take advantage of it . DGG ( talk ) 08:24, 20 November 2016 (UTC)
  • No - as per CBM and Peter's comments. Hchc2009 (talk) 08:30, 20 November 2016 (UTC)
  • Yes; useful, not a problem for the vast majority of pages, and easily solvable for those which need a different order. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me     09:50, 20 November 2016 (UTC)
  • No per SlimVirgin aka SarahSV. In the precursor discussion, I showed an actual real-life case where I feel my ability to control the cite order was useful to at least some readers. That was not disputed. I strongly suspect other editors could point to other such cases. In contrast, to my knowledge no one has shown actual real-life cases where readers benefit from ascending sequence, and that claim is strongly disputed. The arguments in support of reordering are therefore nothing but unproven theories, unsupported assertions. ―Mandruss ☎ 10:13, 20 November 2016 (UTC)
    "No one has shown actual real-life cases" How about nearly 100% of professional journals putting references in order? Headbomb {talk / contribs / physics / books} 10:52, 20 November 2016 (UTC)
    Taking your word for that, how does that show benefit to the reader? ―Mandruss ☎ 11:31, 20 November 2016 (UTC)
    For instance, many books that I read have endnotes divided by chapter, with numbering starting over for each chapter. When I go to look up the note, I see that here are the notes for Chapter 5 and for Chapter 6, but I have no idea what chapter I'm on, so I have to go back to the page where I saw the note, and if the chapter title isn't in the header, I have to flip back top the top of the chapter and find out what the chapter number is. Only then can I actually look up the note. That's pretty standard practice in book publication (although there are the nice books that list the name of the chapter in the notes section, or the page numbers the notes fall on), but it just because it is standard does not mean that it is beneficial to the reader. It's just the way things are done. To say that notes out of order are confusing is untrue because even when they're re-ordered, they don't go 1,2,3,4... in the body of the article, they go 1,5,8,14, because that's where the references just happen to fall. I see no benefit to 1,5,8,14 over 14,5,8,1 when 14 is the most important reference for that section and the others are less important. Give the reader what is primary first, not the reference that just happens to have a low number because it appears earlier in the article then another. There is no intrinsic quality to the number of a reference, it's all just happenstance. Beyond My Ken (talk) 23:49, 22 November 2016 (UTC)
  • Reforder - reasonable compromise. Out-of-sequence limited to those cases that need it per editor discretion. The idea of the Reforder option is that intentional out-of-sequence ordering will be far more effective if not lost in a forest of unintentional out-of-sequence ordering. In that sense AWB can be the friend of editors who use cite ordering, not their adversary. ―Mandruss ☎ 12:30, 20 November 2016 (UTC)
  • No. Automation should not override editorial discretion. There's no justification for the claim that refs not in chronological order would confuse readers. Few readers check references. Those that do -- the more scholarly ones, I'd say -- will be more than capable of choosing the order in which they check them. --Stfg (talk) 10:55, 20 November 2016 (UTC) Please note: I oppose the Reforder option added this morning. It would require editors who have already created articles to go back to them to add the option retrospectively. --Stfg (talk) 12:49, 20 November 2016 (UTC)
  • No - It is reasonable that a more relevant source would be cited before one with less relevance when both are being cited back to back.— Godsy (TALKCONT) 12:35, 20 November 2016 (UTC)
  • Reorder - per Headbomb's continuous remarks. --Dirk Beetstra T C 13:22, 20 November 2016 (UTC)
  • No - As stated above, editorial decision should not be overridden by automation when there is a reasonable purpose in the decision designed to aid the reader. More broadly, we should be an encyclopedia which primarily cares about content, not one which is rule-bound to the detriment of content. Beyond My Ken (talk) 18:01, 20 November 2016 (UTC)
  • No — "Quotation stating idea"10 (source of quotation)1 (ref supporting statement) should not be reordered. I also put the best reference for a statement first in the list. Glrx (talk) 18:35, 20 November 2016 (UTC)
  • Yes – It makes no sense for ref 5 to go after ref 6 if it is invoked. Dustin (talk) 19:09, 20 November 2016 (UTC)
  • No, although the damage is done. There are probably hundred thousands of articles[notes 1] with references in the wrong order (in the sense of being different than any actual editor intended). I see no benefit to the reordering, and some (often slight, but occasionally serious) damage to understanding. (As an aside, a bot should tag all articles with multiple consective references/notes which were ever touched by AWB or a bot, for potential errors caused by this mistake.) — Arthur Rubin (talk) 22:01, 20 November 2016 (UTC)
  • Yes because non-ordered references only are confusing to readers -FASTILY 22:49, 20 November 2016 (UTC)
  • No per Sarah. Nikkimaria (talk) 00:53, 21 November 2016 (UTC)
  • Yes, reorder. I wasn't aware this had been disputed for seven years, or really ever, because it seems completely obvious they should be in numerical order. I don't much care what "professional journals" do - we're the 800-pound gorilla of book-report plagiarism material and bar-bet-settling, so we can do what we want ;) But I do care that readers actually understand what they're looking at, and [15][5][2][12] is harder to read and forces people to jump around in the reference list. "But the order I wrote them in is important!!" is the kind of thing I can imagine convincing myself of while in the middle of writing an article, but it's self-delusion; the number of readers who would see that, assume the order was significant, correctly interpret why the author ordered them as they did, and actually care about the result, is indistinguishable from zero. Worse, without automatic reordering, the likelihood that any given out-of-order reference list is significant actually declines, because almost nobody is going to reorder them manually. There are workarounds for the rare circumstance where order actually does matter; use those if you must and let the rest of us sit back and let the bots fix our sloppiness. Opabinia regalis (talk) 04:10, 21 November 2016 (UTC)
  1. ^ There can only be a visible difference if refs (or notes) are named and reused.
"Nobody is going to manually reorder them," means that the order is not that important. I reordered several long, ref lists a few times, before stumbling upon a bot edit that was undoing my work. The edit description gave no indication of what the bot was doing. Workarounds make it more difficult for other inexperienced editors to understand and participate in updating, correcting or improving the text. Bcharles (talk) 09:57, 23 November 2016 (UTC)
  • No. I complained ref reordering in gen fixes last year. The main reason is because while it might be more aesthetically pleasing to some, I order my refs by priority (best refs first, secondary or duplicate refs second). If a sentence needs multiple footnotes and the citation style doesn't suit shoving both lines into the same ref, ordering by priority makes the most sense. (This has not been contested across multiple FARs so I consider it a common sense understanding. It's also silly to call this "delusion"—readers check the refs in order.) Gen fixes are supposed to be inoffensive, which is why they minimize white space disruption and so on. Gen fixes should not impede productive work in drive-by ref reordering. czar 05:39, 21 November 2016 (UTC)
  • No unless we change WP:CITEFOOT to alert editors that a bot may change the logical order of end sentence cite into a purely numerical one, so if the order if relevant then the cites should be placed right next to the relevant information, and if this inhibits reading flow (so making grouped cites preferable) then to put in a command to prevent a bot changing the order. I do think though that it would be simpler to stop AWB from reordering cites. SilkTork ✔Tea time 14:09, 21 November 2016 (UTC)
  • No I often will place references in a particular order, with a more specific reference first up and a more general secondary source to follow. Jumbling up will be a disservice to the reader. The foot notes are not hard to find in our online edition, since you just click on the number and the brower navigates and highlights the reference. Graeme Bartlett (talk) 22:41, 21 November 2016 (UTC)
  • Yes with the understanding from several of the "no" !votes above that there is a legitimate time and place to use references in non-numerical order (several valid examples cited), and that we have at least one way, via {{R}}, to "protect" that order from bots or random gnomish editors that would otherwise come by and fix it. I understand the concern of this being added to AWB, but there are lots of wikignomes that will do this ref order adjustment to, and, unlike something like DATERET where we have templates to alert editors to a selected style, a reforder aspect will not be clear unless one uses inviscomments or a template like {{R}}. Setting up guidelines when one should force a ref order, and how to indicate that to any other editor without minimal of fuss, would be useful result from the above discussion. I think what we have to recognize is that most readers and editors appear to see the mixed numerical order of a forced reforder as "wrong" and will want to try to fix it, being just as unaware of any previous talk page or consensus discussion that AWB has, and we should find a way that doesn't affect this but does keep editorial discretion, of which there is at least one way; more options should be explored. --MASEM (t) 17:17, 22 November 2016 (UTC)
This argument amounts to saying "We won't be able to stop gnomish editors doing it anyway, so let's allow AWB to do it." It seems a very unsatisfactory reason to me. Peter coxhead (talk) 17:44, 22 November 2016 (UTC)
  • No. There are good reasons for manual control of reference order, for example so that they reflect the logical sequence of the statement they substantiate, or emphasising a key reference over subsidiary ones. The burden shouldn't be placed on content editors to "protect" these decisions from AWB operators. No professional copy-editor in an academic context would arbitrarily re-order the references as written by the author! Joe Roe (talk) 18:57, 22 November 2016 (UTC)
    The idea of the Reforder option is that intentional out-of-sequence ordering will be far more effective if not lost in a forest of unintentional out-of-sequence ordering. In that sense AWB can be the friend of editors who use cite ordering, not their adversary. ―Mandruss ☎ 19:39, 22 November 2016 (UTC)
  • No. The use of references in Wikipedia has historically been tolerant of a wide range of reference styles and philosophies. There have been arguments and controversies, but the consensus is that uniformity is not necessary. We have two major styles of templates (now wrappers of a single implementation). We use parenthetical as well as numbered references. We have references declared in the text and references instead declared in lists at the end. We have many editors who avoid templates in favor of manually formatted references. In this spirit automating a reordering of reference numbers (I assume "chronological" doesn't mean the date of the reference) in the face of even a minority opposition goes against this long standing consensus. StarryGrandma (talk) 19:20, 22 November 2016 (UTC)
  • No. Wiki articles are continually changing, and the numerical order of refs will sometimes change over time. The placement of refs in a sequence is often deliberate and should not be altered without consideration given to the context (by a human editor). The diversity of contexts in which issues of ref order occur indicates that one rule will not satisfy all cases. The numerical order in text is trivial relative to other considerations (e.g. primary, secondary, tertiary importance; relevance; clause order; list item order). Bcharles (talk) 09:57, 23 November 2016 (UTC)

Discussion: AWB bot ref reordering

  • The discussion section below was created precisely for discussion of the substantive issue, as in any RfC. This is an RfC that should have occurred in 2009 after it became clear that the issue could not be resolved outside RfC. ―Mandruss ☎ 22:53, 19 November 2016 (UTC)
    Anyone could have raised an RfC at the time. They didn't. There is no procedure for your "Let's pretend that this is 2009." idea above. This is 2016, and the status quo is established. To attempt to set up an RFC in such a way that "no consensus" means you get the change you want, contrary to normal practice, is not how we do things. All the best: Rich Farmbrough, 23:08, 19 November 2016 (UTC).
    No one knew about it, Rich. It was added on the say-so of two editors, one of whom now supports its removal. Every attempt to have it removed has been ignored. SarahSV (talk) 23:13, 19 November 2016 (UTC)'
    Not so. I removed it from my version of AWB. All the best: Rich Farmbrough, 23:41, 19 November 2016 (UTC).
    Rich, I'm not sure what "not so" refers to. Several people have objected to it, but it has made no difference. Magioladitis said he supported removing it last year, but seems not to be able to do it himself. I asked "how can we get rid of that AWB thing that moves references out of place?" He replied: "I support you on that. In the past I proposed that we make the ref reordering optional and disabled for bots." Can you say how you were able to remove it? SarahSV (talk) 13:50, 20 November 2016 (UTC)
    I downloaded the code and patched it. Later I created a patching system to help avoid regressions. Whether either have survived the intervening years, I don't know.
    I cannot speak for @Magioladitis:, but it is possible that when he said "I support you on that." he was replying to "Can you address the larger issues, M?"
    The 2009 discussion had four participants not two. three seemed to think it was a good thing, and the fourth that it was harmless. I read the discussion and did not join in as it seemed an unexceptional change. Doubtless I was not the only one.
    The Study 329 example isn't a great one, because it's a John and Mary example (and the cites, and arguably the text, should be in the body, not the caption of an image).
    All the best: Rich Farmbrough, 15:30, 20 November 2016 (UTC).
    Seriously? The status quo is established? Because the AWB folks who had control over the code refused to recognize the fact that they had strong opposition to the edits and seek consensus for them? Sorry man, de facto consensus is not established by obstructionism. As for my "no consensus" position, I didn't set anything up that way, I made a suggestion to the closer, clearly identified as a comment, which they can ignore if it doesn't make sense to them. Please don't misrepresent what I'm doing here. ―Mandruss ☎ 23:16, 19 November 2016 (UTC)
    The question of when the status quo has been established long enough to count as the status quo, is, of course, a vexed one. However on Wikipedia seven (7) years would generally be considered ample time. And I council against using terms like "obstructionism" when, by your own admission you aren't familiar with the history. Rjwilmsi has bent over backwards to accommodate those who have legitimate issues with AWB (and some who don't), and together with the rest of the AWB developers has put in an enormous amount of work.
    All the best: Rich Farmbrough, 23:43, 19 November 2016 (UTC).
    If the reordering is removed pending consensus to include it, I will retract the obstructionism claim with apology. ―Mandruss ☎ 00:44, 20 November 2016 (UTC)
  • So,are we talking about AWB or bots that run under AWB? Mr Stephen (talk) 23:23, 19 November 2016 (UTC)
  • The issue is AWB or any automated re-ordering of refs. SarahSV (talk) 23:28, 19 November 2016 (UTC)
  • @SlimVirgin: I confess I wasn't clear on that point, and I should have been. Should we change the headings here and the RfC question? ―Mandruss ☎ 23:29, 19 November 2016 (UTC)
  • These are two very different issues. Perhaps we want different questions? All the best: Rich Farmbrough, 23:51, 19 November 2016 (UTC).
  • Mandruss, this is about AWB reordering refs. It is about the feature that was added in 2009. If we make it more complicated and it confuses people, we will end up with no consensus. SarahSV (talk) 23:55, 19 November 2016 (UTC)
  • These are two very different issues. Perhaps we want different questions? All the best: Rich Farmbrough, 23:51, 19 November 2016 (UTC).
  • Well, since this is 2016 and not 2009, I will suggest that the burden is on those who want to end the reordering, as this is a long-established process. Having the footnote numbers in chronological order makes logical sense in many cases because it generally doesn't matter what citation is shown first and having the numbers in a sequence is naturally easiest on the reader's eyes. There are of course exceptions, as editors may think a particular citation is especially strong or backs up more of the content than other cities -- in these cases, they can override AWB by placing an HTML comment between the refs. If there is any change with how this all works, I wouldn't mind AWB adding an HTML comment that explains how to avoid reordering wherever it reorders. Stevie is the man! Talk • Work 23:56, 19 November 2016 (UTC)
[moved from survey by SV] I've done a lot of these reorderings, and only one has been disputed. It was ultimately resolved by placing an HTML comment between the refs. So, what's the ultimate damage? If anything, the AWB user should instruct the disputing editors on this, or add the HTML comment themselves, similar to how sometimes {{not a typo}} is added. It doesn't have to be a big thing. An AWB user shouldn't care that a consensus of editors on a page wants particular refs to be out of sequence. Stevie is the man! Talk • Work 00:25, 20 November 2016 (UTC)
  • as this is a long-established process - As I said above, de facto consensus arises from the facts that (1) editors have had the ability to make changes to the content in question and (2) they have chosen not to do so. That is not the case here, because the AWB developers had control of the AWB code and were not responsive to editor complaints. They abused the power they had by virtue of technical control and it would be an exceedingly bad idea to reward that behavior by asserting "a long-established process". The message would be that if you just can be obstructive long enough, you will eventually win out. ―Mandruss ☎ 00:42, 20 November 2016 (UTC)
    I'm looking forward to seeing the evidence behind these assertions that don't appear to assume good faith. At any rate, the fact is that it's a long-established process. And based on the experiences reported so far, any specific disputes over reorderings are highly infrequent. Now, if someone can show where anything other than highly infrequent disputes are occurring, of course we should consider that. Stevie is the man! Talk • Work 00:58, 20 November 2016 (UTC)
    Which of the following is incorrect? 1. Highly controversial changes require clear consensus. 2. No clear consensus has ever existed for AWB reordering. 3. A developer with the power to control bot-executed code should be expected to be aware of 1 and 2. 4. The consensus-free code still remains in AWB.
    I cannot escape the logical conclusion that (1) someone has acted in bad faith, or (2) someone should not have control of the AWB code. As I've said elsehwere here, I will gladly retract all such claims if the reordering is removed pending consensus to include it, per item 1. ―Mandruss ☎ 01:16, 20 November 2016 (UTC)
  • It would be useful to have some statistics:
  1. How many refs have been reordered by AWB?
  2. How many were out of order due to the refs renumbering, and how many were placed out of order?
  3. How many cases have been documented where the re-ordering was alleged to be wrong?
Secondly it would be useful to understand if people think that, as a matter of style:
Reference numbers should be ascending:
  1. Always
  2. Except where there is clear priority between references
  3. Let them be random
Personally I subscribe to either the first or second, tending toward the first. If the distinction is sufficiently strong to warrant out-of-order numbers then there may well be a better way of handling it.
All the best: Rich Farmbrough, 23:59, 19 November 2016 (UTC).
Like I say above, AWB ref reordering skips refs separated by an HTML comment, so editors (assuming a consensus) can decide to have the footnote numbers out of order to their heart's content. Stevie is the man! Talk • Work 00:07, 20 November 2016 (UTC)
Indeed (I edit conflicted with you). I suspect that's one of the reasons that hardly anyone is bothered about this either way. All the best: Rich Farmbrough, 00:15, 20 November 2016 (UTC).
  • Mandruss, I've added a link to the 2009 discussion to your post introducing the RfC. I hope that's okay. (Sorry, I should have asked you before doing it.) SarahSV (talk) 00:00, 20 November 2016 (UTC)
    • The only "objector" there said "Not bothered if you continue as it isn't doing any harm, except wasting effort" - this seems like consensus was established - no reason it can't change of course. All the best: Rich Farmbrough, 00:13, 20 November 2016 (UTC).
  • OK, once again. Where, in the real world, is the guidance that the order of references indicates the order of importance? There must be a style guideline or an 'instructions to authors' page somewhere that suggests this. I've never seen one on my travels, and nobody ever comes up with one when I ask in these discussions. Somebody must be familiar with this style and can point us (well, me) at it. Mr Stephen (talk) 00:25, 20 November 2016 (UTC)
    • I believe I saw one journal which allows this. But I could be wrong. All the best: Rich Farmbrough, 00:56, 20 November 2016 (UTC).
    • I just put myself in the place of a reader who only has the time and inclination to look at one source of several cited. In certain cases, which are rare but still important, I want to control which source that is, and I don't know why they wouldn't choose the one physically first in the string (Westerners tend to think left-to-right). I gave a good example of such a case in the precursor discussion. I think I as a Wikipedia editor should have that discretion, regardless of whether this is some widely recognized practice or not. Most readers won't know whether such a practice exists or not, and we are writing for them, not us. ―Mandruss ☎ 01:03, 20 November 2016 (UTC)
Mandruss; you write " I don't know why they wouldn't choose the one physically first in the string". I suggest that they would not because that is not standard practice. Mr Stephen (talk) 10:46, 20 November 2016 (UTC)
As I indicated, few Wikipedia readers know anything about standard practice regarding citation order. Do you disagree with that? I've personally been a Wikipedia editor for 3.5 years and a Wikipedia user for about 7 years, and I didn't know about any such standard practice until a few days ago. Am I some aberration? ―Mandruss ☎ 11:38, 20 November 2016 (UTC)
You are not the matter at hand. Where did you get the idea that references are ordered by importance? I've never seen guidance suggesting it; somebody must have if it's not something that's been made up. Link please. Mr Stephen (talk) 13:28, 20 November 2016 (UTC)
It is in fact something that's been made up, which is not a Bad Thing. The word is innovation, and we are not bound by conventions created by external "authorities". That kind of thinking is simply rigid pedantry. If I'm wrong, link please. ―Mandruss ☎ 04:22, 22 November 2016 (UTC)
As an aside to the main discussion, my recollection is that the Bluebook system of legal citation has some rules about ordering citations by importance. I don't know if the handful of Bluebook afficiondos here at WP observe that, but it could be a possibility.
More to the point here would is the matter of having the notes/citations immediately follow the material they apply to. But some editors believe all note-links (hyperlinks) should be at the end of a sentence. In that case the citations need to be in order as used in the text, and changing that will really confuse the readers. ~ J. Johnson (JJ) (talk) 00:24, 23 November 2016 (UTC)
  • I think this discussion would go better if a couple of points are sorted out at the outset, so that we are all "on the same page".
First, let's have an understanding of the basic terminology and concepts. E.g., what (I believe) we are talking about is whether instances of (e.g.) [1][2][3][7] are better than [3][1][7][2]. (That is, I believe the issue is about the ordering of consecutive strings of numbered links, not the ordering of such links through the whole article.)
Second, we should be clear that those are not "references", they are HTML links. But not links to references, as what is contained in the the mis-named <ref>...</ref> entities is not necessarily a "reference". (Yes, I know, it seems most of you use them that way, but that is certainly not the only way. Hear me out; such distinctions are necessary to avoid ambiguity, confusion, and conflict.) What the <ref>...</ref> tags create are notes (footnotes, endnotes, whatever). What you use them for (whether "references", "citations", "explanatory notes", etc.) is largely irrelevant for this discussion, but we might avoid getting stuck in conceptual dead-ends if we use the most general term, "notes". And "note-links" (or "footnote-links") for the specific element of concern here.
Third, this RfC would be better formulated as whether having strings of note-links in ascending order is merely preferred, or should be mandatory. If that is resolved one way or the other then appropriate measures can be considered, such as adjusting AWB.
Fourth, "random" is not an alternative to "ascending". Notes, and the links to them, are numbered in the order the s/w finds them. Note-links come out of order where a named ref (the <ref=name ...> entity) has been used to point to another instance. (That is, to "re-use a reference".) Don't use named refs, and I believe the ordering problem goes away.
Which then leads us back to other potential problems that underlie the issue considered here. ~ J. Johnson (JJ) (talk) 02:54, 20 November 2016 (UTC)
J. Johnson, yes, ref name is what causes this problem. But if we don't use it, AWB editors add it. SarahSV (talk) 13:13, 20 November 2016 (UTC)
SV: I think you are referring to this automated merging of notes (<ref>s) deemed to be duplicates, replacing one with a named ref. I think that is a problem that needs to be dealt with. (I often modify my notes so they are not duplicates, to avoid this merging.) But behind that is the challenge of "re-using" entire biblographical entries ("full citations"). In the end I think it comes down to: how do you feel about the use of "short citations"? ~ J. Johnson (JJ) (talk) 23:04, 20 November 2016 (UTC)

Compromise proposal: AWB bot ref reordering

CURRENT CONSENSUS IS THAT THIS IS NOT AN APPROPRIATE PROPOSAL. PLEASE IGNORE. ―Mandruss ☎ 13:23, 20 November 2016 (UTC)

I think the simple solution here is to add something like {{AWB-no-ref-reorder}} in the reference section that'll tell AWB to leave ref order alone. This way the minority can be happy, and the majority can continue cleaning up. Headbomb {talk / contribs / physics / books} 10:49, 20 November 2016 (UTC)

PROPOSAL:

@Headbomb: Or, a new way to protect only a single ref sequence without requiring the use of list-defined references, as I've explored in the precursor discussion. - {{reforder |refs=<ref>...</ref><ref>...</ref><ref>...</ref><ref>...</ref>}} - I personally have no objection to that, once AWB gains consensus to reorder in the first place, which should have been done in 2009. First things first. I like this. ―Mandruss ☎ 11:44, 20 November 2016 (UTC)
I'd be entirely fine with that as a supplement too, but tagging the entire article is the simplest solution. Headbomb {talk / contribs / physics / books} 21:25, 20 November 2016 (UTC)
  • Comment Mandruss, do you think this could feasibly be done only for articles created in the last two or three months by non-extended-confirmed editors? It seems from the discussion above that many experienced editors would rather have it at their own discretion, although IMHO it looks a little weird and unprofessional to have the citations be ordered [14][2][5][3] for no reason. Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me     11:58, 20 November 2016 (UTC)
    • Sorry, I don't understand the question.
      In hindsight, maybe I should have framed this RfC as a proposal for that compromise. I am a stickler for process, for doing things the right way, and that may have affected my thinking in an unconstructive way. If so, I apologize, and the question for me is whether it's too late to change directions in this RfC. The question for others may be whether that's the best approach. ―Mandruss ☎ 12:03, 20 November 2016 (UTC)
        • Mandruss, you say you're a stickler for process, so please let this run. The broader question is whether editors should be making context-sensitive edits with AWB. Telling us we have to use special templates or html to stop it misses that point. SarahSV (talk) 13:00, 20 November 2016 (UTC)
      • @Mandruss: I guess if it's possible (if it is, it would slow down AWB just a little bit because of the API querying), then there's not really anything stopping you from adding a third option. The extended-confirmed part might be unnecessary if it's for pages created in the last month. Jc86035 (talk) Use {{re|Jc86035}}
        to reply to me         12:07, 20 November 2016 (UTC)
        • @Jc86035: Considering that the {{R}} template is already being used to protect sequences from AWB reordering, I don't see why using a Reforder template instead would slow down AWB. As far as I know the protection works because AWB ignores cites inside a template transclusion. All I'm doing is eliminating LDR from the equation. I still don't understand what you're saying about extended-confirmed and pages created in the last month. ―Mandruss ☎ 12:13, 20 November 2016 (UTC)
          • @Mandruss: Sorry for the confusion. I just realised I put this in the wrong subsection; my idea was to limit reordering of references to pages created recently by inexperienced editors, regardless of whether the blocking template was used. Jc86035 (talk) Use {{re|Jc86035}}
            to reply to me             12:33, 20 November 2016 (UTC)
          • Added the third option, Reforder. ―Mandruss ☎ 12:34, 20 November 2016 (UTC)
  • How is one making a reasoned choice to order back to back refs un-sequentially expected to know about the proposed "{{AWB|no-reorder}}" template? Though I fail to see a majority in support of reordering references in this manner at this time, and would oppose this template as such; if it were implemented it should be required in the edit summary of bots reordering back to back references into ascending number sequence, so users would know how to prevent it from happening again.— Godsy (TALKCONT) 12:47, 20 November 2016 (UTC)
    • Sorry, I included the {{AWB|no-reorder}} comment only for context, the proposal in this subsection is for Reforder. I have attempted to clarify that by adding PROPOSAL above. ―Mandruss ☎ 13:03, 20 November 2016 (UTC)
  • Mandruss, please don't change the question mid-RfC. The compromise is another version of yes. First you were no in the discussion at CITE, then yes, then no again, then you opened a parallel discussion here, and no, and now yes again (sort of) and changing the question. Please just let it run. SarahSV (talk) 12:51, 20 November 2016 (UTC)
    Let it never be said that I am inflexible! :) Your reasoning is like accusing a politician of being a "waffler" because they changed their mind. Sorry I failed to get it right the first time, or the second (or the third? I don't know, I'm not counting). RfCs add options all the time, because it's difficult to predict what options will be necessary in advance. Wikipedia decision-making is messy. As for "the compromise is another version of yes", I think that's a matter of perspective, and I disagree. ―Mandruss ☎ 12:56, 20 November 2016 (UTC)
    It's another workaround, another version of yes. SarahSV (talk) 13:05, 20 November 2016 (UTC)
    @SlimVirgin: I would like to voice my strong objection to your removal of the third option[2], but I am not going to edit war this with you. You are now being disruptive and exhibiting WP:OWN of this process in my view. Editors who agree with you may !vote No. ―Mandruss ☎ 13:08, 20 November 2016 (UTC)
    @Mandruss:, I'm sorry, but you've caused a lot of extra work here. We had an ongoing discussion at CITE. You flipflopped back and forth there, then opened this before that had ended, without any warning. Now you're doing the same here, and trying to change the question. What you're calling a third option is really option yes(b). SarahSV (talk) 13:19, 20 November 2016 (UTC)
    Deferring to this two-to-one opinion, I have retracted the proposal for now by adding a comment at the top of this subsection. Thank you. Sorry for causing a lot of extra work by trying to help move this issue to a resolution, after seven years. In hindsight I should have ignored your first ping at CITE and stayed the hell out of it. ―Mandruss ☎ 13:23, 20 November 2016 (UTC)
    Thank you for fixing it. SarahSV (talk) 13:52, 20 November 2016 (UTC)
I've restored that 'proposal'. It's a perfectly reasonable option, and one that's in my opinion ideal. Headbomb {talk / contribs / physics / books} 21:37, 20 November 2016 (UTC)
  • @Mandruss: Your third option is, really, just "yes", because it was implicit that the minority of editors who wanted deliberately to put them out of order would have to do something like that anyway. I still think it'd be best if we only reordered the refs for pages recently created by non-extended-confirmed editors (I doubt most newcomers would find out that they're supposed to do that). Would you add that to the RfC? Jc86035 (talk) Use {{re|Jc86035}}
    to reply to me     13:11, 20 November 2016 (UTC)
    Fine. I added a third option because you said, "there's not really anything stopping you from adding a third option", later realizing that you were in the wrong place. Sheesh. You guys sort it out. ―Mandruss ☎ 13:17, 20 November 2016 (UTC)
    Nothing needs to be sorted out. Let it run, then a closer will summarize the consensus. SarahSV (talk) 13:20, 20 November 2016 (UTC)
  • I suggest to the closer that there is no consensus here, unless it be that: everything is confused, the question is poorly put, we haven't worked out what the problem is, and – there is no consensus. ~ J. Johnson (JJ) (talk) 23:21, 20 November 2016 (UTC)
    Just 26 hours after the RfC was created seems a little soon to be drawing conclusions about the level of consensus, don't you think? Why do you think the closer needs the advice of commenters on how to do their job anyway? --Stfg (talk) 00:44, 21 November 2016 (UTC)
    Yeah we should have had a separate pre-RfC RfC to decide what question to ask in this one, as I'm certain there is wide disagreement about how to frame this issue. Or, we can all learn how to give a little for the sake of moving on, and that none of this is all that fucking important in the end. This has become obsessive on the parts of many. High intelligence is counterproductive in the absence of wisdom. ―Mandruss ☎ 08:43, 21 November 2016 (UTC)
I don't know that a pre-RfC RfC is needed, but as a lot of these kinds of questions arise where various editors are running on different interpretations, I think it is generally good to work out a mutually acceptable formulation of the question beforehand. Of course, to get the question right you pretty much have to be half-way to the answer. ~ J. Johnson (JJ) (talk) 00:24, 22 November 2016 (UTC)
Based on what I know about the history of this issue, the personalities involved, and Wikipedia culture in general, I strongly suspect any attempts to "work out a mutually acceptable formulation of the question beforehand", outside RfC, would have been fruitless. ―Mandruss ☎ 04:30, 22 November 2016 (UTC)
It is not appropriate to need to add templates to articles to prevent bots from making changes; bots are meant to avoid inappropriate changes on their own. The characterization as "majority"/"minority" reveals a kind of bias, as does the description of rearranging references as "cleaning up". Remember there is no guidance at all that reference numbers should be in increasing order; that idea is something that a small number of AWB operators invented. The solution is for AWB to back out that change until WP:CITE actually requires a particular ordering of references. — Carl (CBM · talk) 13:47, 21 November 2016 (UTC)

Reorder end-notes, not the references

If it is deemed desirable for references to refer to end-notes in increasing order, then the MediaWiki software should assign numbers to the end-notes accordingly, rather than simply in sequential order of first reference. It can't resolve all cases (if a pair of end-notes are referred to in opposite order in different places in the main text, for example), but I imagine most cases would be dealt with. Reordering the references is just a work-around for the underlying issue. isaacl (talk) 20:52, 20 November 2016 (UTC)

It seems to me you have an idea of possible interest, but I can't quite make it out because of various ambiguities. E.g., what exactly do mean by "references: the numbered-links (e.g.: [1]) in the text? The actual end-notes the link goes to? Or the full bibliographic citation of the source that is frequently the content of the note? And are you assuming the bibliographic citations themselves are scattered through the text, or gathered in a "References" section? Are you considering the use of LDR? ~ J. Johnson (JJ) (talk) 23:15, 20 November 2016 (UTC)
To clarify: if it is desirable for a sequence of adjacent superscripts to be in increasing numerical order, the numbering of the corresponding end-notes can be selected appropriately to maximize this occurring. (*) It doesn't matter where the contents of the end-notes are defined; the software can reorder the final output as desired.
(*) As noted, there are situations where preserving increasing numerical order would require re-ordering or relocating one or more superscripts. For example, an article using a couple of authoritative sources throughout may have occasion to refer to the sources in opposite order. isaacl (talk) 05:48, 21 November 2016 (UTC)
I think this would likely cause even more confusion. It is not true that every style makes the first endnote be number 1 (e.g. endnotes might be sorted by author name, so the first endnote to appear in the text could be number 14). But many styles do make endnotes sorted by number, so the first to appear is 1, etc., and more people would likely be confused if this did not happen.
The underlying cause of the issue on Wikipedia is that our reference notes are not purely endnotes or footnotes (in which case no number would be repeated) but they are also not purely numerical pointers to a list of references (because references lists would not include comments like endnotes and footnotes do). So our reference numbers are somewhat ambiguous, leading different people to interpret them differently. Which is fine, but changing the system more would be confusing. — Carl (CBM · talk) 13:44, 21 November 2016 (UTC)
Strictly speaking, no "style" (or method) of citation "makes" the notes (end-notes) be "sorted by number"; that's just the order the wikimedia s/w finds them in the text. If an article's first note-link is [14] it is not because the end-notes were sorted by author name (presumably using LDR); it is because that link results from a slave named-ref (e.g.: <ref name=xxxx \>) that points to the fourteenth actual note.
The underlying cause is not that "reference notes are not purely endnotes or footnotes", but that named refs are being used to make a note-link appear in more than one place. Don't use named-refs, and this problem won't happen. It is not so much that your so-called "reference numbers" are ambiguous, but that a list of notes referenced by number is confused with a list of sources referenced by an editor.
Which is why I oppose this bot-reordering: changing a basically okay system (aside from named-refs!) to conform to ambiguous and confused understandings of what it should do makes the system more confusing, and the editors more confused. ~ J. Johnson (JJ) (talk) 00:30, 22 November 2016 (UTC)
With hypertext links, I don't think readers notice or care if the first superscript is a "1" or "14". In theory, the MediaWiki software could turn named references into a list of references and generate individual end notes pointing to the same reference, instead of reusing end notes. I suspect it may be challenging to gain consensus support for this approach, though. isaacl (talk) 01:39, 22 November 2016 (UTC)
I think you have missed the main point: some editors care. Also, you seem confused as to what constitues a "list of references" and how that differs from "individual end notes pointing to the same reference". (Particularly: how does re-use of an end-note differ from re-use of a reference?) Depending on how you understand this, I would say that the mediawiki software already does what is necessary. It's just a matter of getting editors to use the tools available, rather than inventing new tools that don't get to the heart of the problem. Which is, indeed, challenging. ~ J. Johnson (JJ) (talk) 00:39, 23 November 2016 (UTC)
There was a suggestion that named references not be used in order to avoid reusing superscript numbers. The MediaWiki software can still avoid reusing superscript numbers with named references: the resulting end notes can either replicate the citation, or point to a citation list that is automatically generated from the named references. isaacl (talk) 03:14, 23 November 2016 (UTC)
Not using named references is not a viable option in long articles with hundreds of refs, some used in 10 or 15 different places in the article. Both keeping ref list bloat down, and managing corrections or refinements to refs mean using named refs is essential. Defining named refs in the reflist section is one way to manage them, but that means new editors will need to learn that system. Bcharles (talk) 10:42, 23 November 2016 (UTC)

Clarification please

I thought when I came here that this was a discussion about should AWB reorganise grouped cite links at the end of a sentence or paragraph into order according to the number assigned to the cite when first placed in the article. From comments above, I am unsure if that is what people are discussing, as it seems people are discussing the order of cites in the article as a whole, or how they are presented in the Ref section at the end of the article.

My understanding of how the system works. See if others agree with this, so we are discussing the same thing.

We use several sources to write an article, and we cite the sources at the point in the article where the information is used with an inline marker. The software identifies the cite with either a number or a letter or both and links the reader to information on the cite which is collected and placed in a section at the bottom of the article. The cite information at the bottom of the article has the same number or letter as was used in the inline marker. The numbers are purely for identification, and do not relate to sequence, as some cites are used in more than one place, so the number marker may appear several times. See Covent Garden. In the reference section the first source listed is Christopher Hibbert; Ben Weinreb (2008). The London Encyclopaedia. Pan Macmillan. pp. 213–214. This is listed first as it is the first used in the article. It has been given the cite number 1. Because that source is used three times, the places it is used are identified as a, b, c. If anyone clicks on 1 a, they will be taken to the first time the cite is used (in the opening sentence). If anyone clicks on 1 b they will be taken to the second time the cite is used (in the first sentence of the geography section, where it comes after cite 25 used in the previous section and before cite 26 which is used in the following sentence. Numerically it is out of sequence here, but that doesn't matter because the number is purely an identifier, and is not meant to relate to any number sequence). If anyone clicks on 1 c they will find the third use which is at the end of the Covent Garden square section, where it comes between cite 59 which has been used in the sentence before and the sentence after. So that cite appears three times, and two of those appearances are out of number sequence. But no editor and no bot would attempt to change the number of the cite or its position. So, no worries.

In some cases, though, we may use several cites in one sentence, and some of those cites may have been previously used, and so their numbers are not in numerical order. Such a case is in The Kinks article where we have this sentence: "The group's fourth single, "All Day and All of the Night", another Ray Davies hard rock tune, was released three weeks later, reaching number two in the United Kingdom, and number seven in the United States.[4][33][36]". Now, note that there are three numbered cites, and they are not consecutive numbers, which means at least two of the sources have been used elsewhere in the article. The sentence contains three pieces of information that have been cited: the single was the group's fourth, it reached number 2 in the UK charts, and it reached number 7 in the USA charts. According to WP:CITEFOOT instead of putting a cite next to each piece of information, we should group them at the end "so long as it's clear which source supports which part of the text." The order of the cites was originally 36, 4, 33 - 36 citing 4th single, 4 citing No 2 in the UK, and 33 citing 7 in USA, in the same order as those statements are given in the sentence. This AWB edit changed the order so the cite numbers are in order. So someone checking that the single was indeed the band's fourth would assume that would be the first cite listed, and would click on cite number 4, which tells us that the single reached 2 in the UK. That person may assume that we haven't cited that it was the band's fourth single, and may either go look for one to place in the article, or may tag that piece of information as uncited.

The numbers are to identify the cites, they are not to indicate any kind of sequencing. That's my understanding. SilkTork ✔Tea time 15:01, 21 November 2016 (UTC)

Except this example violates WP:INTEGRITY. CITEFOOT doesn't say anything that the preferred place to put footnotes at the end of a sentence, but at the end of the phrase that the ref supports, as to support text-source integrity. The three cites given for the Kinks example should be placed throughout the sentence instead of grouped at the end. --MASEM (t) 15:09, 21 November 2016 (UTC)
The Kink's sentence currently violates WP:INTEGRITY because the cites were rearranged into number rather than text order by an AWB edit. As regards the wording of WP:CITEFOOT, in full it says "The citation should be added close to the material it supports, offering text–source integrity. If a word or phrase is particularly contentious, an inline citation may be added next to that word or phrase within the sentence, but it is usually sufficient to add the citation to the end of the clause, sentence, or paragraph, so long as it's clear which source supports which part of the text." My understanding is that if the information is likely to be challenged, put the cite next to the word or phrase, but if it's not contentious the cite can be placed at the end of the sentence. We generally don't have three cites for the same piece of information, so when there are three cites at the end of a sentence they will generally be supporting three different pieces of information - and they will generally be placed in the order in which the information appears in the sentence. Perhaps the wording of WP:CITEFOOT needs to be tightened to avoid misunderstanding? SilkTork ✔Tea time 17:18, 21 November 2016 (UTC)
The keyword is "clause", which means, to me, where you have a comma is a very valid place to drop in a reference to support the clause prior to the comma. And I have done cases where I've done on individual works such as "Smith[1] and Jones[2] both agree that the sky is blue." so that I'm assured that reference won't move than rather playing with reference order issues.
At least to me, when you do multiple refs at the same point, the weight of all those refs relative to the text in front of them and to each should be equal that reference re-ordering (moving refs around at that point to have increasing ref numbing) should not affect the understanding of the article in anyway. If the reference order is important, you've structured something wrong, and it is nearly always possible to rewrite a sentence to have refs appropriate distributed throughout so that you eliminate the reordering problem. --MASEM (t) 00:53, 22 November 2016 (UTC)
You're probably right that it is nearly always possible to do this. To me, and perhaps to some other editors !voting "no" above, the issue is not that there might not be some way to finesse the issue; it's that bots shouldn't be doing work that requires me to finesse an issue. I wouldn't mind a human reordering the refs; I can talk to a human and discuss the issue. Having to format refs in a certain way to keep bots off is like having to put up a deer fence around the roses. I'd rather have deer that don't eat roses. Mike Christie (talk - contribs - library) 01:25, 22 November 2016 (UTC)
"[W]e encourage editors to place all the cites at the end of the sentence" - I don't think that is true. I would only encourage it if the cites broadly supported the sentence as a whole. Where I am relying on a specific cite for a specific fact I will cite at the phrase or word level. For example "Aethelwulf's kingdom was claimed by Aethelhnoth,[1] Aelfric and Cynewulf.[2]" Here it is clear that any reader specifically interested in Aethelhnoth's claim should look at ref. 1, while ref 2 will cover at least the two other claimants.
I read the guidance you quote as encouraging precisely the opposite behaviour, if placing the references together makes it unclear what they support, then they are best placed at the end a smaller semantic unit.
Moreover your "logical and natural" system makes absolutely no sense. For example:
"Aethelwulf's kingdom was claimed by Aethelhnoth, Aelfric and Cynewulf.[1][2][3]"
could mean all three cites apply to the whole sentence, [1] applies to Aethelhnoth, [2] to Aelfric and [3] to Cynewulf, or that [1] demonstrates it was a kingdom, [2] that Aethelhnoth and Aelfric claim it, and [3] that Cynewulf also claimed it, or about thirty other possible interpretations.
All the best: Rich Farmbrough, 20:11, 21 November 2016 (UTC).
I've been pinged in many reviews for footnotes out of numeric order. I thought there was something in the MOS about this. Can anyone confirm or refute this? I agree with Rich in that in SilkTork's example I would have taken advantage of the commas to insert the footnotes in mid-sentence, but this is not always possible. And Rich is quite right; without checking the references, you cannot know what parts of the sentence they support. Hawkeye7 (talk) 20:49, 21 November 2016 (UTC)
I agree that it may not always be possible. But it seems to me that if the citations order is so important, we should at least be able to agree on what the order in a specific case should be. Silk Torq claims that it is in semantic order. Others claim that it is in "importance order". If either were the case then every consecutive use of cites following the other model, and every use which follows neither may very well be "wrong". (Or perhaps we should use [2][1] for importance ordered [4][3] for semantically distributed and [6][5] for the fortuitous occasions when both are valid?)
Again, if they are that important, the citations could well be referred to in the text, thus:

Norden [1] says the name is derived from a wood called Hitch, but Ekwall believes this is a conflation Wychwood, for which the Old English is Hwiccawudu.[2]

  1. ^ J. Norden (1598). Description of Hertfordshire. 
  2. ^ Eilert Ekwall (1928). English River Names. OUP. p. 197-198. 
All the best: Rich Farmbrough, 21:02, 21 November 2016 (UTC).
It's trickier than that. You get sentences like:
John Norden says the name is derived from a wood called Hitch.[1][2]
Where the first reference is about the river, and the second merely supplies his first name. Hawkeye7 (talk) 11:25, 22 November 2016 (UTC)
  1. ^ Eilert Ekwall (1928). English River Names. OUP. p. 197-198. 
  2. ^ Kitchen, Frank (2008) [2004]. "Norden, John (c.1547–1625)". Oxford Dictionary of National Biography (online ed.). Oxford University Press. Retrieved 28 October 2011.