Wikipedia:Village pump (proposals): Difference between revisions
Reverted good faith edits by Headbomb (talk): Rv involved close: leave it for an uninvolved editor or admin to close. (TW) |
|||
Line 263: | Line 263: | ||
==Access Locks: Citation Template Behaviour RFC== |
==Access Locks: Citation Template Behaviour RFC== |
||
{{Archive top|result=I'll start this acknowledging that a sizeable minority objects to the existence of these locks. However, locks have already been displayed on articles through template like {{tl|Closed access}} and {{tl|Open access}} since 2011, and through the citation templates themselves since this summer without any fuss. In light of that, the objections of roughly ten people are nowhere near enough consensus to remove those locks, especially when roughly double that have given ''direct or implicit'' support for the locks, in both this RFC and the visual design RFC. |
|||
Consensus (8 vs 4) is to allow (but not ''mandate'') the flagging of all access-levels (free/limited/registration/subscription) via {{para|url-access}} as well as identifiers (via {{para|''id''-access}}), as well as being against (7 vs 4) the automatic flagging of guaranteed-to-be-non-free identifiers. This allows for editors to choose whether or not to flag free/non-free urls and identifiers in the spirit of [[WP:CITEVAR]]. The deprecation of {{para|subscription}}/{{para|registration}} in favour of the new system is unanimous (11 vs 0). Consensus (roughly 8 vs 4) is that citations with free identifiers that link to official full versions of of the source automatically link the title as if {{para|url}} has been used. |
|||
The deprecation of {{para|subscription}}/{{para|registration}} and implementation of autolinking will be coordinated on [[Help talk:CS1]]. <span style="font-variant:small-caps; whitespace:nowrap;">[[User:Headbomb|Headbomb]] {[[User talk:Headbomb|talk]] / [[Special:Contributions/Headbomb|contribs]] / [[WP:PHYS|physics]] / [[WP:WBOOKS|books]]}</span> 16:18, 30 November 2016 (UTC) |
|||
}} |
|||
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. <span style="font-variant:small-caps; whitespace:nowrap;">[[User:Headbomb|Headbomb]] {[[User talk:Headbomb|talk]] / [[Special:Contributions/Headbomb|contribs]] / [[WP:PHYS|physics]] / [[WP:WBOOKS|books]]}</span> 15:50, 29 October 2016 (UTC) |
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. <span style="font-variant:small-caps; whitespace:nowrap;">[[User:Headbomb|Headbomb]] {[[User talk:Headbomb|talk]] / [[Special:Contributions/Headbomb|contribs]] / [[WP:PHYS|physics]] / [[WP:WBOOKS|books]]}</span> 15:50, 29 October 2016 (UTC) |
||
Line 655: | Line 662: | ||
::::::: 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. [[Special:Contributions/72.43.99.138|72.43.99.138]] ([[User talk:72.43.99.138|talk]]) 15:28, 4 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. [[Special:Contributions/72.43.99.138|72.43.99.138]] ([[User talk: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: ''[[User:Rich Farmbrough|Rich]] [[User talk:Rich Farmbrough|Farmbrough]]'',<small> 00:53, 20 November 2016 (UTC).</small><br /> |
* 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: ''[[User:Rich Farmbrough|Rich]] [[User talk:Rich Farmbrough|Farmbrough]]'',<small> 00:53, 20 November 2016 (UTC).</small><br /> |
||
{{archive bottom}} |
|||
== Draft Namespace Redirects == |
== Draft Namespace Redirects == |
Revision as of 16:18, 30 November 2016
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
New ideas and proposals are discussed here. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals. You may also wish to search the FAQ.
- Consider developing your proposal at the idea lab.
- Proposed software changes should be filed at Phabricator (configuration changes should have gained a consensus).
- Proposed policy changes belong at Wikipedia:Village pump (policy).
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
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.1234. doi:10.1007/JHEP03(2010)094.
which has been rolled out at the end of July of this year.
We are currently at an impasse in terms of the final design and behaviour of the locks. To make things simpler, let's keep this RFC purely about the visual design. A second RFC about the behaviour and technical implementation of the locks will follow this one.
A few considerations for accessibility need to be taken into account
- Any colour has to contrast at least 4.5:1 vs both black and white backgrounds.
- The visual design of each lock needs to be clear and distinct at a small size
- The visual design of each lock should convey "always free to read" "free, subject to some conditions" and "not free"
The current set of locks is
but it is unsatisfactory for a few reasons, namely the non-colour changes are only done in the shackle. Many other versions of the locks have been proposed:
- Green (free to read):
,
- Yellow (free, with conditions):
,
,
,
,
,
,
- Blue (free, with conditions):
,
,
,
,
,
,
- Red (not free):
,
Many combinations exist, but in the interest of having the greatest possible distinction between the locks, the following combinations will have 3 visual changes per level of access: Different colour, different lock body, different shackle.
In the interest of structuring the possibilities,
|
|
With that in mind, please indicate your preference for which design you prefer below. Due to the great deal of aspects we need to cover, let's vote on each aspect separately. Headbomb {talk / contribs / physics / books} 15:30, 29 October 2016 (UTC)
Visual Design RFC !Vote
Please indicate your preference for each aspect of the design below.
Aspect A1) Colour: Green–Yellow–Red (GYR) vs Green–Blue–Red (GBR)
GYR or GBR /
/
![]()
/
/
![]()
/
/
![]()
/
/
![]()
Keep in mind the shackles and bodies could differ depending on Choices A2 and A3.
- 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)
- Mild preference for yellow over blue, because streetlights, but nbd. ~ Tom.Reding (talk ⋅dgaf) 14:33, 30 October 2016 (UTC)
- GBR Seems much clearer, visually. Yellow is a better intermediate color between red and green connoting access level but blue stands out so much better. Chris Troutman (talk) 19:58, 30 October 2016 (UTC)
- GBR: 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)
- GBR On my monitor the yellow doesn't look yellow, but seems like a muddy brown; it therefore lacks an intuitive connection with a yellow streetlight. For that reason I'd go with blue. --SteveMcCluskey (talk) 12:53, 31 October 2016 (UTC)
- GBR per Headbomb's research with red-green colorblind people. Also like Steve above I get more of a muddy brown than yellow. — Scott • talk 21:03, 31 October 2016 (UTC)
- GBR per Steve. --Izno (talk) 11:26, 1 November 2016 (UTC)
- GYR. GBR looks nice, but it doesn't send me the yellow-caution-signal. Perhaps if the yellow contrast against black was heightened, this option would get more support. ~★ 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)
- GYR. Blue indicates existing links. 4nn1l2 (talk) 16:57, 6 November 2016 (UTC)
- GBR per Scott's rationale (colorblindness and muddy brown effect). Tony Tan · talk 00:54, 9 November 2016 (UTC)
- 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)
- 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)
- GBR. Blue is easier to differentiate against the other colors. NinjaRobotPirate (talk) 07:49, 16 November 2016 (UTC)
- 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)
- GYR. Blue doesn't mean anything in a "traffic light" contest. WaggersTALK 12:57, 18 November 2016 (UTC)
- GYR, as there's no way to intuit if green or blue is "freer". (Addendum: I'd support the unlisted option BGR, which avoids the yellow that seems unpopular but also allows the natural color spectrum do its thing rather than trying awkwardly to force blue into the the place of yellow. 03:31, 26 November 2016 (UTC)) —jameslucas (" " / +) 03:24, 24 November 2016 (UTC)
- GBR Were it possible to have yellow that is yellow and not some bilious color reminiscent of the content of a bay's diaper, then perhaps, I would choose that yellow. As that is not possible given the white/black background contrast requirements, I must choose the blue option. Were the question phrased to allow !voters to suggest alternate schemes here, I would choose a scheme where the icons are all of the same color and so avoid perhaps inappropriate 'traffic' semaphore color conventions: GO here; proceed to this link with caution; STOP! don't read this link. The purpose of the icon is to simply indicate that a source is free-to-read or, partially- or fully-restricted. Color is not really required to do that so long as the chosen color meets the contrast requirements and the shapes are sufficiently distinct.—Trappist the monk (talk) 15:46, 24 November 2016 (UTC)
- GBR It's unfortunate that yellow wouldn't show up well –– the muddy color presented is no more intuitive than blue. The blue seems clearly visible. DIY Editor (talk) 03:44, 25 November 2016 (UTC)
- GYR. From my staff account as head of The Wikipedia Library: I feel pretty strongly that blue isn't the right call here, precisely because it stands out too much. Blue is the 'default' color for all links on the internet, so using it here suggests that it is most common, best, most open, or simply most noticeable. A more intuitive scheme is using Green-Yellow-Red, where yellow does not overly stand out and where it for many connotes an in-between state, as in a traffic light. I do think we should use a different tone/shade of yellow since this one does look muddy, but I prefer it to the consequences of blue, and for registration-required, muddy is at least kind of consistent with the status. Ocaasi (WMF) (talk) 18:56, 29 November 2016 (UTC)
Aspect A2) 'Free with Conditions' Shackle: 100% dashed vs 50% dashed vs 25% dashed
(100%) vs
(50%) vs
(25%)
or, depending on Choice A1
(100%) vs
(50%) vs
(25%)
Keep in mind the bodies could differ depending on Choice A3.
- 50% > 25% > 100%. Although 100% dashed is the biggest difference, it looks pretty bad when printed. 50% is a good compromise, and it's, I feel, a cleaner design since it matches the body of the DHF/EHF options below, which I favour. 100% dashed is better for the EDF bodies, however.Headbomb {talk / contribs / physics / books} 00:08, 30 October 2016 (UTC)
50% > 25% > 100%25% > 50% > 100% if printing is both a strong determining factor and 100% looks bad on a lot of printers. If either of those are false, then100% > 50% > 25%100% > 25% > 50%. ~ Tom.Reding (talk ⋅dgaf) 14:33, 30 October 2016 (UTC)- 100% > 25% > 50%. 50 looks most-like a fully closed shackle, oddly enough, and for some reason 25 is marginally better. I'm less concerned about the printworthiness of these icons and in fact might suggest they aren't printed, ever. They serve no use in print form IMO. --Izno (talk) 12:01, 1 November 2016 (UTC)
- Use in print would be marginal, but to say they wouldn't be used at all, I don't buy that. People print Wikipedia articles all the time. I agree that online clarity is more important, however. Headbomb {talk / contribs / physics / books} 12:04, 1 November 2016 (UTC)
- Er, my failing at English:
aren'tshouldn't be would be more correct. --Izno (talk) 12:07, 1 November 2016 (UTC)
- Er, my failing at English:
- Use in print would be marginal, but to say they wouldn't be used at all, I don't buy that. People print Wikipedia articles all the time. I agree that online clarity is more important, however. Headbomb {talk / contribs / physics / books} 12:04, 1 November 2016 (UTC)
- 100% > 25% > 50%. Per Izno; also at 9x I can't make out the dashes in 25% and 50%. ~★ nmaia d 15:47, 4 November 2016 (UTC)
- 100% > 25% > 50%. Per Izno. 4nn1l2 (talk) 17:02, 6 November 2016 (UTC)
- 100% > 25% > 50% per Izno. However, I am concerned about the potential for 100% to look bad when printed. Nonetheless, 50% looks like a fully closed shackle. Tony Tan · talk 01:00, 9 November 2016 (UTC)
- 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)
- 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)
- 100% is the easiest to differentiate. I have some trouble differentiating between 25%, 50%, and a closed shackle, but most people probably have better eyesight than me. NinjaRobotPirate (talk) 08:06, 16 November 2016 (UTC)
- 100% > 50% > 25%. From my normal viewing distance, 25% looks like a smudged version of the open lock. Looks like 100% has it, though: a wholly dashed lock is clearer than a partially dashed one. Ian.thomson (talk) 08:09, 16 November 2016 (UTC)
- 50% > 100%. I agree with the others that 25% is too hard to differentiate. WaggersTALK 12:59, 18 November 2016 (UTC)
- 50% The dashed portion of any of these options, especially at these sizes, 'grays' that section by emulating the halftone printing process. At larger scales, the dashed shackles appear dashed so the meaning is rather more clear. If any meaning is to be extracted from a dashed shackle at the 9px width, there must be enough visible distinction between the 'gray' and the solid so that the eye can detect it at a glance. The best chance for that is with the 50% version.—Trappist the monk (talk) 16:24, 24 November 2016 (UTC)
- 100% seems the clearest to me. DIY Editor (talk) 03:42, 25 November 2016 (UTC)
- 50% > 100% > 25% From my staff account: 50% is clearly a lock and clearly in some in-between state of openness. After that I think 100%% is reasonably ok, but 25% doesn't work for me.
Aspect A3) Body: Dotted–Half–Full (DHF) vs Empty–Half–Full (EHF) vs Empty–Dotted–Full (EDF)
/
/
(DHF) vs
/
/
(EHF) vs
/
/
(EDF)
or, depending on Choice A1
/
/
(DHF) vs
/
/
(EHF) vs
/
/
(EDF)
Keep in mind the shackles could differ depending on Choice A2.
- 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)
- DHF: This is the clearest visual representation imo. ‑‑YodinT 09:04, 30 October 2016 (UTC)
- EDF >> DHF > EHF. ~ Tom.Reding (talk ⋅dgaf) 14:33, 30 October 2016 (UTC)
- DHF > EHF > EDF Chris Troutman (talk) 20:02, 30 October 2016 (UTC)
- Prefer the empty green lock and have a slight preference for the half-filled middle lock, so EHF > EDF > DHF. Per my comments above, I don't think the print case is large enough such that it should influence our decision making in these regards. --Izno (talk) 12:13, 1 November 2016 (UTC)
- Keep the current style. The full red icon looks like a purse, not a lock. How come there's no option to keep the current style? Kaldari (talk) 02:39, 3 November 2016 (UTC)
- @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)
- 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: 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)
- 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: 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)
- DHF > EHF > EDF. DHF looks more like a lock icon to me. ~★ nmaia d 15:47, 4 November 2016 (UTC)
- EDF > EHF > DHF empty for free; semi-empty for semi-free; and full for non-free. 4nn1l2 (talk) 17:08, 6 November 2016 (UTC)
- DHF > EHF > EDF. Although 4nn1l2's rationale for EDF > EHF > DHF makes intuitive sense, the empty green lock looks like a stylized lowercase a when viewed without color. Tony Tan · talk 01:10, 9 November 2016 (UTC)
- DHF per Yodin. --TerraCodes (talk to me) 20:52, 12 November 2016 (UTC)
- DHF looks best to me. The others are a bit confusing between of the stylized-A problem. If the open lock could be made to look less like a stylized A, I probably wouldn't have any preference. NinjaRobotPirate (talk) 08:14, 16 November 2016 (UTC)
- EDF > EHF. To my eyes DHF is just odd, a mishmash of filling from the centre and filling from one side. EDF and EHF are consistent in design approach; filling from the centre isn't side-ist and I find it more pleasing to look at. WaggersTALK 13:03, 18 November 2016 (UTC)
- DHF as per Headbomb (#1). —jameslucas (" " / +) 03:26, 24 November 2016 (UTC)
- DHF The dotted lock body reflects its Open Access heritage (the dotted green lock is the orange OA lock except that the green uses narrower line widths and has a slightly more open shackle). That may or may not be a good thing because these icons are not intended to indicate readability in the open access free-to-reuse sense. However, even though I know that the empty-lock-body icon is the same size as dotted, the openness makes it look larger. For that reason, dotted is best. For the registration and subscription lock, half is best because, well, that's my contribution to this mess.—Trappist the monk (talk) 16:36, 24 November 2016 (UTC)
- DHF seems the most clear. DIY Editor (talk) 03:40, 25 November 2016 (UTC)
- DHF From my staff account: DHF is best because each one is clearly a lock of some sort and yet they are unique and distinct from eachother. E-first risks the green icon not looking like a lock but just some kind of weird letter. Ocaasi (WMF) (talk) 18:56, 29 November 2016 (UTC)
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
![](http://upload.wikimedia.org/wikipedia/commons/thumb/d/db/Padlock-bronze-open.png/72px-Padlock-bronze-open.png)
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)
- 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)
- 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)
- 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)
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 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'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.
![](http://upload.wikimedia.org/wikipedia/commons/thumb/2/25/Open_Access_logo_PLoS_white.svg/20px-Open_Access_logo_PLoS_white.svg.png)
![](http://upload.wikimedia.org/wikipedia/commons/thumb/c/c1/Closed_Access_logo_alternative.svg/20px-Closed_Access_logo_alternative.svg.png)
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)
- 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)
- 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)
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)
Oppose all current suggestions. Sorry but all the above seem to be based on or inspired by the open access logo, . This is unfortunate as this has a very specific meaning (free to re-use) that is distinct from what we're trying to convey here (free to access). The distinction already causes confusion among Wikipedians and the general public, and I don't want us to make it worse. Icons like
and
are especially problematic, as readers might infer they indicate sources that are "more free" than
. Instead, I suggest using icons that are visually very distinct from
. Perhaps a solid red padlock with a square or rectangular base for not free to access, and the same in green but with the shackle pointing to the right for free to access. So icons along the lines of
and
, but smaller and monocolour. Adrian J. Hunter(talk•contribs) 03:43, 31 October 2016 (UTC)
- The use of colors suggest a potential accessibility issue. See the guidelines at WP:COLOR. Praemonitus (talk) 16:04, 31 October 2016 (UTC)
- Although I agree that the current design may obfuscate the two levels of Open Access, I think that the distinction (OA gratis vs. OA libre) is irrelevant for verification purposes. For the latter, free access is important; freedom to re-use is immaterial. 72.43.99.130 (talk) 19:47, 31 October 2016 (UTC)
- Well, no one has proposed square bodies, but there's nothing saying those couldn't be used. Would likely need to be Empty / Half / Full bodies, since a 'dotted body' wouldn't make any sense. However, square bodies would likely lead to confusion with secure vs non-secure urls. Headbomb {talk / contribs / physics / books} 22:36, 4 November 2016 (UTC)
- I believe that Adrian has a legitimate concern here, though I cannot suggest a better alternative myself. Like Headbomb said, a square body could lead to confusion with https security, which would be undesirable. Tony Tan · talk 01:21, 9 November 2016 (UTC)
Suggestion: use emojis as fallback. I'm not sure if this is feasible, but it could be interesting to use the emojis 🔓 — 🔐 — 🔒 in cases where images can't be displayed, as a fallback mechanism. What do you think? ~★ nmaia d 15:59, 4 November 2016 (UTC)
- Avoid red. Red indicates a problem that needs to be addressed, or something that is invalid. Closed access is surely not good, but it is not something that can be addressed in reading the article. The standard OA icon was designed to highlight that at least some material was available OA--and was designed when very little material was actually OA, & was meant to be conspicuous for the purpose of advocacy. We could make a case for using it, because it is still the standard. There's no point is designing our own visual language when there is already an accepted version--we might as well abandon the English WP for Esperanto. DGG ( talk ) 18:04, 7 November 2016 (UTC)
Withdraw both RFCs. This is way too complicated, and some (non-mutually exclusive) proposed options conflict with each other. For complex proposals such as this I believe the mandate to go either way should be far clearer; but because of this complexity, a fair-to-middling "support" consensus is worth less than a poor-to-fair "oppose" consensus. The onus is on the supporters. Show better cause, and renominate. 72.43.99.130 (talk) 19:52, 7 November 2016 (UTC)
I've thought about our color schemes and went back to the design board. I figured a lot of objection is that RED is too-in-your face, and that yellow is not yellow enough. So I think may we ought to consider a Green/Gray/Black scheme like ( /
/
). Headbomb {talk / contribs / physics / books} 17:54, 25 November 2016 (UTC)
- That fails the black background requirement.
- —Trappist the monk (talk) 17:56, 25 November 2016 (UTC)
- @Trappist the monk:
/
/
maybe? I think I'll try a two-tone (grey/green) middle lock. Headbomb {talk / contribs / physics / books} 18:08, 25 November 2016 (UTC)
- Got it, I think
/
/
. We could also consider schemes like
/
/
. I really like that last one. Headbomb {talk / contribs / physics / books} 18:15, 25 November 2016 (UTC)
- From my staff account: Of the 3 you just suggested I like 1 and 3, but not 2 (mixed color is confusing). These are solid choices you added! Ocaasi (WMF) (talk) 18:56, 29 November 2016 (UTC)
- Got it, I think
- @Trappist the monk:
I think Trappist's all-blue proposal (where all locks are of the same colour, the same as the external link icon) would be very nice (much more neutral). − Pintoch (talk) 18:26, 25 November 2016 (UTC)
- Disagree there. We'd lose the clearest distinction between the locks available to most people, and they'd get buried in the sea of blue. Headbomb {talk / contribs / physics / books} 18:29, 25 November 2016 (UTC)
Access Locks: Citation Template Behaviour RFC
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
This is an RFC to decide on the behaviour of citation templates concerning when/how to deal with access locks, and free-to-read articles. Headbomb {talk / contribs / physics / books} 15:50, 29 October 2016 (UTC)
What the Citation Template Behaviour RFC is about
Hi all,
Over the past few months, a bunch of us have been working (see announcement) on designing so called "access locks" for the citation templates (see Help:CS1/Help:CS2) and for the various identifier templates (such as {{arxiv}}, {{bibcode}}, {{doi}}, etc.). See the upcoming Signpost article on the topic for details, both technical and non-technical. Some of you may have noticed the green lock in citations such as
- Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD". Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234. doi:10.1007/JHEP03(2010)094.
which has been rolled out at the end of July of this year.
We are currently at an impasse in terms of the final design and behaviour of the template when it comes to the locks. To make things simpler, let's keep this RFC purely about the behaviour of the locks. A first RFC about visual design of the locks precedes this one. For purpose of the discussion and examples, I'm using the current original locks.
First aspect
First, there is the matter of the templates' allowed and disallowed behaviour. Currently, we're enforcing the unofficial convention that links in |url=
should be free, and flag those that are not completely free via |url-access=registration
and |url-access=subscription
(which respectively display and
after the primary link), but disallow
|url-access=free
(which would respectively display after the primary link, if allowed). Likewise, we're treating identifier links (like doi:10.1007/JHEP03(2010)094 in the above example) as non-free by default, and flag only those that are free via
|doi-access=free
(which displays after the doi link), but disallow
|doi-access=registration
and |doi-access=subscription
(which would respectively display and
after the doi link, if allowed). The point (currently at least) is to reduce the amount of 'visual' clutter. However, we need to decide if that convention is one we want to make official, or if we want to allow more flexibility in the system.
That is, do we want to allow all locks anywhere
- Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD"
. Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234
. doi:10.1007/JHEP03(2010)094
.
or do we consider that our non-official convention conveys clearly enough that the main link is free, while the doi doesn't have free full versions available that we can make it official and enforce it.
- Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD". Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234
. doi:10.1007/JHEP03(2010)094.
Likewise, if we allow all locks, do we want to automatically flag identifiers links we know are subscription-only, like MR0123456 , or let such flagging be an editorial decision?
Second aspect
Second, this concerns whether or not we should deprecate |registration=
and |subscription=
in favour of the new system. The problem with the current use is the message is ambiguous when many links are present. See for example, the current style works well enough if only one link is present:
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. (registration required (help))
but is ambiguous if more than one link is given:
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456. (registration required (help))
The new style would make it clearer to which link registration applies
- Smith, J. (2016). "Fictitious title"
. Fictitious Journal. 1 (2): 3. doi:10.1234/123456.
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456
.
However, we can only deprecate |registration=
and |subscription=
if we support locks everywhere. In either scenario, this will create a backlog of errors, which bots can fairly easily take care of in ~90% of cases. However, if we support both systems, many users and bots inadvertently keep creating errors when they add a doi to a previously doi-less reference, or a url to a previous url-less reference, as they would need to also change |registration=yes
to |url-access=registration
or |doi-access=registration
at the same time.
Third aspect
Third, this concerns the "automatic linking" of titles, based on the presence of free identifiers. Currently, a citation with a PMC (which is always free), automatically links the title
- Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC 4309825
.
This is considered desirable behaviour by some, but redundant by others. The question is, do we extend this behaviour to other identifiers which link to full official free versions as well? That is, if we have a free doi, do we want to present this citation as
- Dunlop, . A.; Apanaskevich, D. A.; Lehmann, J.; Hoffmann, R.; Fusseis, F.; Ehlke, M.; Zachow, S.; Xiao, X. (10 October 2016). "Microtomography of the Baltic amber tick Ixodes succineus reveals affinities with the modern Asian disease vector Ixodes ovatus". BMC Evolutionary Biology. 16 (1). doi:10.1186/s12862-016-0777-y
.
or as
- Dunlop, . A.; Apanaskevich, D. A.; Lehmann, J.; Hoffmann, R.; Fusseis, F.; Ehlke, M.; Zachow, S.; Xiao, X. (10 October 2016). "Microtomography of the Baltic amber tick Ixodes succineus reveals affinities with the modern Asian disease vector Ixodes ovatus". BMC Evolutionary Biology. 16 (1). doi:10.1186/s12862-016-0777-y
.
or do we remove the autolinking from the PMC identifier?
- Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC 4309825
.
With that in mind, please indicate your preference for which behaviour you prefer below. Due to the great deal of aspects we need to cover, let's vote on each aspect separately. Headbomb {talk / contribs / physics / books} 15:30, 29 October 2016 (UTC)
Citation Template Behaviour RFC !Vote
Please indicate your preference for each aspect of the behaviour below.
Aspect B1) Allow all locks vs Restrict locks
- Allow (not mandate) all locks
- Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD"
. Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234
. doi:10.1007/JHEP03(2010)094
.
- Restrict locks (current behaviour)
- Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD". Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234
. doi:10.1007/JHEP03(2010)094.
- Allow all locks if someone wants to comb through all identifiers and flag them as free/non-free, I don't see that as a bad thing. This would then allow us to deprecate
|registration=
and|subscription=
in B3.Headbomb {talk / contribs / physics / books} 00:09, 30 October 2016 (UTC)- After seeing some cases in the wild, many people add {{closed access}} to citations without urls, but dois only. Allowing locks would mean being able to take care of those citations in a much, much better way. If they aren't desired, they can always be removed manually. Headbomb {talk / contribs / physics / books} 12:37, 24 November 2016 (UTC)
Restrict locksAfter 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)
- 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
- 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)
- Restrict locks if there is an assumption that sources are free to access then there is no need to indicate the default position of free access. A green lock on every free access source is going to be a lot of clutter. Nthep (talk) 14:31, 30 October 2016 (UTC)
- No green locks: The locks are useful only to indicate non-free content and the default should be free access like this:
- Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD". Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234. doi:10.1007/JHEP03(2010)094
.
- Auzzi, R.; Elitzur, S.; Giveon, A. (2010). "On Uplifted SUSY-Breaking Vacua and Direct Mediation in Generalized SQCD". Journal of High Energy Physics. 2010 (3): 94. arXiv:1001.1234. doi:10.1007/JHEP03(2010)094
- restrict locks 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)
- 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)
- Restrict locks (and no green locks) per Nthep. Researchers are mainly going to be interested in the primary link. Adding icons to all the links is unnecessary clutter and confusing. I also agree with RexxS that open access should be the assumed default and we don't need to add green locks. Kaldari (talk) 17:22, 31 October 2016 (UTC)
- Allow all locks. The fact that there's disagreement about this is itself evidence that we should allow flagging of both free and non-free sources, because the nature of the "default" expectation depends on the topic area. It must be nice to live in a world where the default expectation is open-access (or at least free-to-read), but that's certainly not the case in the topic areas I work in. Most journal publications are paywalled, many of those will have an alternative source (like PMC) which is free-to-read, and there's no particular reason we should expect readers to know how that works. Opabinia regalis (talk) 20:32, 4 November 2016 (UTC)
- Allow all locks. This supposed convention that DOI (etc) links are assumed non-free, and other links are assumed free, is completely reader-unfriendly. I don't know how readers are supposed to pick up on this convention. Therefore, we need to be consistent across all the links. Ideally, we would flag only those links which are not 100% open access, by the logic that virtually all links in Wikipedia articles (internal links in the article text, external links in the "external links" section, and so on) are assumed to be freely accessible, so we should mark those links that violate this convention. However, this raises the issue of how to deal with links whose subscription/registration-required status is not known. To solve that problem it seems necessary to show locks on all links within journal references when the subscription/registration-required status is known, and to show no lock when no information is available. — This, that and the other (talk) 00:33, 5 November 2016 (UTC)
- Ideally we'd have a system like this: Known to require a subscription: red lock; Known to require registration: yellow or blue lock; Known to be free: no lock; Status not known; silver lock with silver question mark beside it. But that is not what is being proposed here, unfortunately, so I am not going to !vote for it. — This, that and the other (talk) 08:16, 5 November 2016 (UTC)
- Allow all locks, 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)
- 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)
- Oppose general proposal. Hell if I can figure out where to oppose the entire idea here, or if that ship has already sailed. I understand the problem with the subscription-required tags, but I think there are other ways to solve the ambiguity issue than this. There are several concerns that I have with the entire proposal:
- First, universality. Although its been a little bit since I've been active there, I'm very proud of my work at FAC, where I often focus on reference quality and citation formatting. The proposers here say that this is about scholarly publications and not all sources, but let me be very clear here: consistency in reference formatting is a Featured Article requirement; if you're going to implement this here, you're going to need to implement this elsewhere, too, and I do not think the ramifications of applying these standards to books or non-scholarly periodicals have been fully considered. The idea that newspaper-article access levels can be tracked by bot, in particular, strikes me as naive. In fact, I'm dubious that bots can do the things that have been handwaived here as a problem for bots to solve, and I'd like to see some controlled-environment testing of that assertion.
- Second, implied bias. In the "real world" outside Wikipedia, I agree that open access is "better" than closed access, especially in scholarly publications (which are often, at least in part, publicly funded). But there is no obligation to base articles here on open-source content. Indeed, if the best quality sources are less-easily available, those remain the best quality sources. Cutesy icons that make paywalled material look like it is "bad" (and make no mistake, bright red padlocks look bad, in part because they look like citation error text), imply that paywalled or restricted-access material is inferior. Further, I specifically oppose the idea floated somewhere above by an IP editor who I shan't track down, suggesting that editors have an obligation to provide links to the most-free source of their references. Specifically, this places republication sites like ResearchGate as "preferably" to journals' actual official digitization sites; such cases are clearly more accessible, but I question whether they are innately better. I'm here to write open-access articles for an open-access encyclopedia, but I don't necessarily believe that extends any obligation on me to support open-access sourcing in my references.
- Third, this proposal has not in any way discussed how an editor is intended to interact with the system when working from a print source. I know, I know, paper, right? But I do a lot of my article research at libraries, including (at times) specialist and reference collections. Frequently, I have no idea what sources are available online, if any. I link comparatively little. Still, sometimes I have the doi for an article, even if I'm not working from an online copy. I include that doi in my citations because I assume it is of use to editors. I am not interested in auditing its open-access level. I trust that no aspect of this proposal will make use of these locks mandatory? Squeamish Ossifrage (talk) 15:59, 11 November 2016 (UTC)
- RE a few things.
- "The proposers here say that this is about scholarly publications and not all sources".
- No one says that. The system is universal, and would cover all such sources.
- "The idea that newspaper-article access levels can be tracked by bot, in particular, strikes me as naive."
- Again, no one claimed that. Bots can do a lot, and will mostly be helpful with sources that have identifiers. Humans will need to get involved as well, just like they are involved now with
|subscription=yes
.
- 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
- "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.
- 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
- "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.
- "The proposers here say that this is about scholarly publications and not all sources".
- 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)
- Allow all. There are fair arguments for both sides. However, if someone wants to label the links, I think they should be able to do so. The locks can produce unnecessary clutter in some Wikipedia articles, but in less technical articles, labeling the various links could resolve a lot of confusion. Not everyone is familiar with this or has an idea of what the default is for each type of link. NinjaRobotPirate (talk) 08:48, 16 November 2016 (UTC)
- Allow all locks. A few years back, HTTPS links used to have a blue lock next to them. I think this idea is similar, and that soon we'll have an icon to indicate that a link is not secure. Just because the default behavior is to paywall information and knowledge, doesn't mean we need to follow that behavior. I feel that in a few years paywalled access is going to shrink, because the issue is being highlighted more. Having locks to indicate how much of the information we rely on is walled off on one of the major sources of knowledge on the internet is definitely helpful (maybe we'll even see a headline on the clickbait sites like "oh snap! Wikipedia's just paywalls to shame" or whatever!). —Hexafluoride Ping me if you need help, or post on my talk 12:35, 19 November 2016 (UTC)
- Restrict. Broadly, cs1|2 identifiers link to paywalls and registration gates so these sources are not free-to-read. That is the norm for cs1|2 identifiers. There are, of course, exceptions: PMC, arXiv, RFC, etc. cs1|2 knows that these are not the norm so automatically highlights these identifiers with the green free-to-read icon. There is no need to add little red or yellow locks to identifiers that normally link to sources that are in someway restricted; that is the normal and so the expected state for these links. When an identifier links to a free-to-read source, that is novel, so we should highlight that identifier so that readers know that that particular identifier is different. In the similar but opposite case, most urls in
|url=
and|chapter-url=
, and external links elsewhere throughout Wikipedia whether part of cs1|2 citations or not, refer to free-to-read sources. Marking these free-to-read sources as free-to-read conveys no new or useful information to the reader so these sources should only be marked when there is a registration or subscription cost to the reader. Do not highlight the norm. —Trappist the monk (talk) 19:40, 24 November 2016 (UTC) - Allow all locks. I'm commenting from my staff account as head of The Wikipedia Library, because I support and have worked on implementing this feature--so it's simply transparent to do so. If closers want to discount this as an out-of-place staff opinion that's fine of course. Fundamentally, locks allow readers to make decisions about whether and how to verify a source. It is very non-trivial that many sources are closed access--not free to read--since one of the core strengths of Wikipedia is the ability to and benefit from "checking the source". I'm well-aware that WP:PAYWALL doesn't preferences open sources over closed ones and have always supported that line. Yet this is not a comment on which sources to use, but how to indicate to the user what experience they will have when they click through. As a fundamental principle of usability, it's good to let the reader know what to expect, and these locks do so in a predictable and lightweight way. Second, links with open locks will be clicked on more, as readers without institutional access come to associate a positive experience with them. This provides added incentive for publishers to make sure there are free-to-read versions of their content available in ways consistent with copyright. This is not a political stance (although open access is undoubtedly better for readers than closed access); it's a simple win-win that encourages a good experience for readers while increasing the intelligent consumption of Wikipedia's content. Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)
Aspect B2) Automatically flag non-free sources vs Don't automatically flag non-free sources
Note we're talking about default behaviour only. Locks could always be added manually in individual articles, assuming choice B1 allows for them
- Automatically flag non-free sources
- Don't flagged by default (current behaviour)
Keep in mind the automatic flagging depends on choice B1. If we choose to restrict locks, then the second behaviour wins by default.
- 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)
- 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)
- As a point, again, no assumption would be made. Under this proposal, only known-to-be-X would be automatically marked as
- Don't flag by default per Headbomb as this could cause confusion, and because I voted for restricting locks above. Kaldari (talk) 17:27, 31 October 2016 (UTC)
- Per Headbomb, don't flag by default, though it sure would be nice to avoid needing to set the access state for everything. --Izno (talk) 12:31, 1 November 2016 (UTC)
- 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)
- Conditional: Flag by default if/when
sometimes not-free identifiers which haven't been flagged as not being free
are all (mostly) identified/worked-around/etc. Until then, Don't flag by default. ~ Tom.Reding (talk ⋅dgaf) 13:03, 8 November 2016 (UTC) - Flag by default per "Opabinia regalis". We have to start somewhere, so we should flag sources by default when they are 100% confirmed to be non-free. Tony Tan · talk 02:21, 9 November 2016 (UTC)
- Flag by default. I can see the argument that this could be confusing, but if we know what the access level is, we should probably provide that information. NinjaRobotPirate (talk) 08:52, 16 November 2016 (UTC)
- Flag by default. Some sources are known to be (and have always been) paywalled, or require registration at least. There's no harm in assuming that an Elsevier link is (unless specified otherwise) paywalled. It's the default behavior of certain (and most) publishers. On the other hand, some publishers are built upon open access, such as PLOS, therefore the links coming from such sources are open access and there's no harm in automatically assigning them the green (un)lock. —Hexafluoride Ping me if you need help, or post on my talk 12:40, 19 November 2016 (UTC)
- Hexafluoride (talk · contribs) That's not quite what's being proposed. This sort of flagging can be done by bots. What we're talking about is the template automatically flagging guaranteed-to-be-non-free identifiers. That is, links like MR1129886 will always be non-free. Do we want to automatically flag them as such, possibly introducing an inconsistent style? For instance, a source can both have a non-free doi and a non-free MR, but the template would only automatically flag the non-free MR, since the doi can often be free. This would introduce an inconsistency that would need to be resolved by manually flagging the doi with
|doi-access=subscription
, or by manually suppressing the automatic flag. Headbomb {talk / contribs / physics / books} 13:08, 24 November 2016 (UTC)
- Hexafluoride (talk · contribs) That's not quite what's being proposed. This sort of flagging can be done by bots. What we're talking about is the template automatically flagging guaranteed-to-be-non-free identifiers. That is, links like MR1129886 will always be non-free. Do we want to automatically flag them as such, possibly introducing an inconsistent style? For instance, a source can both have a non-free doi and a non-free MR, but the template would only automatically flag the non-free MR, since the doi can often be free. This would introduce an inconsistency that would need to be resolved by manually flagging the doi with
- Do not auto-flag non-free sources. I presume here that the question refers to cs1|2 identifiers, most of which are not free-to-read. Because that not-free-to-read state is the norm, we should not allow the use of icons that say this normally-not-free-to-read is, yep, you guessed it, not free-to-read. Do not highlight the norm. Redundant; clutter; pointless. If the question is intended to also include non-free sources accessed through
|url=
and the like, I oppose that because cs1|2, without a very large database of urls, cannot know if this particular url is free-to-read or is restricted.—Trappist the monk (talk) 19:52, 24 November 2016 (UTC) - Do not auto-flag by default. Again from my staff account: Even among the most notorious paywalled publishers such as Elsevier, an increasing number of articles appear in "hybrid" journals which publish both open and closed content under the same publication. This is further complicated by embargoed content that is closed for its first 6-24 months and then becomes open later. We don't yet have the infrastructure to reliably tag closed access by default. It also reduces the effectiveness of the partially and fully open locks as signals of a better experience; they stand out more when they are not in a sea of closed locks, which is what would commonly happen in our highly paywalled world. Lastly, as not-free-to-read is unfortunately still the norm, it makes much less sense to "tag the norm". Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)
Aspect B3) Deprecate old system vs support both old and new systems
- Deprecate
Supported
- Smith, J. (2016). "Fictitious title"
. Fictitious Journal. 1 (2): 3.
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456
- Smith, J. (2016). "Fictitious title"
. Fictitious Journal. 1 (2): 3. doi:10.1234/123456.
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456
- Smith, J. (2016). "Fictitious title"
. Fictitious Journal. 1 (2): 3. doi:10.1234/123456
Unsupported
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. (registration required (help)) Error: |registration= is deprecated, use instead |url-access=registration.
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456. (registration required (help)) Error: |registration= is deprecated, use instead |doi-access=registration.
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456. (registration required (help)) Error: |registration= is deprecated, use instead |url-access=registration or |doi-access=registration.
- Support both systems (current behaviour)
Supported
- Smith, J. (2016). "Fictitious title"
. Fictitious Journal. 1 (2): 3.
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. (registration required (help))
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456. (registration required (help))
- Smith, J. (2016). "Fictitious title"
. Fictitious Journal. 1 (2): 3. doi:10.1234/123456.
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456
- Smith, J. (2016). "Fictitious title"
. Fictitious Journal. 1 (2): 3. doi:10.1234/123456
Unsupported
- Smith, J. (2016). "Fictitious title". Fictitious Journal. 1 (2): 3. doi:10.1234/123456. (registration required (help)) Error: |registration= could apply to multiple links, use instead |url-access=registration or |doi-access=registration.
In call cases, there is currently no error messages being displayed. The ones shown above are mockups of what could be displayed in the next update.
- 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)
- 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)
- 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)
- 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)
- Are you sure? It is not necessary for the cs1|2 templates to accept
-
- 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.
- Fixed the indent and inserted a missing
-
- 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)
- 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
- 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)
- 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
- 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)
- It definitely is required, otherwise we cannot handle cases like
- 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)
- 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)
- @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)
- 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)
- @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)
- Deprecate Opabinia regalis (talk) 20:36, 4 November 2016 (UTC)
- Deprecate, per above votes. ~ Tom.Reding (talk ⋅dgaf) 13:07, 8 November 2016 (UTC)
- Deprecate if most resulting errors could be fixed quickly. Having two systems would be too confusing to readers and editors alike. Tony Tan · talk 02:25, 9 November 2016 (UTC)
- 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)
- Deprecate, presuming that
|subscription=
and|registration=
are replaced with a new more specific system (not necessarily the one being contemplated in this series of RfCs) because these two parameters are non-specific and have been / are used where a cs1|2 template has both a url (perhaps in|url=
) and one or more of the named identifiers. When this occurs, it is impossible to determine by inspection, to which the restriction notice applies. —Trappist the monk (talk) 20:24, 24 November 2016 (UTC) - Deprecate. Again from my staff account: I trust the judgement of Trappist and others that it's best not to have to redundant systems. Also, deprecate "fails gracefully" in that it allows for cleanup and informs the user what the new system entails. Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)
Aspect B4) Always autolink titles with free identifiers vs Autolink titles with PMC only vs Never autolink titles
Note we're talking about default behaviour only. If autolinking by default is not desired, title linking could always be done manually in individual articles. If autolinking by default is desired, autolinking could always be suppressed manually in individual articles.
- Always autolink titles with free identifiers
- Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC 4309825
.
- Dunlop, J. A.; Apanaskevich, D. A.; Lehmann, J.; Hoffmann, R.; Fusseis, F.; Ehlke, M.; Zachow, S.; Xiao, X. (10 October 2016). "Microtomography of the Baltic amber tick Ixodes succineus reveals affinities with the modern Asian disease vector Ixodes ovatus"
. BMC Evolutionary Biology. 16 (1). doi:10.1186/s12862-016-0777-y
.
- Autolink titles with PMC only (current behaviour)
- Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC 4309825
.
- Dunlop, J. A.; Apanaskevich, D. A.; Lehmann, J.; Hoffmann, R.; Fusseis, F.; Ehlke, M.; Zachow, S.; Xiao, X. (10 October 2016). "Microtomography of the Baltic amber tick Ixodes succineus reveals affinities with the modern Asian disease vector Ixodes ovatus". BMC Evolutionary Biology. 16 (1). doi:10.1186/s12862-016-0777-y
.
- Never autolink titles
- Williams, R. O. (6 January 2015). "How Do You Use AAPS PharmSciTech?". AAPS PharmSciTech. 16 (1): 1–2. PMC 4309825
.
- Dunlop, J. A.; Apanaskevich, D. A.; Lehmann, J.; Hoffmann, R.; Fusseis, F.; Ehlke, M.; Zachow, S.; Xiao, X. (10 October 2016). "Microtomography of the Baltic amber tick Ixodes succineus reveals affinities with the modern Asian disease vector Ixodes ovatus". BMC Evolutionary Biology. 16 (1). doi:10.1186/s12862-016-0777-y
.
A green lock could follow the title, depending on choice B1.
- 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)
- 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)
- 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) - (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.) - Always autolink — clear benefit to readers and editors. Carl Fredrik 💌 📧 11:02, 30 October 2016 (UTC)
- 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)
- 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)
- You don't edit much on health content, do you. Jytdog (talk) 15:15, 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)
- 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)
- 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)
- 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)
- 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)
- 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)
- I'm perplexed. You wrote:
germane because PMC refs will always also have a pmid
. Is that true? Right now, cs1|2 templates with|pmc=
are not required to have an accompanying|pmid=
. Are you arguing off topic here for a function in the cs1|2 template that would throw an error when a template has|pmc=
without a matching|pmid=
? You wrote:the PMC parameter should behave exactly like the PMID parameter
. At present, the|pmid=
parameter causes Module:Citation/CS1 to link the assigned identifier value to PubMed. The Module links the value assigned to|pmc=
to PubMed Central and it also links the template's|title=
parameter to the same PubMed Central page. On the one hand you write:always autolink pmc parameter
and on the other hand you write:the PMC parameter should behave exactly like the PMID parameter
. Are these not incompatible statements? —Trappist the monk (talk) 11:03, 1 November 2016 (UTC)- User:Trappist the monk of course there is no "requirement" to use pmid. What I wrote was that in WP:MED the pmid is the most important parameter in a template and everybody in WP:MED uses it. It is essential in practice and you will find it ubiquitous in articles about health. Yes, the pmid paramater links to the pubmed abstract, like this 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)
- 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)
- 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)
- 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)
- 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)
- Per Kanguole, "Never autolink title, always autolink identifiers, and suggest that |url= only be used for URLs not covered by identifiers". I see nil reason, if we are highlighting links elsewhere with locks, to provide autolinking anywhere but in the context of the identifiers. The software complexity also isn't worth it. --Izno (talk) 12:24, 1 November 2016 (UTC)
- Always autolink It's obviously a usability benefit to have the title always link to a free-to-read source if one is available. All of this stuff about PMIDs seems completely beside the point; the PMID never leads directly to a free-to-read source. Opabinia regalis (talk) 20:38, 4 November 2016 (UTC)
- Always autolink identifiers: Linking the title is a good design feature, because it establishes a very simple, user-friendly pattern: follow the title's link to be taken to the best available way to access the source. Using autolinks is a good pattern because it lets us use reliable identifiers for those title links rather than duplicating data (e.g. supplying a URL to dx.doi.org) or using a potentially non-permanent URL when it's ultimately equivalent to the (nominally permanent) DOI. That said, I also think that we should not autolink identifiers that only lead to index entries, e.g. PMIDs—they don't match the pattern of the title linking to the source itself. {{Nihiltres |talk |edits}} 21:44, 4 November 2016 (UTC)
- Always autolink title for better usability if the links always lead to free, official, and full versions according to Headbomb. Tony Tan · talk 02:33, 9 November 2016 (UTC)
- Always autolink. It's a design that the user has been accustomed to (click on the title if there's a URL). The link and PMC might be different and don't always lead to the same site. —Hexafluoride Ping me if you need help, or post on my talk 12:48, 19 November 2016 (UTC)
- Never autolink. This will require Module:Citation/CS1, the code that underlies the cs1|2 templates, to make judgements that may not accord with an editor's preference. When there is no value assigned to
|url=
and only one free-to-read identifier, while it will be a pain, it is not too difficult to imagine how the code would accomplish this task. As soon as there are two or more free-to-read identifiers, then somehow, the code must select one or the other to apply to|title=
. Which shall it be? What if the code does not choose the one that the editor prefers? Sure, we could add yet more parameters to tell cs1|2 how to resolve the dilema; we could overload|url=
so that an editor could tell the Module to create a url for|title=
from a particular identifier. There may be other 'solutions'. In the end, if an editor must have|title=
linked, it is simplest to simply place the url in|url=
and be done. cs1|2 is complex and confusing enough as it is, don't make it worse. —Trappist the monk (talk) 20:55, 24 November 2016 (UTC) - Comment Also from my staff account: My personal opinion is that the correct method is that the title link should be to the paper/version of record, whether it is closed or open. Free-to-read versions may be preprints or another pre-publication manuscript. I don't think we yet live in a world where we can reliably autolink the title, especially as Trappist mentions, if that means deciding which version should be the "primary" one. Ocaasi (WMF) (talk) 18:40, 29 November 2016 (UTC)
Citation Template Behaviour RFC discussion
As described, both choices for the "First aspect" regarding "allowed and disallowed behavior" (also identified as "Aspect B1") seem to confuse rendering with annotation. My personal preference would be for it to be always acceptable for a citation to be annotated "|url-access=free" and "|doi-access=registration / subscription", but the rendering behavior should continue using the current convention that reduces visual clutter by only displaying locks when expectations are broken (i.e. the default expectation is that the main link is free while "doi" doesn't have a free full versions available). I think the correct behavior is a third option for Aspect B1, call it "allow all annotations, but display lock symbols only if annotations differ from the default expectation". In this third option it would always be allowed for an editor to individulaly annotate the subscription status of all parts of the citation, but the citation code would only display the lock symobls if an annotation differs from the default expectation (i.e. if a citation is annotated with "|url-access=free" no green lock should be shown for the title, as that is the expected behavior). —RP88 (talk) 16:35, 29 October 2016 (UTC)
- Which option keeps the current status quo unchanged? Hchc2009 (talk) 17:06, 29 October 2016 (UTC)
- Hchc2009, from what I can determine the code what was rolled out today uses the "Restrict locks" option. For example, code rolled out today produces the following...
{{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456}}
→
- Author (2010). "Title". doi:10.1234/123456.
{{cite journal}}
:|author=
has generic name (help); Cite journal requires|journal=
(help)
{{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=free |doi-access=subscription}}
→
- Author (2010). "Title". doi:10.1234/123456.
{{cite journal}}
:|author=
has generic name (help); Cite journal requires|journal=
(help); Invalid|doi-access=subscription
(help); Invalid|url-access=free
(help)
{{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=subscription |doi-access=free}}
→
- Author (2010). "Title". doi:10.1234/123456.
{{cite journal}}
:|author=
has generic name (help); Cite journal requires|journal=
(help)
- ...while I think it should do the following (which doesn't match either of the two offered options):
{{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456}}
→
- Author. (2010). "Title" . doi:10.1234/123456.
{{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=free |doi-access=subscription}}
→
- Author. (2010). "Title" . doi:10.1234/123456.
{{cite journal |author=Author |title=Title |year=2010 |url=http://example.com |doi=10.1234/123456 |url-access=subscription |doi-access=free}}
→
- Author. (2010). "Title"
. doi:10.1234/123456
.
- —RP88 (talk) 17:43, 29 October 2016 (UTC)
- Hchc2009, from what I can determine the code what was rolled out today uses the "Restrict locks" option. For example, code rolled out today produces the following...
Is there any reason why we're not giving people a choice in the RfC of sticking with the 28 October status quo? I'm not seeing any compelling argument (or indeed consensus) from making any change from that position. Hchc2009 (talk) 17:41, 29 October 2016 (UTC)
I don't see that the limited choices presented here actually represent the best behaviour for readers and inexperienced editors. My belief is that there is little or no value in flagging a link as free. Whom does that benefit? Is the average reader going to think "I'll follow that link because it's free"? Of course not. The only value in having visual indicators is to warn readers when links point to content that is not free, which may save some time for some readers. Secondly, I disagree strongly with having a "mixed bag" of unofficial conventions. There is no use assuming that one type of link is free and another type is non-free. Only those already very familiar with pmid/pmc/doi/arxiv will know which is which type and we're not writing the encyclopedia just for them. Pick one convention and stick to it - I'd recommend always marking all links requiring subscription/registration and never marking links that are free. That benefits readers and is simple enough for inexperienced editors to grasp quickly. Finally, I think the new system of moving to corresponding parameters for |url-access=
, |doi-access=
, etc. and deprecating the old system of |registration=
and |subscription=
is an improvement, giving proper flexibility and should be implemented. --RexxS (talk) 18:42, 29 October 2016 (UTC)
- No locks. I see no compelling reason to clutter citations with little dingbats. The locks are a political statement, not a tool for readers. The reader is not helped in the slightest by their presence. The reader either wants to read the source or doesn't. No reader is going to look at a little icon and say, "I really wanted to read the whole thing, but I can't, so I'm not even going to look for the free abstract or first page that the publisher might provide." And what do you plan to do when a journal changes its access policy? If the journal is important and frequently cited, someone will need to update hundreds, maybe even thousands of citations scattered all over the encyclopedia. I realize that interested editors have invested a lot of effort into this proposal, but I see no way in which it helps the encyclopedia. Ozob (talk) 18:45, 29 October 2016 (UTC)
- What most often happens to me is that I click on a link which is not free (beer)-to-access and end up wasting time in doing so, because my desire is to access the information at low-cost. $40 a paper is decidedly not low-cost. It is most certainly not a political statement. You should review the option above regarding auto-icon-ing sources which are always non-free, since I am unsure you read the proposals to any degree. --Izno (talk) 13:04, 1 November 2016 (UTC)
- If I am reading you correctly, you are claiming that if you read a publisher's website and are provided with a free abstract, then you have "wast[ed] your time" because you cannot "access the information at low-cost." Even for papers that are not free, I can't interpret your claim as anything other than exaggeration.
- To be clear, I did read the whole proposal. It assumed that Wikipedia editors wanted some kind of locks. Well, I don't. For the reasons I gave above, I don't want any locks at all. I still don't see a compelling argument in their favor, and certainly not one that outweighs the clutter they create. Ozob (talk) 23:55, 1 November 2016 (UTC)
- 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)
- 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)
- 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 their decision. "Here's a link, but we're not going to tell you if you can read it or not" sends the reader on a wild goose chase. Worse, if they click on DOIs a few times and they happen to be taken to paywalled sources everytime, they may conclude DOIs are always paywalled and will just stop bothering clicking on DOIs in general. Headbomb {talk / contribs / physics / books} 14:41, 30 October 2016 (UTC)
- Pardon me while I return to a previous point.
I believe the anon's point is that access to sources is important for verifying the correctness of Wikipedia. This is true, but I don't see it as an argument for (or against) locks.
Indeed. Imo, LoudLizard was overreaching by implying that the presence of icons in citations is essential to the Wikipedia content the citations verify, or to verification in general, invoking the pillars of Wikipedia etc. which (again imo) makes it sound like a religious argument. However I do believe that readers should know a source has access requirements before they click the link. Whether the proposed scheme is the best way to do that is an open question. Oh, and by the way, pdf icons are useless and possibly redundant. Most browsers have pdf capability, or load pdf plugins in default configuration. 72.43.99.138 (talk) 14:50, 30 October 2016 (UTC) - (ec) I realize that "go here" and "avoid" aren't the intent, but nonetheless that's what they convey. Imagine for a moment that you have not been thinking about journal access for years. You are a high school student who has come to Wikipedia for the first time. How could you possibly interpret a fiery red closed lock except as no? Ozob (talk) 14:56, 30 October 2016 (UTC)
- Pardon me while I return to a previous point.
- Green/red doesn't say "go here" and "avoid", it says "You can read this one for free" and "You can read this one, if you have a subscription to the journal, or are willing to pay". The reader decides if they are willing to pay or not. And if they decide they don't want to pay, that is their decision. "Here's a link, but we're not going to tell you if you can read it or not" sends the reader on a wild goose chase. Worse, if they click on DOIs a few times and they happen to be taken to paywalled sources everytime, they may conclude DOIs are always paywalled and will just stop bothering clicking on DOIs in general. Headbomb {talk / contribs / physics / books} 14:41, 30 October 2016 (UTC)
- 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
- Do you also consider that adding PDF icons after external links ending in
- 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)
- 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)
- 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)
- 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)
- 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)
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). Template:Fr icon
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:
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
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 {{Section link}}: required section parameter(s) missing] 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):
- It is confusing to phrase it as whether or not to "autolink". As the example shows, the URL implied by an identifier is always automatically generated and attached to the identifier. The question is the same URL should also be attached to the title if
|url=
is not set.
- The proposal says this is only about default behaviour and that linking the title could be suppressed manually, but this is not possible with anything that has been proposed so far. Are you proposing an additional parameter to control this?
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)
- Extra parameters are part of the editing interface, not the implementation, and ought to be mentioned. To return to the lack of clarity, it might help if you replaced each "autolink" with "autolink title". (Adding bullets to the examples woudl also make them clearer.) Kanguole 01:37, 31 October 2016 (UTC)
DOI behavior
An earlier discussion (which I found here) pointed out that DOIs do not correspond to a single URL and hence do not have a well-defined access policy. According to the DOI handbook, a DOI may resolve to multiple URLs. For example, a DOI could resolve to an open access repository in some countries (perhaps due to legal requirements in those countries) and to a closed access repository elsewhere.
Representing this kind of indeterminacy with a single icon is impossible. I am not even sure how easy it is to recognize that such indeterminacy is present. The present proposals seem intended to cover DOIs, but what is supposed to be done about such situations? Ozob (talk) 00:18, 31 October 2016 (UTC)
- No doi has ever been shown to resolve to two different levels of access pages. Do you have a real example of such a case? Headbomb {talk / contribs / physics / books} 00:24, 31 October 2016 (UTC)
- No. It's a theoretical concern. If others are willing to attest that this does not happen in practice then I would be satisfied. Ozob (talk) 02:31, 31 October 2016 (UTC)
- I have never witnessed that in the wild. − Pintoch (talk) 09:39, 31 October 2016 (UTC)
- Wonderful! So this is not something to worry about. Ozob (talk) 00:15, 2 November 2016 (UTC)
- Doesn't it happen all the time? Researcher publishes journal article that ends up behind publisher's paywall. Journal policy allows author to publish article on website author controls, so author posts free copy. Same document, two URLs, different access. Government employee pens article on government's dime, so the article is public domain. Journal publishes article but keeps it behind publisher's paywall. Anybody can republish the article. Same document, arbitrary number of URLs, different access. Bell Telephone Labs researcher pens article, submits to Bell System Technical Journal and to IEEE rag (which knows it will be published in BSTJ); same text exists in two places; for a time, Lucent made BSTJ open access, same content had free access and available behind IEEE paywall. Nobel Laureate Irving Langmuir publishes his work in the General Electric Journal and in the IEEE during 1914; it's public domain now; Google digitizes and publishes the GE Journal online for free, but PD IEEE article stays behind pay wall. Glrx (talk) 21:27, 5 November 2016 (UTC)
- All this is true, but also not pertinent to these RFCs. If I may, what you are describing applies more to the function of the citing contributor. It is up to her/him to find the most accessible source for the material that supports the related claim in wikitext. Readers don't need more than one link. The need one link, or one class of links, (the least onerous) that will help them verify the related claims in the article. Do the present proposals make this task easier? Imo, this also implies that free links should be the expected norm in a freely accessible encyclopedia; any access requirements need be only signaled once if only a single such link or a single such class of links is present. This encyclopedia is supposedly freely editable; if the state of access changes, interested editors can make changes. But that aspect is also not pertinent to these RFCs. 72.43.99.138 (talk) 15:04, 6 November 2016 (UTC)
Scholarly versus popular
Open access has since the inception of the concept in 2002 referred to access to scholarly publications in academic journals. The proposed system above is designed to flag perhaps all citations to academic journals in Wikipedia. The discussion above is framed to invite comment from contributors who use academic citations.
If this system gets adopted in Wikipedia, then soon enough, someone is going to raise the issue of whether the same locks could be used on citations to popular sources. For example, someone might want to know if links to subscription newspapers or magazines are free to read or paywalled. Is there anyone here who is willing to speculate how this likely potential use could play out?
Would people here who support this icon's use for academic content also support its use for popular content? Would anyone here oppose that use, and the application of the "open access" concept to non-scholarly works?
If this concept is something that might be used by people who use any citation, then perhaps all sorts of people should comment on this proposal. If this proposal is something that would restrict non-academic use, then again, perhaps all sorts of people should be invited to comment. I am thinking about what I might say to people who do not use academic citations to explain the extent to which this discussion might be relevant to them. Blue Rasberry (talk) 17:01, 1 November 2016 (UTC)
- For 'popular media', the locks would be used pretty much the same way. For example, for a source with subscription required, we'd have something like
- Smith, J. (2010). "Title of article". Time Magazine: 47. Retrieved 2016-11-01.
- This would replace the current (via
|subscription=yes
)
- Smith, J. (2010). "Title of article". Time Magazine: 47. Retrieved 2016-11-01.
{{cite journal}}
: Unknown parameter |subscription=
ignored (|url-access=
suggested) (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)
- Smith, J. (2010). "Title of article". Time Magazine: 47. Retrieved 2016-11-01.
![Closed access icon](//upload.wikimedia.org/wikipedia/commons/thumb/0/0e/Closed_Access_logo_transparent.svg/9px-Closed_Access_logo_transparent.svg.png)
- 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).
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Draft Namespace Redirects
![](//upload.wikimedia.org/wikipedia/commons/thumb/e/e7/Dialog-information_on.svg/40px-Dialog-information_on.svg.png)
![](//upload.wikimedia.org/wikipedia/commons/thumb/3/39/Internet-group-chat.svg/48px-Internet-group-chat.svg.png)
Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page has been added to the following list:
When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.
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
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).
- 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
- 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)
- Oppose - redirects don't need to be deleted unless there's some pressing need to delete them, like they're misleading, implausibly incorrect, or a BLP violation, as examples. Leaving redirects from page moves in order to aid navigation is one of the primary uses of redirects. Leaving a redirect from a draft article when it's moved to article space is a useful message to the draft's creator that it's been accepted to article space (instead of deleted, as they might otherwise reasonably assume when they load their draft and instead get the "this page has been deleted" message), and a useful message as well to other editors who might come to create a draft on that subject that the article already exists. In the vast majority of cases the draft creator can probably then request G6 or G7 deletion if they so desire. And, of course, redirects are cheap and there's no pressing need to "clean up" draft space. Ivanvector (Talk/Edits) 13:53, 3 November 2016 (UTC)
- Oppose. There are a variety to reasons to keep the redirects. Offsite bookmarks, editors' memories of where a page was, a pointer for a newcomer intending to draft to tell them that the article already exists. The redirect is particularly important if the mainspace title doesn't exactly match the drafting title. For the rest, they may be "unnecessary", but "unnecessary" is a very very low test, far below problematic. Wanting to delete them wholesale generates considerable collateral costs. For each one, an investigation is required to determine whether one of the variety of reasons applies. This is, immediately and obviously, textbook busywork. This means the proposal is for a net negative benefit to the project. No, only delete the redirects if you can articulate a reason to do so. --SmokeyJoe (talk) 21:20, 3 November 2016 (UTC)
- "They cause unwanted links"? Special:WhatLinksHere sorts the links by namespace, and you can select namespaces, so there is no issue with links from draftspace cluttering your investigations of links, and, it is no different from user and the many talk namespaces that may freely and excessively link to articles. Also, they included wanted links to articles. When working to expand, or consider the possibilities of expansion, one useful thing to do is to examine all incoming links. Each is presumable there for a reason, and helps paint a picture of a history of editor interest in the article. Wholesale deletion of redirects is needlessly destructive of this resource.
- CSD#G7 may be used by sole authors. Non-admins may be forced to create redirects on page moving, but they may have them immediately deleted per CSD#G7. Perhaps some would like to make the option more obvious? I oppose CSD#G6 being used on anything with a non-trivial version history, or on redirects created by others' page moves from either draftspace or userspace to mainspace. Within draftspace, using G6 to delete redirects created from moving a page from a typo-error title would be fine. --SmokeyJoe (talk) 22:56, 3 November 2016 (UTC)
- Oppose. Pointless exercise. Agathoclea (talk) 21:54, 3 November 2016 (UTC)
- Oppose as they are useful and do no harm. Redirects of this nature streamline the process for those returning to the former draft, by taking them directly to where the content now resides, as opposed to adding the extra step of them having to click there through the deletion log.— Godsy (TALKCONT) 05:11, 4 November 2016 (UTC)
- Oppose per 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)
- Oppose for reasons above plus WP:DWAP. ⁓ Hello71 12:23, 4 November 2016 (UTC)
- Oppose per above. FWIW I normally create articles in my own userspace before moving them to mainspace when I think they are done, and the redirects left behind are a reminder that they started out there. I have never thought of deleting them, there is no reason to do so, and the same applies to draftspace redirects.--JohnBlackburnewordsdeeds 12:40, 4 November 2016 (UTC)
- Oppose per my comments in the discussion section below. Mz7 (talk) 20:06, 4 November 2016 (UTC)
- 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)
- 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)
- Oppose - No apparent benefit to deleting redirects into mainspace, and obvious drawback. Draft creator or editors of draft may want to look at it and may be satisfied that it has been approved (or may even want to AFD it). Robert McClenon (talk) 00:02, 12 November 2016 (UTC)
- Oppose There is no cost, and preserving the obvious redirect history is a benefit. Steven Walling • talk 19:33, 16 November 2016 (UTC)
- 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).
- Oppose Deleting a redirect without reason is pointless. Much easier just to point out the problems with individual redirects.--NetworkOP (talk) 22:29, 21 November 2016 (UTC)
- Oppose. As an AfC reviewer, I think the assertion that "most" editors know when their draft is moved to mainspace is underestimating how unintuitive Mediawiki can be for new users. I'd expect a flood of confused new editors at WP:AFC/H if this was implemented. Besides, as others have pointed out, redirects are cheap and no pressing need to delete these has been articulated. Joe Roe (talk) 13:04, 23 November 2016 (UTC)
- Oppose These things exist for a reason. Being cross-space doesn't change that, and moving them to delete-space only adds to the logs. Unscintillating (talk) 02:04, 28 November 2016 (UTC)
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).
- Oppose there simply is no reason for wholesale deletion at all per the consensus at "version 1" of this proposal, waiting six months (or even six years) makes no difference. Redirects from draft to mainspace do absolutely no harm at all, they are useful for the reasons already explained by others. They are not comparable to links from mainspace to other spaces. Roger (Dodger67) (talk) 16:56, 23 November 2016 (UTC)
- Oppose These things exist for a reason. Being cross-space doesn't change that, and moving them to delete-space only adds to the logs. Unscintillating (talk) 02:06, 28 November 2016 (UTC)
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).
- Hi Gluons12 non-logged user can create articles in draft and often do (for instance on the current recently created list is National Pro Patria Party) KylieTastic (talk)
- 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)
RfC: AWB bot ref reordering
![](//upload.wikimedia.org/wikipedia/commons/thumb/e/e7/Dialog-information_on.svg/40px-Dialog-information_on.svg.png)
![](//upload.wikimedia.org/wikipedia/commons/thumb/3/39/Internet-group-chat.svg/48px-Internet-group-chat.svg.png)
Please consider joining the feedback request service.
An editor has requested comments from other editors for this discussion. This page has been added to the following lists:
When discussion has ended, remove this tag and it will be removed from the lists. If this page is on additional lists, they will be noted below.
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)
- "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)
- This isn't the case at all; in my field (biochemistry/bioinformatics) I can't find any journals that would allow multiple numbered references in non-sequential order. Here's the American Chemical Society guide, for example: [2]
When citing more than one reference at one place by number... list the numbers in ascending order
. Opabinia regalis (talk) 20:03, 25 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)
- Big no. In a string of multiple refs, the most relative and directly supporting should be first, even if that makes the ref numbers not be strictly increasing. This is particularly true of the first ref because in practice I often have situations where one source cites 90% of the material in a statement and the remaining refs are much less important to the overall verifiability. I don't want the highly import ref to be shuffled among those less important refs. I want it to be first. Jason Quinn (talk) 00:28, 24 November 2016 (UTC)
- No - proposal is ill-prepared as to describing the mechanism, what necessitates it, and what the other consequences might be. It seems an frivolous automation that would be restricting possible editor wishes that might cause problems. Just because one can isn't a reason to do it, it's a reason things go wrong. Markbassett (talk) 20:58, 24 November 2016 (UTC)
- No. A substantial quantity of unordered refs is intentionally "disorderly", and the vast majority of those doesn't use {{R}}. In addition, there is also likely just as large a quantity of currently ordered refs, whose order is meaningful but not protected with {{R}}, because it has not yet occured to the article editors that a future edit can mix up ref numbers. All in all, this is a job that should be left to humans who leave human edit summaries, and not to AWB users, whose edits I never check on the watchlist, because I assume that the app knows what it's doing. Daß Wölf 00:40, 25 November 2016 (UTC)
- No If an editor spends significant time fixing issues in a particular article, they might reorder or otherwise rearrange some refs as part of that work—good! However, mindless reordering by bot is not helpful because someone who actually understood the topic and who actually read the references took a decision about how the references should be arranged. Many inconsistencies are tolerated (WP:ENGVAR and WP:CITEVAR) and always displaying numbers in ascending order is trivia. Johnuniq (talk) 02:22, 25 November 2016 (UTC)
- Well said! Beyond My Ken (talk) 17:31, 25 November 2016 (UTC)
- Alternatively, the editor who has spent significant time fixing an article was concentrating on the content and didn't try to redistribute the references so they'd come out in some allegedly significant but in practice inscrutable non-sequential order, because they knew that a bot would eventually stop by to fix it ;) Opabinia regalis (talk) 20:03, 25 November 2016 (UTC)
- I frequently modify my notes so that the bot that eventually comes by won't break them by trying to merge them using named-refs. ~ J. Johnson (JJ) (talk) 22:58, 25 November 2016 (UTC)
- That is probably the case quite often, Opabinia regalis, but not always, and it isn't fair to assume it. We're talking about an automated assumption here. If I read "Smith said 'the sky is green' and Jones agreed.[m][n]", then I'd expect m to refer to the Smith reference and n to refer to the Jones. If Jones has been cited before Smith earlier in the article, then numerical ordering won't give this. The numbers reflect the order in which sources were introduced in the article, not the order in which they apply to a specific sentence. What is done in the journals in one specific field is irrelevant here, as is any opinion about what is "better"; the latter depends on your mileage. All we're talking about here is the extent to which automation should automate one way of going about it. --Stfg (talk) 13:50, 26 November 2016 (UTC)
- Obviously, the correct way to write that in a context where someone might come along and edit the text is "Smith said 'the sky is green'[m] and Jones agreed.[n]" Less obviously, but importantly, if you really want your out-of-order references to communicate anything to the reader other than "this article was sloppily edited", then you should be all for automated reordering. Since most instances of non-sequential references are unintentional and meaningless, removing them makes your intentional ones more likely to stand out. The simple solution to this problem is for people who think they're communicating something significant with their reference order choice to annotate this by using one of the already-available workarounds. Opabinia regalis (talk) 04:44, 27 November 2016 (UTC)
- I used to be in favour of mid-sentence citations for precisely that reason, but turned against them after seeing an experienced FAC reviewer give them very grudging acceptance. I'll reconsider that. For the rest, if language like "obviously", "if you really want ...", "sloppily" comes into it, I fear we'll just have to agree to disagree. Language like that does little to advance a rationale; more, perhaps, to express an attitude to those who disagree with you, but that's not my problem. This is only a matter of taste after all. I remain unconvinced. --Stfg (talk) 19:17, 27 November 2016 (UTC)
- The preferences of FAC reviewers, experienced or otherwise, is very much the tail wagging the dog; the huge majority of articles where this is done are not FA candidates. I don't mean anything by the language - "sloppily" was in reference to my previous vote, where I was talking about myself - but to be honest, I do think it's obvious that people who want to use non-sequential references to signal meaning are voting against their own interests here. Opabinia regalis (talk) 22:55, 28 November 2016 (UTC)
- Thanks. Fair point about FAC, but the reviewer did offer reasons. The main one was the appearance of fussiness. From my own experience, general readers can find those little superscripted numbers burdensome and may not realise that they don't have to check out every single one. There is a significant difference between an encyclopedia and a professional or academic journal here.
A thought that crosses my mind is that professionalism (if that is what it is) in the presentation of citations really only matters at the top quality end of the encyclopedia, where one might hope that an article would have several watchers interested in maintaining quality and would take care over this. (Or am I being naively optimistic in that? :)) At lesser quality levels, the order of citation numbers is rather the bicycle shed compared to the nuclear power station of journalistic writing, gushing fandom, misreading of sources, self-promotion, and all the other horrors we all see every day. So at one end, I suspect, this automated action may be a nuisance; elsewhere, it's almost certainly an irrelevance.
One point that I do think matters: I'm here because articles in which I took care over this sort of thing, and that I'm watching, suddenly got hit by this automation. Yes, I now know there are workarounds, but I didn't know them then and they are not widely advertised. The automation is implementing a preference of certain editors, not something the MOS requires. I am unhappy that that was done without consensus to do it. That probably can't be undone now, but imho it shouldn't continue until the real discussion has been held: not about what automation is allowed to do, but about what the MOS should say about the presentation of citations. --Stfg (talk) 10:56, 29 November 2016 (UTC)
- Perhaps people who think cosmetic appearance should be more important than any other kind of significance could be persuaded to not use named-refs. That is the simplest solution. ~ J. Johnson (JJ) (talk) 22:35, 27 November 2016 (UTC)
- No For reasons given by many others, this is placing 'tidiness' over any editorial judgement (best source, most relevant source, most comprehensive source, before secondary or supporting sources that may merely confirm some detail). A tool capable of ordering, in the hands of an editor familiar with content, might be useful for those who wish to use it, but having bots going around re-ordering with no notion of why the refs are ordered as they are, is not a net gain IMO. OK, many articles are reffed chaotically at present, not only 'un-numerically', but because of editors putting new refs at the end of the list, or conversely in 'pole position', rather than as a result of editorial judgement, but having refs look neat, but remain 'content/relevance chaotic' is not an improvement. The practical matter of checking a footnote in a printed text is completely different from clicking a ref-number. ps Summoned by bot Pincrete (talk) 18:36, 26 November 2016 (UTC)
Notes
- ^ There can only be a visible difference if refs (or notes) are named and reused.
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:
- How many refs have been reordered by AWB?
- How many were out of order due to the refs renumbering, and how many were placed out of order?
- 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:
- Always
- Except where there is clear priority between references
- 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).
- Statistics I have some preliminary numbers. Approximately 100 pages every day have the references put out of order, approximately 100 pages every day have order restored. I have a sample of both over an elven day period in late July.
- Needed Analysis of how the new out-of-order refs arise (i.e., accidentally by editing other parts of the article, deliberately by re-arranging the refs, or can't tell, by adding a ref.)
- All the best: Rich Farmbrough, 19:06, 23 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'm pinging the other editors who were discussing it at CITE before Mandruss opened this: @Bcharles, CBM, WhatamIdoing, GoingBatty, B, Johnuniq, Magioladitis, Izno, Kmhkmh, Headbomb, Blue Square Thing, Arthur Rubin, Peter coxhead, Stfg, Mike Christie, and Pppery: SarahSV (talk) 00:40, 20 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)
- Pinging others who have discussed this: @Beyond My Ken, Ryan Norton, Beetstra, and Afterbrunel: SarahSV (talk) 13:10, 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)
- 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[3], 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)
- @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)
- The first time you tried to walk it probably didn't work so well, either. I agree that success in these matters is difficult, rare, and even fleeting. But I hope that eventually we'll get the hang of it, and the rock will crack. ~ J. Johnson (JJ) (talk) 02:29, 24 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)
- If the MediaWiki software were enhanced to create a reference list automatically out of the named references (or even automatically grouping identical un-named references), as I suggested, then editors would no longer need to do it manually. isaacl (talk) 02:05, 24 November 2016 (UTC)
- You are probably thinking that named-refs are your only option, but that is incorrect. What you really want is probably 1) to cite ("re-use") your sources multiple times, but 2) without replicating the "reference" (the end-note containing the full citation). You do not need named-refs to do this. Another option (and vastly superior, I think) is short citations (or "short cites"). The full citations get collected on any convenient area (or not), where they can be put in any order you want; in your notes (in the
<ref>...</ref>
tags) are the short cites (like "Smith, 2004", as created by the {{sfn}} or {{harv}} templates) which link to the full citations. For an example see Hockey stick controversy#Notes. (The big red error messages are where someone hasn't figured out how to use named-refs properly.)
- Isaacl: we already have bots "
automatically grouping [merging] identical un-named references
." That only creates more problems. ~ J. Johnson (JJ) (talk) 02:34, 24 November 2016 (UTC)
- All I'm saying is the software could automatically gather up the citations and produce appropriate end notes in a manner such that any consecutive associated superscripts will be in increasing order. In this way, editors will still retain the ability to control the order of the hyperlinks in the superscripts. isaacl (talk) 03:59, 24 November 2016 (UTC)
- And what I am saying is that we already have that. Where it breaks is when named-refs are used. (Don't use named-refs, and this entire RfC is moot.) But this is perhaps unclear to you because you are not entirely clear on the difference, and the significance of the difference, between notes and citations, and their use. ~ J. Johnson (JJ) (talk) 19:39, 24 November 2016 (UTC)
- My apologies for failing to communicate clearly. I understand there are ways for editors to manually create citation lists and refer to them in end notes. I think that it would be nice if the software could take of the grunt work and automatically create a citation list. With this approach, it would be irrelevant if a named reference were used to refer to a citation. isaacl (talk) 03:12, 25 November 2016 (UTC)
- I wish I had time to write some code that would remove named-refs, and even extract all full citations from the notes and put them into a list. Until then, the fix to the problems created by use of named-refs is not more s/w functionality to paper over the problems of the last fix, but to just not use named-refs to start with. As to the "grunt work" of creating citations (manually?), it is not any more work to put them in a special section than into <ref> tags. (Unless VE adamantly insists on doing things its way.) Use of named-refs provides no savings of time or effort over the use of short cites; the only difficulty is that having already learned how to use a poor method of handing citations editors balk at investing any effort in learning a better method. ~ J. Johnson (JJ) (talk) 22:50, 25 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 think what you and Masem say makes sense. My understanding from the wording of WP:CITEFOOT and other discussions on this matter, is that the preference has been to reduce as much as possible the number of times that a cite marker is used in a sentence because it inhibits reading flow. We are encouraged to remove cite markers from the lead (even though the lead is the most read part of an article) because any information in there will be cited somewhere in the body of the article. I personally like having useful access to the sources. I dislike it when the double citation method is used when the cite marker directs me to a short citation rather than the full one, and then I have to go to the book details separately which don't tell me the page number, and now I can't go back automatically to the short cite with the page number or to my place in the article without rolling back my browser. I don't know why folks do that - it makes work for me when checking details, and simply wastes time. Anyway. Rant over. Perhaps what is needed is clearer wording in WP:CITEFOOT so we are not having discussions over its interpretation. I particularly like your Aethelwulf's kingdom example, and something like that in WP:CITEFOOT would clear up any potential confusion. That said, I still don't see why we should have a bot changing the order of the cite markers simply because they use numbers - if they used symbols we wouldn't even be having this discussion. Well, they do use symbols, it's just that the symbols are numbers which can be arranged in a sequence. SilkTork ✔Tea time 00:14, 26 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]
- All the best: Rich Farmbrough, 21:02, 21 November 2016 (UTC).
- It's trickier than that. You get sentences like:
- Where the first reference is about the river, and the second merely supplies his first name. Hawkeye7 (talk) 11:25, 22 November 2016 (UTC)
- ^ Eilert Ekwall (1928). English River Names. OUP. p. 197-198.
- ^ Kitchen, Frank (2008) [2004]. "Norden, John (c.1547–1625)". Oxford Dictionary of National Biography (online ed.). Oxford University Press. Retrieved 28 October 2011.
- And again if that is sufficiently important, it can be set up accordingly.
- Norden (first name John[1]) says....
- All the best: Rich Farmbrough, 00:05, 24 November 2016 (UTC).
UI design flaw with watchlist and alert list
I unwatched Lomography and was told: The page "Lomography" has been removed from your watchlist. I then dropped down my alerts list (the bell icon) and wanted to mark the topmost item as read (by clicking the blue ball, which does this). I could not click the ball because it was still covered by the unwatch message. I also could not find any way to clear/remove the unwatch message without reloading the page: clicking it, or outside it, or pressing Esc, does nothing. Equinox ◑ 07:14, 26 November 2016 (UTC)